I would certainly agree with what @Jason-MSFT said.

The bootstrapper install (looks like InstallShield calling a MSI wrapper judging by the command line) is exiting too early, so the detection method first time around fails. Normally the wrapper has exited (so the setup.exe has finished) but the /v/qn parameter has been passed to the extracted MSI to install within, and it's that which populates the uninstall key you've added for detection.

If the InstallShield wrapper supports it, you can use the /SMS option (so your install command is /S /SMS /v/qn) which does the wait for you (SMS being the old name for SCCM).

If it doesn't, one way around this is to add some form of timeout or delay command, so in simple form if you wanted a 60 second wait afterwards, the script below (call it install.cmd would work)

%~dp0DPM_Setup64_3_6_0.exe /S /v/qn
C:\windows\system32\timeout.exe /T 60 /NOBREAK

You amend the deployment type to call install.cmd, and should then work as you need.

Hope that helps!

I had already tried adding the root CA cert there and once added, then generated the boot image (and noted it had a SHA256 checksum when the boot image generation was completed).

Exactly the same failure unfortunately, despite the fact smsts.log could actually see that there was a cert generated from the CA and it was referenced in WinPE - it still came back with the same error as the boot image and client without the root CA cert.

I suspect this is because (as I mentioned earlier) we're not using full PKI for client auth when domain connected, and using enhanced HTTP with the inbuilt ConfigMgr certs.

Thanks for the feedback Jason, much appreciated.

In our case, CRL checking is already turned off and the root CA isn't specified (because we're not using PKI)

The boot image had been generated with those turned off already, but when attempting to retrieve the task sequence list, it communicates with the CMG using HTTPS and therefore fail.

I do think it may be a limitation with the way the token-based authentication works, because as you say the client in the boot image doesn't have a token to authenticate to the CMG against or that the CA is trusted either. I suppose you could attempt using a bulk registration token using a pre-start command, but I suspect actually if that was the case, an option would exist in the create task sequence media options to do that?

Jason,

Thanks for that. If using a public CA isn't an option, how would I establish trust in the boot media so that when the CMG is contacted, it knows that the authority is valid and can proceed?

Looking at SMSTS.log in X:\windows\temp\SMSTSLog\ using the boot media, I can see that after setting the TS variables once WinPE has booted, it mentions this:

Missing root CA environment variable from variables file

The next part of the log is as below, I've blocked out the CMG address but it appears in all the blocked out parts of below:

This is just before the callback status secure failure.