Chapter 9: Keeping Your Windows Client Secure – Mastering Windows Security and Hardening

Chapter 9: Keeping Your Windows Client Secure

In this chapter, you will learn about the best practices and techniques that are used to keep the Windows operating system (OS) secure. So far, we have covered many technologies that make up a robust and well-rounded security program. This includes administration and management tools, hardware security, network security, and an identity management program. This chapter, along with Chapter 10, Keeping Your Windows Server Secure, will cover the core of what this book is about, directly securing and hardening the OS that your users use.

Securing your Windows client is a critical task, and it is one that requires ongoing maintenance and operation in order to protect your devices as vulnerabilities continue to evolve and grow. In this chapter, we will cover how to keep your Windows devices up to date by deploying Windows Update for Business and securing your devices with advanced hardening configurations. Then, we will finish the chapter by discussing configuring Windows 10 privacy settings.

This chapter will include the following topics:

  • Securing your Windows clients
  • Introducing Windows Update for Business
  • Advanced Windows hardening configurations
  • Windows 10 privacy

Technical requirements

There are many walk-throughs throughout this chapter that will instruct you on how to enable different types of settings. In order to follow along, you must have an Azure Active Directory (Azure AD) tenant configured and administrative rights to manage resources in Azure. You will also need Active Directory Domain Services configured to follow along with the Group Policy guides. In addition, a few services that we cover will require licenses and infrastructure in order to follow the references in this chapter. They include the following:

  • Microsoft Intune License
  • Configuration Manager hierarchy

Let's start by learning how to secure your Windows clients.

Check out the following video to see the Code in Action:

Securing your Windows clients

It's important to keep up to date with your workstation OS because once a product is made end of life by Microsoft, they no longer invest time to release updates for these products. Extended support is available in some instances. However, generally, outdated OSes will only provide hackers more incentive to target these systems. If you aren't on Windows 10 already, start planning an upgrade as soon as possible!

Currently, there are no plans to increment the major build number to version 11 or 12. New builds (known as feature updates) are released at no charge to users if their license is valid. Depending on the edition, updates are released on servicing channels and can be configured through various means, including automatic updates through Windows Updates, Windows Update for Business, and Windows Server Update Services (WSUS), and they can be delivered and configured through tools such as Intune, Configuration Manager, or Azure Automation Update Management.

Windows as a Service (WaaS) is a concept that was first introduced with Windows 10. While this idea is multi-faceted, it typically revolves around Microsoft's continued effort to improve the deployment and servicing of Windows clients. Traditionally, a servicing strategy involves extensive IT effort along with the coordination of end users to schedule support time for tasks such as re-imaging, updating, and deploying PCs. This also limits the speed of which new features become available and slows the security update process that helps protect the organization and enable new technology for users. Key concepts to understand with Windows as a Service include the types of updates delivered as well as the servicing channels that determine "when" the updates will be available. This will be covered in more detail in the Introducing Windows Update for Business section.


You can learn more about Windows as a Service at

First, let's take a look at Windows Update for Business and provide you with the information that is needed to configure Windows Updates with Intune.

Introducing Windows Update for Business

One of the major differences between Windows Server Update Services (WSUS) and Windows Update for Business is a direct connection from the computer endpoint to the Windows Update service when it's configured using the Windows Update for Business policies. Updates are no longer approved and deployed granularly according to "what" type or KB, as is the case with WSUS, but managed to the level of "when" they are deployed. Windows Update for Business, also sometimes referred to as WufB, can be configured by Intune or Group Policy. Let's take a look at a few key concepts to understand the types of updates delivered and the servicing channels that determine "when" updates will be available to devices:

  • Feature Updates are released twice a year, usually around the end of Q1 and Q3. These are the major build releases in Windows, and they offer the latest updates in security features and UI enhancements.
  • Quality Updates can be scoped to security and non-security-related fixes. Quality updates include critical updates, security patches, drivers, updates to the servicing stack (windows update service), and Windows product updates. Typically, these are the patches that are released on "Patch Tuesday."
  • Driver Updates can be delivered through Windows Updates and toggled on or off.
  • Microsoft Product Updates are updates targeted to Windows Apps and Office products.
  • There are two types of release schedules available when configuring update policies, and they are as follows:
  • Semi-Annual Channel is the "production" or regular servicing channel that receives feature updates twice per year.
  • Windows Insider Program is for the release available prior to general availability. This allows organizations to test builds, validate compatibility, and send feedback to Microsoft before they are released into production.

Microsoft recommends using deployment rings to deploy Windows features and quality updates. This will allow you to specify groups of computers to deploy updates to and pilot updates before rolling them out to all your systems. A common scenario would be to separate your deployment rings by department. Depending on the number of devices, you can create an early adopter or pilot user group for each department and a production or general release ring. This will allow time for the pilot group to validate and report to the IT team that there are no issues. It's important when deciding on test groups that there is equal representation across the different business workloads and app personas that exist in your organization. One example of this could be to create groups for Finance, HR, and IT and choose 10-15 people who are willing to provide feedback and offer insights to their update experience. These groups should receive the update well in advance of others in their departments, and they should have a clear escalation point to IT so that it can be determined whether an update has broken a critical business app. Luckily, Intune Windows 10 Updates has a pause and rollback feature in case there are problems that need to be mitigated from the pilot phase discovery.

The following screenshot demonstrates the use of deployment rings to target subsets of user devices and incrementing the feature and quality update deferral periods:

Figure 9.1 – Windows 10 update rings in Intune

For more information about building update deployment rings for Windows 10, visit

Next, let's take a look at how to build and deploy Windows 10 update policies using Intune.

Configuring Windows updates in Intune

Follow these steps to configure Windows 10 update deferral periods, specify installation maintenance times, and set update deadlines:

  1. Log in to the Microsoft Endpoint Manager Admin Center at
  2. Click on Devices and choose Windows 10 update rings. Click on + Create profile.
  3. Give it a friendly name such as Procurement – Pilot Users and a description. Click on Next.
  4. Set the Update settings, as shown in the following screenshot:

    Figure 9.2 – Update settings in the Windows 10 update policy in Intune

  5. In User Experience Settings, set the following values:

    Automatic Update Behavior: Auto install and restart at maintenance time

    Active hour start: 8 AM

    Active Hours end: 5 PM

    Restart checks: Allow

    Option to pause Windows updates: Disable

    Option to check for Windows updates: Enable

    Require the user's approval to restart outside of work hours: Not Configured

    Remind user prior to required auto-restart with dismissible reminder (hours): 4

    Remind user prior to required auto-restart with permanent reminder (minutes): 30

    The active hours start and end periods determine the time during which updates will be suppressed. Using the Auto install and restart at maintenance time option will allow the PC to reboot during the maintenance window outside of the device's active hours setting.

    For more information about managing device restarts and the different update behaviors, visit

  6. In the Use deadline settings, let's configure the number of days during which a user must install feature and quality updates before they are automatically applied:

    Deadline for feature updates: 7

    Deadline for quality updates: 3

    Grace period: 2

    Auto reboot before deadline: yes


    New update behavior settings are frequently being added to Intune. Some of the settings are not available in all Windows 10 versions. Research which settings are available before deploying them to your users.

  7. Click on Next. Choose a group to assign the policy to and click Next.
  8. Click Review + Create and choose Create to build the policy.

Windows update policies can be assigned to both user and device groups. If your organization has many shared devices, then we recommend using device groups to avoid assignment conflicts that can occur from multiple users logging in to the same shared device. One strategy would be to use Azure Automation to dynamically populate device groups based on the user's primary device. Then, you can assign the policy to the device group but organize the deployment by users.

Managing update deployments

In the Microsoft Endpoint Manager admin center, go to Devices and choose Windows 10 update rings. Select the profile that was created earlier. In the Overview section, notice the toolbar and its available actions. Here, you can decide to pause both feature updates and quality updates. There is also an option to uninstall them if you need to roll back. If you use the Pause feature, updates are paused for up to 35 days. If you need to extend this, use the Extend feature.

The following screenshot shows all of these actions from within the deployment ring:

Figure 9.3 – Windows 10 update rings in Intune

Let's now take a look at the monitoring section.

Monitoring update deployments

Under the monitoring section, there are three built-in reports for the Device status, User status, and the End User update status to help monitor the profile settings. The Device status and the User status will display the deployment status of the Windows Update profile against the members of the groups to whom the profile was assigned. The end user update status will give you details about the current device's Quality Update Version and Feature Update Version. As you can see in the following screenshot, additional information is provided, listing the name of the device, the user, the last scan time, and the device's last check-in time:

Figure 9.4 – End user update status in Windows 10 Update profile

While this provides a helpful overview of the current status of your quality and feature updates, the end user update status doesn't provide much in-depth information about the overall compliance of your updates, nor any troubleshooting information for failed installations. We recommended deploying the Update Compliance solution in Log Analytics.

The following diagram is from the WaaSUpdateInsights solution, which is available for free in Log Analytics. The solution will break down the rollout of security updates, feature updates, Defender AV signature updates, and Delivery Optimization (DO) settings:

Figure 9.5 – Security update deployment status in Update Compliance

Next, let's take a look at the advanced Windows hardening configurations to help protect your ecosystem of devices.

Advanced Windows hardening configurations

Next, let's look at the advanced Windows hardening configurations to deploy to your client workstations. These configurations will cover user authentication with biometrics and PINs, risk prevention by setting up Defender AV scan settings and SmartScreen filters, and the protection of user data with BitLocker Drive Encryption. We will also discuss how to mitigate common attack vectors, such as name resolution poisoning and Man-in-the-Middle (MITM) attacks, that can be overlooked in your default Windows baseline policies and put your systems at risk from an inside attack.

First, let's look at using Windows Hello for Business to replace passwords as an authentication mechanism.

Enabling Windows Hello for Business

Windows Hello for Business is a great first step in a passwordless journey and enables the use of biometric sensors or device PINs as an alternative way to log in to Windows. Windows Hello for Business is backed by an asymmetric public/private key pair or certificate-based authentication, which can be used to authenticate with Azure AD, on-premises AD, and other identity providers that support Fast ID Online v2 (FIDO). When a user registers for Windows Hello for Business through a new device enrollment, or later on through the Windows settings app, the credentials are bound to the device, and the public key is mapped to an identity provider such as Azure AD. The validation of this pairing occurs through a two-step verification during the registration process. Keys can be generated either by a device's hardware Trusted Platform Module (TPM) or by software, and they can be configured in the deployment settings. Currently, Windows Hello for Business supports the following types of authentication mechanisms:

  • Device PIN
  • Fingerprint or face biometric authentication
  • Phone sign-in when using Windows Hello for Business PIN on an Azure AD joined companion device

For more information about using Windows Hello biometrics in an enterprise, refer to

For more information on Why a PIN is better than a password, visit

Let's use Intune to configure Windows Hello for Business and set PIN requirements using these steps:

  1. Log in to
  2. Choose Devices and select Windows under the By platform menu. Choose Windows Enrollment to edit the enrollment settings.
  3. Select Windows Hello for Business under General. Change the dropdown, and Configure Windows Hello for Business to Enabled.
  4. Click on Save to apply and assign the policy to all users.

The Windows enrollment settings in Microsoft Endpoint Admin Center are where you can configure options such as automatic enrollment to Intune with Azure AD join and configure autopilot profiles. Select Windows Hello for Business to configure the preceding settings:

Figure 9.6 – Windows enrollment settings in Intune

The default settings are a good starting point and offer a balance of both security and usability for your users. Modify any settings as necessary to meet your baseline requirements.

When users enroll a new device or log in with their passwords after the settings have been applied, Windows will prompt them to configure a Windows Hello for Business login method. The available options will depend on whether the underlying hardware supports it. Users can also modify or configure additional sign-in methods using Sign-in Options from the Settings app, as shown in the following screenshot. If these settings have been set with Intune or Group Policy, users will see the message *Some of these settings are hidden or managed by your organization:

Figure 9.7 – Windows Hello for Business Sign-in options in the Settings app

Next, let's look at how to configure BitLocker encryption using Intune and leverage Azure AD to store recovery keys.

Managing BitLocker encryption

BitLocker encryption is a common technology used to encrypt device data on disk drives. Historically, BitLocker was deployed and managed using the Microsoft BitLocker Administration and Monitoring (MBAM) tool, which is part of the Microsoft Desktop Optimization Pack (MDOP), through Group Policy administrative templates. The MBAM administrative interface is used to report compliance, manage configurations, and store recovery key information for organizations. MBAM can also integrate with Configuration Manager for native functionality directly from the Configuration Manager console. Microsoft recently announced that MBAM development ended in 2019 and its services will be deprecated in 2024: It is strongly recommended that you start leveraging Azure AD and Intune to deploy and manage BitLocker Drive Encryption settings as soon as possible. For an in-depth overview of BitLocker Device Encryption in Windows 10, we recommend visiting

Using Intune and Azure AD, BitLocker can be managed using device configuration profiles, Intune security baselines, or by manually using the BitLocker Configuration Service Provider (CSP). Follow these steps to enable BitLocker Device Encryption for Windows 10 devices using a device configuration profile and save your recovery keys to Azure AD:

  1. Sign in to
  2. Go to Devices and choose Configuration Profiles under Policy.
  3. Create a profile and give it a friendly name, such as Windows 10 - Bitlocker. Enter a description and choose Windows 10 and later from the Platform dropdown.
  4. Choose Endpoint Protection as the profile type and click on Settings. Choose Windows Encryption.


    There are many available configurations for Windows encryption. By enabling BitLocker, a recommended set of minimum requirements is configured. Each organization may have its own unique encryption standards and policies.

  5. Change Encrypt Devices to Require.
  6. Change Configure encryption methods to Enable. Leave the default settings as they are.
  7. Under the BitLocker OS drive settings, change Additional authentication at startup to Require.
  8. Change OS drive recovery to Enable.
  9. Change Recovery options in the BitLocker setup wizard to Block.
  10. Change Save BitLocker recovery information to Azure Active Directory to Enable.

    Important note

    Make sure that you enable this setting to store your BitLocker keys in Azure AD.

  11. Change Store recovery information in Azure Active Directory before enabling BitLocker to Require.
  12. Change Write access to fixed data drive not protected by BitLocker to Block.
  13. Change Fixed drive recovery to Enable.
  14. Change Recovery Options in the BitLocker setup wizard to Block.
  15. Change Save BitLocker recovery Information to Azure Active Directory to Enable.
  16. Change Store recovery information in Azure Active Directory before enabling BitLocker to Require.
  17. To enable BitLocker on removable drives such as USB, change Write access to removable data drive not protected by BitLocker to Block.
  18. Choose OK, and then click on Create to build the profile. Click on Assignments under Manage, and select a device security group to assign the profile to.

Once the profile makes its way to the device after the next policy sync, the user is prompted via a toast notification to enable device encryption, which opens the BitLocker Drive Encryption wizard.


Changing the Warning for other disk encryption setting to Block will attempt to silently enable BitLocker; otherwise, the user will be asked. WARNING: Turning on BitLocker with another device encryption solution enabled can render the device unusable.

The BitLocker recovery key will be stored in Azure AD and is recoverable by both the end user and the Azure cloud device administrators. The following screenshot shows the Recovery keys option under the Monitor menu when you view information about a managed intune device:

Figure 9.8 – Recovery keys in Microsoft Endpoint Manager admin center

End users can self-service their BitLocker recovery keys by logging in to and choosing their name (located in the top-right corner). Then, simply select Profile and then Get BitLocker keys next to your device name. A popup will display the PC name and recovery key, as shown in the following screenshot:

Figure 9.9 – Self-service recovery key from the apps Access Panel profile

Next, let's look at real-time protection settings by configuring the Windows Defender AV scan settings using Intune.

Configuring Windows Defender AV

Windows Defender is built into Windows 10 out of the box with a predefined set of configurations. By default, protection is enabled, and virus definition updates are delivered through the Windows Update service unless they are configured differently. Let's take a look at configuring real-time protection scan settings in order to optimize your Windows Defender protection. Follow these steps to create a device configuration profile in Intune to manage Defender AV settings. For more information about configuring Windows Defender AV scanning options, visit

  1. Sign in to
  2. Click on Devices, choose Windows, and select Configuration Profiles under Windows Policies. Click on Create Profile to build a new device configuration profile.
  3. Give it a friendly name, such as Windows 10 – Defender Antivirus, and a description. Choose Windows 10 and later as the Platform type and Device restrictions as the Profile type.
  4. Choose Microsoft Defender Antivirus. The following table lists a recommended configuration baseline for your consideration:

    Figure 9.10 – Defender AV scan recommendations for device configuration profiles

  5. Click on OK and OK again, and choose Create to build the new profile.
  6. Click on Assignments and select a device group to assign the profile to.

When configuring the profile, we skipped over a few configurations, one of which was to configure actions on detected malware threats. Many settings are only applicable to certain device platforms or when choosing Not configured, which will accept the default out-of-the-box settings.

Next, let's learn how to add some additional protection for websites and downloaded applications by configuring Microsoft Defender SmartScreen.

Enabling Microsoft Defender SmartScreen

Microsoft Defender SmartScreen is a protection feature that is used to help deter or block your users from visiting potentially malicious websites and running harmful files downloaded from the internet. SmartScreen cross-checks the potential website or file against a list of reported phishing sites and files downloaded by other Windows users. If the site or file in question is found, a warning notification will be presented to the user. SmartScreen for websites (previously known as SmartScreen filter) and downloaded files can be configured by Group Policy or MDM. The following screenshot shows a SmartScreen notification that is blocking the execution of a known malicious file:

Figure 9.11 – Windows Defender SmartScreen blocking a malicious app

Let's configure Defender SmartScreen for both apps and websites using Intune by following these steps. You will be creating two separate profiles:

  1. Sign in to
  2. Click on Devices, choose Windows, and select Configuration Profiles under Windows Policies. Click on Create Profile to build a new device configuration profile.
  3. Give it a friendly name, such as Windows 10 – Defender SmartScreen, and a description. Choose Windows 10 and later as the Platform type and Endpoint Protection as the Profile type.
  4. Click on Settings and choose Microsoft Defender SmartScreen. Enable SmartScreen for apps and files and leave Unverified files execution as Not Configured.
  5. Click on OK and OK again, and choose Create to build the profile.
  6. Click on Assignments and select a security group of devices to which you want to assign the policy.
  7. Repeat steps 1 to 3 to create a new profile. Choose a unique name such as Windows 10 – Defender SmartScreen Web Filter. Choose Windows 10 and later as the Platform type and Device Restrictions as the Profile type.
  8. Select Microsoft Defender SmartScreen. Set SmartScreen for Microsoft Edge to Require, and choose Block for Malicious Site Access.
  9. Click on OK and OK again, and choose Create to build the profile.
  10. Click on Assignments and select a security group of devices to which you want to assign the policy.

The following screenshot is an example of a known malicious website being blocked:

Figure 9.12 – Website blocked by the Microsoft Defender SmartScreen filter

We have now covered several great security features of Windows, including Windows Hello for Business, BitLocker encryption, Windows Defender AV, and configuring SmartScreen. Next, let's look at additional advanced hardening configurations to prevent intruders from intercepting communications that can lead to breached accounts.

Preventing name resolution poisoning

When a Windows system attempts to communicate using internet protocols such as TCP/IP, UDP/IP, or ICMP/IP, it must discover the IP address of the destination system in order to create the communication. To do this, Windows will attempt to use a local hosts file or send a DNS request in the hope that it finds the entry. It's when these methods fail that communications become prone to name poisoning exploits. If a request fails, the Windows system will attempt to send two additional types of requests over the local network to facilitate a response. They are known as Link-Local Multicast Name Resolution (LLMNR) or NetBIOS Name Service (NBT-NS) type requests. If you are using the popular Google Chrome browser, an additional service, known as a Multicast Domain Name System (mDNS), will also be enabled and prone to the same types of attacks.

If an attacker gains access to your network, they can set up fake services in order to trick clients into connecting to them by offering responses to these unanswered requests. The malicious services will present a fake login prompt that can trick the user into entering their credentials, which ultimately results in the capturing of password hashes. These hashes are harvested and can later be cracked by using various cracking techniques. Let's take a look at LLMNR first and learn how to disable it.

Link-Local Multicast Name Resolution

Using a tool such as Responder (, an attacker can intercept multicast requests if they are not disabled on your devices. In the following screenshot, a poisoned answer was sent to a PC from a multicast request on the local network. An attacker can then coerce a user into entering their credentials into a false prompt that results in a captured password hash. The LLMNR protocol is enabled by default in Windows systems:

Figure 9.13 – Responder sending a poisoned LLMNR response to a client

The following screenshot shows a successful poisoning attack extracting the password hash:

Figure 9.14 – Successful capture of a password hash

LLMNR can be disabled using the following registry key:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
  • EnableMulticast REG_DWORD value of 0

To disable LLMNR with Group Policy, follow these steps:

  1. Open the Group Policy Management Console and create or modify an existing GPO.
  2. Go to Computer Configuration > Administrative Templates > Network > DNS Client.
  3. Open the Turn off multicast name resolution policy and set it to Enabled.

Once the policy has been applied, an attempt to poison the LLMNR protocol response has been rectified. The following screenshot shows no successful attempts to poison any responses to the target system:

Figure 9.15 – No responses found using the LLMNR protocol


We strongly encourage that you understand the use of the LLMNR protocol and how it can adversely affect workstation communications before disabling it. Some organizations may need to consider additional network access controls and rely on strong password requirements as mitigation if this cannot be turned off.

Next, let's look at the NetBIOS name service and how to disable NetBIOS over TCP/IP for network interfaces.

NetBIOS Name Service (NBT-NS)

NBT-NS is another broadcast protocol over TCP/IP that, like LLMNR, is leveraged by the Windows system to find resources. It is enabled by default for all interfaces in Windows and can be exploited in a similar way to the LLMNR protocol. If the Windows system localhost's file or inquiry to DNS cannot resolve the request, then it will resort to using NBT-NS to find the resource. Any rogue system can then respond to these broadcast messages and send poisoned responses.


As previously mentioned for LLMNR, disabling NetBIOS can break communication with your systems if broadcast messages are being used to resolve NetBIOS queries. This should be understood carefully before disabling.

To view the NetBIOS settings of an adapter, open the Network and Sharing Center and click on Change adapter settings. Double-click on your Ethernet adapter, select Internet Protocol Version 4 (TCP/IPv4), and choose Properties. Click on Advanced and choose the WINS tab. As you can see in the following screenshot, NetBIOS settings are set to default, which enables NetBIOS over TCP/IP:

Figure 9.16 – The WINS tab in Advanced TCP/IP Settings of a network interface

Unfortunately, NBT-NS must be disabled on all interfaces on a system and cannot be accomplished using Group Policy alone. Let's look at how we can use a PowerShell discovery script and a Configuration Manager configuration item to detect and disable NetBIOS over TCP/IP for all interfaces:

  1. Open the Configuration Manager console. Go to Assets and Compliance > Compliance Settings > Configuration Items and click on Create Configuration Item.
  2. Give it a friendly name, such as Disable NetBIOS Interfaces, and click on Next.
  3. Click on Next at the Supported Platforms menu options to keep the default settings:

    Figure 9.17 – Create Setting in a configuration item

  4. Under Discovery script, select Add Script….
  5. Keep Windows PowerShell selected and let's build the discovery script.

The first section of the code will define the $NBTNS variable. We will use the Get-ItemProperty cmdlet to look in the following registry hive and enumerate all of the TCPIP_GUID keys that start with tcpip using a * wildcard. We want to look specifically at the REG_DWORD value of NetbiosOptions. In this location of the registry, there can be many entries depending on the number of network adapters used:

$NBTNS = Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\tcpip* -Name NetbiosOptions

  • The NetbiosOptions value of 0 is the default.
  • The NetbiosOptions value of 1 is enabled.
  • The NetbiosOptions value of 2 is disabled.

In the following screenshot, you can see the amount of unique TCPIP_GUID values to potentially look through:

Figure 9.18 – TCPIP_GUID network adapters stored in the registry

Next, we will create an IF statement that says that if the value of NetbiosOptions does not equal 2, set the $NTBNSCompliance compliance variable to No. If it does equal 2, set it to Yes:

If (!($NBTNS.NetbiosOptions -eq "2")){ $NBTNSCompliance = "No" } Else { $NBTNSCompliance ="Yes" }

Now, we will print the output of $NBTNSCompliance so that Configuration Manager can use it for evaluating compliance, as shown in the following screenshot:

Figure 9.19 – Edit Discovery Script of a Configuration Item

Click on OK. Then, click on Add Script under Remediation Script. Keep Windows PowerShell as the script language.

In order to remediate each unique network adapter, we will use the Set-ItemProperty cmdlet to change all of the NetbiosOptions REG_DWORD values to 2 for each unique TCPIP_GUID:

Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\tcpip* -Name NetbiosOptions -Value 2

The following screenshot shows the Edit Remediation Script dialog box with the script code used for this task:

Figure 9.20 – Edit Remediation Script in a configuration item

  1. Click on OK, and then click on the Compliance Rules tab in the Create Setting dialog box. Click on New to create a new compliance rule.
  2. Give it a friendly name, such as Disable NetBIOS. In The setting must comply with the following rule, leave Equals selected and enter Yes in the box.
  3. Select both Run the specified remediation script when this setting is noncompliant and Report noncompliance if this setting instance is not found.
  4. Choose Information for Noncompliance severity for reports. Click on OK, click on OK again, and choose Next back in the Create Configuration Item Wizard.
  5. Click on Next a few times to complete the wizard and build the configuration item.

For this configuration item to be used in the evaluation of compliance and for remediation, create or assign it to an existing security baseline. We covered creating a security baseline in Chapter 8, Administration and Remote Management, specifically in the Building a configuration baseline section.

After the security baseline has been assigned and evaluated on a source system, we can confirm the configuration by checking the interface settings. The following screenshot shows that Disable NetBIOS over TCP/IP is selected in the Advanced TCP/IP Settings of this network adapter:

Figure 9.21 – Advanced TCP/IP Settings of a network adapter

Next, let's take a look at disabling a feature enabled with the Google Chrome browser, known as mDNS, which can similarly be exploited as an attack vector.

Disabling Google Chrome mDNS

The Google Chrome browser includes a built-in mDNS service known as Bonjour, which is used in its broadcasting technology for locating computers and streaming devices. The Google Chrome mDNS service is generally unnecessary in a corporate environment, although it is useful for consumers for streaming to home media devices or using Chrome's Google Cast. As we learned with the LLMNR protocol and NBT-NS earlier, mDNS is prone to the same types of request/response poisoning, which makes it an exploitable attack vector for someone inside your network. The following screenshot is the Google Cast functionality in the Chrome browser:

Figure 9.22 – Google Cast from the Chrome browser

It is recommended that you mitigate the risks associated with Google Chrome mDNS by disabling Google Cast and blocking the Google Chrome mDNS service with a firewall rule. Let's look at how to accomplish this.

When Google Chrome is installed, it creates an inbound firewall rule, with the display name Google Chrome (mDNS-in), allowing communication on port UDP 5353 inbound for all profiles, as follows:

Figure 9.23 – Windows Defender Firewall with Advanced Security Inbound Rules

With netstat and process monitor (ProcMon) logging enabled, using Google Cast will show that chrome.exe is leveraging communications over UDP 5353:

Figure 9.24 – The netstat output showing that chrome.exe is using UDP 5353

Unfortunately, just disabling this firewall rule will not work because, each time Google Chrome updates, the rule will be re-enabled. For this scenario, we can turn to a discovery/remediation script and use Configuration Manager as the compliance engine. Let's demonstrate how to do this using these steps:

  1. Open the Configuration Manager console. Go to Assets and Compliance > Compliance Settings > Configuration Items and click on Create Configuration Item.
  2. Give it a friendly name, such as Google Chrome Security, and click on Next.
  3. Click on Next in support platforms to keep the default settings. Click on New in Specify settings and enter the following settings:

    Figure 9.25 – Create Setting in a configuration item

  4. Under Discovery script, select Add Script….
  5. Keep Windows PowerShell selected, and let's build the discovery script.

We will be using the Get-NetFirewallRule PowerShell cmdlet to find a rule that matches the display name of Google Chrome (mDNS-In). Let's set the $ChromeMDNS variable and use the cmdlet to filter and return any results that match the display name:

$ChromeMDNS = (Get-NetFirewallRule | Where {$_.DisplayName -eq "Google Chrome (mDNS-In)"})

Next, we want to use an IF statement to determine whether the property dereference operator of the action on the $ChromeMDNS variable is set to Allow. Based on the return, we will use it to set a variable for compliance, called $ChromeMDNSCompliance. If the firewall rule is set to allow, set the compliance variable to No, or else set it to yes:

If ($ChromeMDNS.Action -eq "Allow"){ $ChromeMDNSCompliance = "No" } else { $ChromeMDNSCompliance = "Yes" }

Finally, print the output to be used for evaluating compliance:


The compliance evaluation shows the full code source in the Edit Discovery Script window:

Figure 9.26 – The Edit Discovery Script window

  1. Click on OK. Click on Add Script under Remediation Script. Keep Windows PowerShell as the script language.

    We will leverage the Set-NetFirewallRule cmdlet to block any firewall rule that is found with the display name Google Chrome (mDNS-In):

    Set-NetFirewallRule -DisplayName "Google Chrome (mDNS-In)" -Enabled True -Action Block

  2. Click on OK and then click on the Compliance Rules tab in the Create Setting dialog box. Click on New to create a new compliance rule.
  3. Give it a friendly name such as Disable Chrome mDNS-In. In The setting must comply with the following rule, leave Equals selected and enter Yes in the box.
  4. Select both Run the specified remediation script when this setting is noncompliant and Report noncompliance if this setting instance is not found.
  5. Choose Information for Noncompliance severity for reports. Click on OK and click on OK again to get back to Create Configuration Item Wizard.

Next, we want to disable Google Cast. Google Chrome has ADMX-backed templates available that can be downloaded from the Enterprise standalone pack and imported into Group Policy. However, since we are building a configuration item, let's look at how to use the registry key and enforce compliance using a security baseline:

  1. Click on New to create a new setting, and enter the information shown in the following screenshot:

    Figure 9.27 – The Create Setting window in a configuration item

  2. Click on the Compliance Rules tab, and enter the settings displayed in the following screenshot:

    Figure 9.28 – Compliance Rule in a configuration item

  3. Click on OK, click on OK again, and then choose Next back in Create Configuration Item Wizard.
  4. Click on Next a few times to complete the wizard and build the configuration item.

Once the configuration item has been created, create or assign it to an existing security baseline where it will remediate for noncompliance. Once the setting is applied, the Cast option is removed from the browser and the firewall rule will be blocked, as shown in the following screenshot:

Figure 9.29 – Inbound Firewall Rules in Windows Defender Firewall

Next, let's take a look at how to prevent an MITM attack by disabling the Web Proxy Autodiscovery Protocol (WPAD).

Disabling the Web Proxy Autodiscovery Protocol (WPAD)

WPAD is used by the Windows system to find a configuration file called wpad.dat, which is used to determine the IP or server to proxy HTTP(S) web traffic. With WPAD enabled, an unknowing computer can broadcast a request to find a proxy either issued through DHCP or DNS. If no resolution is found, an attacker can poison the DNS response and effectively use their system as a web proxy to serve a modified wpad.dat file. Once an unknown victim's machine uses this fake proxy, all web traffic can be monitored through the fake service, including the ability to modify requests and responses using tools such as Burp Suite (MITM). If the attacker's malicious proxy server forces HTTP-NTLM authentication, it can entice users to supply credentials that can lead to captured passwords.

The following screenshot shows the default Windows 10 settings with WPAD enabled. This PC even has the Windows 10 recommended computer baseline applied:

Figure 9.30 – Proxy settings

To disable WPAD, we recommend that you disable two services using Group Policy or registry settings:

  • WinHTTP Web Proxy Auto-Discovery ServiceWinHttpAutoProxySvc

Registry settings can be configured and enforced using both Group Policy and a security baseline in Configuration Manager. Set the following value to disable WinHTTPAutoProxySvc:

  • HKLM\SYSTEM\CurrentControlSet\Services\WinHTTPAutoProxySvc
  • Start REG_DWORD is 4 (this sets the start up mode to disabled)

Once the PC restarts, the service is stopped, and the start up type is set to disabled. Additionally, if a user tries to re-enable WPAD, the setting will not be enforced unless they physically start the service using administrative rights. The following screenshot shows the LAN settings in Internet Properties once the service has been disabled:

Figure 9.31 – Internet Properties > Local Area Network (LAN) Settings

So, we have just covered advanced configurations that are used to prevent attackers from poisoning responses to communications over the network. We covered multicast name resolution, NetBIOS-NS, multicast DNS, and WAPD. Next, let's look at how to configure a Microsoft Office security baseline.

Configuring Office security baselines

Another area that should be considered when hardening Windows is the office suite of applications. Microsoft Office is one of the most widely used sets of applications in Windows systems and is the target of many vulnerabilities. According to the cybersecurity firm Kaspersky, there has recently been a shift in focus for attackers with Microsoft Office as the preferred target in comparison to other attack surfaces, such as browsers, Flash, Java, and PDF file formats. Refer to the following article:

There are several different ways that Office security baselines can be applied. The Microsoft Security and Compliance Toolkit offers a recommended baseline included in its toolkit package for both computer-based and user-based policies. Security configurations can be enforced onto devices using the following:

  • GPOs for AD domain-joined or hybrid Azure AD join
  • The Administrative Templates device profile type for Intune and Azure AD joined devices
  • Configuration Manager security baselines and LGPO packages
  • User-based policies using only the Office cloud policy service for Office 365 ProPlus

The Office cloud policy service for Office 365 ProPlus is the most modern approach to deploying user-targeted office policies. There are some base requirements and limitations to using this service. The web interface, as shown here, is the administrative console used to create policies and build customized installations of Office for deployments:

Figure 9.32 – Office cloud policy service admin center

For more information about the Office cloud policy service, including the minimum requirements to use it, refer to

Let's look at how to use the recommended Office security baselines from the Microsoft Security and Compliance Toolkit in order to create a Configuration Manager configuration baseline and deploy user-based policies with an LGPO package.

Deploying user-based office policies

This scenario works well for co-managed devices where workloads favor Configuration Manager:

  1. Log in to your Configuration Manager site server or location with access to a deployment share for creating packages.
  2. Download the baseline or the latest available version from the Microsoft Security and Compliance Toolkit at the following link and extract it:

  3. Download and extract it.

    The first step is to import the baseline into a GPO to act as a template. We can then make changes to and use this template as a reference point moving forward. Create a testing Organizational Unit (OU) so as not to apply these policies to any production objects. For this example, we created a TestGPO OU under Workstations.

  4. Open the Group Policy Management Console and create a new GPO under a Test OU. Give it a descriptive name, such as Office 365 ProPlus – User 1908.
  5. Find the newly created GPO under the Group Policy Objects folder, right-click on it, and choose Import Settings.

    We are going to want to find the extracted folder with the Office 365 security baseline that we downloaded earlier. Additionally, you may need to import the Office 365 ProPlus ADMX files to map the settings to the GPOs. Otherwise they will not have friendly names. Instructions on how to manage a Group Policy Central Store can be found here:

A download link for the Office 365 ProPlus ADMX files can be found here:

  1. Click on Next and Next again, and then click on Browse to find the location of the GPO's folder from the extracted Office 365 security baseline. Click on Next.
  2. In the list of GPOs, select the MSFT Office 365 ProPlus 1908 – User policy and then click on Next. Click on Next again, and choose Finish. Finally, click on OK a few more times to finish the import wizard.

    There are several other policy files included with the Office baselines, such as newly added configurations to supplement the standard default baseline. It is recommended that you review these policies and append the GPO you created if you wish to include them in the policy. Once all the changes have been added to the GPO, let's back it up and save it to the deployment share. We will be using the .pol file from the backup to apply user policy settings with the LGPO.exe tool via a deployment package.

  3. Go to Group Policy Object, right-click on the GPO, and choose Back up…. Select the destination folder to back up the policy.
  4. Create a new folder in the deployment share where you keep your applications and packages and give it a friendly name.
  5. Navigate to the directory where you backed up the GPO and go to {GUID}\DomainSysvol\GPO\User. Copy the registry.pol file to the directory you created on the deployment share.
  6. Find the LGPO.exe file extracted earlier from the LGPO download and copy it into the same folder as the registry.pol file in the deployment share.


    We will be using this directory in the Configuration Manager package as our source files later. It's important to save the directory to a deployment share so that we can use the Uniform Naming Convention (UNC) network path as the source folder location.

Next, we are going to create a .bat file to kick off the unattended installation of LGPO.exe. For this, we will use Notepad:

  1. Open Notepad and enter the following code. This will call the LGPO.exe tool and use the /u switch to install the registry.pol file user policies. gpupdate /force will apply them immediately:

    @echo off

    LGPO.exe /u %~dp0registry.pol

    gpupdate /force

  2. Navigate to File > Save As, and change Save as type to All files. Enter install.bat in the filename and browse to the directory in the deployment share that has LGPO.exe and Registry.pol. Then, click on Save.

    Next, let's create a package in Configuration Manager for deployment.

  3. In the Configuration Manager console, go to Software Library > Application Management, and choose Packages. Click on Create Package.
  4. Give it a name, such as Office 365 ProPlus – User Policy, and a description.
  5. Select This package contains source files. Click on Browse and choose Browse again. Enter the UNC path to the directory that you saved in the deployment share earlier. Click on OK.
  6. Click on Next. Click on Next on Program Type and keep Standard Program selected.
  7. In the Standard Program menu, enter a name such as Install GPO. Click on Browse in Command Line, and navigate to the deployment share directory with the Install.bat file created earlier and select it.


    By default, the Open dialog box when browsing for a command line is scoped to Executable files. Make sure that you click on the drop-down list and select All Files to find the .bat file.

  8. Enter the information displayed in the following screenshot for Run, Program can Run, and Drive Mode:

    Figure 9.33 – Create Package and Program Wizard in Configuration Manager

  9. Click on Next. Click on Next in the Requirements menu to keep the defaults as they are. This is to allow the program to run on any platform with an unknown disk space and a maximum allowed runtime (minutes) set to 120.
  10. Click on Next in the Summary menu after confirming the settings. Click on Close in the completion screen.
  11. Select the new package and click on Deploy from the toolbar.
  12. Click on Browse and select a device collection. Click on Next.
  13. In the Content menu, click on the Add dropdown, choose Distribution Point Group, and select a distribution point group to distribute content to. Click on OK. Then, click on Next.
  14. In the Deployment settings menu, keep Required selected for Purpose. Select the Allow clients on a metered Internet connection to download content after the installation deadline, which might incur additional costs option.
  15. In the Scheduling menu, select Schedule when this deployment will become available. Then, click on New in Assignment Schedule and click on OK to assign to the following schedule.
  16. Click on the dropdown in Rerun behavior and choose Always rerun program. Click on Next.
  17. In the User Experience menu, select Allow users to run the program independently of assignments. Click on Next.
  18. Select Download content from distribution point and run locally for both deployment options in the Distribution Points menu. Click on Next.
  19. Click on Next after confirming the settings. Click on Close in the Completion menu.

The following screenshot shows the package deployment in Software Center for one of the target workstations:

Figure 9.34 – Package installation in Software Center

Now that we have deployed the LGPO package for Office 365 User policies, we can create a configuration item and baseline to monitor the settings for our compliance reports. We cover the process of creating a configuration item from a GPO step by step in Chapter 8, Administration and Remote Management, in the Creating a configuration baseline from a GPO section.

After importing the template GPO into a configuration item, we built a baseline called Office 365 Security Baseline – User and deployed it in monitor mode to the workstations. When opening the Configuration Manager applet from the control panel on a workstation, you can see the evaluation condition against the LGPO package we deployed earlier in the following screenshot:

Figure 9.35 – The Configuration Manager applet from Control Panel

Now we have a reporting mechanism to use against the user policies. From a life cycle perspective for the user-based policies, use the GPO you created in the TestGPO earlier to act as a template. Any time a change is required, update the GPO and repeat the process here to deploy an updated package and an updated configuration item.

This process may seem tedious, but it works well for Azure AD joined devices where Group Policy is not applicable. If you are using Intune Administrative Templates, there is no way to bulk import all of the recommended Office security baselines at this time, and recreating the baseline would take a lot of time.

Hardening Google Chrome

The Google Chrome browser has quickly become one of the most popular browsers used in organizations today according to statcounter global stats:

Not only is it quick and user friendly, but it also offers cross-platform compatibility and has a great set of built-in configurable security features. Google also offers an enterprise bundle that allows fine-grained control over security policies, add-on extensions, and customizations that can be controlled with Group Policy or by using Google Cloud Management. To download the Google Chrome Enterprise bundle, visit this link:

Included in the bundle is a set of ADMX and ADML files that can be imported into your Central Store for Group Policy management. The Center for Internet Security (CIS) readily releases benchmarks for the Google Chrome web browser, and it is recommended that you download and review these settings in detail. You can download the free benchmarks here:

Let's now look at a few of the policies that should be considered for implementation immediately in order to harden Google Chrome using Group Policy. Once the ADMX and ADML files have been imported to the Central Store, navigate to Computer Configuration > Administrative Templates > Google > Google Chrome. Consider the following settings as a good starting baseline:

Figure 9.36 – Recommended settings for Google Chrome security policy

Navigate deeper into the policy tree to Google > Google Chrome > Content Settings. Consider the following settings as part of the baseline:

Figure 9.37 – Recommended settings for Content Settings

The following table shows additional settings that are worth your consideration:

Figure 9.38 – Additional recommended settings

We will now look at Chrome extensions.

Whitelisting extensions

Extensions are a popular way to enhance the functionality of Google Chrome. From a security perspective, they prove to be difficult to control or report on their use. This is because extensions aren't installed like a normal application running on your Windows systems. One example would be a VPN extension that a user installs to try and circumvent a firewall rule blocking access to a video streaming site. In order to control extensions, it's recommended that you set the following policies under Google > Google Chrome > Extensions:

Figure 9.39 – Recommended extension policies for Google Chrome

By setting the asterisk (*) value in the Configure extension installation blacklist policy, you will effectively block all extensions unless they are specified in the Configure extension installation whitelist policy. An extension ID can be found by going to the Chrome web store here:


By configuring the blacklist policy, users will be prevented from installing any extensions that aren't whitelisted.

Find the extension you want to whitelist. The extension ID is the long string of characters at the end of the URL in the address bar. For example, the extension ID for Windows 10 accounts is ppnbnpeolgkicgegkbkbjmhlideopiji. In the following screenshot, you can see the extension ID in the address bar before the question mark at the end of the URL:

Figure 9.40 – Chrome web store for installing extensions

Next, let's take a look at how to lock down the registry and prevent user modification with Group Policy settings.

Preventing user access to the registry

Another area of consideration for hardening Windows is to restrict user access to the registry through Group Policy. This can help to prevent the unauthorized modification of the registry through the user's context, but it does not protect other administrative sources from making changes. You can prevent access to registry editing tools by using Group Policy and these steps:

  1. Open the Group Policy Management Editor and create a new GPO within an OU that contains user accounts.
  2. Give it a friendly name, such as Windows 10 – Reg Lock. Right-click on it and choose Edit.
  3. Navigate to User Configuration > Policies > Administrative Templates > System. Select Prevent access to registry editing tools.
  4. Choose Enabled and select Yes in the dropdown under Disable regedit from running silently.
  5. Click on OK and close the Group Policy Management Editor.

The next time a user goes to open regedit.exe, even if the user is a local administrator, they will receive a message similar to the following screenshot:

Figure 9.41 – Registry Editor disabled with Group Policy

This will also help to prevent any modification of the registry if malicious codes gain access to the user context and try to make registry modifications.

For the best security and to ensure that other applications do not modify your registry settings without approval, it is recommended that you use AppLocker or Windows Defender Application Control (WDAC) to whitelist an allowed list of applications. Next, let's take a look at WDAC and how it protects your system by policing what applications can run on your Windows systems.

Windows Defender Application Control

WDAC is used to create a whitelist of applications, file paths, and Component Object Model (COM) objects, and can enforce protections such as script signing - on processes to help protect your system from unauthorized applications. WDAC is built around the Zero Trust model in which applications and processes must prove their trustworthiness before they are able to execute. If the application, process, or path is not whitelisted, it will be blocked. Unlike AppLocker, WDAC enforces policies at the device level and cannot be assigned to specific users and groups. Additional protection can be used to complement WDAC when used in conjunction with the hypervisor isolation of Virtualization Based Security (VBS) and UEFI SecureBoot. Both technologies combined have been collectively referred to as Device Guard. WDAC can be deployed separately from VBS. However, without the isolation features that VBS offers, you don't get the full protection of user and kernel-mode operations. WDAC policies can be enabled with Group Policy, Intune, or Configuration Manager.

It is recommended that you thoroughly understand the effects that WDAC policies have on your systems. As mentioned earlier, they are designed with the Zero Trust concept and can block critical applications from running if the policy isn't configured carefully. Deploy a Microsoft Defender Application Control policy in audit mode first to understand the effects on your Windows devices. Once audit mode is enabled, you can view the WDAC logs from Event Viewer under Applications and Services\Microsoft\Windows\CodeIntegrity\Operational. WDAC events can also be queried with the Kusto Query Language (KQL) using Advanced Hunting in Microsoft Defender ATP.

If using Configuration Manager to deploy WDAC policies, you can choose to enable Audit only mode, as shown in the following screenshot:

Figure 9.42 – Deploying an Application Control Policy with Configuration Manager


WDAC policies are built in XML format. They are configured using PowerShell and are converted into binary before they are deployed. Windows has preconfigured base policies that can be used to build your own XML definitions. To view the rules of these policies, use the Get-CIPolicy cmdlet. Example policies are stored in the following path: %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies

Considerations for WDAC or AppLocker

Both technologies are designed to support the policing of applications and files that can run on your Windows systems. The biggest difference between WDAC and AppLocker is that WDAC policies are always targeted at the device level and will affect all users that use the device. With AppLocker, policies can be enforced to specific users or groups of users. While WDAC is the preferred method of applying application control policies for Windows 10, Microsoft still recommends using AppLocker in combination with WDAC if you require a granular level of enforcement.

Configuring customized policies can be extremely time-consuming and may require careful consideration when planning for a deployment. Microsoft has created a lot of documentation regarding the deployment of WDAC policies that should be read in detail before starting an implementation on your Windows device. For more information, refer to

Next, let's look at the different privacy settings in Windows 10 and learn how to configure them.

Windows 10 privacy

Windows 10 has many great features that provide an enhanced and connected experience for its users. As a result, there are many data- and privacy-related settings that are enabled by default that could pose a potential security risk for some organizations. While many of these features are great for consumer use, they may not be applicable to work organizations. Let's run through a few settings and look where to disable them if needed. To configure these privacy settings, we will leverage Intune device configuration profiles. All of the settings in the following table are available via a Windows 10, and later, platform using the Device Restrictions profile type.

This table is a compiled list of base recommendations:

Figure 9.43 – Recommended privacy settings in Intune

For a full list of settings that can be configured using Device Restriction profiles, including the preceding setting definitions, refer to

Controlling the privacy settings for each app

Depending on your organization's privacy policies, configuring settings from the Privacy category in an Intune Device Restrictions profile allows you to configure which features are available for use on a per-app basis. Some of the available settings include the following:

  • Account information
  • Calendar
  • Camera
  • Contacts
  • Email
  • Location
  • Microsoft
  • Notifications

If using the Privacy category to configure these settings, you can use the Per-app privacy exceptions category to explicitly configure which applications are allowed access to use these features. Otherwise, all applications will be blocked.

Additional privacy settings

There are a few additional privacy settings for consideration that are not configurable with Device Restriction profiles. Let's look at how to set the following privacy options using custom profiles and Group Policy:

  1. Disable the device advertising ID that lets apps make ads more interesting to you based on your app activity.
  2. Disable any tailored experiences based on diagnostic data, which are used for personalized tips, ads, and recommendations that enhance Microsoft products and services for your needs.
  3. Set the diagnostic data that is sent to Microsoft to Basic Only.
  4. Disable the app launch tracking that enables Windows to track app launches in order to improve start and search results.

To disable the advertising ID and tailored experiences, create a custom profile Intune Device Configuration profile:

  1. From the Microsoft Endpoint Manager admin center, click on Devices and select Create Profile.
  2. Give it a friendly name, such as Windows 10 – Custom Privacy Settings, and give it a description. Choose Windows 10 and later as the Platform and Custom as the Profile type.
  3. In the Custom OMA-URI settings, click on Add to create a new setting. Create these two configurations with the following settings:

To disable the advertising ID, create the OMA-URI setting, as shown in the following screenshot. Use this OMA-URI string: ./Device/Vendor/MSFT/Policy/Config/Privacy/DisableAdvertisingID:

Figure 9.44 – Custom OMA-URI setting

Once this setting has been configured, click on Add to create an additional setting for Tailored Experiences. To disable Tailored Experiences from using diagnostic data, use the OMA-URI settings shown in the following screenshot. Use this OMA-URI string, ./User/Vendor/MSFT/Policy/Config/Experience/AllowTailoredExperiencesWithDiagnosticData, as follows:

Figure 9.45 – Custom OMA-URI setting

After the row has been added, click on Add to create an additional setting to change the default level of diagnostic data sent to Microsoft. We recommend that you keep the default or, at least, allow the basic setting depending on your organization's privacy concerns. Allowing telemetry data to flow to Microsoft helps to improve their machine learning. To change the level of telemetry to basic, use the OMA-URI settings shown in the following screenshot. Use this OMA-URI string, ./Device/Vendor/MSFT/Policy/Config/System/AllowTelemetry, as follows:

Figure 9.46 – Custom OMA-URI setting


When collecting telemetry in Log Analytics or another solution in Azure, be sure to configure and set System/AllowDeviceNameInDiagnosticData to an integer value of 1 in order to allow the device name to be sent. Otherwise, you will see a # in place of the device name.

Next, let's look at how to disable Windows track app launches in order to improve the start and search results. For this policy, we can use Group Policy or the registry.

If using Group Policy, set the following policy:

  • User Configuration > Administrative Templates > Windows Components > Edge UI

    Enable the Turn off tracking of app usage policy.

To set this setting with the registry, modify the following registry key:

  • HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\EdgeUI

    Set the DisableMFUTracking REG_DWORD to 1.

To check other available privacy settings, open the Settings app, and click on Privacy. You can see two of the settings we just disabled in the following screenshot that are under General:

Figure 9.47 – General options in the Privacy settings

Let's now take a look at the privacy settings for the Microsoft Edge browser.

Privacy settings for Microsoft Edge

Microsoft has recently rebuilt Microsoft Edge based on the open source Chromium project. Its rebirthing, according to Microsoft, will help to realign the browser and contribute to the open source community to deliver improved compatibility across all browsers. As a result, many of the security policies we covered in the Hardening Google Chrome section apply to the Edge browser. To download the latest Microsoft Edge security baselines, visit this link:

Using the Administrative Templates device configuration profile in Intune, and following the guidance of the Security and Compliance Toolkit, you can build and assign an Edge security baseline directly in Intune that is completely customizable. You can also use the Microsoft recommended baseline settings by deploying the Microsoft Edge baseline profile in Intune Endpoint Security, as shown here, from the Microsoft Endpoint Manager admin center:

Figure 9.48 – Microsoft Edge baseline in Intune

All three policy options support the Chromium-based Edge browser. When attempting to change privacy settings in Edge, you will see the briefcase icon that displays the information tooltip, as shown in the following screenshot:

Figure 9.49 – Edge Chromium privacy settings

To download Microsoft Edge for business, visit this link:


In this chapter, we introduced securing end user Windows devices and some of the different Windows 10 versions available. We then covered the Microsoft Defender ATP service by providing a feature overview and guidance for onboarding machines. Following this, we discussed Windows 10 updates using the Windows Update for Business technology and how to configure deployment rings using Intune.

Next, we reviewed advanced Windows hardening configurations, which included technologies such as Windows Hello for biometric authentication, Windows encryption using BitLocker, how to configure Windows Defender AV real-time protection, and SmartScreen. Then, we discussed additional hardening tips to prevent name resolution poisoning and MITM over network communications. We also covered additional hardening tips by discussing Microsoft Office security baselines and hardening Google Chrome. Finally, we finished the chapter with Windows 10 privacy and data protection.

In the following chapter, you will learn how to keep your Windows server secure. We will introduce you to securing your Windows server and reviewing the roles and features within the Windows server. We will also be covering Microsoft Defender ATP and Windows updates before finishing the chapter with a discussion on how to harden your Windows server.