Managing Windows 10 Security Features Using ConfigMgr

ConfigMgr pros are well aware that Windows security is beyond crucial. You also know that Windows 10 is a cornerstone of Microsoft's defense against an ever-growing threatscape.

In this report, I bring these topics—Windows 10, security, and ConfigMgr—together. My aim is to provide enough technical depth for you to know what to do and get it done. I also link to external resources where you might want detailed information or instructions.

Servicing Windows and ConfigMgr

Windows 10

Windows 10 is a service-based operating system, the updating of which differs from the standard approach which has been undertaken for all other versions of Windows.

Previously, operating systems would be updated with new features infrequently. Major versions such as Windows XP and Windows 7 would only be released every few years. This model does not work in today's rapidly changing, always connected world, where new security features and deployment mechanisms are required to meet these needs.

As such, Windows 10 introduces the Semi-Annual Channel (SAC), a twice-yearly update channel where new features are introduced into the operating system. The updates take place around March and September, and each baseline release has an associated servicing period, after which Microsoft drops support for the baseline release.

On September 6th, 2018, Microsoft announced new extended servicing periods for Windows 10 baselines. Previously each Windows 10 baseline had a shorter 18-month lifecycle which caused some concern for businesses. This change allows business more time to test and deploy Windows 10. Existing versions all received a 30-month lifecycle, so adopters of Window 10 1803 now have until November 10, 2020 before an upgrade is required to remain in a supported mode.

For new releases, the March releases will have an 18-month lifecycle and the September releases a 30month lifecycle, for Enterprise and Education editions. The full details are as below:

The Semi-Annual Channel terminology, replaces the Current Branch/Current Branch for Business model, from Windows 10, version 1703, and this aligns with the naming convention adopted with Office 365.

So, how exactly are Windows 10 baseline versions numbered? The first two digits signify the year of release, e.g. 18 is 2018, and the last two digits the month in which it was released, therefore 03 equals

March and 09 September. Currently, Windows 10 is at 1803 baseline version with 1809 the next planned.

The Semi-Annual Channel consists of two phases, Semi-Annual Channel (Targeted) and Semi-Annual Channel.

The targeted phase starts when the baseline version is released; the operating system is not deemed business ready in this phase but should be implemented to a small section of targeted devices in the business to test new features, ensure applications and solutions operate before broadly deploying across the environment.

Microsoft announces the baseline as business ready approximately four months into a baseline's lifecycle, although businesses can adopt them for a broad deployment if no blockers exist internally. The change to Semi-Annual Channel from SAC (Targeted) does not require any re-installation of the Windows operating system. Instead, a simple installation of the latest patch update brings the OS into this phase of the software's lifecycle.

Two other channels exist for Windows 10, and it is worth mentioning these for completeness. These are the Windows Insider, and Long Term Servicing Channel (LTSC).

  • Windows Insider builds allow the business to start validating within the Windows development cycle a full six months before potential new features are introduced in a general release. Adoption, via the Windows Insider Program, means that the business can engage with Microsoft, feeding back information early to assist with compatibility issues and test Line of Business applications with the latest OS.
  • Long Term Servicing Channel is utilized in enterprises where rapid change and disruptive upgrades need to be avoided. Each release of the LTSC will only receive service updates for the duration of its lifecycle, have a mainstream support cycle of 5 years with another 5 years of extended support. The LTSC edition of Windows 10 should only be used on devices with single use cases, such as ATMs or embedded kiosk devices.

The Managing Windows 10 Security Features document will focus on managing the Semi-Annual Channel via Microsoft System Center Configuration Manager (ConfigMgr) only.


To keep up with management of Windows 10, and its new, associated feature set ConfigMgr is also running as a Service. ConfigMgr is no longer running with a major version release, like 2007 & 2012 previously. It is now termed Current Branch (CB), and it adopts the same version naming convention as Windows 10, the first release being 1511.

ConfigMgr is updated three times a year, usually in February, July and October. The former and latter releases tie in with the Windows 10 Semi-Annual Channel and help to support the features released in these versions. Each ConfigMgr release is supported for a 12-month period, after which time it is advised to update to a supported release. The update is achieved via an in-console upgrade to ease the move between versions.

ConfigMgr drops support for older Windows 10 releases, when those baselines come out of their support lifecycle, and older versions of ConfigMgr do not support newer Windows 10 baselines. It can get confusing, at times, to keep up with which version supports which. Luckily Microsoft produces a handy support matrix to assist with this dilemma

The underlying message from Microsoft is to stay current. This report shows you how you can use ConfigMgr to stay current with Windows 10 and manage the latest security feature set.

Windows 10 Feature and Quality Updates

With Windows 10, changes have been made as to how the operating system is updated, compared to previous Windows versions.

Quality updates do not contain new features but provide fixes and are released monthly. Windows 10 quality updates are available in three flavours for end workstations, cumulative, deltas and express updates.

  • Cumulative updates are just that, meaning that the previous month's updates will be included in the update package and therefore these can grow substantially through the lifecycle of a Windows 10 release with updates exceeding a GB in size.
  • Delta updates is a monthly quality update for Windows 10 that just delivers changes to existing OS components, but they will only install if the previous month's quality update is present. Delta updates are approx. 300-500MB in size per month.
  • Express updates contain only the differentials, or changes, between the current and the new release and get delivered to an organisation's computing environment from Microsoft's content delivery network. Due to this they are substantially smaller in size than cumulative and delta updates. They are typically 100-200MB in size per month.

Whilst it may seem obvious to implement express updates to reduce the size of updates, the payoff only occurs between distribution points and the workstations themselves; since the update package will need to download the cumulative and the express update and these cannot be separated.

Microsoft has eased some of this pain recently, introducing features in ConfigMgr 1806 such as the ability to exclude certain architectures from the software update package and deploying software updates without content.

Microsoft has recently announced a new model for Window 10 updates, available from February 12, 2019, when delta updates will no longer be shipped, and express updates will be the preferred method for monthly patching. The provide details at This is new model is expected to give enormous savings in network bandwidth and cache size on distribution points.

ConfigMgr provides a mechanism for managing both feature and quality updates. Certain pre-requisites need to be in place to manage these updates. Ensure the following is in place and configured.

  • Heartbeat discovery – Enabled via Administration\Overview\Hierarchy Configuration\Discovery Methods
  • A Software Update Point installed and configured using Windows Server Update Service minimum release (WSUS) 4.0 with KB3095113 on Windows Server 2012. KB3095113 is not required on Windows Server 2016.
  • A Service connection point running in Online mode. Offline mode can be used but the Servicing Dashboard will only update when the next offline update is applied.
  • Enable the Upgrade classification on the Software Update Point via \Administration\Overview\Site Configuration\Sites\Right click the site\Configure Site Components\Software Update Point. In the Classifications tab choose Upgrades.
  • Enable the Windows 10 product on the Software Update Point via \Administration\Overview\Site Configuration\Sites\Right click the site\Configure Site Components\Software Update Point. In the Products tab choose Windows 10.
  • Run a Software Update synchronisation post enabling the classification and product on the Software Update Point via \Software Library\Overview\Software Updates\All Software Updates\Synchronize Software Updates.

Quality updates are managed in the Software Updates node of the ConfigMgr console under Software Library\Software Updates. The rule of thumb here is to keep things simple. However, staggering the deployment of patches will assist both with testing and reducing the amount of network traffic at the time of deployment.

Create an Automatic Deployment Rule (ADR) with multiple deployments assigned.

  • Pre-pilot deployment – Deployed to a handful of devices in the estate, where end users will give feedback if issues arise. The update should be made available immediately with an immediate deadline.
  • Pilot deployment – Based on the success of the pre-pilot deployment, the pilot is pushed to more devices. Ideally, define a group of devices in AD and create a query collection targeting members of the AD group. The deployment should be made a few days post pre-pilot, allowing time for feedback from those initial users, therefore make it available 7 days from the quality update being available, with a deadline of 14 days.
  • Production deployment/s – At this stage, the latest patches have been tested by the targeted users and are ready to progress into production. This can be achieved, either by a push to all devices or broken down into groups to reduce network traffic, with staggered available and deadline times. The first push needs to be made post the pilot deployment phase deadline.

Phased deployments of Software Updates is due to be introduced in SCCM imminently and has already been introduced in the Technical Preview edition of SCCM with version 1806 (

Phased software updates allow for granular staging of deployments which only move into the next phase of deployment if an agreed percentage of successful installation is achieved. They also introduce the ability to disable progression to the next phase of deployment if there are problems, a big red button if you like. To see how phased deployments work for Task Sequences in ConfigMgr take a look at the Adaptiva feature deep dive

Features updates contain new features, and these are the new baseline releases delivered every six months. These can be managed in two ways in ConfigMgr by Servicing or In-Place Upgrade (IPU).

Servicing is managed from the Software Library\Overview\Windows 10 Servicing node. At the root of this node is the Windows 10 Servicing Dashboard, a visual representation of Windows 10 usage, servicing rings and monitoring of servicing plans. Also included in a handy lifecycle timescale graph, percentage details on expired and soon to expire devices and an option to create a servicing plan.

With the pre-requisites for Windows 10 in place, feature updates will appear in the Software Library\Overview\Windows 10 Servicing\All Windows 10 Updates node, and servicing plans are created to filter the specific updates required for devices. Servicing plans are effectively ADRs for Windows 10 feature updates. The recommendation here, again, is to stagger the plans to run pre-pilot, pilot and production rings.

Windows 10 servicing works well when utilizing the Microsoft security stack for disk encryption and antivirus, BitLocker and Defender respectively. Using these products reduces some of the known risk with deployment of the feature updates via servicing.

The benefits to implementation via servicing against in-place upgrade are:

  • The downloaded file used for servicing is approx. 1GB smaller than the set-up files used when upgrading via an in-place upgrade task sequence
  • The amount of down time to users is less, since the upgrade downloads in the background and there is less time taken applying the upgrade.

Servicing isn't as flexible as an in-place upgrade in layering on updated drivers or applications, however with 1803 Microsoft introduced the ability to run custom actions during feature update in pre-install and pre-commit phases.

In-place upgrade (IPU), however gives full flexibility when moving from one Windows 10 baseline to the next and is achieved via an upgrade task sequence. The Windows 10 ISO is extracted into the ConfigMgr content source and in the Software Library\Overview\Operating Systems\Operating System Upgrade Packages node Add Operating System Upgrade Package is selected to create the package to be used in the IPU.

Creating the IPU is simply a case of navigating to the Software Library\Overview\Operating Systems\Task Sequence node, right-clicking and selecting Create Task Sequence. From the Create Task Sequence Wizard the Upgrade an operating system from an upgrade package option is selected.

With the task sequence created, the flexibility and granularity, in comparison to servicing, becomes obvious. Pre and post install groups are created with suggestions such as Remove incompatible applications, Remove/suspend third-party security and Apply customizations and personalizations.

Setupdiag was introduced with Windows 10 1803. A command-line tool which can be used in the IPU to assist with diagnosing upgrade problems and why the update failed. Setupdiag searches log files and uses a set of rules to match up known problems. ConfigMgr 1806 now includes a group Run Actions on Failure, and the setupdiag tool should be executed in this phase via a Run Command Line step using the syntax SetupDiag.exe /Output:"%_SMSTSLogPath%\SetupDiagResults.log" /Mode:Online.

If you are using third-party security products, it is recommended to use the IPU to control suspending or removing them. This is useful, for example, if updates are required. New releases can be installed in postprocessing or suspended products re-enabled.

IPU gives that extra bit more when it comes to controlling the flow of upgrade, but this comes at a price. The upgrade files are about 1GB greater in size than a feature update and the time taken to implement the IPU takes longer, so end users are impacted as a result. If application updates are added to the mix, this could be the perfect time to deploy out an Office 365 update, then a simple feature update soon turns into a major desktop refresh.

Servicing Versus In Place Upgrade for Feature Updates



Good when using MS security stack (Defender, BitLocker)

Works better when using third party AV or disk encryption

Smaller download

Upgrade package larger then feature update

Less down time for user

Greater down time for user, larger interruption

Just the feature update applied

Flexibility allows installation of other applications, drivers etc.

Managing Defender with ConfigMgr

Windows 10 comes with its own built in anti-malware product, Windows Defender. Defender builds on the principles set by System Center Endpoint Protection (SCEP). Since the product is effectively SCEP rebranded, rebadged and improved, there are still plenty of references to Endpoint Protection within ConfigMgr. Just like SCEP, Defender can be deployed, configured, administrated, and monitored through ConfigMgr via the Endpoint Protection Role.


The initial step to Defender management via ConfigMgr is to install the Endpoint Protection Role at the top of the ConfigMgr hierarchy. If ConfigMgr is being managed by a Central Administration Server (CAS), then the role must be installed on this server. Otherwise, the role must be installed on the primary site server. When installing the role, the license terms for Endpoint Protection must be accepted to be able to use the role.


During the configuration of the Endpoint Protection Role there is the option to join the Microsoft Advanced Protection Service (MAPS). Windows Defender uses MAPS, a cloud-based service, which taps into distributed resources and machine learning and delivers endpoint protection at a rate which is faster than traditional signature updates.

To achieve this, a device will encounter a new file and send a query to the service, MAPS assess that the file is unknown and then requests a sample of the file, the file is uploaded from the client and this sample is checked against machine learning classifiers. MAPS will then send back a signature to the device, which in turn blocks the file and reports back to the cloud and all customers are then protected against the threat.

It is recommended to switch on MAPS to the Advance membership setting when prompted. This will assist with the gathering of data from infected clients, sharing problems to help reduce the threat to other devices.

With the role installed, it is important to ensure that the Endpoint Protection Client Settings are enabled. This is achieved in Administration\Overview\Client Settings. The Default Clients Settings should not be altered. Instead, a custom client device setting should be created and deployed to a collection containing the devices which require Defender client management via ConfigMgr. In the custom client setting select Endpoint Protection and set Manage Endpoint Protection client on client computers to Yes. Consider the other Endpoint Protections client settings available and configure these accordingly.

Endpoint Protection has a set of antimalware policies which can be targeted at collections, like ConfigMgr client settings. The Default Client Antimalware Policy is located in Assets and Compliance\Overview\Endpoint Protection\Antimalware Policies. As with client settings, it is recommended that default policy is unaltered and custom policies are defined.

The antimalware policies define:

  • What scheduled scan settings to use. For example, what day to run, at what time, whether to invoke a quick or full scan, whether to check for the latest definition updates before running scanning and whether to limit CPU usage during a scan.
  • What default action to take on finding an infection: remove, quarantine or allow.
  • What real-time protection settings to enforce. This determines whether to enable behavior monitoring, to protect against network exploits or scan downloaded files etc.
  • Which files, folders and policies should be excluded from scans.
  • Whether to delete quarantined file after a certain amount of days, allow users to add to file, folder and process exclusions or to randomize scheduled scans and definition update start times.
  • What source to update definition files from and how long, in hours, to fallback to an alternative source for definition files if ConfigMgr is used as the primary location.

Managing Windows Defender via ConfigMgr requires the product category named Windows Defender added to Software Update Point. To do this, navigate to Administration\Overview\Site

Configuration\Sites. With the ConfigMgr site selected, from the Ribbon choose Settings\Configure Site Components\Software Update Point. In the Products tab select the Windows Defender product. Also, in the Classifications tab, Definitions Updates and Security Updates must be selected.

After the next Software Update Point synchronization Windows Defender updates will appear in \Software Library\Overview\Software Updates\All Software Updates. A synchronization can be forced by right-clicking the All Software Updates node and selecting Synchronize Software Updates.

Windows Defender has two types of updates that need to be managed via ConfigMgr, protection updates and product updates.

Protection updates are also known as "definitions" or "signature updates". These updates are rapid and frequent.

Product updates are known as "engine updates" and "platform updates" are monthly updates which introduce major feature updates and bug fixes during the Windows 10 lifecycle.

An Automatic Deployment Rule should be created to managed definition updates. To create an ADR, navigate to \Software Library\Overview\Software Updates\Automatic Deployment Rules. When creating the ADR note that there is a handy Definitions Update template available from the Template drop down menu on the General screen of the ADR wizard. The template for definition updates will only deploy the definitions. However, by removing the Update Classification on the Software Updates section of the wizard, then product updates will also be deployed out using this rule. By using the template, all the settings are configured and all that needs to be specified is a deployment package used to store the updates. When the ADR is created, right-click and run the rule and add in deployments to targeted collections.


To report on Defender within ConfigMgr, several options are available. Under \Monitoring\Overview\Security\Endpoint Protection Status are two nodes, System Center Endpoint Protection Status and Malware Detected. The former gives feedback on total active devices protected and any which are at risk, along with top five malware stats, malware remediation status and more.

Collections can be added to the dashboard by going into the properties of a collection, selecting the Alerts tab and enabling View this collection in the Endpoint Protection dashboard. The latter dashboard shows a list of malware discovered in the environment. From this dashboard, threats can be allowed, quarantined files can be restored for a threat, clients with the infection can be viewed or more detail on the malware threat can be obtained.

Devices can be triggered to force a scan at any time from the ConfigMgr console. Right-clicking an object and selecting Endpoint Protection allows a Full or Quick Scan or definition download to be performed.

Windows Defender Exploit Guard Policies

With Windows 10 1709, Microsoft introduced Exploit Guard to the Windows Defender suite. Exploit Guard tools and features assist in keeping an environments network safe from exploits. Features of Exploit Guard require Windows 10 E5 licenses if automated reporting into Windows Defender Advanced Threat Protection and attack surface reduction are required. All features, except exploit protection, require Windows Defender AV as a pre-requisite. The Windows 10 requirements have been captured by Microsoft in this handy matrix

Windows Defender Exploit Guard consists of four features. They can be evaluated in an audit mode to assess impact before being implemented.

The Exploit Guard features are:

  • Attack surface reduction rules. These target behavior associated with malware and malicious applications to infect machines, such as script and executables within Microsoft Office which attempt to download and execute files.
  • Controlled folder access rules. These protect files and folders from modification by malicious applications.
  • Exploit protection rules. These apply mitigation techniques on the operating system's process and applications.
  • Network protection. This extends the protection already offered by implementing Windows Defender SmartScreen by blocking access to domains which may host phishing scams, exploits, and other malicious content.

Management of Exploit Guard is in the \Assets and Compliance\Overview\Endpoint Protection\Windows Defender Exploit Guard node of the ConfigMgr console.

When creating an Exploit Guard policy, all or some of the features can be enabled. The features below are the latest, as of ConfigMgr 1806.

For Attack Surface Reduction:

  • Files and folders to exclude from Attack Surface Reduction rules
  • Block executable content from email client and webmail
  • Block Office applications from creating child processes
  • Block Office applications from creating executable content
  • Block Office applications from injecting code into other processes
  • Block Win32 API calls from Office macros
  • Block JavaScript or VBScript from launching downloaded executable content
  • Block execution of potentially obfuscated scripts
  • Block credential stealing from the Windows local security authority subsystem
  • Block executable files from running unless they meet a prevalence, age or trusted list criteria
  • Block untrusted and unsigned processes that run from USB

For Controlled Folder access:

  • Configure Controlled folder access
    • Block
    • Block disk sectors only
    • Audit
    • Audit disk sectors only
    • Disabled
  • Allow apps through Controlled folder access
  • Additional protected folders

For Network Protection:

  • Configure Network Protection
    • Block
    • Audit
    • Disabled

For Exploit Protection – the location to an already configured XML is required.

To create the XML file for Exploit Protection, a reference machine is required. The settings are configured in the Windows Defender Security Center application under App & browser control\Exploit protection settings. An Export settings link can be used to export out, or the PowerShell command: Get-ProcessMitigation -RegistryConfigFilePath exportfilename.xml.

With Windows Defender Exploit Guard policies defined, it is a case of deploying them to targeted collections within ConfigMgr.

Managing BitLocker as Part of a Windows 10 Deployment in ConfigMgr

ConfigMgr has built-in steps which assist you with the management of BitLocker within an environment.

BitLocker encryption is Microsoft's data protection solution. It integrates with Windows 10 and reduces the threat of data loss when devices are stolen or incorrectly decommissioned. It can be used on devices which have a Trusted Platform Module (TPM) chip 1.2 or later. However if a device does not have an appropriate TPM chip then BitLocker can still be implemented, and a USB startup key is required to boot the device or resume it from hibernation.

BitLocker can protect both operating system drives and removable media drives. Windows 10 1511 introduced the latest BitLocker algorithm AES-XTS and it is recommended that this is implemented at the 256bit key length.

BitLocker can be configured to operate in one of two modes:

  • Transparent Operation mode. This mode utilizes the capabilities of Trusted Platform Module (TPM) hardware to provide for a transparent user experience - the user powers up and logs into Windows as normal. The cryptographic key used for disk encryption is sealed (encrypted) by the TPM.
  • User Authentication mode: In this mode the user will have to provide a numerical PIN or insert a USB device that contains the start-up pin for their computer to allow it to boot. This mode can be used in conjunction with the TPM.

BitLocker steps have been integrated into Operating System Deployment, so a task sequence can manage the solution in either a bare metal or wipe and load scenario.

The following BitLocker steps are available in a Task Sequence:

  • Disable BitLocker. This step disables BitLocker on a device and is useful in a wipe and load scenario. It does not decrypt data on the disk. The step must be initiated in full OS mode.
  • Enable BitLocker. This step enables BitLocker on up to two partitions on a hard drive. It can also be used to store the recovery key in Active Directory. This step also defines if TPM Only, Startup Key on USB, TPM and Startup Key on USB, or TPM and PIN should be used. If so, TPM must be enabled, activated and ownership allowed, before this step executes. The step must be initiated in full OS mode.
  • Pre-provision BitLocker. This step pre-provisions the used space only on a hard drive whilst in WinPE. This encrypts the disk faster. This step can be skipped for devices that do not have a TPM chip. With ConfigMgr 1806, a new option to use full disk encryption is available. This option encrypts the whole disk, which can take a long time on larger disks.

Managing BitLocker via the task sequence is simple. The example of steps to use, below, is for key management within Active Directory. Active Directory is extended for BitLocker management by default on Windows Server 2012 domain controllers and above.




Run Command Line

Sets encryption level to AES-XTS 256 for Win 10 devices via the command line:

REG ADD HKLM\SOFTWARE\Policies\Microsoft\FVE /V EncryptionMethod /t REG_DWORD /d 7 /f

Prior to Preprovision BitLocker step in the Preinstall group

Pre-provision BitLocker

Built in task sequence step that pre-provisions the used space only on a hard drive whilst in WinPE, encrypts the disk faster

In the Preinstall group, prior to laying down the operating system

Disable BitLocker

Built in task sequence step to disable BitLocker in a wipe and load scenario so disk changes can be made

In the State Capture group, runs in full OS

Enable BitLocker

Built in task sequence step that allows configuration of TPM, Startup Key on USB, TPM and Startup Key on USB, or TPM and PIN. Also, whether to use full disk encryption, store recovery key in Active Directory and whether to wait until encryption completes before moving on to the next step.

In the State Restore group, runs in full OS

Microsoft BitLocker Administration and Monitoring

There is the option of using Microsoft BitLocker Administration and Monitoring (MBAM) solution. This solution assists with increasing security; storing the recovery key in a SQL database, generating a new recovery key for a device when used and eases the end user experience, introducing a self-service portal for users to recover devices when prompted for a recovery key.

MBAM makes use of a script provided by Microsoft, Invoke-MbamClientDeployment.ps1, which can be downloaded from The InvokeMbamClientDeployment.ps1 script stores the recovery key into the MBAM database via the Recovery Service Endpoint and enables BitLocker on the device, therefore the built in Enable BitLocker step is not required when implementing MBAM in a task sequence.

MBAM can be installed in standalone mode, or it can be integrated with ConfigMgr. When integrated with ConfigMgr a new collection of MBAM Supported Computers is created in the root of the Device Collections node. MBAM reports and configuration items are also added to ConfigMgr.

Third-Party Patching with ConfigMgr

Third-party patching within ConfigMgr is a new feature introduced with CM 1806. Prior to 1806, System Center Updates Publisher (SCUP) a stand-alone tool could be used in conjunction with ConfigMgr to import software catalogs and publish update information to a configured Windows Server Update Services (WSUS) server. ConfigMgr could then synchronize the updates into the site server database and make the updates available to end clients via the Software Update Point (SUP) role.

SCUP hadn't had many updates in the last few years, but recently an update was released to support Windows 10 clients. With the new third-party patching feature this functionality is enabled within ConfigMgr without having to stand up SCUP in the environment.

This doesn't mean that SCUP is obsolete. For example, SCUP has additional catalogs available that are not yet be available. The two solutions can co-exist.

Consideration of specific architectural configuration is required when implementing the third-party patching feature. The following pre-requisites and configurations apply in the ConfigMgr hierarchy.

  • Disk space on the top-level SUP to support the download of binaries for third-party updates. The amount of space required will depend on the type and number of updates required for patching. If there is insufficient disk space, then it is possible to move the WSUSContent folder to another drive with sufficient space. This guide by Microsoft explains how to do this
  • Internet connectivity is required. Port 443 is needed to connect to the partners catalog list at
  • If a SUP is remote from the top-level site server, then a server authentication certificate from an internal certificate authority or public provider is required on the WSUS instance. Also, the SUP needs to be enabled for SSL, otherwise it will not be able to communicate with the WSUS instance. This is achieved under Administration\Overview\Site Configuration\Servers and Site System Roles. With the site system hosting the SUP role selected, in the Site System Roles pane, double-click Software update point. In the Software Update Point Component Properties, select Require SSL communication to the WSUS server.
  • In the Software Update Point Component Properties, select the Third Party Updates tab and select Configuration Manager manages the certificate, ConfigMgr will use a self-signed certificate, or Manually manage the certificate. If manually managing the certificate, a tool such as SCUP is required to create the required certificate. Details on how to do this are contained in the System Center Updates Publisher Signing Certificate Requirements & Step-by-Step Guide article To allow the creation of the selfsigned certificate the following requirements need to be met:
    • Remote registry needs to be enabled on the SUP
    • The WSUS server connection account requires remote registry permissions on the SUP
    • A registry key needs to be created on the ConfigMgr site server using the following command REG ADD "HKLM\Software\Microsoft\Update Services\Server\Setup" /v EnableSelfSignedCertificates /t REG_DWORD /d 1 /f
  • The WSUS server connection account requires remote administration permissions on the SUP server to install the certificate to the Trusted Publishers and Trusted Root stores. If this is not possible then the certificate can be exported from the local computer's WSUS store and placed in the stores.

With the pre-requisites implemented, third-party updates need to be enabled on the SUP. This is done under Administration\Overview\Site Configuration\Sites. With the ConfigMgr site selected, from the Ribbon choose Settings\Configure Site Components\Software Update Point. In the Third Party Updates tab check the Enable third-party software updates box.

Enable third-party software updates needs to be set to Yes in a custom client setting deployed to targeted devices. This is enabled in Administration\Overview\Client Settings. In the client setting navigate to the Software Updates section to locate and enable this setting.

In ConfigMgr 1806, a partner catalog is available and ready to use (the HP client updates catalog). Partner catalogs are from software vendors who have already registered their catalogs with Microsoft. Custom catalogs can be added, but these must use https and be digitally signed.

The method to use third-party catalogs is different to using standard software updates within ConfigMgr. The following process must be adhered to:

  1. In the Software Updates Library\Overview\Software updates\Third-Party Software Update Catalogs node, add a custom catalog. This can be selected from the ribbon.
  2. In the Third-party Software Updates Custom Catalog wizard, add a Download URL, which is the HTTPS address of the custom catalog.
  3. The imported catalog must then be subscribed to using the Subscribe to Catalog option in the ribbon. This syncs the update metadata into the WSUS server. When subscribing, the admin must review and approve the catalog certificate.
  4. The catalog should start to download at this point, however a sync can be forced by clicking the Sync Now button in the ribbon.
  5. After the catalog downloads, a software updates synchronization needs to be initiated from Software Library\Overview\Software Updates\All Software Updates\Synchronize Software Updates.
  6. On completion of the software updates sync, the required products need to be selected from Administration\Overview\Site Configuration\Sites. With the ConfigMgr site selected, from the Ribbon choose Settings\Configure Site Components\Software Update Point and in the Products tab select the required products.
  7. Another software updates synchronization is required to synchronize the new product's updates into ConfigMgr.
  8. Third-party updates appearing in the Software Library\Overview\Software Updates\All Software Updates node in the ConfigMgr console, alongside the usual software updates. An icon with a blue arrow represents a metadata-only software update and these need to be published so that they can be deployed. Right-clicking on a metadata-only update allows the Publish Third-Party Software Update Content option to be selected. This downloads the update binary into the WSUSContent folder, the progress of which can be monitored in the SMS_ISVUPDATES_SYNCAGENT.log file.
  9. A final software updates synchronization is needed to change the state of the published update from metadata-only to a deployable update with content.

At this stage, the third-party update can be added to a deployment package and software update group. It is a standard software update and can be deployed out to a targeted collection of devices.

Managing Security Features as Part of the Operating System Deployment

ConfigMgr Operating System Deployment (OSD) provides the perfect mechanism to manage Windows 10 security features at build time. This provides an automated method during the task sequence switch on the latest features or to convert from old to new.

With Windows 10, it is recommended to move from legacy BIOS to Unified Extensible Firmware Interface (UEFI) and turn on Secure Boot to take advantage of the security benefits that they provide.

Until Window 10 1703 this was difficult to achieve, since BIOS uses the Master Boot Record (MBR) to save information about the hard drive data while UEFI uses the GUID partition table (GPT). This required formatting of the drive to the GPT layout. Microsoft released the MBR2GPT tool located in the c:\windows\system32 directory to ease that pain. The tool converts the disk partition layout whilst keeping the data on the drive intact.

MBR2GPT can be performed in WinPE or full OS mode. It is recommended to run this WinPE, though there may be occasions where running this in full OS is a necessity.

At a basic level, the BIOS to UEFI can be performed in three steps in the task sequence.

  1. Turn on the required UEFI and Secure Boot settings in BIOS using vendor tools to achieve this
  2. Run the MBR2GPT to convert the disk layout from MBR to GPT
  3. Restart the computer—this step is important as no further writes to the converted disk can take place until the device boot back up in UEFI mode.

Each vendor provides tools which assist with BIOS configuration. As an example, HP has the HP BIOS Configuration Utility (BCU) which can be downloaded from

Within the HP BCU, the HPQPswd64.exe tool can be used to create an encrypted password file to assign to the BIOS. The next step is to export the BIOS settings from a reference machine using the command BiosConfigUtility64.exe /get:<filename.txt> to export the settings into a TXT file. The file can be modified to enable or disable settings. It is possible to export settings from different devices and merge the settings into one TXT file, as settings not relevant to a device are ignored. This simplifies the configuration of the settings on various HP devices. The settings are applied in a task sequence using a Run Command Line step with the command BiosConfigUtility64.exe /set:<BIOSSettings.txt> /verbose /cpwdfile:<BIOSPasswd.bin>.

The next step in the task sequence runs the MBR2GPT tool via a Run Command Line step using the command line MBR2GPT.exe /convert /disk:0 if being executed in WinPE. If the command is being used in full OS mode, then the /allowfullOS switch is required.

Finally, a Restart Computer step is required. This will restart to either the boot image assigned to the task sequence or to the currently installed operating system. This depends on whether the MBR2GPT is executed in WinPE or full OS, respectively.

Windows Defender Application Control the Easy Way

Windows Defender Application Control (WDAC), allows control of Windows 10 devices by creating policies that define whether a specific driver or application can be executed on a device. Applications or drivers need to be specified as trustworthy and doing this reduces the threat of executable-based malware significantly. WDAC restricts application usage via a feature called configurable code integrity (CI). CI guarantees that only the trusted code runs from the boot loader onwards and hardens the operating system against kernel memory attacks using virtualization-based protection of code integrity (HVCI). WDAC works in-conjunction with Secure Boot, to ensure that boot binaries and the UEFI firmware are signed and have not been tampered with.

WDAC is not a simple solution to implement, in comparison to many other Windows 10 security features. Download the Microsoft TechNet documentation on WDAC and AppLocker in PDF format and there is a hefty 273 pages of content to consume. WDAC requires a full understanding of the business' application portfolio. As an admin, you must have full control of deployment and management of your apps.

To implement WDAC in the enterprise, the following process needs to be implemented. This is WDAC in its simplest form:

  • Build a reference machine with all the business' applications installed
  • Ensure the machine is virus- and malware-free
  • Create a WDAC policy in PowerShell and execute against the device, in audit mode initially
  • Deploy the policy against a device (in audit mode)
  • Delete the Audit Mode Enabled option from the policy so it becomes enforced and test against a device
  • Rename the policy to SIPolicy.p7b and copy it to C:\Windows\System32\CodeIntegrity for testing in enforced mode

If further policies are created, then these need to be merged since only one WDAC policy is allowed per device.

Since Windows 10 1703, a new option, known as the managed installer has been provided. It can automatically authorize applications deployed by a software deployment solution, such as ConfigMgr. The managed installer simplifies WDAC implementation by not requiring the administrator to specify explicit rules for software that is being managed through ConfigMgr. Using ConfigMgr covers the following: a pre-defined circle of trust for the ConfigMgr client binaries and its dependencies, Windows OS components, Store apps, and any application which is deployed via ConfigMgr.

WDAC is currently a pre-release feature in ConfigMgr. Pre-release features must be enabled for the whole hierarchy. To allow pre-release features to be used, navigate to \Administration\Overview\Site Configuration\Sites. Select the site and then click the Hierarchy button in the ribbon. In the General tab, select Consent to use Pre-Release features. Once switched on, this change cannot be reversed.

With consent enabled, the next step is to turn on the WDAC feature itself. Pre-release features are located in \Administration\Overview\Updates and Servicing\Features in the SCCM console. The WDAC feature should be right-clicked and turned on.

To create the WDAC policy, navigate to \Assets and Compliance\Overview\Endpoint Protection\Windows Defender Application Control. Right-click Windows Defender Application Control and choose Create Application Control Policy.

The Create Application Control Policy wizard allows the configuration of the WDAC policy in a few simple steps. Policies can be enabled in Audit only or Enablement enforced mode. It is recommended that Audit only mode is enabled initially to analyze the impact of the WDAC policies before enforcing them.

The policy also allows the use of the Intelligent Security Graph (ISG). The ISG taps into Microsoft's vast intelligence and threat analytics data and assists with classifying applications as having a good reputation. When application files are executed, the data from the ISG is used to assist the WDAC policy with authorizing the decision. If no deny rules exist in the deployed policy, then the reputation classification data will be utilized to authorize the application. This is another great way of reducing the complexity of enabling WDAC in your environment.

Be aware that ISG is an option available to devices running Windows 10 1709 onwards only. With the WDAC policy created it is a case of simply deploying out to a targeted collection of devices.

Windows Device Health Attestation

Windows Device Health Attestation (DHA) was introduced in the first release of Windows 10, 1507. The Health Attestation Service is a Microsoft trusted cloud service operated which performs a series of health checks and reports to Mobile Device Management (MDM) what Windows 10 security features are enabled. It can also be run as an on-premise service on Windows 2016 server, ensuring that the DHA report does not leave the network.

This feature:

  • Integrates with the Windows 10 MDM framework
  • Works with devices that support Trusted Module Platform (TPM) 1.2 or 2.0, provisioned in firmware or discrete mode.
  • Allows enterprises to raise the security bar to hardware monitored and attested for security for on-premise devices managed by Active Directory, hybrid managed with both Active Directory and Azure Active Directory or Azure Active Directory on managed cloud-based devices.

A DHA policy checks the following boot configuration or attributes:

  • Secure Boot
  • BitLocker
  • Early Launch AntiMalware (ELAM)

To manage DHA in ConfigMgr, a client setting needs to be enabled under \Administration\Overview\Client Settings. It is recommended to use a custom client setting to define this. In the Computer Agent setting the client setting Enable communication with Health Attestation Service needs to be set to Yes.

If using an on-premise DHA service, then the client setting Use on-premises Health Attestation Service needs to be set to Yes. Additionally, beginning with ConfigMgr 1702, the on-premise DHA URL needs to be configured on Management Points to support internal devices which do not have Internet access. In the Administration\Overview\Site Configuration\Sites node, right-click the site and select Configure site components\Management Point. In the Management Point Component Properties window, select the Advanced Options tab and add in the on-premise DHA URL.

DHA can be monitored in ConfigMgr under the \Monitoring\Overview\Security\Device Health Attestation node. The DHA dashboard reports on:

  • Health Attestation Status: displays devices in compliant, noncompliant, error, and unknown states.
  • Devices Reporting Health Attestation: displays a percentage of devices reporting their DHA status.
  • Noncompliant Devices by Client Type: displays devices which are non-compliant
  • Top Missing Health Attestation Settings: displays the number of devices which are missing the DHA setting.

Configuration Baselines for Security

The following security features can be implemented via ConfigMgr Configuration Items (CI) and Baselines. A baseline is a collection of one or more configuration items, each item being evaluated on a schedule.

CI's can be created using PowerShell scripts, file system or registry key information.

Below, I'll show you how to apply baselines to some essential features, such as Windows Defender Credential Guard, Windows Defender SmartScreen, User Account Control (UAC), and Windows Defender Firewall.

To allow computers to run baselines, the client setting Enable compliance evaluation on clients needs to be enabled in the Administration\Overview\Client Settings node. In a custom client setting, navigate to the Compliance Settings section and set to Yes.

In the Assets and Compliance\Overview\Compliance Settings\Configuration Items node, click Create Configuration Item in the ribbon. The configuration item should be set to devices managed with the Configuration Manager client and set to Windows Desktops and Servers (custom) and filter the CI according to operating system version and architecture. In the Specify settings for this operating system section add in the relevant details. See the details below for each security feature and the registry keys required to implement for settings and compliance rules.

With a CI defined, create a Configuration Baseline, located in the \Assets and Compliance\Overview\Compliance Settings\Configuration Baselines node and add in the CI to the Configuration data section and deploy the baseline to a targeted collection of devices.

Windows Defender Credential Guard

Credential Guard, introduced with Windows 10, uses virtualization-based security to isolate secrets so that only privileged system software can access them. Credential Guard protects against credential harvesting by running LSASS in a separate virtual machine on the client. All NTLM and Kerberos hashes are stored in the LSAISO process running in the secure virtual machine, separate from the running operating system. This provides protection of the password secrets even at the kernel level because the secrets are not stored there.

To enable Credential Guard via the registry, the following details are required:





HKLM\ System\CurrentControlSet\Control\DeviceGuard




HKLM\System\ CurrentControlSet\Control\DeviceGuard



1 for SecureBoot


3 for SecureBoot and DMA




1 with UEFI lock


2 without lock

To enable Credential Guard via the GPO, the following details are required:



Computer Configuration\Administrative Templates\System\Device Guard\Turn On Virtualization Based Security


Computer Configuration\Administrative Templates\System\Device Guard\Turn On Virtualization Based Security

Select Platform Security Level - Secure Boot or Secure Boot and DMA Protection

Computer Configuration\Administrative Templates\System\Device Guard\Turn On Virtualization Based Security

Credential Guard Configuration - Enabled with UEFI lock or Enabled without lock

Windows Defender SmartScreen

Windows Defender SmartScreen acts an early warning system against websites that could potentially engage in phishing attacks or attempt to distribute malware.

It can be enabled for Internet Explorer or Microsoft Edge browsers. A Windows Defender Browser Protection add on is also available for Google Chrome.

To enable Windows Defender SmartScreen via the registry, the following details are required:












1 for SecureBoot or

3 for SecureBoot and DMA




1 with UEFI lock


2 without lock

To enable Windows Defender SmartScreen via the GPO, the following details are required:



Computer Configuration\Administrative Templates\System\Device Guard\Turn On Virtualization Based Security


Computer Configuration\Administrative Templates\System\Device Guard\Turn On Virtualization Based Security

Select Platform Security Level - Secure Boot or Secure Boot and DMA Protection

Computer Configuration\Administrative Templates\System\Device Guard\Turn On Virtualization Based Security

Credential Guard Configuration - Enabled with UEFI lock or Enabled without lock

User Account Control (UAC)

User Account Control (UAC) was introduced with the Window Vista operating system. UAC limits application software to standard user privileges until an authorized increase or elevation is approved by an administrator. By doing this, only applications trusted by the user are given administrator privileges, reducing the risk of malware compromising the system.

A variety of UAC settings can be implemented. To enable UAC via the registry, the following settings can be configured under the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System key:

Registry Name

Group Policy alternative



User Account Control: Admin Approval Mode for the built-in Administrator account

= Disabled

= Enabled


User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop

= Disabled

= Enabled


User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

= Elevate without prompting

= Prompt for credentials on the secure desktop

= Prompt for consent on the secure desktop

= Prompt for credentials

= Prompt for consent

= Prompt for consent for non-

Windows binaries


User Account Control: Behavior of the elevation prompt for standard users

= Automatically deny elevation requests

= Prompt for credentials on the secure desktop

3 = Prompt for credentials


User Account Control: Detect application installations and prompt for elevation

1 = Enabled (default for home)

0 = Disabled (default for enterprise)


User Account Control: Only elevate executables that are signed and validated

= Disabled

= Enabled


User Account Control: Only elevate UIAccess applications that are installed in secure locations

= Disabled

= Enabled


User Account Control: Run all administrators in Admin Approval Mode

= Disabled

= Enabled


User Account Control: Switch to the secure desktop when prompting for elevation

= Disabled

= Enabled


User Account Control: Virtualize file and registry write failures to per-user locations

= Disabled

= Enabled

Windows Defender Firewall

The Windows Defender Firewall has been around since Windows XP days. It was originally known as the Internet Connection Firewall, then Windows Firewall. Since Windows 10 1709 it has been renamed to the Windows Defender Firewall. The Windows Defender Firewall is designed to filter network data transmissions to and from a Windows client and block any communications that are deemed harmful to the device.

It is recommended that Windows Defender Firewall always be enabled even if other firewalls are turned on. Windows 10 will constantly notify with a warning if the firewall is not turned on and this notification cannot be switched off.

Windows Defender Firewall policies are part of the Endpoint Protection solution and can be created under the \Assets and Compliance\Overview\Endpoint Protection\Windows Defender Firewall Policies node. The policies allow basic management of the firewall, which need embellishing with Active Directory GPO's to allow or block specific programs or ports.

When defining a policy, the firewall can be enabled on: the domain, private and public profiles. Incoming connections can be blocked to client computers, including any defined in an allowed list and the user can be notified if the firewall blocks a new program.

When a Windows Defender Firewall policy is deployed to a collection, the policy is randomized over a two-hour period to avoid flooding the network.

Windows Defender Advanced Threat Protections Tie in with ConfigMgr

Beginning with ConfigMgr 1606, Windows Defender Advanced Threat Protection (ATP) can be managed and monitored. ATP is a cloud-based service, which assists businesses to detect and prevent advanced threats on their network. ATP requires a Windows 10 Enterprise/Education E5 or Microsoft 365 E5 license and can be configured and accessed via the URL

Clients can be onboarded using an onboarding file created in the ATP portal. Devices must be running Windows 10 1607 and later to be able to onboard.

In the ATP portal, click the Endpoint Management menu item and choose System Center Configuration Manager (current branch) version 1806 and Download package. The ATP configuration file contains sensitive information, so this file should be kept in a secure location.

To onboard clients in ConfigMgr, navigate to the \Assets and Compliance\Overview\Endpoint Protection\Windows Defender ATP Policies node. Create a new Windows Defender ATP Policy and ensure that Onboarding is selected from the Policy type checkboxes. The ATP configuration file needs to be applied and which file samples which should be shared for analysis by the ATP service. With the policy defined it is simply a case of deploying out to a targeted collection of devices.

Within ConfigMgr is a Windows Defender Advanced Threat Protection dashboard, located in \Monitoring\Overview\Security\Windows Defender ATP Status. This dashboard gives details on:

  • Windows Defender Agent Deployment Status: the number and percentage of devices with an active ATP policy onboarded.
  • Windows Defender ATP Agent Health: the percentage of devices which report as:
    • Healthy
    • Inactive
    • Agent stopped
    • Not onboarded

Devices can be offboarded using an offboard configuration file. When an offboarding file is created, it is valid for 30-days. An offboarding policy needs to be created and deployed.