Updated Intune Scripts and a Security Profile for the SMB

Some years ago, Microsoft published a repo on GitHub describing how to use PowerShell to interact with the Microsoft Graph and create/manipulate objects within Intune. This was soon followed by another project, where they published three “Security profiles” as pictured below:

Most of the configurations required to support these deployments were included in a corresponding GitHub repo (which you can find here). This was an excellent resource and has been used by many people around the globe to develop their own flavors and standardized configurations for managing devices in Intune.

About a year ago, Microsoft announced that the original Intune graph samples repo was to be archived, as most of the functions were moving to the newer Microsoft Graph PowerShell SDK. Long story short, we have a new repository now, but so far as I can tell, these other security profiles I mentioned above have not been kept up. Which is too bad.

But, wherever there is disappointment, there is also opportunity!

In the past I had sort of patched together my own version of a security profile that I thought would be a good fit for the small and mid-sized business (SMB). It has evolved over time, but in general I always took my initial direction from the “Enterprise” baseline, and I expanded from there. Today I will share the updated version.

Understanding the format

I wanted to create this as an example, and make it easy for others to take and use or modify however they see fit. You don’t have to use the same policies that I included here, they can just be a reference point, sort of like the original published examples. There were some things I did not like about the “Enterprise” profile that I wanted to fix:

1. Some of the settings do not pertain to SMB environments (e.g., Device Guard/Credential Guard is not licensed/supported in M365 Business Premium)
2. There were too many different parts–you had to download the entire repo basically and maintain several scripts and folders with JSON files, etc.
3. I did however want to maintain some modularity in case folks just want to grab a piece of the pie, and not take the whole thing, so to speak.

In the end, here is how I solved these issues. First, I modified the “Enterprise” policies to look for unapplicable or obsolete settings, and make it more appropriate for an SMB environment. Second, I embedded the JSON describing each policy right into the script, so that you can just grab one thing and run it (similar to how I have done it in the past). Last, I made individual scripts for different policy types. In other words, if you only want to work with Compliance policies, you can just grab that piece and work with it separately.

Each script follows the same format:

1. Connect to Graph
2. Define function(s)
3. Define policies (JSON)
4. Call the function(s) to create the policies

Pretty straightforward.

You can find the updated scripts in my GitHub repo here: Microsoft-365/mggraph-samples · vanvfields/Microsoft-365 (github.com)

More updates underway

There are additional things I would like to flesh out still, and put into the scripts eventually. Some of these items are in flux right now, and some of them may only make their debut in a separate “SMB-Strict” profile which is similar to what Microsoft calls “Specialized” security in the Enterprise. Therefore, I plan to publish some additional scripts/profiles to this repo over the next few months.

What’s included in the SMB profile

For now, I have opted to include the following:

• Compliance policies: Following the “Enterprise” example from Microsoft, I included a policy that will apply a few settings “Immediately” and another with a 24-hour delay (this is because some compliance settings can cause issues if applied immediately). As well, there is a policy related to Defender for Business (a.k.a. Defender for Endpoint in the Enterprise). Run Install-SmbCompliancePolicies.ps1
• App protection policies: These protect corporate data on iOS and Android devices, whether personal or company owned. I always implement this for every customer, as it allows us to selectively wipe corporate data from lost/stolen/departed mobile devices. Run Install-SmbAppProtectionPolicies.ps1
• Device configuration & ADMX profiles: Most of these are, again, lifted and modified directly from Microsoft’s original “Enterprise” configuration. This includes stuff like BitLocker, Antivirus settings, ASR rules, Edge browser settings, and more. I removed a few things that, from my experience at least, didn’t make sense in the SMB on a broad scale. For example, I do not block extensions in Edge, I don’t require USB storage devices to be encrypted by default, and I don’t turn on Credential Guard (since we aren’t licensed for it anyway). That isn’t to say some of these may not be desirable in certain SMB settings or perhaps in a “Strict” profile. If you still want some of those items, modify what I provided here, refer back to Microsoft’s examples, or wait for my next iteration to drop in a few weeks.
  • I also included some extras such as Windows Health Monitoring, Update rings, and more.
  • Run Install-SmbDeviceConfigs.ps1 and Install-SmbAdmxConfigs.ps1
• Settings Catalog Baselines: These are the more “modern” version of Device configuration profiles, and it is what all of the “Intune Security Baselines” are built out of. A lot of people complain about the Security Baselines though because there are so many settings under a single policy, and some of the settings overlap (and even conflict) between the different baselines (e.g. you will find some of the same settings under the OS baseline and the Defender baseline, as well as the Edge baseline, etc.). In my policies, I broke all this apart, and made sure that each setting only appears once, and, once again, removed items that are not as widely applicable or available in the SMB. Run Install-SmbSettingsCatalogBaselines.ps1. NOTE: I recommend using this instead of the “legacy” Device configuration & ADMX profiles described above.
• Conditional Access policies: One of the major benefits to everything moving over to the new Microsoft Graph PowerShell SDK is that we can work with both Intune and Entra all at once. So why not include your favorite CA policies when you deploy your security profiles? Run Install-SmbCondtionalAccessPolicies.ps1
• Install everything: You can just run Install-SmbSecurityProfile.ps1 to import all the policies at once, rather than individually.

As always, none of these policies will be assigned or enabled by default (and there are no assignments for exclusions either, e.g., Emergency access accounts). You would need to do all that on your own. I always recommend using a pilot group before rolling out across an entire organization. Note that you might also have additional configuration to complete (not just importing and assigning these policies). For example, if you want to set up device enrollment options such as restrictions or autopilot, or configure Microsoft Defender EDR for onboarding, etc.

Some of these details I hope to get included in future updates on this concept but for now I would suggest you start by referring to my Best Practices checklists for each respective product.

You might ask: “What about just using the Intune security baselines? Or the Endpoint security profiles?”

Sure, you can use those if you want to. These “SMB” versions are all based on those Enterprise templates anyway, but note that if you deploy both, you may have to modify some settings so as not to end up with conflicts (and check your licensing requirements as well). I personally like to use the Security baselines as a reference point when building and deploying my own policies and profiles. Therefore, I would prefer to use a script to deploy my own Settings Catalog policies that I can break apart into smaller pieces and manage differently than the giant Security Baselines.  At the end of the day, it doesn’t really matter how you choose to set the various bits on your devices (we have a lot of choices now), but to each their own.

Other notes

In case you want to understand a bit of why I picked the policy set that I did for the SMB profile, here is a basic run-down of my thinking.

First, most SMB’s do not buy mobile devices for their users, and pretty much stick to BYOD. I would say BYOD for workstations is also a thing, sometimes, but mostly I still see companies supplying laptops/desktop computers to employees. This is what I think should be the standard–BYOD mobile, but company-owned laptops. As such, I require only app protection policies (MAM) for mobile devices, which covers most of the risks we are concerned about in the SMB, and then for laptops we require device compliance (full MDM management). This approach ensures that we always have a way to wipe a device wherever corporate data lives, and gives us the most control where risk is highest.

Second, I am putting an emphasis here on Defender for Business rather than third-party Antivirus/EDR. You would obviously have to modify this security profile to exclude Defender-related stuff if you’re still using something else. But, in the SMB, cost is paramount, and when we are already paying for an Enterprise-grade EDR in our primary subscription, why pay for it again somewhere else? Just move to the Microsoft solution and enjoy lower TCO, and integration with Device Compliance and Conditional Access!

Third, in this example profile I am trying to cover the major security points without being too heavy-handed or restrictive. Running into walls is perhaps more common in the culture of the Enterprise, but the SMB is not used to wearing as much of a straight-jacket so to speak. Not suggesting there isn’t room for improvement by any means, but there is always a balancing act, and we have to start somewhere, right?

Now, it is up to you, the Managed Services Provider, to make life both easy AND secure for the customer. So over time, I suggest that you do include things like (for instance) restricting the ability to add browser extensions. Of course, this implies you will be managing the extensions, so your customers will have everything they need to do their work in the browser. In my experience consulting with SMBs and the MSPs who serve them, not everyone is managing down to that level of detail yet. Therefore, I removed certain items from Microsoft’s original policy set to keep this more “broadly applicable” in the SMB. Again, move up to additional or stricter policy sets as makes sense for you.

How I like to implement in practice

In general, I begin most of my engagements by running over my Best Practices checklists for core services like Entra ID, Intune, Exchange Online, SharePoint Online, etc. Then, I would visit the Defender security center (https://security.microsoft.com) and make sure that the Defender for Business first run experience has taken place, and that it is all set up and connected to Intune. Finally, I would deploy my policies.

When I am ready to launch, I would start by assigning them to a pilot group first.  After I have verified and/or remediated whatever was required, I would expand to larger groups. And finally, I never enable Conditional Access for devices (e.g. Require device to be marked as compliant) until I have actually seen my devices successfully showing up as compliant, first. So that policy in particular would be the last to go live.

Hopefully this gives you some understanding of what it looks like in practice. Good luck!