4 lessons learned from deploying Microsoft Defender with Intune

These come from a sizable deployment of 70 000+ endpoints, mostly physical Windows 10 devices, but not only, we completed earlier this year in an hybrid environment (Active Directory, System Center Configuration Manager, Azure Active Directory and Intune) which roughly took ~7 months from start to finish, engineering included. Some things have changed a little bit since then but most of what I am going to cover still applies.

A little bit of context : we decided to change our then current endpoint security solution for various reasons, the most important of which were:

• Move away from an internal solution, and switch to a Cloud-based solution from Microsoft for better integration, less operational burden, etc.
• Improve our EDR (Endpoint Detection & Response) capabilities since the focus these days is no more on signature-based "traditional" antivirus.
• Get better visibility, insights and control over our endpoints no matter where they are (Internal network, VPN or Internet).
• Financial gains and loss of trust in our previous security provider.

We had several options to choose from, for the deployment itself, but settled on an hybrid one simply because even if going full Cloud for managing our endpoints has been our strategic direction for quite some time now, we were just not ready yet ! So this will be of particular interest to organisations like ours that simply cannot go straight to AAD / Intune / Defender.

I do not intend to drown you under technical details or tell you ours is the only way, but rather give you hints and directions on a number of topics based on real-world experience.

Lesson #1 - Get your devices properly Hybrid Azure AD-Joined and in turn Intune enrolled

This is essentially your first step, and it took us quite an inordinate amount of time to hunt for, and remediate, faulty machines : simply broken, sitting on closed networks, old proxy settings lingering, etc. While there are several ways of achieving this, we ended up managing this through a combination of Group Policy Objects:

• We triggered hybrid joining through GPO (HAADJ and Azure AD Primary Refresh Token).
• We triggered Intune enrollment through GPO (user credentials) as well.
• We doubled this with an SCCM sync to Intune (special collection) as a catchall and ALSO to cover machines where the logged on user has no valid Intune license.

Because, yes, Intune otherwise requires a user license but does not when machines get there that way. In case you are wondering, this is not cheating it is just that the licenses for SCCM cover devices managed either on-premises or in the Cloud.

Network connectivity is critical, make sure you have direct access to everything and do not forget that some things simply cannot be inspected. A word of caution, making all of this work through proxies is likely going to be a nightmare (we did not do it but have a pretty good idea of what it means as that was our setup until not so long ago). Moreover, ensure the Internet-related features of your SCCM infra, including Cloud Attach are enabled and properly configured. Refer to this link for more info.

Note 1: HAADJoining machines through GPO will throw an error every time you run a gpupdate or GPO refresh on their own. This is well known and documented in this troubleshooting article.
Note 2: overall a delicate process that sometimes goes wrong (HAADJ and/or Intune enrollment), so be prepared to hone your troubleshooting skills accordingly. Generally speaking it is usually faster to clean stuff locally (dsregcmd, scheduled tasks, Intune ID in registry, etc.), have machines removed from AAD, and then start again from scratch, double checking everything, than trying to pinpoint the exact step that failed originally.

Lesson #2 - Of co-management, Intune and GPO

If, like us, you are going to use Intune to manage Defender, or anything else really that is device-related, while still relying on your on-prem SCCM Infra, be sure to properly configure co-management in SCCM so that the Intune settings will actually apply.

That is not the only thing to pay attention to though, you must make sure that whatever you do, a given setting only gets managed in a SINGLE location between Active Directory (GPO), Intune, and SCCM; that is a cardinal rule. Clean up your environment and pick one side for each setting regardless of how the tools are configured to "win" over each other.

Any other approach is bound to fail, in particular do not overlay different values for a given setting through different tools, the results are unpredictable. We learned this the hard way through a series of major incidents (bad luck mostly) even though we did recognize and adhere to these principles early on in our project.

Another related matter is that Intune is SLOW, so double check assignment and exclusion groups when you do something, because correcting a mistake is much more cumbersome than with GPO or SCCM.

In particular, and that helped us a lot, do not hesitate to use a transverse approach where you push stuff through SCCM (including using a Cloud Management Gateway to extend your reach to the Internet) or GPO. Said stuff will often end up being PowerShell scripts to perform local cleanup by the way...

Note: Intune Sync runs only every 8 hours and is not configurable yet. Some changes are applied rather immediately, others... not so much. So, keep in mind whenever you are doing something, that you will have to force local syncs and check diagnostics logs to find out if / when something finally got through.

Lesson #3 - Defender firewall, do not rely on Intune (yet)

Good luck managing that thing through Intune, we ultimately gave up and did it through GPO. Things have improved it seems, but I do not think it is actually viable to go the Intune route despite what Microsoft says, in particular, you get no nice wizard to work with or clear view of your rules once in Intune.

Our recommendation is to stick to GPO to configure Defender firewall. Fortunately it still is a completely separate product that uses the "Defender" umbrella naming rather than a tightly integrated piece of software which makes this separate management easier to work with. That said, you can now have Defender upload the firewall logs into the Defender console (a nice feature), see here for the announcement and there for more info.

Also very important, is to plan your Firewall rules early on in the project, and test them beforehand, especially if you are using the opportunity to cleanup and or strengthen existing policies ;-). This work can be started well in advance, and completely uncoupled from other activities as there is no real adherence to the rest of Defender, as explained above.

Regarding firewall settings, one quick tip : configure logging by splitting the logs for each context (Public, Private, Domain), specifying a different file for each, increasing log size, and only logging drops. This will make your troubleshooting considerably easier.

Note: the built-in Windows firewall, like other security features of Windows (AppLocker for example) exists independently of the core Defender features, bringing it under the Defender "umbrella" brand name is mostly a marketing trick which explains the poor level of integration with other parts of the solution.

Lesson #4 - Know your environment, especially before moving forward with Attack Surface Reduction rules and Controlled Folder Access in Defender

First, let me share a relevant link to an interesting blog post from Palantir about their Defender deployment and ASR in particular. We recommend sharing this with your Security team for, let's say, increased awareness of what lies ahead. :-)

ASR and CFA are the Defender features that will have the most impact on your apps and ultimately the user experience. Make sure you test A LOT, even more so if your environment is heavily Office-oriented or has many Line of Business apps.

As a general rule, prepare audit policies for troubleshooting and exception policies for handling small groups of problematic users while you steam ahead with the general deployment. This is true for ASR but also for any other significant Defender feature : firewall, AppLocker, etc.

We succeeded in getting most of our user base on the ASR standard policy but nevertheless needed one major ASR exception policy to address the most problematic settings (Office code related ones) for a subset of our users. Try identifying potentially problematic groups in advance, like for example, the Finance guys, and work with them to understand their setup/work environment.

The most diverse and representative your initial testers will be, the better. Drop the site/location-based approach for that initial phase, as you really want maximum functional coverage for tuning your policies.

Ultimately, ensuring we could work in a short loop with our Security team, to validate any change in global approach, define exception policies, discuss specific cases, or simply let them deal with the craziest things we uncovered, proved instrumental in our ability to move at a brisk pace.

Final words

Tread cautiously.

That is how I would sum this up. We cannot stress this enough, whatever Security solution you had before, switching to the Intune / Defender combo is no walk in the park, and will require careful consideration, planning and engineering.

Intune, most notably, is not to be taken lightly, as the product is NOT yet at the level of SCCM or AD or even competing Mobile Device Management solutions. You WILL face issues, if only because the product is surprisingly lacking features, constantly evolving, with documentation and experience still being scarce on the market. One example: nested groups was not a thing during our deployment, and forced us to design around this limitation "flattening up" an entire OU-like structure we relied on for scoping and reporting with our previous product...

Special Thanks to the core project Team : Laurine Rabusson, Olivier Badeau and Fabien Anglard.