Using Microsoft Intune to manage your Windows Enterprise desktops is all about standardizing and simplifying the management layer of your environment. As explained in the previous chapter, everything is centered around structuring your configuration sets (and applications) separately from the target Operating System (OS) to remove the need to create custom images that might include these things from the get-go.

Policy management within Microsoft Intune makes it possible to configure the following options from within the Devices menu:

• Compliance policies
• Conditional access
• Configuration profiles
• Settings catalog
• ADMX import
• Scripts
• Group policy analytics
• Enrollment restrictions

Group Policy management has been around for more than 20 years and is a way to configure the behavior of a group of users or computers in a domain. This is still possible with an on-premises domain today, but if you want to start modernizing your policy and settings management, you should start looking at Microsoft Intune and the feature set it provides for policy management. There are some disadvantages associated with using GPOs, one of them being that it requires a line of sight to a domain controller. Another is that GPOs are fire-and-forget, but what do we mean by this? GPOs are assigned to a specific group of users and devices, and they are applied when a device connects to a domain controller on a regular basis. There is no reporting back to the domain controller if the device receives and applies the policy correctly, if no domain controller can be contacted, or if no new or changed policies are applied.

Sometimes, due to misconfiguration, a Windows device may try to contact a domain controller far away on the internal network with very slow connectivity, which can result in very long boot and sign-in times. Many of these issues can be avoided with a purely cloud-joined and -managed device.

Microsoft Intune is a perfect match for a new way of working guided by modern management and cloud-native, as it just requires internet connectivity following the initial onboarding into Microsoft Intune.

In this chapter, we will focus on cloud-native devices, that is, Enrtra-joined and Intune-managed Windows devices, but what we learn will also apply to hybrid domain-joined devices that are managed from Microsoft Intune in a co-managed state. One important thing to note here is that GPO and Mobile Device Management (MDM) settings are on the device identity layer, where policies and configurations are either target users or devices, whereas co-management between Microsoft Intune and System Center Configuration Manager (SCCM) is on the management plane.

First, we need to look back at traditional Windows management, where all Windows devices were on-premises in the office, in production, or with end users working at home with VPNs. Modern policy management is still an option on those devices if they are hybrid-joined to Entra ID.

The best option moving forward with new devices is to go purely Entra-joined and onboarded with Windows Autopilot. What we cover in this chapter covers both scenarios. This book is dedicated to cloud management, and certain scenarios do not apply to hybrid-joined devices, which is why you need to make some decisions to go to Entra-joined devices to get the best end-user experience. Start small, start with a Proof of Concept (POC), and showcase the benefits of modern policy management. A best-practice approach is to block on-premises devices in your POC from getting GPOs from the local Active Directory instance; otherwise, you can end up in a situation where you are not 100% sure where the settings are being applied from.

A Configuration Service Provider (CSP) is an interface for reading, setting, modifying, and deleting configuration settings on a device. These settings map to registry keys or files. Some CSPs support WAP format, some support SyncML, and some support both. SyncML is only used over the air for Open Mobile Alliance Device Management (OMA DM). On the other hand, WAP can be used over the air for OMA client provisioning, or it can be included in a phone image as a .provxml file that is installed during boot.

Some policies can only be configured at the device level, whereas other policies can be configured at the user level. This means that device-level policies will have an effect independent of the user logging in to the device, whereas user-level policies will only have an effect depending on the user logging in to the device. As an example, different users can have different homepages in Microsoft Edge, so it is appropriate to assign a policy with that setting to a user group, whereas security settings that need to be applied at the device level are appropriate to assign to device groups.

User scope is where the policy only applies to the user who logs in to the device, and the policy can vary depending on who is logging in to the device. The following is an example of what the CSP tree looks like when configuring a user policy:

• ./User/Vendor/MSFT/Policy/Config/AreaName/PolicyName is used to configure the policy.
• ./User/Vendor/MSFT/Policy/Result/AreaName/PolicyName is used to get the result.

Device scope is where the policy only applies to the device itself, regardless of the user who logs in to the device. The following is an example of what the CSP tree looks like when configuring a device policy:

• ./Device/Vendor/MSFT/Policy/Config/AreaName/PolicyName is used to configure the policy.
• ./Device/Vendor/MSFT/Policy/Result/AreaName/PolicyName is used to get the result.

The biggest difference between a GPO and a CSP policy is that a CSP policy has a result channel as well, so every setting that is configured on the device will report back to the MDM system – in this case, Microsoft Intune.

If we take a closer look at the policy structure, it looks like the Windows registry is arranged in a tree structure:

Figure 9.1: CSP policy tree

By using ADMXInstall, you can add ADMX-backed policies for those Win32 or Desktop Bridge apps that have been added between OS releases. ADMX-backed policies are ingested by your device by using the CSP policy URI: ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall.

The OMA-URI string needs to go into the CSP policy URI:

• ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Applicationname/Policy/ADMXFileName.
• ./Vendor/MSFT/Policy/Config/ remains the same for all machine-based policies that you deploy to the device.

Applicationname and ADMXFileName are user-defined. In this case, Applicationname is App1, and you can use the same name as ADMXFileName. Just remember that ADMXFileName needs to be unique, which means you cannot deploy two ADMX files with the same name on a device, as it will fail and any additional ADMX files will not be added to the device.

Here is the content of the ADMX file in my case – this could also have been Google Chrome, Microsoft Office, Internet Explorer, or others:

Figure 9.2: Registry entry for AdmxInstalled

Then, if you take a closer look at the registry, the first place where they are written is HKLM\SOFTWARE\MICROSOFT\PolicyManager\AdmxInstalled.

The policy is always declared under a GUID and with the name you gave the policy in Microsoft Intune when you created the policy.

Then, you will be able to see the naming of the policy category that you are using when creating a policy setting: HKLM\Software\Microsoft\PolicyManager\AdmxDefault

If the policy is a device policy, you will be able to see the direct results that apply to the devices in the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device.

In the end, all a policy does on a Windows device is set some registry keys, and it is the same with MDM policies. All the policy settings go here: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\.

MDM policies are applied when a device syncs, either from Microsoft Intune or as part of the 8-hour schedule when a Windows device is running with MDM sync on.

For an IT admin to sync a device from Microsoft Intune, they need to start the Microsoft Intune admin center and follow these steps:

1. Click Home | Devices | Windows | Windows devices.
2. Search for the device you want to sync, and then select the device and click Sync. Intune will then try and reach out to the device through Windows Push Notification Service (WNS).
3. You can read more about WNS in the next section.

Figure 9.3: Device sync

4. In the same view, where you just selected a single device, you can also leverage Bulk Device Actions:

Figure 9.4: Bulk device actions

5. Select Windows for OS.
6. For Device type, select Cloud PCs or Physical devices.
7. Select Sync as Device action:

Figure 9.5: Bulk device action – Windows

8. Then, you can select up to 100 devices that Microsoft Intune will reach out to and perform the sync:

Figure 9.6: Bulk device action

When leveraging bulk device actions, Microsoft Intune uses WNS. In the next section, you will learn about how WNS works.

WNS enables Microsoft Intune to send toast, tile, badge, and raw updates from Microsoft Intune to MDM-enrolled devices. This provides a mechanism to deliver new updates to your users in a power-efficient and dependable way:

1. Microsoft Intune makes an HTTP POST to the channel URI. This request is made over SSL and contains the necessary headers and the notification payload.
2. WNS responds to indicate that the notification has been received and will be delivered at the next available opportunity.

   WNS does not provide end-to-end confirmation that your notification has been received by the device or application. Microsoft Intune provides this option by showing the status in the Device actions status view on the Overview blade for a specific device:

   

   Figure 9.7: WNS workflow

3. There is also an option for an end user to do this from the client side. On the client side, you can do a sync from Company Portal or the settings app.
4. In the Start menu, you can search for Company Portal (we recommend that IT admins always push Company Portal to the end user’s Windows device), which will give you the option to sync this device:

Figure 9.8: Company Portal

5. If Company Portal is pinned to the Start menu, you can right-click and sync this device:

Figure 9.9: Sync this device

6. In Company Portal, go to settings, and then click Sync:

Figure 9.10: Manually sync your device

7. In the Windows settings app, you can go to Accounts | Access work or school.
8. Select the identity from Entra ID, and then click Info.
9. You are then able to see the policy areas managed by your company.

   On Windows 11, you also have the same option as on Windows 10, but you can perform an export of your management log files directly from the Access work or school page in the Settings app:

   

   Figure 9.11: Managed by your company

10. When you click Info, you will get a more detailed page:

Figure 9.12: Managed by your company

11. If you scroll to the bottom of this Settings page, you will see Device sync status, where you can see Last Attempted Sync and the Sync button:

Figure 9.13: Device sync status

When a user is doing an MDM sync, all new policies will be applied to the device and it will be verified that all existing policies have been applied.

That concludes this section on WNS and MDM synchronization. In the next section, we will cover getting started with policy design in Microsoft Intune.

When designing your strategy for policy management with Microsoft Intune, it is important to take the right approach.

By starting with a security baseline, we get well-tested and secure sets of policies; you can even disable or remove individual settings in the security baseline if they do not suit your organization. When you have deployed the security baseline, you can start adding other policy types that suit your security or configuration needs.

There are several policy types in Microsoft Intune. In the following list, you can see the different policy types and the order in which you should start creating policies:

1. Configure the security baseline.
2. Configure the policy from the Endpoint Security blade.
3. Configure the policy from the Settings catalog.
4. Configure the administrative template.
5. Configure the device configuration.
6. Leverage a custom policy as a last resort.

Just remember that there are no right and wrong approaches, but if you’re undertaking a migration from Active Directory GPOs to MDM settings management, it might be a good time to start afresh and see what you need to configure instead of taking the legacy GPO settings of your on-premises environment with you. Sometimes, organizations do not even know why they implemented a specific policy setting back when they originally created it. Perhaps the person responsible for implementing this policy setting is no longer even with the company and did not leave any documentation on why the setting was configured the way it was in the first place.

As there is no conflict handling in the MDM stack, you might inadvertently create a conflict between two settings coming from two different policies to the same user or device. These could be from the same policy type or different policy types, so it is important to spot and monitor any conflicting policies.

1. In order to monitor any conflicting policies, head to the Microsoft Intune admin center, and under each device, go to Home | Configuration:

Figure 9.14: Configuration policy status

2. You can see the policy that has conflicts and the work required to remediate the conflict:

Figure 9.15: Policy conflict

3. When drilling down into the policy, you can see which settings are in conflict. In this case, I see that there is a conflict between a policy in the Endpoint Security blade and the Antivirus – Windows Defender Antivirus policy type:

Figure 9.16: Profile settings

4. Going to that policy, you can see in the Per-setting status blade that the top line, CPU usage limit per scan, has conflicts. When you find conflicts, you need to go into the policies with conflicts and change the conflicting settings so they are only configured in one policy:

Figure 9.17: Per-setting status

Let’s now have a look at how to implement different policy types.

It’s possible to migrate your existing Active Directory-based group policies into Microsoft Intune. This can be done with the Group Policy analytics feature.

Many businesses that are looking at Microsoft Intune management need a good path to the new modern workplace. The translation of existing policy settings to Intune can be tricky. This service will make life much easier for IT admins. Let me explain in more detail what Group Policy analytics does and how you can use it yourself; it can be found on the Devices blade:

Figure 9.18: Group Policy analytics

1. First, make sure to perform an export of your existing policy settings from within your on-premises Group Policy Management console.
2. Export the policies by right-clicking and selecting Save Report….
3. Save the files somewhere centralized, as we need to upload them to Microsoft Intune:

Figure 9.19: Save the policy report

4. In the Microsoft Intune admin center, select Devices | Group Policy analytics.
5. Click on Import:

Figure 9.20: Import

6. Search for the policy report file you exported:

   

   Figure 9.21: Import the GPO files

   NOTE

   When you have multiple policies, you can upload them all here, too, for further analysis.

7. After you run the policy analysis, you will see the MDM Support column (which also applies to Windows), showing how many of your settings/policies are also available in Microsoft Intune to migrate from GPOs to Intune settings on a 1:1 basis:

Figure 9.22: MDM Support

8. You will get the information you need to proceed. The GPOs you imported are now all listed with the following information:
   • Group policy name: The name is automatically generated using the information in the GPO.
   • Active Directory Target: The target is automatically generated using the Organizational Unit (OU) target information in the GPO.
   • MDM Support: This shows the percentage of Group Policy settings in the GPO that have the same setting in Intune.
   • Targeted in AD: Yes means the GPO is linked to an OU in an on-premises Group Policy. No means the GPO isn’t linked to an on-premises OU.
   • Last imported: This shows the date of the last import.

   

   Figure 9.23: Default Domain Policy

   With Group Policy analytics, you import your on-premises GPOs. The tool analyzes your imported GPOs and shows the settings that are also available in Microsoft Intune. For the settings that are available, you can create a Settings Catalog policy and then deploy the policy to your managed devices.

9. After you have imported your GPOs, you can select the GPO that you want to migrate to Intune by clicking the Migrate button.

Figure 9.24: Migrating GPOs to Intune

10. You need to select the GPO settings that you want to migrate and then click Next:

    

    Figure 9.25: Migrating GPOs to the cloud

    These are the settings you’ve identified as necessary to your organization as you move to cloud-based policy management. Configure the setting values as per your organization’s requirements. Where possible, we configured the settings values as per the Group Policy:

    

    Figure 9.26: Migrating GPO settings

11. You need to give the new settings catalog profile a name:

Figure 9.27: Migrating profile info

12. Continue with the guide to add scope tags and assignments, and then finally deploy the policy. You can skip the assignment and the policy will be created without an active assignment.

Figure 9.28: New browser policy

You have successfully migrated your browser policy and are ready to test it on Intune-managed devices before you deploy the policy at scale.

This concludes the section on Group Policy analytics, which can help you with your policy migration from on-premises GPOs to Microsoft Intune MDM policies.

In this chapter, you’ve learned about the basic policies in Microsoft Intune and how they apply to your Windows endpoints. This is knowledge that you can use to better understand what happens on a Windows device when you start to deploy policies to your endpoints from Microsoft Intune.

In the next chapter, we will go into more depth on how to configure different policy types from within Microsoft Intune.

1. Do CSP and ADMX policies write to the local registry in the same way?
   1. No
   2. Yes
2. What is the maximum number of devices for bulk actions in MDM?
   1. 10
   2. 50
   3. 100
   4. 1000
3. What does WNS stand for?
   1. Windows Name Server
   2. Windows Push Notification Service

1. (a)
2. (c)
3. (b)

If you want to learn more after reading this chapter, please use the following free online resources:

• Manage endpoint security in Microsoft Intune | Microsoft Docs: https://docs.microsoft.com/en-us/mem/intune/protect/endpoint-security
• Device compliance policies in Microsoft Intune – Azure | Microsoft Docs: https://docs.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started
• Use templates for Windows 10 devices in Microsoft Intune – Azure | Microsoft Docs: https://docs.microsoft.com/en-us/mem/intune/configuration/administrative-templates-windows
• Restrict device features using policy in Microsoft Intune – Azure | Microsoft Docs: https://docs.microsoft.com/en-us/mem/intune/configuration/device-restrictions-configure

Learn more on Discord

To join the Discord community for this book – where you can share feedback, ask questions to the author, and learn about new releases – follow the QR code below:

https://packt.link/SecNet