Roberts Blog

The House of ConfigMgr and Intune on Endpoint Management Way

DigiCert – CMG Server Authentication Certificate – Prove Domain Control using WWW

I just went through the process of requesting a PKI certificate from one of the third-party certificate providers for my lab CMG, I used DigiCert, and the route I took was a little bit off-piste, as in not well-documented, so I thought I’d share.

CMG’s require a PKI “server authentication” certificate as an installation requirement:

This certificate can be issued internally using Enterprise PKI or issued by a Public provider. Simply put, the choices are a ‘third-party’ public provider versus an Enterprise server residing on your corporate network running Certificate services.

Notable key reasons why you’d use either:

  • Enterprise PKI – Complete management control over issuance and revocation for the entire lifetime of the certificate, requires an infrastructure footprint that can span both the Intranet and Internet (CRL publishing) with an attendant team with reasonable PKI skills. Fits well in a large organisation that needs PKI for more than ConfigMgr, but not so well in small environments. Requires a documented procedure and preservation of knowledge for 1 to 2 years to handle certificate expiration, which can be difficult for small teams who leave the PKI server (often a VM) alone until it is needed. I’ve seen a customer’s admin attempt to return to an Enterprise PKI VM only to find it is missing, make sure you read about what to back up up on your Enterprise PKI CA … and small shops be aware that once you implement Enterprise PKI you have both an ability and a liability in the environment. The trusted root certificate and any intermediate certificates need to be installed onto devices that are going to talk to a CMG.

  • Public PKI – No actual infrastructure is required, a one time cost until the certificate needs renewing (make a calendar reminder for at least 2 weeks before expiration). Renewal is a relatively straight-forward process but requires documentation or a decent guide. Windows 10 contains a DigiCert root certificate that will be in the CMG’s server authentication certificate certification path, that’s a tick in the box for one of the CMG’s security requirements and importantly means we do not have to install certificates on devices for them to talk to the CMG. This pathway opens up the minimal steps needed to install the ConfigMgr client on remote devices, which is CCMSETUP.EXE and a command line to point at the CMG, and I like it a lot, unlocks an age old problem around client install on workgroup devices residing anywhere in the world.

Before a client can talk to the CMG to do the actual authentication (Azure Identity, Token identity, Certificate identity) it has to have a root certificate installed that the CMG trusts, either your Enterprise PKI trusted root certificate if you are using an Enterprise PKI certificate, or if you are using a Public PKI certificate a Windows 10 built-in root certificate. Here’s a DigiCert certificate issued for my CMG showing the certificate certification path or “chain”, the certificate is linked or chained to an intermediate certificate which is linked or chained to the DigiCert root certificate:

I won’t cover the process for handling the CMG server authentication certificate request with DigiCert end-to-end, instead I’ll redirect you to a quite competent fellow EM MVP, Eswar Koneti, who wrote a good blog post on the entire procedure, from how to request the certificate to authorising it with DigiCert, to obtaining the certificate in readiness to hand it off to a CMG.

He has other posts, specifically one that talks about how to switch from Enterprise PKI to Public PKI which is definitely worth having a look at.

In Eswar’s guide he resorts to using Email as a means to prove control over the domain being used, which then leads to issuance of the Certificate.

DigiCert’s three options for doing this security-handshake before the certificate is issued currently are:

  1. Email
  2. File
  3. DNS

With Eswar taking the email route, I’ll show you how to take the File route.

The shot below shows a certificate that DigiCert are processing, I’ve provided the CSR and now need to prove that I own the domain:

The reason I went about using the file route is because I do not have email for, and I couldn’t get the DNS method to work using a TXT record containing the CMG DNS name or a TXT record containing the TLD, like this:

Since is just a CName alias to the destination, there is no DNS zone in which to create a TXT file, has anyone else used DNS to prove control over the domain when ordering a certificate for a CMG? Or does DigitCert assume it is a sub-domain and isn’t checking the top level domain?

Without Email access and with the DNS changes not being recognised by DigiCert, that leaves the File method, which entails publishing a TXT extension file on a web server.

You might as well download the fileauth.txt file now and store it on your web server.

Before we dive in be aware that this change will take an already existing CMG service offline for several hours, as we will modify the public DNS CName record making it inaccessible to clients for a period of time. Therefore the Email and DNS routes are more desirable as a consequence outside of a lab.

Firstly go to your DNS admin portal and change your CMG CName alias, so that instead of pointing at your destination it points at the IP address of your web server.



It will take an hour or two for the DNS record to expire and be refreshed, dependent on the TTL.

In the meantime visit your web server.

Create a folder somewhere so as to host the fileauth.txt file you downloaded from DigitCert:


The above example shows Website as the root folder, you can call this anything you want, however the following folder and its sub-folder must remain the same: well-known\pki-validation

Here’s a shot of Explorer:

Drop fileauth.txt into the pki-validation folder.

Visit IIS Manager.

One of your web sites will have your DNS name bound to it, mine is, if you don’t have an existing website create a new one yourself (create a new folder for it, sort out its bindings, put a test landing-page in there, make sure it renders in a web browser) and follow on with these steps.

Open your websites bindings and add the FQDN that you use for your CMG CName, mine is

Once the DNS change for the CMG’s CName has taken place, punching it in to a web browser will take you to your website.

If you have a landing page for your website, mine is a WordPress blog, you should see it, if not check that the CName change we made has replaced the previous by visiting a website like, if that is okay it’s most likely firewall rules if its a new website.

Next we create a virtual directory using our website as the target:

The Alias has to be called .well-known, and the physical path points to the new well-known folder that we created earlier. Worth noting that you can create the well-known folder and its subfolder within an existing websites folder, I kept them separate for no real reason.

You should have a new virtual directory shown hanging off your website:

Open a web browser, punch in the URL and see if the FileAuth.txt files contents are rendered.

In my case the URL would be: HTTP://

Here’s the file appearing in the web browser:

Once it is showing, return to DigitCert and complete the process for proving control over the domain for this certificates request, and go collect your certificate. Eswar’s guide explains what to do next, but before moving on revert your DNS CName change back to your destination:

And also remove the website virtual directory and the folder structure, so as to tidy up.

An hour or two later DNS lookups will show the CName has changed back, at which point you are good to go with installing the CMG with your new PFX certificate.


Delivering CMTrace using Intune during AutoPilot

In this post I’m going to go through the steps needed get the CMTrace tool onto a system during an AutoPilot build, purely so we can pour over logs without the hassle of manually bringing the tool onto the system, or copying the logs onto a remote system with the tool available.

During a failed AutoPilot build, reading the IME (Intune Management Extension) log is a bit of an “art” in of itself, but viewing that log in Notepad is no fun at all; And mapping a network drive so as to copy CMTrace locally is a chore that doesn’t bear repeating often. It’s best if the tool is delivered during AutoPilot.

Whatever we do we’re going to need to lean on Intune’s Win32 app delivery support (not the Line-of-business App which requires an MSI), which affords us the ability to package up multiple files and folders then invoke something in there. In our case the executable for CMTrace and a PowerShell script.

To begin we need to download that IntuneWinAppUtil tool and point it at the folder containing the files, upload the resulting INTUNEWIN file to Intune and deploy that as required to the AutoPilot devices.

There’s two notable ways to go at delivering CMTrace with Intune, firstly just package up the CMTrace executable without a script present and let Intune run a PowerShell command to copy the executable to a destination folder, or package up the executable along with a PowerShell script which does the copying.

You can include a script if for example you wish to do more than just copy the executable to a destination folder, such as associating CMTrace as the handler for the LOG and _LO extensions as EM MVP Jörgen Nilsson does in this excellent post. Or you could put most of it on a single command, but it is worth noting that there is a character limit in Intune for command lines so don’t make them too long.

The two approaches allow for different scenarios during AutoPilot, light and easy with the admin finding the tool and launching when needed, or with no need for an admin to launch the tool before opening a LOG file (file associations set).

In this post I’m going to use the scripted route to only copy the executable to the C:\Windows directory, and leave you to wander over to Jörgen Nilsson’s post if you want to add the file handler associations stuff (just paste his script content into the script created here).

I have a folder structure to build out Intune Win32 applications while using the IntuneWinAppUtil utility. I keep this separate from my ConfigMgr source folder. It has both a folder for the source files and a folder to accommodate the resulting INTUNWIN files that are spewed out by the IntuneWinAppUtil tooling:

  • Source\Intune\<Application Folders>
  • Source\Intune\INTUNEWIN\<Application Folders>

Here goes.

  • Create a build folder for CMTrace in your Intune application source folder, call it CMTrace
  • Copy CMTrace.exe to the build folder
  • Create a new PS1 file in the build folder and call it cmtrace.ps1
  • Open the PS1, pour in the contents below, as usual check that the quotation marks are correct, save the file. Worth running the script in-place to make sure it works before proceeding.

Here’s a basic script to work from:

Copy-Item “$($PSScriptRoot)\CMTrace.exe” -Destination C:\Windows\CMTrace.exe -Force

We now have CMTrace.exe and cmtrace.ps1 in the new build folder.

You can modify this script up with as many modifications as you want, I doubt there would be many for CMTrace, but for other deployments scripting opens a door that allows us to customise delivery as we need.

The IntuneWinAppUtil packaging tool is pretty easy to use, requires three inputs to run for most scenarios of source folder, source file (the exe or the ps1) and the output folder:


Here’s the command line to package CMTrace:

IntuneWinAppUtil.exe –C “D:\Source\Intune\CMTrace” –s “D:\Source\Intune\CMTrace\cmtrace.ps1” –o “D:\Source\Intune\INTUNEWIN\CMTrace”

We’re about to run the packaging tool:

Here’s the IntuneWinAppUtil tool after packaging the source folder: