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

1

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:

2

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

3

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

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:

 certlm 

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):

upgradets

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:

C:\Windows\Inf\setupapi.dev.log”

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

Increase the Speed of PXE Boot/TFTP When Using SCCM Distribution Point

If you’re looking to improve the performance (quite significantly in my experience) of Trivial File Transfer Protocol/TFTP (in other words to improve the download speed of your SCCM boot images to your clients from the DP) you can add some registry keys on the server hosting the PXE-enabled Distribution Point to achieve this.

The two keys required (and the values I suggest using) are:

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\SMS\DP" -Name RamDiskTFTPBlockSize -PropertyType DWord -Value "16384"
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\SMS\DP" -Name RamDiskTFTPWindowSize -PropertyType DWord -Value "8"

Once the keys have been added, restart the “Windows Deployment Service Server” service and that’s you finished. 🙂

One caveat with this change is that it can also adversely affect performance and in some cases even break PXE altogether (as I found out with my Hyper-V 2012 R2 VM’s – VM’s stopped working completely while physical hardware zipped along like shit off a stick) so some tweaking of the values may be required depending on your environment. Basically one size does not fit all with this change.

Can’t find any proper information on SCCM CB but it looks like this is a supported change from looking at this TechNet post: link

UPDATE 30/09/2016 – some much better detail and testing results for this TFTP optimisation provided by Jörgen Nilsson on the excellent ccmexec.com website – link

/ JC

Posted in SCCM 2012 R2, SCCM Current Branch | Tagged , , , | 4 Comments

Quickly Determine all Local Drive Letters on a Device From Command Line

To quickly see which drive letters/volumes are available from a command prompt you can use wmic to get a quick summary.

The following command will give you the information you need:

wmic logicaldisk get description,name

/ JC

Posted in Uncategorized | Leave a comment