Chapter 6: Administration and Policy Management

In this chapter, we will be covering the administration and policy management of Windows devices within an organization. This is a very important task and one that requires ongoing interaction, support, and reviews to stay up to date with changing trends in technology. The foundational direction of your administration strategy should largely be driven from your established framework and baselines, as discussed in Chapter 2, Building a Baseline. This should help direct admins on how to administer your Windows environment and provide clear direction during policy configuration to meet the defined requirements that have been created and agreed upon.

When it comes to recommendations for enterprise-grade solutions for managing Windows clients, Microsoft Endpoint Configuration Manager (MECM) and Intune are the industry-leading standards. In the following sections, we will dive into an overview of both solutions, as well as reviewing the tools available in each to help ensure the successful administration of your baselines, configurations, and policies.

To accomplish these tasks, we will review the following topics:

• Understanding device administration
• Managing devices with Configuration Manager
• Managing devices with Intune
• Administering a security baseline

Technical requirements

To follow along in this chapter, you will need the following technical requirements as a minimum:

• MECM
• Microsoft Intune
• Access to the Group Policy Management Console

Understanding device administration

Ensuring devices remain hardened and secured is unrealistic without a proper device management solution. Unless you administer a very small number of devices, you are going to need some form of management to effectively apply policies, distribute software, manage security updates, and continuously service endpoints after they are handed over to your employees. Without it, your organization will be putting itself in an extremely vulnerable situation.

First, let's look at the evolution of device management and the progression to unified endpoint management throughout the years.

Device management evolution

Using a device management model, many large organizations have adopted MECM, formerly known as System Center Configuration Manager (SCCM), as the standard for on-premises device management. Configuration Manager is a fully mature solution whose capabilities range from image deployment to software distribution, patch management, and policy enforcement. To operate effectively, a Configuration Manager hierarchy requires resources and the deployment of infrastructure either on-premises or in IaaS. As new PC hardware is purchased and new Windows builds are released, a lengthy and complex life cycle process to support the new requirements will typically follow. Additionally, the underlying operating system and physical hardware, if on-premises, must also be maintained. Throughout the book, we may refer to Configuration Manager as MECM, SCCM, ConfigMgr, and Endpoint Manager. All are common forms used to reference Configuration Manager. MECM is a highly complex and robust solution, and therefore hundreds of reference docs are available through Microsoft docs and other third parties. In the sections that follow, we will try to reference only what we consider relevant to the material in this book, with the understanding that there may be other ways to complete these tasks.

Recently, we have seen disruption to the previous model and a shift that is changing the dynamics of device management. In recent years, there has been increased adoption of Mobile Device Management (MDM) tools that evolved in parallel with the growth of mobile platforms such as iOS and Android. This growth has sometimes led to multiple administration environments within enterprises, one for phones and tablets, and the other for desktops and laptops. This generates a lot of overhead and requires a broader skillset to support, manage, and operate multiple platforms. It also adds overhead to your security strategy as both need to meet the security requirements of your policies. Validating security within multiple environments can create challenges and adds its own complexity.

A major advantage of using an MDM solution is an out-of-the-box approach. The ability to take an Original Equipment Manufacturer (OEM) device out of the box, power it on, log in with your corporate account, and begin receiving policies, configurations, software, and security settings is a game-changer. This approach has been well received and is now widely adopted by corporate-owned and bring-your-own Windows, iOS, and Android devices. Using MDM helps companies shift away from traditional imaging, complex on-premises management solutions, and the overhead it brings. More recently, Microsoft has made significant enhancements with Intune and Configuration Manager integrating both solutions into one unified management approach for your device management program with Intune and co-management.

As the model continues to evolve, we are slowly seeing a transition to unified endpoint management, bringing together all endpoints into one management solution, as shown in the following diagram:

Figure 6.1 – The evolution of device management

For most organizations, this shift isn't going to happen overnight, but the good news is that Microsoft has built a solid foundation and avenue to make the journey a reality.

As a review and precursor to device management, we are going to discuss joining a Windows device to your organization. Traditionally in on-premises deployments, devices are joined to your domain in Active Directory and managed through group policy. Today, we have flexibility, and devices can be both domain and hybrid Azure Active Directory (AD) or fully Azure AD joined. MDM with Intune is supported for hybrid, domain, and fully Azure AD-joined devices.

Let's look at an overview of each model.

Differences between domain join, hybrid, and Azure AD-joined devices

Domain join is the traditional model and allows the central administration of your corporate end user devices and Windows servers on-premises. When joining your device to a domain, you are joining that machine to your Active Directory Domain (ADD). Once joined, you can use Group Policy Objects (GPOs) to configure and enforce your policies based on your defined baselines. You will also most likely supplement Group Policy with an additional management tool such as Configuration Manager. This method has served as a very mature and reliable model.

If you want to use a cloud-only solution to administer your devices, then you will need to Azure AD join your devices. This method directly joins your device to the cloud environment and Azure AD where you can manage and administer your devices using an MDM solution such as Intune. This model also supports the ability to use co-management with MECM. Moving to the cloud model provides a far more powerful and robust deployment, allowing for the improved provisioning of your devices and increased flexibility for your users. Azure AD-joined devices will require you to log in with your Azure AD cloud credentials, which can be synced from an on-premises AD.

Tip

There is also the concept of Azure AD-registered devices that supports the use case of Bring Your Own Device (BYOD). This allows Windows, iOS, Android, and macOS devices access to your corporate resources without being required to sign in to your device with your work account.

Many organizations may face dependencies that still require an on-premises Active Directory infrastructure. If this is still a requirement, hybrid Azure AD join provides the benefits of both Azure AD and Active Directory. With this method, your devices will still be joined to your on-premises Active Directory, but will also be registered in Azure AD. This allows for management using Group Policy, Configuration Manager, or the option to use co-management with Microsoft Intune. Windows 7 and later and Windows Server 2008/R2 and later all support this method.

The following diagram shows these three different options for your devices:

Figure 6.2 – Domain-joined, hybrid, and Azure AD-joined examples

Next, let's look at one of Microsoft's device management solutions – Microsoft Endpoint Configuration Manager. In the following section, we will provide details on how to effectively manage devices and policies using this enterprise-grade solution.

Managing devices with Configuration Manager

MECM is a world-class enterprise device management solution for workstations, laptops, and Windows servers. Its robust set of tools and centralized management are invaluable for ensuring that device security and configurations are compliant. It is highly scalable and can deploy operating systems, manage the application life cycle, push security updates, configure security baselines, manage antivirus, collect telemetry, and define compliance policies with a robust set of built-in reporting.

The Configuration Manager infrastructure usually contains a hierarchy of servers, including a Central Administration Site (CAS), primary sites, and additional secondary sites based on the organization's scale configured with system roles. Depending on the number and location of users and devices, having multiple servers to act as Management Points (MPs) and Distribution Points (DPs) for hosting content is not uncommon. Even with a complex deployment, your entire ecosystem of devices can be controlled from a single administrative console. To connect to the hierarchy, Windows clients have deployed an agent that creates the connection point to Configuration Manager.

Software Center is the familiar user-facing application installed on client machines that allows users to request and install applications and software updates. For companies with remote workers without an office or possibly VPN, clients can be managed directly over the internet using an Azure Platform as a Service (PaaS) resource known as a cloud management gateway or through internet-based client management through internet-facing site systems. Configuration Manager integrates with many other Microsoft cloud-based solutions, including Intune for co-management, Endpoint Analytics with tenant attach, and Windows Autopilot. Together, these tools create a robust, unified endpoint management solution branded as Microsoft Endpoint Manager. Configuration Manager is a key component of unified endpoint management and we want to review a few concepts regarding managing devices. In the next few sections, we will be covering the following topics:

• Client collections, settings, and communications
• Securely deploying clients for Configuration Manager
• Connecting to the Azure cloud and Intune co-management

A Configuration Manager deployment can become highly complex, and we won't go into detail about configuring a site hierarchy. There are many great blogs available over the internet, and the Microsoft docs are a great place to get started at the following link: https://docs.microsoft.com/en-us/mem/configmgr/.

Let's have a look at managing client settings and communicating between site components.

Client collections, settings, and communications

Monitoring the health and status of your clients is an important aspect of maintaining a well-managed device administrative ecosystem. If a production client is active but not sending a heartbeat, then the device could be at risk and unable to be managed or patched remotely. Monitoring client activity and status is also very helpful for maintaining an accurate device inventory.

In Configuration Manager, resources (or clients) are organized by being placed in collections by users or devices. Resources can be added to collections manually, by building custom rules, using WQL queries, and through other methods. For more information about collections in Configuration Manager, visit this link: https://docs.microsoft.com/en-us/configmgr/core/clients/manage/collections/introduction-to-collections.

Built-in security roles

Role-based access control (RBAC) can be applied to limit the scope of resources that administrators have access to manage. There are many built-in security roles, and they can be assigned directly to individual users or Active Directory security groups. A few examples of security roles include the following:

• The Application Administrator built-in security role grants permission to the author and deploys applications.
• The Software Update Manager role grants permission to define and deploy software updates.

Role-based administration is also helpful for hierarchies with multiple sites that have different administrators to create a separation of duties between the clients that they can manage. To assign security roles, go to Administration | Security | Administrative Users.

For more information on role-based administration in Configuration Manager, visit this link: https://docs.microsoft.com/en-us/mem/configmgr/core/understand/fundamentals-of-role-based-administration.

Now that we have reviewed collections, we need to define the settings the agents will use to communicate with the site systems. Let's look at the client settings options for Windows clients.

Client settings

Client settings are used to specify agent configurations such as caching settings, policy polling, compliance settings, and Software Center customizations, such as company branding. These settings are grouped into client setting policies and are assigned to device collections. Multiple policies can be assigned to devices, and they are evaluated by a priority weight set during policy creation. The default custom client setting is set to 1,000. In the following screenshot, you can see all the different settings available for configuring client settings:

Figure 6.3 – Default client settings in Configuration Manager

Client settings can be configured under Administration | Client Settings and include both device and user-based options.

Remote device actions

Configuration Manager also has the ability to set remote device actions, such as collecting device inventory telemetry or forcing a policy sync. This helps force a policy sync if the request needs to be expedited sooner than the polling interval cycle configured in the client settings. The following screenshot shows some examples of the available options for device actions:

Figure 6.4 – Remote actions in Configuration Manager

In addition to client notification remote actions, there are other remote menu options available, including the following:

• Client Settings will show you a view of all client settings applied to a device.
• Start can initiate a remote desktop session and open Resource Explorer for viewing system information.
• Run Script will let you run a PowerShell script against a device.
• Block will prevent a client from receiving a policy and communicating with the hierarchy.

For more details on client management operations, visit this link: https://docs.microsoft.com/en-us/configmgr/core/clients/manage/manage-clients.

Now that we have covered configuring collections and client settings, let's discuss how clients communicate with the site systems.

Client communications

Clients communicate with different site systems such as MPs and DPs using the most secure method available. An MP site system provides location information to clients, such as the location of distribution points, and delivers policy data. The DP site system contains application source files and software updates and is where the client connects to download content. Client authentication uses HTTP or HTTPS methods, and authorization can occur for both the user and device.

Tip

Microsoft recommends using HTTPS or enhanced HTTP for all client communications. HTTP communications are deprecated in version 2103 for client communication with site systems.

For secure client communications, and typically seen in on-premises Active Directory, clients use an internal certificate issued through their certificate authority. Client authentication can also use a self-signed certificate and authenticate by verifying an Azure AD user or device token. In the following screenshot, the Configuration Manager control panel applet displays the client certificate as self-signed for an Azure AD-joined co-managed device over the internet:

Figure 6.5 – Configuration Manager applet client properties

To read more about the communications between clients and Configuration Manager, visit this link: https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/communications-between-endpoints.

Tip

MECM supports CNG v3 certificates. To read more about cryptography and next-generation certificates, visit this link: https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/network/cng-certificates-overview.

To configure client communication settings for your MPs and DPs, go to Administration | Site Configuration | Servers and Site System Roles. Each site system you select will list all the installed roles that are configured. Double-click them to view their properties. In the following screenshot, the MP properties for this site server require client communications to use HTTPS:

Figure 6.6 – MP client communication settings in Configuration Manager

Configuration Manager encrypts the data between the clients and hierarchy to prevent traffic from being analyzed using SHA-256 as the primary algorithm. To read more about the cryptographic functions in detail, visit this link: https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/cryptographic-controls-technical-reference.

Securely deploying clients for Configuration Manager

There are a few different methods that can be used to deploy the Configuration Manager client. For an in-depth analysis, Microsoft docs has a great write-up that can be found at this link regarding best practices for client deployments: https://docs.microsoft.com/en-us/configmgr/core/clients/deploy/plan/best-practices-for-client-deployment.

Let's look at several different methods used to deploy clients today:

• Group Policy installation is supported for Windows only. Using a GPO, clients can be deployed on computer objects. The installation bootstrapper and commands are configured in the software installation node in GPMC under Computer Configuration | Policies | Software Settings, as shown in the following screenshot:

Figure 6.7 – Software installation bootstrap for Configuration Manager agent

• Software update-based installation also uses Group Policy and can be used for both new installations and client upgrades. Software update-based installations will require a server with the Software Update (SUP) site system role installed.
• Logon script installations can be done with GPO using the CCMSetup.exe file located in the Program Files/Microsoft Configuration Manager/Client directory from a UNC path or network share.
• Client push installation methods can be used to deploy clients automatically on computers that are discovered by site discovery within Configuration Manager.
• Image installation is an option to preinstall the client during device imaging.
• Manual or packaged installations are useful for boots-on-the-ground installations or for targeting a collection of devices for client upgrade scenarios.
• Intune MDM installation can be used for devices that are managed by Intune.

Using Intune, CCMSetup.msi is configured in an app deployment. The ccmsetup command line can be customized to support on-premises and Azure AD authentication scenarios. Additional resource requirements are needed if using the Azure AD method with the cloud management gateway. The following screenshot shows an example of the Intune app installation properties of the ccmsetup.msi bootstrapper:

Figure 6.8 – Microsoft Endpoint Manager view of the ConfigMgr client in Intune

Tip

To find the CCMHOSTNAME value for the Azure AD method, run the following query in SQL Server Management Studio for the main site database: select * from proxy_settings. The ConnectorInfo column contains the necessary information.

For more information about deploying clients with Azure AD Identity, visit https://docs.microsoft.com/en-us/configmgr/core/clients/deploy/deploy-clients-cmg-azure.

Regardless of the method used to deploy agents, Microsoft recommends the following security best practices:

• Use PKI certificates for clients that communicate with Internet Information Services (IIS) site systems by using HTTPS.
• If managing computers in Active Directory, only auto approve clients from trusted domains.
• If deploying the agent on an image, remove the certificates before Sysprep to ensure clients don't impersonate each other.
• Use a trusted root key to validate MP for your clients.
• Always update software update points to include the latest agent version.
• Disable WINS lookup to ensure that only Active Directory Domain Services is used to find valid management points.
• Use HTTPS or enhanced HTTP for secure communication between site systems.

To view a full detailed list of security best practices from Microsoft, visit this link: https://docs.microsoft.com/en-us/configmgr/core/clients/deploy/plan/security-and-privacy-for-clients.

Next, let's review the connection of Configuration Manager to the Azure cloud and enabling co-management with Intune.

Connecting to the Azure cloud and Intune co-management

As part of ongoing investment from Microsoft in Configuration Manager, you can now connect your hierarchy to Azure services and create a better-unified endpoint management experience. Some of the advantages of cloud attachment include the following:

• User and device-based Azure AD authentication.
• Support for the cloud management gateway and internet-based client management.
• Azure AD user and group discovery.
• Connections to Log Analytics.
• Deploy Microsoft Store for Business apps.
• Azure AD tenant attach for Configuration Manager actions and tools from the Microsoft Endpoint Manager admin center.

Depending on which services you configure, you can use the built-in Azure Services Wizard to deploy the resources in Azure AD needed to create the connections. For details on how to use the Azure Services Wizard and more information about Azure services in general, visit this link: https://docs.microsoft.com/en-us/mem/configmgr/core/servers/deploy/configure/azure-services-wizard.

In addition to connecting with Azure services, when enabling Configuration Manager for co-management, you can cloud-attach your hierarchy and manage devices both with Configuration Manager and Intune. Inside the administration console, you can control which workloads are managed by each solution. Some of the major benefits of enabling co-management include the following:

• Configuration Manager actions from Microsoft Endpoint Manager.
• Manage device configurations, apps, compliance policies, and endpoint protection from the solution of your choice.
• Better RBAC and central visibility for all your co-managed devices.
• Support for Windows Autopilot.
• Support for Conditional Access with device compliance conditions.
• Client health details in Microsoft Endpoint Manager.

The following screenshot shows the workload sliders for switching between Intune and Configuration Manager. It can be found under Administration | Cloud Services | Co-management:

Figure 6.9 – CoMgmtSettingsProd in Configuration Manager

Co-management can be enabled on existing Configuration Manager devices, or set up with modern provisioning using the Intune MDM installation discussed earlier. You will need to have at least Azure AD, Microsoft Intune, and Windows 10 or later with hybrid Azure or fully Azure AD-joined devices.

For more information about enabling co-management, visit this link: https://docs.microsoft.com/en-us/mem/configmgr/comanage/overview.

Next, let's look at how to manage policies and baselines using Configuration Manager.

Managing policies and baselines in Configuration Manager

Managing policies and baselines is part of the core compliance functionality in Configuration Manager. To view them, navigate to Assets and Compliance | Overview | Compliance Settings. Some of the available compliance settings include the following:

• Configuration Items contains settings for computers or mobile devices. You can create your own custom configuration items or download and import them from a vendor.
• Configuration Baselines contains the configuration items that you want to deploy to a collection to evaluate the compliance of your policies. Deployments can be put into a monitor or remediate mode.
• User Data and Profiles manages the user's settings for folder redirection, offline files, and roaming profiles.
• OneDrive for Business Profiles is used to configure the OneDrive for Business settings for Windows clients, such as known folder redirection.
• Compliance Policies is where you create policies that can be used in conjunction with conditional access. Compliance policies can be created for devices without the Configuration Manager client.
• Conditional Access settings manage conditional access to company resources.

  Tip

  Most conditional access settings will be moved to Microsoft Endpoint Manager and Azure AD. Later versions in the Configuration Manager current branch servicing model now direct you to use this portal.

• Company Resource Access allows you to create VPN, Wi-Fi, and certificate profiles to deploy to your devices.
• Microsoft Edge Browser Profiles contains custom settings to create an Edge browser policy in Windows 10.

Let's look at what configuration items are and how they are used to evaluate settings on Windows 10 devices and servers.

Creating a configuration item

A configuration item contains a list of settings and compliance rules that are used for evaluation against a device's current settings. There is a lot of flexibility when choosing a setting type, and the options will vary depending on the platform selected during policy creation.

Some of the available setting types in a configuration item include the following:

• Active Directory query
• An assembly
• A filesystem
• IIS metabase
• A registry key and registry value
• Using a custom script
• SQL query
• XPath query

The following screenshot shows a configuration item using the integer registry value as the setting type for the detection method. The specific hive, key path, and value name are all specified:

Figure 6.10 – Configuration item using the Registry value setting type

Tip

The checkbox for Create the registry value as a REG_DWORD data type if remediated for noncompliant rules is selected. This allows the REG_DWORD data type to be created or updated if the configuration baseline is set to remediate non-compliant rules.

The Compliance Rules tab in the Configuration Item setting is where you can specify the conditions for evaluation against the device. Each setting can have more than one compliance rule.

The following screenshot shows a compliance rule with a condition that says the value name must be set to zero to be compliant. Choose the Remediate noncompliant rules when supported checkbox to force this setting onto the PC if found to be non-compliant.

Figure 6.11 – Compliance rule options for a configuration item

You can specify many different settings in a configuration item and then assign it to a configuration baseline for deployment to devices.

The following screenshot shows an example of different configuration items that can be created and assigned to baselines:

Figure 6.12 – Configuration items in Configuration Manager

Now that we have covered how to create a configuration item, let's look at building a configuration baseline using configuration items and remediate any non-compliant configurations.

Using a configuration baseline

A configuration baseline can contain one or many configuration items, other baselines, or software updates that are used during a policy evaluation on a client. A configuration baseline is deployed to collections where each device then downloads it and assesses it against the current device values. The following screenshot is the Configuration Manager Properties applet from the control panel on a Windows client. It shows all the assigned configuration baselines, the revision number, the last evaluation time, and the compliance status for each baseline:

Figure 6.13 – Configurations in the Configuration Manager control panel applet

The client will receive any new baselines during the next machine policy retrieval and evaluation cycle. When organizing baselines, it's not uncommon to group them by their functions, as seen in the preceding screenshot. For example, you could create a baseline for Windows security settings and another for Google Chrome security and each one would contain all relevant configuration items.

To create and view configuration baselines in the administrative console, navigate to Assets and Compliance | Compliance Settings and choose Configuration Baselines. In the following screenshot, the properties of Google Chrome Baseline CIS contain two configuration items that will be used for evaluation against the device:

Figure 6.14 – Configuration baseline properties

Configuration baselines can also be imported from other sources if you don't want to create them from scratch.

After the baseline has been built, you can deploy it to collections of devices. When scheduling a deployment, you can choose to remediate any non-compliant rules, generate alerts, and schedule the frequency of evaluation. For remediation to work, the configuration item must have the Remediate noncompliant rules when supported checkbox selected in the compliance rules, as discussed previously when creating a configuration item. Baselines deployed without the remediation option selected will be in monitor mode only. The following screenshot shows the deployment properties for the Google Chrome baseline:

Figure 6.15 – Configuration baseline deployment properties

Now that we have covered our overview of configuration baselines, let's look at how to run reports to view device compliance.

Reporting on a configuration baseline

Configuration Manager is filled with many built-in reports for a wide range of collected data, from software inventory to resource usage to baseline deployment compliance. To find the reports, navigate to Monitoring | Reporting | Reports and browse through the list. Let's look at the overall compliance status of a configuration baseline deployment. Follow these steps to run the Summary compliance of a configuration baseline for a collection report:

1. In the Configuration Manager console, go to Monitoring, click on Reporting, and choose Reports. Expand the Reports folder in the left-hand navigation to view the expanded tree view.
2. Select the Compliance and Settings Management folder and choose the Summary compliance of a configuration baseline for a collection report to open the menu.
3. Click on Values next to Configuration Baseline Name and select a configuration baseline. We chose Google Chrome Baseline CIS, created previously in this example.
4. Click on Values next to Collection and choose a collection that you wish to report on. In this case, we will choose the collection we deployed earlier.
5. Click on View Report to open the report.

The following screenshot shows the compliance status of the Google Chrome baseline. Click on the disk icon in the toolbar to view the export options, such as exporting to CSV:

Figure 6.16 – Compliance report for a configuration baseline

Some values that are returned on the report contain clickable links. You can click the number to dig deeper into the baselines and view details such as which clients are non-compliant for each different configuration item, or even to the individual rule level that makes up the underlying configuration item.

Now that we have covered reporting on a configuration baseline deployment, let's look at using CMPivot to query devices in real time.

Querying devices with CMPivot

The CMPivot tool in Configuration Manager can be used for querying against an individual device or an entire device collection and return real-time data. This is extremely helpful if you need to troubleshoot an issue or view up-to-the-minute data on a client as there is a delay in the results returned from reporting. To use CMPivot, you build queries against the entities table using the Kusto Query Language (KQL). The KQL syntax is comparable to building SQL statements or, if you are familiar with WMI, using the WQL language. It is also the query language used for Azure Log Analytics. To start CMPivot, open a device collection, right-click a device, and choose Start CMPivot. Note that only one instance of CMPivot can be running at a time. To run a basic query to return the operating system, double-click on the OS entity table to populate it in the query editor and choose Run Query. If the device is online, the results will be returned as in the following screenshot:

Figure 6.17 – CMPivot query results

Part of the convenience of using CMPivot when used for querying multiple devices is the option to run scripts directly against the query results right from the interface. You can build complex KQL queries to narrow down a selection of devices sourced from a larger device collection based on criteria and use Run Scripts to send a remediation action such as stopping a service or closing an application.

If the Configuration Manager hierarchy is tenant-attached to Microsoft Endpoint Manager, you can also run CMPivot queries directly from the Microsoft Endpoint Manager portal. To do this, the account running CMPivot from MEM must also have the appropriate permissions to do so in Configuration Manager. To learn about the requirements and limitations of CMPivot, visit this link: https://docs.microsoft.com/en-us/mem/configmgr/core/servers/manage/cmpivot.

We have just covered an overview of Configuration Manager, including how to create and manage policies and baselines for your clients. Next, let's dive into Microsoft's cloud-based device management solution, Intune, and learn how to use MDM to manage devices and enforce policies.

Managing devices with Intune

Microsoft Intune is an Azure-based device management solution and is a standard for MDM and Mobile Application Management (MAM). Intune has a full feature set for deploying apps and configurations with support for Windows, macOS, iPadOS, and mobile platforms such as iOS and Android. It is a single solution to enforce security baselines and device configurations, manage endpoint security, deploy applications and layer protection policies, and much more.

As mentioned earlier, Intune can be integrated with Configuration Manager for co-management, as well as connected to solutions such as Microsoft Defender for Endpoint and other third-party mobile threat defense partners. Before we jump into enforcing policies, let's review some of the core concepts of Intune MDM. In the next section, we will cover the following topics as they relate to features in Intune:

• Configuration Service Provider (CSP)
• MDM versus MAM or Intune App Protection Polices (Intune APP)
• Windows enrollment methods

First, let's discuss how Intune manages the configuration of your MDM-enrolled devices using CSPs to drive policy configuration.

CSP

A CSP is the layer that MDM providers use to configure custom settings on mobile devices. More specifically, Windows version 10 and later use the Open Mobile Alliance Uniform Resource Identifier (OMA-URI) to identify and configure these settings. Configurations for CSPs are typically formed using a Synchronization Markup Language (SyncML) XML-formatted message and enforced on the client using the Open Mobile Alliance Device Management (OMA-DM) protocol. Just like traditional Group Policy, the CSP acts as a medium to configure settings such as a registry key, for example. It is important to understand CSPs for MDM as this is what configures settings on your devices using Intune compared to using GPOs and the traditional domain Group Policy processing engine.

CSPs are typically represented graphically in tree form. In the diagram that follows, the root node is at the top, followed by rounded elements and rectangular elements. The rounded elements are the different nodes, and the rectangular elements represent a setting that can be configured with a value. The first element after the root dictates the identifiable name of the CSP, and the first rectangular element is the setting. When put together, they formulate the full URI path. The following diagram demonstrates the tree view of a CSP:

Figure 6.18 – CSP diagram for the BitLocker RequireDeviceEncryption setting

For this CSP, MSFT (Microsoft) is the vendor root and BitLocker is the CSP node. The full URI path for the CSP would be as follows in XML format:

./Vendor/MSFT/BitLocker/RequireDeviceEncryption

Setting the Data integer to 0 in the SyncML XML format will disable this policy:

<SyncML>

    <SyncBody>

        <Replace>

            <CmdID>$CmdID$</CmdID>

            <Item>

                <Target>

                    <LocURI>./Device/Vendor/MSFT/BitLocker/RequireStorageCardEncryption</LocURI>

                </Target>

                <Meta>

                    <Format xmlns="syncml:metinf">int</Format>

                </Meta>

                <Data>0</Data>

                </Item>

        </Replace>

    </SyncBody>

</SyncML>

Documentation on the BitLocker CSP can be found here: https://docs.microsoft.com/en-us/windows/client-management/mdm/bitlocker-csp.

When building device configuration profiles in Intune, choosing the Settings Catalog or Templates profile type contains mostly CSP-backed policies. If the policy you're looking for doesn't exist in Intune, choosing the custom setting from Templates allows you to manually configure a CSP and specify the OMA-URI, data type, and value. The following screenshot shows the custom profile type for configuring a Microsoft Defender removable storage access control policy:

Figure 6.19 – Custom template in Intune

This policy maps to registry keys on the Windows client. After the profile has been assigned to a group of users or devices, you can confirm this setting has been configured by opening the registry on the Windows client and going to HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows Defender. The XML data type in the screenshot has been populated under the data for the PolicyGroups string value.

Figure 6.20 – CSP configuring a registry setting

For a full list of the available CSP, visit this link: https://docs.microsoft.com/en-us/windows/client-management/mdm/configuration-service-provider-reference.

Now that we have discussed how Intune uses a CSP for policy definitions on your devices, let's look at the difference between MDM and MAM.

MDM versus MAM

In the managed device, or MDM, scenario, devices are enrolled in Intune to become fully managed at the device level. Using MDM on a Windows device allows admins to administer it in a similar fashion as Group Policy by deploying applications and assigning user and device-based settings using device configuration profiles. Some examples of policies and remote actions that are available with Intune MDM include the following:

• PIN and password requirements for unlocking your device
• VPN configurations and settings
• Deploying certificates
• Configuring Wi-Fi settings and profiles
• Distributing line-of-business applications and other apps
• Assigning compliance policies such as a minimum required Windows version
• Configuring security baselines and administrative-backed templates (ADMX)
• Remote device wipe with factory reset
• Custom configurations for CSPs not available natively
• Windows update and delivery optimization settings

Having control at the device level allows device-specific remote actions such as forcing a policy synchronization, initiating a wipe and factory reset, locating a device, collecting diagnostic logs, and managing BitLocker key rotation. Intune also provides a comprehensive set of inventory and reporting data such as device attestation reports and hardware inventory.

In the MAM scenario, corporate data is controlled at the application level only by using Intune app protection policies. Intune app protection policies can be targeted at Microsoft 365 apps as well as custom line-of-business and other third-party applications that have integrated with the Microsoft Intune App SDK. MAM can be used in conjunction with MDM to provide an additional security layer over corporate data. Although many device-specific policies and remote commands can't be enforced using MAM, certain actions can be used to selectively wipe company data from apps or restrict how data can be interacted with between the app and host device. A few examples include applying an Intune app protection policy for Microsoft Outlook that doesn't allow company data to be copied and pasted outside the app, requiring a PIN on app launch, or blocking access to company data from a jailbroken or rooted device. Assigning Intune app protection policies for applications running on Windows is called Windows Information Protection (WIP). To learn more about WIP, visit this link: https://docs.microsoft.com/en-us/windows/security/information-protection/windows-information-protection/protect-enterprise-data-using-wip.

Next, let's discuss the two types of enrollment methods for Windows devices to become Intune-managed.

Windows enrollment methods

To manage Windows devices with Intune, they need to be connected to the service. The two main methods of enrollment are user self-enrollment and administrator-based enrollment, and each has different methods and scenarios for completing the enrollment process. User self-enrollment scenarios include the following:

• Windows Autopilot in user-driven mode
• Intune enrollment (MDM only)
• Azure AD join with auto-enrollment
• BYOD

Administrator-based enrollment scenarios include the following:

• Windows Autopilot for pre-provisioned deployment
• Bulk enrollment methods for many devices
• Using a device enrollment manager to enroll kiosks, point-of-sale systems, or shared PCs
• Using Configuration Manager-based enrollment

Each enrollment scenario has its own unique capabilities, and Microsoft has outlined the best practices for when to use each one. It is recommended to review this list to determine which method may best suit your needs. It's not uncommon to use more than one, especially if your company has a mix of user-assigned devices and shared devices such as kiosks or point-of-sale systems. You can review the best practice recommendations by visiting this link: https://docs.microsoft.com/en-us/mem/intune/enrollment/enrollment-method-capab.

Now that we have covered the basics of MDM and Intune, in the next section, we will discuss how to use Intune and Microsoft Endpoint Manager.

Using Intune and Microsoft Endpoint Manager

MEM is the unified endpoint management solution that brings Intune and Configuration Manager together. The MEM admin center is used with Intune for configuration management of both MDM and MAM devices, as well as for deploying apps, creating compliance policies, configuring software updates, and managing endpoint security. MEM provides unified reporting views to gain insights into the compliance of your Windows devices from both Intune and Configuration Manager telemetry. Through Endpoint Analytics, you can analyze the productivity of your devices by identifying slow hardware, boot times, or app crashes. Using software updates, Windows updates for business policies can be scheduled and assigned directly from the Microsoft Endpoint Manager console, including feature update deployments or expedited security updates for out-of-band patch releases. There are many features worth exploring with Microsoft Endpoint Manager and you can log in to the admin center at this link: https://endpoint.microsoft.com.

Intune also integrates with other solutions across the Microsoft stack, such as Defender for Endpoint and additional third-party solutions. To view the connectors, log in to the admin center, go to Tenant Administration, and select Connectors and tokens. Here you can also connect the Microsoft Store for Business, view your connection to Configuration Manager, and configure certificate connectors to your on-premises certificate authority.

Next, let's look at an overview of device actions that are available for MDM-managed devices in Microsoft Endpoint Manager.

Devices and remote actions

To view the available remote device actions, go to the device overview by clicking on Devices, choose Windows under By platform, and then search for or select a device. The remote actions will be available in the top toolbar and include the following options:

• Retire will remove managed app data.
• Wipe restores the device to the factory Windows OS.
• Delete removes the device from Intune management.
• Sync forces a check-in to the Intune service for policy.
• Restart forces a device to restart.
• Fresh Start removes any apps (pre-installed OEM) installed on a Windows 10 PC.
• Autopilot Reset reapplies a device's original settings, bringing it back to a business-ready state.
• Quick scan/Full scan will run Defender antivirus scans.
• Update Windows Defender security intelligence will update the Defender malware definitions.
• BitLocker key rotation will rotate BitLocker keys.
• Locate device will send a location signal for tracking geolocation.
• Sync machine policy/Sync user policy actions will force a policy refresh for MECM-connected clients.

The following screenshot shows the available device actions in the toolbar from Microsoft Endpoint Manager:

Figure 6.21 – MEM remote device actions

The Remote device, Sync machine policy, Sync user policy, and App evaluation cycle actions are only available for Configuration Manager tenant-attached devices.

Now that we have looked at an overview of Intune and Microsoft Endpoint Manager, let's cover how to manage policies and baselines using Intune.

Managing policies and baselines in Intune

There are a few areas in MEM for configuring policies, and sometimes that can lead to confusion on where to configure them and increase the potential for policy conflicts on the device. It's key to understand what the policies are doing, what method to use to apply them, as well as when to assign them to users or devices. It's particularly important when moving away from GPO-based policy management into modern management to be aware of conflicts and which setting takes priority. Luckily, there are a few options for how to handle this, which we will discuss later in Chapter 8, Keeping Your Windows Client Secure. Let's review the options to apply policies and configurations for Windows. They include the following:

• Intune security baselines
• Endpoint security
• Device configuration profiles
• Device compliance polices
• PowerShell scripts
• Windows Update for Business policies

To leverage the CSPs for MDM and modern management using Intune, the goal is to create the lightest-weight policy payload possible to deliver to the device. When defining how to apply your baseline configurations, it is recommended to use the following approach:

1. Deploy Intune security baselines first. They provide recommended best practices and security settings are preconfigured.
2. Deploy device configuration profiles or endpoint security policies for security-related settings to supplement baselines.
3. Deploy ADMX-based policy templates for Win32 apps or policies not yet available in Intune.

Let's review each configuration option based on the recommendation.

Using Intune security baselines

When building policies in Intune, it is recommended to start here first. Intune's security baselines are preconfigured groups of Microsoft's recommended security settings. They are the MDM equivalent of the GPO security baselines found in the Windows Security Compliance Toolkit. Security baselines are a collective grouping of individual device configuration profiles put together to form one policy that can be targeted at both users or devices for Windows 10 and later platforms. Microsoft frequently releases updated versions of these baselines and allows you to compare the new release to your current baseline for version control directly in Microsoft Endpoint Manager. When you are ready to append your baselines with the newly released policies, all you need to do is change the instance version and the deployment is automatic.

The available security baselines include preconfigured policies for the following:

• Security baseline for Windows 10 and later
• Microsoft Defender for Endpoint baseline
• Microsoft Edge baseline
• Windows 365 security baseline

To view the security baselines in Microsoft Endpoint Manager, log in to the admin center at https://endpoint.microsoft.com, click on Endpoint Security, and choose Security Baselines. The following screenshot is what the portal looks like for managing and monitoring Intune security baselines:

Figure 6.22 – Intune security baselines in MEM

To learn more about Intune's security baselines, visit this link: https://docs.microsoft.com/en-us/mem/intune/protect/security-baselines.

Next, let's look at device configuration profiles in Intune.

Device configuration profiles

Device configuration profiles are where most of the policy settings exist for Windows in Intune. It is recommended to use these settings to supplement the Intune security baselines. In fact, security baselines are just a collection of device configuration profiles already preconfigured by Microsoft. There are a few profile types available when creating a new device configuration profile that include the following:

• Settings catalog for searching all available policies
• Templates, which contain preconfigured groups of settings by function
• Administrative templates for ADMX-backed policies such as Group Policy preferences that exist today
• Custom settings for deploying CSPs yet to be mapped in Intune

The administrative templates and custom settings are options listed under the Templates profile type. After building a profile and selecting the assignment, you can choose to configure scope tags or applicability rules depending on the profile type. These tags help define a criterion that a device must meet for the settings to apply. A scope tag is a custom attribute assigned to a device to help identify it. An applicability rule specifies a property value in relation to the OS edition and version to determine whether a device meets the minimum requirements to apply the profile. The following screenshot demonstrates an applicability rule checking for Windows 10/11 Enterprise and the client must be within the build number range:

Figure 6.23 – Applicability Rules in Intune device configuration profile settings

First, let's look at using the settings catalog to build a custom policy.

The settings catalog

The settings catalog contains all the available MDM-backed settings configurable in Intune. It allows you to build your own policy from scratch and choose from any available mapped MDM setting to design the policy in a way that makes sense for your administrative needs. Using the settings picker, you can search for a variety of settings, including administrative templates, and add them to your profile. As with all device configuration profiles, it also includes reporting capabilities directly in the profile overview after you assign it to users or devices. The following screenshot shows the Settings picker option to add settings to your profile:

Figure 6.24 – Settings picker in Intune

Next, let's look at using templates when creating a device configuration profile.

Using templates

The Templates profile type contains settings that are grouped and organized by specific functions for ease of use. Unlike the settings catalog, where you must build a profile from scratch, you can use templates to build policies based on a category or functionality. A few examples include Delivery Optimization settings for software updates, or Device Restrictions settings for controlling a wide range of settings, from the Windows App Store to password requirements. Templates contain both CSP-backed policies, including the custom profiles type, and administrative templates for ADMX-backed policies. We covered the custom profile type in the Managing devices with Intune section, including a link to the CSP references. Let's review the Administrative Templates options.

Administrative templates in Intune contain thousands of settings structured in a similar way to Group Policy in Active Directory. In fact, they are built around the XML configurations of a GPO. Aside from Windows-specific settings, administrative templates include ADMX-backed policies for Microsoft Office and Microsoft Edge, and support configuring policies for other Win32 and third-party applications, such as Google Chrome, through a process called ADMX ingestion.

Policy assignments can be applied to user and device groups depending on whether the policy is scoped to user-specific or computer-specific settings. When browsing through administrative templates, follow a familiar path of a Group Policy setting. For example, in the following screenshot, policies found traditionally in Computer Configuration Administrative Templates Windows Components Windows Remote Management can be found by using the same path, starting with Windows Components:

Figure 6.25 – Administrative templates in Intune

Administrative templates provide the familiarity and flexibility many administrators are used to when working with Group Policy. Next, let's look at configuring security settings using endpoint security.

Managing endpoint security

Just like a device configuration profile, endpoint security policies allow you to configure MDM-backed settings, but with a specific focus on Windows device security. This provides flexibility by allowing security administrators using Intune to focus more on security-based policies. We covered Intune security baselines earlier in this section, but you can find additional device security features under the Manage section. These include specific policies for Defender Antivirus, disk encryption, and advanced Defender for Endpoint features such as attack surface reduction rules. These policies can be used on their own or to supplement the Intune security baselines. The following screenshot shows the antivirus summary from Endpoint security and lists any policies that are created:

Figure 6.26 – Antivirus summary in Endpoint security

One advantage of endpoint security over device configuration profiles is the ability to assign policies to Configuration Manager tenant-attached devices. This includes non-Intune-managed Windows Server and Windows 10 and later clients.

Next, let's look at using a PowerShell scripts policy to deploy custom scripts.

Deploying PowerShell scripts

The PowerShell scripts node can be found in MEM under the Devices | Policy section. To deploy a policy, the device must be enrolled in Intune. When configuring a PowerShell script policy, you can choose to run the script under the currently logged-on user's credentials, enforce script signature checks, and run the script using 64-bit PowerShell. On the local device, the PowerShell script's function relies on the Intune Management Extension service to check for and run scripts. The process can be found in the service's Microsoft Management Console (MMC). It is recommended to review the documentation in detail to understand all the prerequisites and behavior when using a PowerShell script policy. You can find more information at this link: https://docs.microsoft.com/en-us/intune/apps/intune-management-extension.

Next, let's look at deploying apps in Intune.

Deploying apps in Intune

Deploying apps in Intune follows a similar app deployment methodology to many other device management solutions. Some of the app types supported include the following:

• MSI
• APPX and MSIX
• Web apps
• Store links
• Office click-to-run (C2R) apps
• Microsoft Edge
• IntuneWin file extensions

In addition to custom line-of-business applications, you can connect Intune to Microsoft Store for Business and sync over any purchased modern apps and assign them to your users. In Windows 11, business store apps assigned to your private store have moved to the Company Portal app.

Tip

If creating a policy to block public apps, but while allowing the private store, users will see a blocked message when opening the Microsoft App store on Windows 11.

For handling complex app installations that are not packaged in a single MSI file, you can use the Microsoft Win32 Content Prep tool to package it into an IntuneWin file and deploy it through Intune. For more information on packaging Win32 apps for Intune, visit this link: https://docs.microsoft.com/en-us/mem/intune/apps/apps-win32-prepare.

For more information regarding application deployment in general using Intune, visit this link: https://docs.microsoft.com/en-us/mem/intune/apps/apps-windows-10-app-deploy.

Next, let's look at an overview of device compliance policies and how they can be used to control access to company resources.

Overview of device compliance policies

One great benefit of managed devices is the ability to set compliance requirements that must be met to ensure security settings are in place to gain access to company resources. When a Windows device is evaluated, Intune leverages Azure AD to keep a compliance status. This status, coupled with conditional access, allows administrators to block or apply restrictions to devices until they meet the rule requirements set by the policies.

The following screenshot is the device compliance overview of a managed Intune device. There are six separate compliance policies assigned to this device used in the compliance evaluation:

Figure 6.27 – Device compliance state of an Intune managed device

Actions can be configured for devices that are non-compliant, and these are as follows:

1. Mark a device as non-compliant.
2. Send an email to the end user.
3. Retire the non-compliant device.

The Device compliance status can then be used as an access condition for a conditional access policy; for example, a conditional access policy assigned to all users that states that access to SharePoint Online requires multi-factor authentication or a compliant device. If the user's device falls out of compliance, then they must use multi-factor authentication to access SharePoint Online even if on a company-issued device.

We recommend configuring Windows compliance policies for the following evaluations:

• Windows device health attestation rules requiring BitLocker, Secure Boot, and code integrity.
• Windows device properties setting a minimum OS version. This will help ensure that devices are patched or otherwise marked as non-compliant.
• Windows Security policies to block simple passwords, require a minimum length of 6 characters, and lock a device after 15 minutes of inactivity.
• Require data storage encryption.
• Windows device security policy that requires a firewall, antivirus, and antispyware solution to be enabled.
• Require a Trusted Platform Module (TPM) to be present.
• Require the Microsoft Defender for Endpoint solution to be enabled with real-time protection and up-to-date signature definitions.
• Require a machine risk score to be medium or lower from Microsoft Defender for Endpoint.

  Tip

  Co-management customers can also leverage Configuration Manager compliance as an evaluation condition for devices.

At the time of writing, Microsoft has added a custom compliance policy setting for use with a discovery script for added flexibility.

When building your compliance policies, it will help keep you organized by separating them by function in the event you need to troubleshoot issues with evaluation. In the following screenshot, the compliance settings are categorized by functions that can serve as a guide when building your own policies:

Figure 6.28 – Compliance settings in Intune

Tip

Be careful when assigning policies to both user and device groups. This could cause a policy to try and be evaluated in both contexts and could cause false compliance evaluations.

Now that we have provided an overview of Microsoft's unified endpoint management solutions, let's discuss different scenarios for administering security baselines for Windows clients and servers.

Administering a security baseline

Once we have chosen our framework and designed and built our policies and standards, we need to start applying our baselines to managed devices. There are many scenarios and device states that play a factor in your administration decision and more than one way to deploy baselines. Technical limitations aside, each method will have its own pros and cons and you might find taking more than one approach to complement the next is preferred depending on your environment.

Deploying managed configurations

The following chart can act as a reference when deciding what solution best suits your environment. This list is not all-inclusive, but these are the most common methods for administering baselines on enterprise-managed PCs:

Figure 6.29 – Scenarios for administering a security baseline

Be mindful when choosing the application method and simplification is best to avoid creating conflicts.

Summary

In this chapter, we covered administration and policy management and the importance of managing devices. We started with an overview of device administration and the different ways in which Windows devices can connect and register to your domain. We then learned about Configuration Manager and how to securely deploy clients and manage policies and configurations.

Next, we walked through managing devices with Intune. We discussed the differences between MDM and MAM and covered how to use Intune with Microsoft Endpoint Manager. We talked about managing policies and baselines in Intune and recommendations on how to apply policies when using MDM. Finally, we covered different scenarios for how to administer security baselines to managed devices.

In Chapter 7, Deploying Windows Securely, we will cover different ways to build and deploy hardening images, covering different tools and techniques for Windows clients, servers, and virtualized environments.