For those of you not familiar with Windows Defender ATP, it is Microsoft's cloud endpoint security and monitoring solution that enables detailed information to be collected at the individual devices. This, in turn, provides near real-time insights into vulnerabilities and active attacks on compromised devices in the environment, and enables a degree of automated response to mitigate those attacks.
I recently deployed Defender ATP in a customer environment and ran into an interesting challenge trying to onboard Windows 10 devices. After the service was setup, testing the service by using the Local Script onboard worked fine and my test device was reporting back to ATP. As I moved to start to onboard additional devices en masse, I noticed that my devices were not registering at all.
For some background:
Endpoints all Windows 10 1909
ConfigMan not in use
All devices already Hybrid AAD Joined (implies all computer objects synced from AD)
All devices already enrolled with Intune
The approach was to leverage Intune to enable all the other devices to onboard into ATP. Referencing the Microsoft documentation identified from the ATP portal itself, for Intune it takes you to the Onboard Windows 10 Machines Using Mobile Device Management Tools page. Going here really just gives you another link to refer to the Intune document Enforce Compliance for Microsoft Defender ATP with Conditional Access in Intune, whose title is somewhat misleading given that we were looking for information on how to onboard devices in ATP through Intune.
, whose title is somewhat misleading given that we were looking for information on how to onboard devices. But, nonetheless, this link does contain details on using a specific Intune Device Configuration profile to enable Defender ATP.
The Device Configuration profile in Intune has a dedicated profile type for Windows 10 named "Microsoft Defender ATP (Windows 10 Desktop)" that provides you the configuration elements for telemetry and data uploads. I created a profile using this type and assigned it to a device group for controlled testing.
Given that this was in Intune, it's not an immediate application, so I let the profile sit for about 24 hours. Technically, this should have only taken about 8 hours (less for my test devices I recently deployed and enrolled for this testing specifically). Device policy refresh for Intune can be found at the Microsoft doc here.
To my surprise the next day, when checking the configuration profile for my policy, I only had 3 computers showing as successful, but 0 for pending, errors, etc. This gave the impression that only 3 computers processed the policy despite my device group containing about 15 devices.
These three devices represented the first computer I onboarded using the local configuration script when I first deployed ATP. The other two were test devices that I had just deployed specifically for my ATP testing.
After a lot of "Googling" I came up with no leads on why I was experiencing this issue. From what I could find, the policy was configured correctly and assigned correctly, and all the other devices in the group were successfully syncing all other policies from Intune. When looking at the devices themselves, the MDMReport and logs (see here) didn't even indicate that they were trying to process the policy at all.
I reached out to several other resources that deal more with Intune and Windows management than I do received many pointers. These included using the new Microsoft Endpoint Manager (https://devicemanagement.microsoft.com) portal to create the profile instead of Intune as well as using the Microsoft Defender ATP Baseline as a means to trigger the devices to process the new profiles. Neither had any impact.
As I started to get deep in the woods for anything that could be an issue, I noticed that my initial device (using the local configuration script) was in a standard OU that had several policies applied like all the other standard test devices but my two dedicated test computers were in an OU without most of the GPOs applied. Given that the first test device was configured using the script, I assumed that maybe a GPO could be causing a problem.
Sure enough, after gradually adding GPOs to the OU with dedicated test devices, I finally discovered a policy that was setting the Defender Firewall configurations that was somehow stopping the device from onboarding to ATP. Looking at the custom firewall rules set by GPO, there were none that should have any impact on the computer to talk to Intune, and all the devices were able to sync all other policies from Intune. But once removing the firewall settings from GPO, all my other devices successfully onboarded to ATP.
My primary focus is not on systems management, so I can only assume based on my observation.
My original assumption would be that when a Device Configuration profile (or any profile for that matter) is assigned within Intune to a group, Intune would process all members of that group and report back an Error, Not Applicable or Conflict status if it could not properly push it down to the device.
But what I saw is that Intune acts as if it is blind to all the devices the profile is assigned to until the device can sync the profile and report back if it either was successful or encountered an error. To a degree, this makes sense that Intune needs the device to report back the status, but it can result in Intune appearing to not even think devices are in scope of the policy.