Enabling HSTS and selecting most secure ciphers and protocols for HTTPS for ConfigMgr

Many IT security departments these days frequently scan their servers using a vulnerability scanner such as Nessus or Qualys to look for software that needs patching or settings that need to be changed, in the hopes of finding and fixing them before the bad guys exploit them. On web servers, the findings may include needing to enable HSTS (HTTP Strict Transport Security) and configuring the server to only use the latest versions of TLS and use the most secure ciphers. As many ConfigMgr roles rely on a web server, this may mean your ConfigMgr server(s) appears on the vulnerability report with findings.

So, the big question is: Does enabling HSTS cause problems for ConfigMgr? I have tested this extensively and I believe the answer is no, it does not cause problems. If you are concerned, there is a way to minimise the risk by settings the “max-age” for HTST to just 1 hour to begin with (in the end you should set this to 1 year as that is the industry recommended time).

The second question is: Does ConfigMgr still work if you limit the TLS protocols and ciphers to only the most secure? Again, the answer is yes, ConfigMgr continues to work just fine.

Before you begin, you must understand what HSTS is and how it could break things if it is set incorrectly. HSTS instructs browsers to always expect a secure connection to a site and they will refuse to connect in the future if they do not find a valid SSL certificate. Due to this you must only set HSTS if you are running ConfigMgr with SSL certificates and can guarantee that you will always be doing so in the future.

To enable HSTS you must be running all ConfigMgr roles in HTTPS mode. This includes the Management point and Distribution point, as well as the Enrollment point and Enrollment proxy point if you are still using those.

WSUS must also be configured to use HTTPS.

If you are running a Reporting services point, you must use Report Server Configuration Manager to configure SQL Server Reporting Services (SSRS) to use SSL. There is also a separate process to enable HSTS on SSRS if you are using the 2019 version.

You should be aware that this guide will set HSTS for all websites hosted on your server. If you run any other sites on your ConfigMgr server, you should make sure that you can guarantee HTTPS connections to those sites as well.

Configuring HSTS in IIS 10.0
Microsoft has confusingly continued to use version 10.0 for IIS in Windows Server 2016 and 2019 even though they have added features to IIS in the newer versions of Windows Server. In Windows Server 2016 the full version for IIS is IIS 10.0 version 1607 and in Windows Server 2019 it is IIS 10.0 version 1809. HSTS can be enabled in both versions but have slightly different procedures.

If you are running Windows Server 2016, open Internet Information Services (IIS) Manager and select the site your ConfigMgr roles are running from (by default this will be Default Web Site). Double click on HTTP Response Headers, then click Add from the Actions pane on the left. In the Name field enter “Strict-Transport-Security”, and in the Value field enter “max-age=31536000; includeSubDomains”. Click OK to save this header.

Setting the Strict-Transport-Security header in IIS 10.0 on Windows Server 2016

If you are running Windows Server 2019, open Internet Information Services (IIS) Manager and select the site your ConfigMgr roles are running from (by default this will be Default Web Site). In the Actions pane on the left click HSTS… and tick Enable, put the value 31536000 in the Max-Age field and tick includeSubDomains and Redirect Http to Https. Click OK to save this setting.

Enabling HSTS in IIS 10.0 on Windows Server 2019

Note: The 31536000 value for max-age is equal to 1 year in seconds. This is the industry standard time for this value. If you want to test this before fully committing to a year you can set this value to 3600 (1 hour) or 86400 (1 day). Once you have completed your testing and are satisfied that HSTS is not causing any problems, you should set this to 31536000.

If you are running a previous version of IIS, you may still be able to enable HSTS by configuring the HTTP Response Header. Microsoft has an article that covers enabling HSTS in previous versions of IIS here.

Configuring HSTS in SQL Server Reporting Services
SQL Server Reporting Services (SSRS) has long been decoupled from IIS, so configuring HSTS for your IIS sites will not configure it for the reporting services site if you have a Reporting services point set up in ConfigMgr. In order to configure HSTS for SSRS you must be running SQL Server 2019 Reporting Services or later, as this is the first version where Microsoft has officially supported setting custom response headers.

To configure the Strict-Transport-Security header in SSRS 2019, start by opening SQL Server Management Studio and selecting Reporting Services from the Server type drop down menu and entering the server’s name, followed by the authentication details you use. Once connected, right click on the server’s name in Object Explorer on the left and select Properties. Go to Advanced and look for the CustomHeaders field. By default, this is empty, so you should enter the following value:

<CustomHeaders><Header><Name>Strict-Transport-Security</Name><Pattern>(.+)\/Reports\/(.+)</Pattern><Value>max-age=31536000; includeSubDomains=true</Value></Header></CustomHeaders>
Showing where to set the Strict-Transport-Security header in SQL Server Management Studio

This sets the header name (Strict-Transport-Security) and the value (max-age=31536000; includeSubDomains=true). You also have to use a regular expression to set which URLs will be matched and this header applied to. For a default install of SSRS, your ConfigMgr reports will be accessible at https://<ConfigMgrServer.com/Reports/. If this is the case, the regex “(.+)\/Reports\/(.+)” will work as this matches any URL that has characters before and after “/Reports/”. If you need to modify this regex for your environment, I recommend using a regex testing site such as this one.

Once you have entered the text in the CustomHeaders field click OK to close the Server Properties page. You must then restart the SQL Server Reporting Services service before it will take effect.

Configuring best practise for TLS versions and cipher suites offered by IIS
The easiest way to disable old TLS versions and insecure cipher suites is to download the tool IIS Crypto from Nartac Software. Once downloaded, run it on your ConfigMgr server and click the Best Practices button at the bottom of the window. This will leave only TLS 1.0, 1.1 and 1.2 enabled and disable many less secure ciphers such as MD5 and 3DES. I would also recommend unticking TLS 1.0 to disable that.

You can review exactly what has been disabled by going through the list of protocols and ciphers that have been left enabled in the Schannel tab and the Cipher Suites tab. If you’re happy with the changes that it will make, click Apply and then close IIS Crypto. You must restart the server before the changes will take effect.

Once you have completed this you can ask your security team to rescan your ConfigMgr server and check that it no longer shows vulnerabilities relating to HSTS or insecure HTTPS protocols and cipher suites.

Switch from Legacy BIOS to UEFI on existing installs of Windows Server 2016 (and 2012 / 2012 R2)

With most modern servers now shipping with UEFI enabled by default and many virtual hypervisor platforms supporting it for guest VMs as well, you may wish to switch your existing installations of Windows Server 2012, 2012 R2 or 2016 from booting with legacy BIOS to booting with UEFI. Thanks to a small tool introduced by Microsoft in Windows 10 1703, MBR2GPT.EXE, this can be done very easily.

You will need to download a copy of Windows 10 1703 or later in order to follow this guide as you need a copy of MBR2GPT.EXE and you need to boot your server into the version of WinPE that comes with these releases of Windows 10. You cannot run the tool in versions of Windows prior to 1703 (which, technically, Window Server 2016 is as it uses the same codebase Windows 10 1607).

Make certain your platform supports UEFI booting before continuing with this guide. If it does not, you will no longer be able to boot into Windows after you have changed the partition table from MBR to GPT.

If this process fails it has the potential to make your server unbootable, corrupt your data and cause lengthy downtime. Make certain you have an adequate backup of your server and a restoration process in place before proceeding.

Okay, with the big scary warnings out of the way, let’s get going!

First start by loading the Window 10 1703 (or later) ISO onto a USB drive, DVD, or if you’re following this process on a VM, mount it directly on the VM. Restart your server and boot the server from the Windows installation media. Click Next on the language selection screen and on the next screen click Repair your computer.

When the options screen comes up select Troubleshoot, and in Advanced Options select Command Prompt. You’ll find yourself at the command prompt in X:\Sources. Change directory to X:\Windows\system32 and start diskpart. Type list disk to list the disks attached to the system and note down the one that contains the OS. This will likely to be disk 0 but may not be depending on your servers’ disk layout.

diskpart List Disk

Exit diskpart and type MBR2GPT.exe /validate /disk:0. This will run the MBR2GPT tool on your OS disk to validate that it is ready for the conversion. If it is successful, run MBR2GPT.exe /convert /disk:0 and wait for the conversion to complete – it should not take long.

MBR2GPT Convert

That’s it for the conversion. Now restart your server, enter setup and enable UEFI booting. Save and exit and Windows should boot right up without any issues.

Now there is some optional clean up you can do. How optional it is depends on if you’ll ever want to extend the size of the drive. On a physical server it is unlikely your partition doesn’t already use the full size of the drive, however on a VM where it is possible to increase the size of the disk, you may have need to extend it in the future. It also depends on if you use BitLocker or not – more on that in a moment.

Here’s the deal. In Windows, open a command prompt and start diskpart. Type select disk 0 and then list partition. You will see three partitions – a 500 MB recovery partition, your OS partition and a 100 MB EFI system partition. That 500 MB partition is no longer in use since you no longer have an MBR partition. The new system partition is that 100 MB one at the end, and because it is at the end it will block you extending your OS partition. Fortunately, you can reuse that 500 MB of space and put the EFI system partition there instead.

If you use BitLocker to encrypt your drive the 500 MB partition also contains the unencrypted system files needed to start your computer. In this case, you cannot delete the partition. If you really need to be able to extend your partition in the future you can either unencrypt your drive, move the partition and then re-encrypt it, or use a third-party partitioning tool to move the EFI system partition to the front of the disk.

If you want to complete the partition clean up, here’s what to do. First, reboot the server and use the same steps as earlier with your Windows 10 installation media to end up back at the command prompt. From here, enter diskpart and type select disk 0 and then list partition. Note down which partitions are the 500 MB recovery partition and 100 MB system partition (typically these will be partition 1 and partition 3). Proceed to delete these partitions by first selecting them and then deleting them, using the commands select partition 1 followed by delete partition override and then select partition 3 followed by delete partition override.

diskpart Delete Partitions

Now create a new EFI system partition at the front of the disk using the command create partition efi size=100, format it using format quick fs=fat32 and assign it a drive letter using assign letter=s. Next, use the list volume command to get a list of volumes and make a note of the drive letter your OS drive is on (very likely C).


Exit diskpart and type bcdboot C:\Windows /s S: to copy the necessary system files to the new EFI system partition.

Finally, enter diskpart one last time, type select disk 0 and then select partition 2 and then type extend to reclaim that 100 MB of space at the end of the drive (may as well, right?) This will leave you with 2 partitions – the 100 MB EFI system partition at the beginning of the drive and your OS partition. Exit diskpart and restart your server.


And that’s it, the server now boots with UEFI and the partitions are all tidied up1.

1The astute among you will have realised that actually, the partitions aren’t quite as clean as you might like. Due to the old system partition being 500 MB and the new one being 100 MB, there is now 400 MB of unused space between the system partition and the OS partition. You have a few options here. The first, and simplest, is to actually create the new EFI partition with 500 MB of space rather than 100 MB. It doesn’t need that much space, but it will look better in Disk Management not having that random unused space between the partitions. Your second option is to simply leave it there, which could be beneficial in the future. If you ever turn on BitLocker it will need to create a 350 MB partition to store the unencrypted system files needed to boot your computer, and it can do so inside that 400 MB of space. Your third option is to use a third-party partitioning tool which is capable of extending your OS partition into the space in front of it, which is something that diskpart cannot do.


Buy Me A Coffee

Migrating your Microsoft PKI infrastructure to Windows Server 2016 (Part 2)

Migrating your Microsoft PKI infrastructure to Windows Server 2016 (Part 1)
Migrating your Microsoft PKI infrastructure to Windows Server 2016 (Part 2)

In the second part of this guide I will be migrating my online issuing CA to Windows Server 2016. As before this guide is written as a guide to upgrade from a Windows Server 2012 R2 CA to a Windows Server 2016 CA, however it is equally valid for moving a CA from any older version of Windows server to Windows Server 2016.

The majority of the steps in this guide are identical to the steps for the offline root CA, however there are a few differences as this is a domain joined system and at the end of the guide you will need to re-register any certificate templates you have.


Start by building your new Windows Server 2016 server. I recommend again that you give it the same name as your current issuing CA, although it is possible to change it if you are willing to modify some registry keys later on in the process. If you do give this server the same name do not join it to the domain yet. This will be done later in the guide once the existing issuing CA has been removed from the domain. You should also patch the new server with the latest Microsoft patches at this time.

Migration – Backing up your existing issuing CA server

The first step is to back up the CA using the command certutil -backup C:\SubCABackup KeepLog. If you do not care about keeping the logs then you can omit the KeepLog part and instead the logs will be truncated.

You will need to enter a password, remember it and make it complex as this backup contains your issuing CA private key.


The next thing to backup is the CA configuration, which is stored in the registry in the following location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc. Back it up by typing reg export "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc" C:\SubCABackup\CertSvcRegBackup.reg


You now also need to make a record of what certificate templates you have created as these will need to be re-registered on the new CA. The easiest way to do this is to run the command Certutil -catemplates > "C:\SubCABackup\Catemplates.txt". This pipes the output to a file called Catemplates.txt which you can open later to see the names of the templates.

It is also worth backing up your CAPolicy.inf file which you can do easily enough by copying it into the backup folder by typing copy C:\Windows\CAPolicy.inf C:\SubCABackup.

Once you have done the work to backup your existing issuing CA it is time to uninstall the CA role. Before doing this run Get-WindowsFeature in Powershell and have a look at what additional CA features you currently have installed (for example you may have the Web Enrolment service and/or Online Responder roles installed). Make a note of these so that you know what features to install on the new issuing CA server.


To uninstall the certificate authority role use the Powershell command Remove-WindowsFeature Adcs-Cert-Authority and press enter. If you did have any additional CA roles installed you may need to remove those first; in my case I had to remove the Web Enrollment service (this was done by running Uninstall-AdcsWebEnrollment).

You will need to restart the server to complete the role uninstall.

It is now important that you copy the SubCABackup folder to your new issuing CA as the next step is to remove the existing issuing CA from the domain and power it down.

To remove the old issuing CA from the domain using Powershell type Remove-Computer HOSTNAME replacing HOSTNAME with the name of your issuing CA. Restart the server to complete the domain removal and then power down the old issuing CA.

Load Active Directory Users and Computer from a management workstation and delete the computer account for the old issuing CA.

Migration – Configuring your new issuing CA and restoring from the backup

Power on your new issuing CA and join it to the domain. You can do this from Powershell by typing in Add-Computer –DomainName yourdomain.com -Credential YOURDOMAIN\Administrator replacing the domain with your domain and the admin account with your admin account. Restart the server to complete the domain join.

Once the reboot has completed you must install the CA role. Do this using Powershell by typing in Add-WindowsFeature ADCS-Cert-Authority and pressing enter. As with the root CA this now needs to be configured using the backup from the old issuing CA, which you do with the following Powershell command:

Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCA -CertFile "C:\SubCABackup\LaptopPoc Sub CA.p12" -CertFilePassword (Read-Host "Enter password" -AsSecureString)

Replace the value after -CertFile with the path and name of the .p12 file from your issuing CA backup. When you press enter you will be prompted for the password you used to back up your original issuing CA.

If this step is successful you will receive ErrorID 0 as your return code.

Next you need to restore the database and logs. Before you do this the CA service must be stopped. Do that by typing in net stop certsvc and pressing enter. Once it has stopped restore the database and logs using the command certutil -f -restore C:\SubCABackup. The -f forces an overwrite of the data that was configured in the barebones CA setup. Once again you must enter the password you used to backup your original issuing CA.

Before starting the CA service you must import the registry configuration. If you opted to change the name of your issuing CA server you need to go through the C:\SubCABackup\CertSvcRegBackup.reg file and replace and reference to the old server name with your new server name. Once this is done you can import the configuration by typing reg import "C:\SubCABackup\CertSvcRegBackup.reg".

Finish up the restoration process by copying the CAPolicy.inf file back into the Windows directory by using the command copy C:\SubCABackup\CAPolicy.inf C:\Windows

One final thing

There may be one other thing you need to consider before you can start your new issuing CA and that is the location of the web CRL. This is a website that is likely hosted inside your network that contains an up to date certificate revocation list which your issuing CA needs to have access to before it will start. This may not be a problem for you at all if your web CRL is hosted on an separate web server that you did not touch during this migration. However, if like me your web CRL is hosted on your issuing CA, this will have been lost when you decommissioned your previous issuing CA.

To resolve this you will need to install IIS on your new issuing CA and configure a new site to host your CRL. The URL to the CRL must match the previously configured CRL location, so if it used to be accessible via http://PKI.yourdomain.com then it must still be accessible there now. You can find the URL for your CRL by looking at any certificate issued by your CA, going to the Details pane and looking at the CRL Distribution Points field.

Restoring your certificate templates

With everything else done you can now start your new issuing CA by typing in net start certsvc. Now you will need to re-register each of the certificate templates you had on your previous issuing CA. Open the Catemplates.txt file you saved by typing notepad Catemplates.txt and use it as a reference for the names for each of your templates. You will need to run the following command for each one:

certutil -setcatemplates +TEMPLATENAME

Replace TEMPLATENAME with the name of your certificate template. Note that + before the template name.


Do this for each of your templates. Once completed all of your templates will be available again and all issuing permissions will be retained.

That completes the process of migrating your issuing CA to a new server. If you have multiple issuing CA servers you will need to repeat this process for each of them. You may also need to reinstall any additional certificate service roles such as Web Enrollment1, which you can do either in Powershell or by using a management workstation with Server Manager. You should make sure you delete the C:\SubCABackup folder so that you don’t leave your issuing CA private key laying around.

1You may encounter error 0x80070057 when reinstalling the Web Enrollment role. If you do, take a look at this blog post: AD: Certification Authority Web Enrollment Configuration Failed 0x80070057 (WIN32: 87)


Buy Me A Coffee

Migrating your Microsoft PKI infrastructure to Windows Server 2016 (Part 1)

Migrating your Microsoft PKI infrastructure to Windows Server 2016 (Part 1)
Migrating your Microsoft PKI infrastructure to Windows Server 2016 (Part 2)

As part of my efforts to upgrade my POC lab to Windows Server 2016 I got around to migrating my PKI infrastructure. This consists of an offline root CA and an online issuing CA. In Part 1 of this guide I will be migrating my offline root CA to Windows Server 2016.

This guide is written as a guide to upgrade from a Windows Server 2012 R2 CA to a Windows Server 2016 CA, however very little has changed since the Windows Server 2003 days and this guide is equally valid for moving a CA from any older version of Windows server to Windows Server 2016.

I am a big advocate of the core versions of Windows Server and in this guide I will be migrating from and to Windows Server core. A CA is a perfect example of a server that does not need the overhead of the GUI and additional services that comes with the full GUI edition of Windows Server and if you don’t already use core for your CA, this is a perfect opportunity to migrate to one!


In preparation for the migration build your new Windows Server 2016 server. I recommend that you give it the same name as your current root CA server – it is possible to give it a different name however this will require changing registry keys later on in the migration process. Take this opportunity to patch it with the latest Microsoft patches!

Migration – Backing up your existing root CA server

The first step is to back up the CA using the command certutil -backup C:\RootCABackup KeepLog. Note that the KeepLog part is optional, however without it the backup will truncate the logs. I prefer to bring the whole lot across in case the logs are ever needed in the future for auditing purposes.

You will need to enter a password, remember it and make it complex. This backup contains your root CA private key, do not make it easy for an attacker to obtain.


The next thing to backup is the CA configuration, which is stored in the registry in the following location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc. Back it up by typing reg export "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc" C:\RootCABackup\CertSvcRegBackup.reg


Additionally it is worth backing up your CAPolicy.inf file which you can do easily enough by copying it into the backup folder, by typing copy C:\Windows\CAPolicy.inf C:\RootCABackup


Finally, copy the RootCABackup folder to your new CA.

Migration – Configuring your new root CA and restoring from the backup

Log on to your new root CA server and start by installing the CA role. The easiest way to do this is with PowerShell, so type powershell into your administrative CMD prompt and enter the following command to install the CA role: Add-WindowsFeature ADCS-Cert-Authority

Now configure this new CA using the backup of the old CA. This can also be done with PowerShell using the following command:

Install-AdcsCertificationAuthority -CAType StandaloneRootCA -CertFile "C:\RootCABackup\LaptopPoc Root CA.p12" -CertFilePassword (Read-Host "Enter password" -AsSecureString)

Replace the value after -CertFile with the path and name of the .p12 file from your root CA backup. When you press enter you will be prompted for the password you used to back up your original root CA.

If this step is successful you will receive ErrorID 0 as your return code.


This restores the root CA private key, however next you need to restore the database and logs. Before you do this the CA service must be stopped. Do that by typing in net stop certsvc and pressing enter. Once it has stopped restore the database and logs using the command certutil -f -restore C:\RootCABackup. The -f forces an overwrite of the data that was configured in the barebones CA setup. Once again you must enter the password you used to backup your original root CA.


Do not start the certificate authority service just yet! Before doing that the registry settings from the previous root CA need to be restored. Do this by typing reg import "C:\RootCABackup\CertSvcRegBackup.reg"

Note: If you chose to change the name of your root CA server you will need to go through the values in this registry file and change any reference to the old server name to your new server name before importing it.

Finally copy the CAPolicy.inf file back into the Windows directory by using the command copy C:\RootCABackup\CAPolicy.inf C:\Windows

Now you can start the root CA by typing net start certsvc. The service should start with out any issues. To verify this you should log on to a management workstation and load the Certificate Authority MMC snap-in, connect to the new server and verify that your issued / revoked certificates are listed (as this is a root CA there should be very few issued certificates!)

Once you are satisfied that the new server is configured correctly and working, make sure that you delete the C:\RootCABackup folder. As previously mentioned, this contains your root CA private key, you do not want to leave that laying around!

Coming soon is Part 2, which will focus on migrating the issuing certificate authority. Thankfully the steps for this are very similar with only small differences due to it being a domain joined server.


Buy Me A Coffee

Error 80070057 when attempting to update Windows Server 2012 R2

Once when I was updating some servers running the version of Windows Server 2012 R2 I encountered something odd; no patches appeared in Software Center or in the Windows Update panel, even though the server was several years out of date and definitely had applicable updates!

In WindowsUpdate.log I found the following error message repeating:


The fix for this is to manually download and install KB2919355, which is the April 2014 update rollup for Windows Server 2012 R2. After this has been installed and the server has restarted, re-run your updates scan and updates will show up in Windows Update or Software Center.


Buy Me A Coffee

Increasing the maximum run time for Windows 10 and Windows Server 2016 cumulative updates

One of the things I have noticed since starting to deploy Windows Server 2016 is that the cumulative updates can fail to install when deployed from SCCM. It starts to run but then times out due to the maximum run time having been reached. By default this is set to 10 minutes. However due to the updates being larger and taking longer to install than updates prior to the cumulative updates era 10 minutes doesn’t seem to be long enough. The fix for this is to simply increase the maximum run time for cumulative updates for both Windows Server 2016 and Windows 10 from 10 minutes to 30 minutes.

Screen Shot 2017-06-05 at 23.12.35

Screen Shot 2017-06-05 at 23.12.47

This is a bit tedious as you’ll have to do it every month for both Windows Server 2016 and every version of Windows 10 you have in your environment. Hopefully Microsoft soon catches on to this and changes the default run time to 30 minutes so that this ceases to be an issue. There is already a Configuration Manager UserVoice entry for this idea, so if you’re reading this, pop over and vote to increase its visibility!


Buy Me A Coffee

ISATAP failing with error 0x490

ISATAP can be very useful if you need to manage out from a machine with an IPv4 address to a machine with an IPv6 address. This is commonly used where DirectAccess has been deployed as all DA clients will be using IPv6. Being able to RDP to them or use the SCCM Remote Control feature from a machine inside your network is very helpful for the IT support staff – it’s as if the user was just working from their desk like usual!

One time I was configuring an ISATAP interface on a server and I got the follow error in the event log:

Unable to update the IP address on ISATAP.yourdomain.com. Update type: 1. Error Code: 0x490

I scratched my head over this for quite a while – setting up an ISATAP interface should be easy! After a while I remembered that there was a history of disabling the IPv6 components on servers via GPO. It turns out that even though the GPO had been removed, the setting to disable IPv6 had been tattooed on the servers it had once been applied to.

To check this I had a look in the following location in the registry:


The value was set to 0xFFFFFFFF (it may instead be set to 0xFF). This disables enough of the IPv6 components to prevent an ISATAP interface from being able to be created.

Simply delete the DisabledComponents key and restart the server. So long as everything else is set up correctly you will have your ISATAP interface when you next log in.
Buy Me A Coffee

Scan failed with error 0x80244021 with WinHTTP proxy configured

While trying to update one particular server using SCCM 2012 R2 I discovered that it was not updating, with the following error was appearing in WindowsUpdate.log and UpdatesHandler.log:

Scan failed with error = 0x80244021

In my case this issue was occurring because a proxy server was configured but no exception was in place for the WSUS / SCCM server. This meant that the server was trying to access the WSUS server through the proxy! To see what my proxy settings were I opened an elevated CMD prompt and entered the following command:

netsh winhttp show proxy

The following information was returned:

Proxy Server(s): ProxyServer.local
Bypass List :

As you can see, the bypass list is empty. In order to create an exception for the WSUS server, enter the following command:

netsh winhttp set proxy ProxyServer.local "https://WSUSServer.local" 1, 2

This sets the proxy and sets the WSUS server as an exception. Re-running netsh winhttp show proxy will now show you the following output:

Proxy Server(s): ProxyServer.local
Bypass List : https://WSUSServer.local

As you can see the WSUS server is now part of the bypass list, meaning that attempts to access this website will not go through the proxy.

Restart the WindowsUpdate service and re-run the Windows Update scan. You should no longer see scan error 0x80244021.

1Whether you use HTTP or HTTPS for your WSUS server depends on your WSUS or SCCM configuration.

2If you need to add multiple exceptions enter the first one, followed by a comma, followed by the next one and so on.


Buy Me A Coffee

The clients that didn’t know they were on the corporate LAN

I recently came across an issue where all of the Windows 10 clients in a particular remote site were unable to access network resources when connected to the local LAN. The strange thing? This LAN was part of the corporate network.

After searching around I found a number of people reporting similar issues with clients configured to use DirectAccess, usually being caused by things such as a corrupt Name Resolution Policy Table (NRPT) or other issues with the DirectAccess configuration. This led me to try exporting the NRPT registry keys from a working client and importing them on one of these clients that was not working. But… that did not fix the problem. And anyway, there were devices in other offices that worked when they were connected to DA and the corporate LAN. This problem was limited to this particular office, so I started to dismiss DirectAccess as being the problem.

A little more troubleshooting and I discovered something else. When connected to the LAN these clients could not ping the IP address of any internal server hostname I tried pinging. Any time I tried to use ping on an internal server I just got back "Ping request could not find host hostname.local. Please check the name and try again." They could be pinged by IP address though. So perhaps a DNS issue? Perhaps not, as I discovered that nslookup did work.

Checking the Application log in Event Viewer I found the following three critical errors repeating every minute or so:

NETLOGON | Event ID 5719
There are currently no logon servers available to service the logon request.

DNS Client Events | Event ID 8015
The system failed to register host (A or AAAA) resource records (RRs) for network adapter
with settings:

The reason the system could not register these RRs was because the update request it sent to the DNS server timed out. The most likely cause of this is that the DNS server authoritative for the name it was attempting to register or update is not running at this time.

Time-Service | Event ID 129
NtpClient was unable to set a domain peer to use as a time source because of discovery error. NtpClient will try again in 15 minutes and double the reattempt interval thereafter. The error was: The entry is not found. (0x800706E1)

This led me to think there was something wrong with these client’s ability to contact DNS, which eventually led me back to DirectAccess. As noted previously, these clients did work when connected via DirectAccess. So, I thought, if I remove the DirectAccess configuration, will that make any difference to this broken-when-on-the-corporate-LAN situation? As I couldn’t just remove the DirectAccess client from the DirectAccess security group (because the client could not contact the domain controller to receive the policy change) I had to find the DirectAccess configuration in the registry and delete it there. It resides under HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DNSPolicyConfig. I my case there were 4 entries underneath this key, composed of DA-{GUID}. I deleted these keys, restarted the client and found, to my delight, that it was now functioning correctly on the LAN. For good measure I re-added the DirectAccess configuration (this time by simply adding the client back into the DirectAccess security group) and confirmed that with the DirectAccess configuration back in place, the client was broken again on the LAN.

So, what was going on? Eventually the following article from Microsoft led me to the answer: Network Location Detection. This article details the process Windows goes through to determine whether or not it is on the corporate network. When a network adapter status change is detected Windows attempts to access the URL that is stored in the registry key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity\DomainLocationDeterminationUrl. The URL in this key will have been configured by whoever originally set up DirectAccess in your organisation. If Windows does not receive a valid HTTP response (HTTP status 200 OK) it believes you are not connected to the corporate LAN and attempts to connect to DirectAccess. During this process the entry in the NRPT table that governs what DNS server to use when connected to DirectAccess is used and, because you are not actually connected to DirectAccess, name resolution problems start to occur.

What about a fix? Why couldn’t the client access the network location detection URL? This goes back to the way DirectAccess is configured. Best practise states that your DirectAccess servers should have two network adapters; one internal and one external. Only the external adapter should be configured with a default gateway to prevent routing issues. Internal routing has to be done via static routes.

And that was the key. This was a small remote site that had only recently been connected to the corporate network and there was no static route between the DirectAccess server and the IP subnet being used by this site. After hours of investigating, this issue was resolved in a single moment by issuing the following PowerShell command:

New-NetRoute -InterfaceAlias InternalAdapterName -DestinationPrefix Subnet/Mask -NextHop GatewayAddress

I went back to my broken client, opened my browser and entered the network location detection URL and was presented with the Microsoft IIS splash page. I restarted all the clients onsite and they correctly detected that they were on the corporate LAN.