Confirm Service Account Credentials The Easy Way with PowerShell (e.g. SCCM Network Access Account)

Sometimes you will have an AD Service Account configured and you might not be sure what the password is – a good example of this that sometimes catches me out is the SCCM Network Access Account.

To safely test the account username and password we can use PowerShell with the following simple and safe command:

Start-Process -FilePath winver.exe /c -Credential (Get-Credential)

This will attempt to run “winver.exe” and a prompt will appear asking for credentials:


If the account credentials that you enter are not correct you will see the following error:


But if the credentials provided are correct then “winver.exe” will open as expected and no error message will be produced:


Simple but effective ūüôā

/ JC

Posted in PowerShell, SCCM Current Branch, Tips, Uncategorized, Windows | Leave a comment

Add CMTrace.exe to Computers Being Deployed via Task Sequence

To make sure you have CMTrace.exe available for use on machines that are deployed via SCCM Task Sequences you can add a “Run Command Line” task immediately after the “Apply Operating System Image” that copies the executable from the boot image being used to deploy the OS (CMtrace.exe is included by default SCCM Current Branch WinPE boot images – WinPE is mapped as X:\ during OSD) and results in it being available once OSD completes:

 cmd /c xcopy X:\SMS\BIN\x64\CMTrace.exe %OSDTargetSystemDrive%\Windows\System32\ /E /H /C /I /Q /Y

This command line will need to be amended in the unlikely scenario (it’s 2017 after all) that you’re deploying a 32-bit Operating System to change the xcopy target path accordingly.

/ JC

Note: This was originally documented on TechNet yonks ago: Link

Posted in OSD, SCCM Current Branch, Tips, Uncategorized, WinPE | Leave a comment

Use Task Scheduler to Schedule Server Reboot Out of Hours

You may from time to time have a requirement to reboot a server out of hours after implementing a change that requires a restart.

Rather than logging in at Silly O’Clock at night you can use the Windows Task Scheduler to set up a Task to have an unattended reboot occur out of hours.

Open “Task Scheduler” from the Start menu and select “Create New Task“.

Complete the “General” tab¬†by adding the following values for “Name“, “Account” and “Configure for“:


By using the “SYSTEM” account we can be sure that the required permissions to reboot/shutdown the computer are present.

On the “Triggers” tab click on “New” and configure a time suitable for your environment. In my example I have chosen a one time event at “22:00:00” as this is deemed out of hours:


On the “Actions” tab click on “New” and configure the task as per below:


In the “Program/script” field add the word “shutdown“.

In the “Add arguments (optional)” field make sure the following is added:

/r /t 0 /c "Planned Server Reboot via Task Scheduler Task" /f

Click “OK” twice and you’re done.

The command that you have just configured passes the following instructions to the “Shutdown.exe” executable:

  • /r = Reboot
  • /t 0 = waits 0 seconds before restarting
  • /c = comment to be added into the System log in Event Viewer
  • /f = forces the reboot even if users are logged on, programs are open, files are locked etc.

/ JC

Posted in Tips, Windows | Leave a comment

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 “” 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

Posted in MBAM, OSD, PowerShell, SCCM Current Branch | Leave a comment

Open Local Computer Certificates MMC From Single Command

A quick and simple post today.

Since Windows 8/Windows Server 2012 you can directly open the Local Computer Certificates MMC console by running the following command:


This will launch “certlm.msc” showing the information that you want.

You can still open the default store using “certmgr.msc” as you could on previous versions of Windows.

/ JC

Posted in Batch File, Windows | Leave a comment

SCCM Windows 10 Upgrade Task Sequence: BitLocker PIN Protector Issues on Laptops

I’ve recently been looking at using SCCM Windows Upgrade Task Sequences to migrate from Windows 10 1511 to Windows 10 1607 for a customer.

On desktop devices this process ran through as expected and didn’t cause any real problems (i.e. nothing that I wasn’t expecting or that couldn’t be easily resolved).

Laptops with PIN protectors enabled did present¬†a problem however…

It seems that while the upgrade process disables BitLocker automatically, PIN protectors become active again too early (i.e. before the end of the Task Sequence) meaning that end users would need to enter their PIN at least twice (possibly more depending on any additional Restart Computer actions in the Task Sequence) before the Task Sequence completes successfully.

Obviously this might be a pain in the arse for end users so it would be nice to find a way to avoid them having to enter their PIN repeatedly.

My solution for this is shown in the image and text below (steps highlighted in red are the ones required to resolve this specific issue):


The commands for each of the highlighted tasks are:

# Disable BitLocker Protectors Indefinitely
cmd.exe /c "manage-bde -protectors -disable C: -RC 0"

# Re-enable BitLocker Protectors
cmd.exe /c "manage-bde -protectors -enable C:"

# Disable BitLocker Protectors for Single Reboot
cmd.exe /c "manage-bde -protectors -disable C:"

The first highlighted command disables BitLocker protectors indefinitely (Reboot Count = “0” turns off protectors until you issue an “-enable” command) which means you can reboot the device as many times as you like without BitLocker rearing it’s ugly head at all.

The second highlighted command re-enables all BitLocker protectors which therefore reverses the “Disable BitLocker Protectors Indefinitely” command.

The final highlighted command (“Disable BitLocker Protectors for Single Reboot”) disables BitLocker protectors on the C: drive again but using the default Reboot Count (when “-RC” isn’t specified the default value is used which is “1”) which only disables the protectors for a single reboot.

This means that after the final “Restart Computer” task the OS has been upgraded, all custom actions in the TS will have completed and all protectors for the C: drive are all switched back on.

Bloody marvellous.

/ JC

Posted in OSD, SCCM Current Branch | 4 Comments

“Finish Installing Device Software” in Windows 10 Action Center

If you get a message in the Windows 10 Action Center saying “Finish installing device software” with a red/white cross and a UAC symbol on then it’s likely that a driver is missing, a driver needs some software installed or that Windows needs your permission to resolve one of these actions (hence the UAC symbol).

In can be an absolute bastard to figure out which device/driver is causing this issue but one way to track it down is to click to allow the install to complete and then look in the file:


Look for Finish-Install actions (typically they will be the latest entries in the log file if you’ve just clicked to complete the action immediately before looking) and that should lead to you to identifying the troublesome device. Back of the net.

/ JC


Posted in Uncategorized | Leave a comment