Now we come to the fourth and final post in this series, enrolling a Windows 10 virtual machine with Intune so that we can see it’s status start reporting through to Microsoft Defender Advanced Threat Protection. For these steps I’ll be using the Azure based Windows 10 VM I created in the last post.
After signing in to the VM, head in to Settings, Accounts, Access work or school and then Enroll only in device management.
We could have gone through an AAD Join instead, which would be a preferred approach in many cases, but let’s just assume that this is a BYOD/personal device scenario. It will take a few seconds for the enrollment to take place after credentials have been suppplied.
Next up, verify that you have enrolled in the right tenant by verifying the credentials. If you don’t juggle several tenants this probably isn’t too much of a requirement, but I know I’m not the only person who juggles more test tenants than is normal.
Now we can either be patient, and sit back and wait until we see the VM start reporting, or we can start poking around to see what’s happening. The first place you can check for progress is within Endpoint Manager. Here you can see that the Windows 10 VM has enrolled, but that any of the servers I added previously don’t show here, as they aren’t managed by Intune.
If we go back to our Windows 10 VM, there are some easy indicators to monitor as to the MDATP status, and Task Manager is an easy way. At first you won’t see any Defender ATP related processes.
Within a short time period you should see some Windows Defender Advanced Threat Protection processes appear, which is a sign that we are on the right track. Yes, it still says Windows Defender, not Microsoft Defender, but I can easily think of a few reasons why changing it could be problematic.
Because you’ve probably most likely still got Endpoint Manager open, let’s take a look at Endpoint security, Microsoft Defender ATP to see that we now have a device checking in. Again, remember that we won’t see any of the servers we enrolled through Azure Security Center (ASC) here, because their data collection is via Log Analytics and the Microsoft Monitoring Agent (MMA).
If we now jump over to Microsoft Defender Security Center, we will see that Windows 10 VM listed alongside the ASC enrolled VMs we used to trigger the creation of the MDATP tenant.
If we go back to one of the things I highlighted at the beginning of this series, I mentioned that I used this alternate approach of enabling MDATP via ASC was to try to prevent higher level SKU contamination of our Microsoft 365 Business Premium tenant and cause confusion about what features MDATP alone was providing versus the combination of adding something like a Microsoft 365 Enterprise E5 license would cause. There is a side effect that you can see below in the Add admin centers view – we don’t get to see Microsoft Defender ATP in the list. That’s okay, we already know that it is active and working.
You also won’t see any MDATP licenses available for assignment. I specifically deployed the Windows 10 VM as an Azure VM with ASC Standard so that I would be covered with it’s included MDATP licensing. It also means I get a chance to jump in to ASC to see what’s new and what’s changed since the last time I checked.
That’s it for this post, and is also the end of this series of posts, which was really just focused on getting MDATP into the tenant in an unusual way that hopefully showed you some things in Azure you may not have been aware of. In the next post series, I’ll be covering some of the benefits you see when you add MDATP to your M365B environment, including taking a more traditional approach to adding MDATP via user licensing instead of device based enrolment with ASC.
intunedin.net 