MBAM Client Deployment PowerShell Error 0x803d0006 – SCCM OSD in Disconnected/Offline Environments

Whilst deploying MBAM as part of a Windows 10 OSD Task Sequence in SCCM CB the “MbamClientDeployment.ps1” task was failing I was getting the error message shown below in the client “smsts.log” file:

 HRESULT: 0x803d0006 

I logged into one of the failed clients, opened Internet Explorer and attempted to connect to the URL for the MBAM Core Service manually – this took 42 feckin seconds! Obviously this is far too slow for the connection via the PowerShell script to be successful so the next question was why was this taking so long…

After a period of frustration, emotion and profuse swearing I ended up digging a bit deeper to see what was happening under the hood when trying to connect to the URL of the MBAM Recovery and Hardware Service (i.e. https://mbam01.testlab.local/MBAMRecoveryAndHardwareService/CoreService.svc).

To do this I installed a tool called Fiddler (sounds dodgy but it’s a lightweight freeware tool for monitoring web connections – far simpler to implement and use when compared to WireShark or Microsoft Message Analyzer) on a client and once again accessed the URL via Internet Explorer to see what connection attempts were being made by the client when attempting to access the MBAM service.

Turns out that calls were being made to Windows Update URLs and various “crl.microsoft.com” URLs. Basically the clients were trying to download the latest Root level Certificate Revocation Lists/Certificates from Microsoft’s servers over the internet. Because the clients didn’t have access to the internet due to firewalls blocking, the clients eventually timed out trying to connect to Microsoft which subsequently took the response time for the MBAM service connection over the allowed limit. This resulted in a timeout occurring when MbamClientDeployment.ps1 ran.

If the clients were able to access the internet (and able to connect to the URLs they were reaching out to) then there wouldn’t have been a problem and the script would have completed without any problems.

To make absolutely sure I tested this by unchecking the Internet Explorer option “Internet Options | Advanced | Check for server certificate revocation” on the client – rebooted the client and retried: I was able to hit the MBAM web service immediately with zero delay. Ticked the box again, rebooted, retried and the response was back up to 42 seconds (i.e. buggered again).

I don’t think it’s possible (or desirable) to disable certificate revocation checking for all certificates so another solution had to be found to this problem.

In the end the solution was to disable the automatic updating of the Root CA certificates/CRLs using the following registry key:

 HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot "DisableRootAutoUpdate" | Dword = 1 

I accomplished this via a PowerShell script running as part of the Task Sequence.

  1. PowerShell script to set the “DisableRootAutoUpdate” registry key
  2. Reboot
  3. MbamClientDeployment.ps1

This disables the automatic update of the Root CA’s resulting in there being no delay in the MBAM service connection and consequently the MBAM PowerShell script completes successfully.

The PowerShell script to make the registry changes contains the following lines of code:

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\SystemCertificates" -Name "AuthRoot" -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot" -Name "DisableRootAutoUpdate" -PropertyType "Dword" -Value "1"

Hopefully this will save someone else the hours of misery that I endured to get this bastard to work…

/ JC

Advertisements
This entry was posted in MBAM, OSD, PowerShell, SCCM Current Branch. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s