If you administer ConfigMgr frequently you have probably come across your fair share of clients that are not appearing in the console, or don’t appear to be completing their registration process. The first place most of us go is the ClientIDManagerStartup.log file as this log details the CcmExec process start up and is one of the first log files that errors will show up in if there are problems communicating with the site server.
You may see the following error appear in the log file: 0x87d00231.
Unfortunately, 0x87d00231 is a fairly generic error message that pretty much just means “something went wrong”. If you Google it, you will see a variety of solutions ranging from reinstalling the client to checking your PKI environment is functioning correctly or checking the health of your Management Point(s). These are very valid suggestions; however, they could lead you down a time-consuming rabbit hole. Before you go down that rabbit hole there is one very simple thing it could be, and the answer can be quickly found in the CcmMessaging.log file:
Yes, it could be as simple as the user of the device having set their connection as a metered connection. This can be done on Windows 8.1 and Windows 10 clients. Now you know the reason the user’s device isn’t completing its registration, you can find out why they are using a metered connection and correct it if it’s in error.
Since mid-December 2019 I have been trying to update my SCCM lab environment from 1906 to 1910. For the first few weeks of release it was in the early update ring, but no matter how many times I ran the PowerShell script to enable early updating, the update would not appear in the Updates and Servicing node in SCCM.
Oh well, no matter, I thought. Perhaps it’s buggy and has been pulled, or maybe there’s just some odd reason my environment isn’t compatible. I’ll just wait for the general release.
General release comes and goes… and still no update. What’s going on?! I am 100% certain that my Service connection point is set to Online, I have restarted the SMS_EXECUTIVE service so many times, and also restarted the whole server just to be as thorough as possible! I know my server has internet connectivity because the Software update point is happily downloading and applying the January 2020 updates to my servers and clients. And finally, I have checked dmpdownloader.log, CMUpdate.log and hman.log and there are no obvious errors in there to tell me why I’m not seeing the latest update.
(Okay – that paragraph was a overblown way to tell you what you should definitely check if you haven’t already, before you continue to read).
So, what was going on?
Delving a little deeper in the hman.log file, I did find the following two errors:
CServerStatusReporter::DeliverToStatusManager(): ERROR: Cannot deliver status message to SMS_STATUS_MANAGER, could not write the message to varfile E:\Program Files\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs\90sna58w.SVF due to a file error: The file or directory is corrupted and unreadable.
Error: Failed to move file E:\Program Files\Microsoft Configuration Manager\inboxes\hman.box\ForwardingMsg\___CABConfigMgr.Update.Manifest.MCM to E:\Program Files\Microsoft Configuration Manager\inboxes\hman.box\CFD\ConfigMgr.Update.Manifest.CAB, Win32 error = 1392
When I attempted to navigate to “E:\Program Files\Microsoft Configuration Manager\inboxes\statmgr.box\statmsgs” I got an error message telling me the location was corrupted and unreadable!
I got the same error when I tried to navigate to “E:\Program Files\Microsoft Configuration Manager\inboxes\hman.box\CFD”. I’m not entirely certain how these two locations became corrupted, but thankfully Windows Explorer allowed me to rename them to “statmsgs.old” and “CFD.old” respectively, and then re-create the folders.
Once I restarted the SMS_EXECUTIVE service once more, hman.log finally filled up with information about the new update and the download proceeded. Finally, I have my update!
In all seriousness, this may be a very marginal case and may not be the reason you can’t see the latest update for SCCM. However, it seemed worth documenting; just in case someone else has the same symptom!
I would suggest clicking Check for updates in the Updates and Servicing node and then paying close attention to your hman.log file for any errors similar to the ones I found. Bear in mind that it might be different folders that cause errors for you, so keep an eye out for any errors with files being moved between inboxes.
Anyway, I’m off to go play with new SCCM features…!
SCCM extensively uses Background Intelligent Transfer Service (BITS) to transfer data between a client and the SCCM server. This also affects downloading client policy! One of the first things that SCCM uses BITS for is to download the client to the machine when you initiate a client push. If BITS is heavily throttled you may find the following entries in your ccmsetup.log file (typically found in C:\Windows\ccmsetup):
Starting BITS download for client deployment files.
Download update: Copy job has been queued.
Download update: Copy job has been queued.
Download update: Copy job has been queued.
There may be some entries showing the progress of the client download, however if BITS is throttled this may be proceeding very slowly.
If you want to check whether BITS is being throttled on a particular machine open a command prompt window and type RSoP to perform a Resultant Set of Policy. Once the RSoP window opens navigate to Computer Configuration —> Administrative Template —> Network —> Background Intelligent Transfer Service (BITS) —> Limit the maximum network bandwidth for BITS background transfers and check if it is enabled and what limitations are in place.
In my case it was limited to 10 KBs at all times! Far too slow to get anything done in a reasonable time.
The next thing you can do before you start talking with your fellow sysadmins and the network team about removing the throttling is to prove that it is the BITS throttling causing the issue. As long as you are a local administrator on one of the clients this can be done quickly by editing one registry key and restarting the Background Intelligent Transfer Service. Open regedit and navigate to HKLM\SOFTWARE\Policies\Microsoft\Windows\BITS and change EnableBitsMaxBandwidth from 1 to 0. Then open services.msc and restart Background Intelligent Transfer Service. This will remove the BITS throttling on that machine until group policy is reapplied and sets EnableBitsMaxBandwidth back to 1. Before that happens however you should have time to re-deploy the SCCM agent or push a new client policy and observe whether or not it happens in a much more timely fashion than it did before.
Once when I was updating some servers running the version of Windows Server 2012 R2 I encountered something odd; no patches appeared in Software Center or in the Windows Update panel, even though the server was several years out of date and definitely had applicable updates!
In WindowsUpdate.log I found the following error message repeating:
The fix for this is to manually download and install KB2919355, which is the April 2014 update rollup for Windows Server 2012 R2. After this has been installed and the server has restarted, re-run your updates scan and updates will show up in Windows Update or Software Center.
One of the things I have noticed since starting to deploy Windows Server 2016 is that the cumulative updates can fail to install when deployed from SCCM. It starts to run but then times out due to the maximum run time having been reached. By default this is set to 10 minutes. However due to the updates being larger and taking longer to install than updates prior to the cumulative updates era 10 minutes doesn’t seem to be long enough. The fix for this is to simply increase the maximum run time for cumulative updates for both Windows Server 2016 and Windows 10 from 10 minutes to 30 minutes.
This is a bit tedious as you’ll have to do it every month for both Windows Server 2016 and every version of Windows 10 you have in your environment. Hopefully Microsoft soon catches on to this and changes the default run time to 30 minutes so that this ceases to be an issue. There is already a Configuration Manager UserVoice entry for this idea, so if you’re reading this, pop over and vote to increase its visibility!
Getting your operating system deployment one step closer to being zero touch is always a good goal, so with that in mind here is how to automatically enable BitLocker during OSD using a PIN that you define in a variable at the beginning of the Task Sequence.
The first thing to do is add the OSDBitlockerPIN variable to the collection you advertise your OSD Task Sequences too. This is very likely the All Unknown Computers collection. Right click on it and select Properties. Navigate to the Collection Variable tab and click New. The name is OSDBitlockerPIN and you should untick “Do not display this value in the Configuration Manager console”.
Next up open your Task Sequence and add the Enable BitLocker step. This can be placed anywhere after the Setup Windows and ConfigMgr step.1 Make sure Current operating system drive is selected and then select TPM and PIN. You can then enter anything into this field as it will be overwritten by what you enter into the OSDBitlockerPIN variable when you start the Task Sequence.
Finally, go ahead boot your client into the WinPE environment. Select your Task Sequence and click next and you will be presented with the Edit Task Sequence Variables step. You may already use the OSDComputerName variable in which case you will already be familiar with this! Double click on OSDBitlockerPIN and enter the PIN you wish to use for this machine.
Click Next and the Task Sequence will run and complete. BitLocker will be enabled and the PIN will be set. Now you don’t have to configure BitLocker after the operating system has been deployed!
1I would add the Enable BitLocker step at the very end of your Task Sequence, otherwise you will have to enter the PIN each time the machine reboots after applications or updates are installed. You could suspend BitLocker before each reboot, but why go to the extra effort.