In ConfigMgr version 2002 Microsoft introduced the ability to remotely collect client logs using the client notification channel and have them delivered to your Management point. This is very useful as it means you can troubleshoot client issues without disturbing your users.
Assuming that the connection between your Management point and your client(s) is healthy and the request is making it to the client, a new log will appear in C:\Windows\CCM\Logs called Diagnostic.log when the log collection is initiated. A successful log collection will generate three lines in the log:
In a rare case, however, client log collection may not work. One reason may be that the size of the compressed client logs exceeds 100 MB, which is the limit according to Microsoft’s documentation. Another reason, which is not documented anywhere, is that if the full path of any log (including the log name itself) exceeds 116 characters in length, the log collection will fail.
For example, the following would work as the full path is exactly 116 characters:
This is very unlikely to cause you a problem as none of the ConfigMgr client log files are this long. However, if you capture application install\uninstall logs and decided to put them in the same folder as the ConfigMgr client logs directory, there is a possibility that they will exceed this path length. If this is the case, you will need to choose a new path to store these logs and move them on all your clients.
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.
Considerations 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.
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.
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.
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.
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:
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.