Prepare ConfigMgr Client for Capture doesn’t remove the AllowedRootCAHashCode value

In the most situations it doesn’t matter that the AllowedRootCAHashCode value doesn’t get removed during a Capture of the client, but there is one situation where it does matter. This one situation is when there has to be one image for multiple domains and every domain has its own issuing CA’s. This situation is a problem because the client stores a copy of the Root Certificate in the AllowedRootCAHashCode key. Because it contains the wrong value for the Root Certificate the client isn’t able to get a new Site Signing Certificate (which is also stored in the registry), so the client isn’t able to check the policies.

As workaround for this I created a Task Sequence step (in the install Task Sequence) to delete the HKLM\SOFTWARE\Microsoft\CCM\Security\AllowedRootCAHashCode.

Another workaround (which is probably a bit easier) can be found at the ConfigMgr Technet forum ( where I posted this situation. The workaround posted here is to create a Task Sequence step (in the Build and Capture Task Sequence) to delete the whole HKLM\SOFTWARE\Microsoft\CCM\Security\ key.

More information about the Task Sequence Step Prepare ConfigMgr Client for Capture:
More information about Renewing or Changing the Site Signing Certificate:


Active Directory Site Boundaries are “static”

Active Directory sites are the easiest way of defining ConfigMgr site boundaries, because they are based on physical segments. BUT besides that, you have to keep in mind that they are also static in two different ways:

  1. All the different subnets have to be manually included and configured in the Active Directory sites.
  2. Once an Active Directory Site Name is selected as an ConfigMgr Site Boundary, ConfigMgr will check on the selected Site Name. Even when you rename the Active Directory site!

For more information about site boundaries:


How a client chooses a Distribution Point

Lately I get and see a lot of situations like this…

Question: I created an extra Distribution Point (DP) on a remote location, but the clients on the remote location are still connecting to the standard DP. Why are these clients not connecting to their local DP?
When there are more DP’s in the same site and/or boundary, by default, the client will first connect to the DP with BITS enabled and not the closest one. If you want the clients to connect to their local DP, you have to make the DP protected.

…So I thought it might be handy to write in a few short steps how this process works.

Step From Action
1 Client Sends a content location request to its Management Point (MP)
2 MP The search for Distribution Points (DP’s), with the content, starts in the client’s current site. This can be the client’s assigned site, secondary site attached to it, or a site to which the client is roamed. When the content is not available here the search goes to the assigned site.
3 MP The list of found DP’s will be sorted. When a protected DP is found, where the client’s boundary is included, only this will be returned. If there is not a protected DP found it will return a list of non-protected DP’s that host the content.
4 MP The remaining DP’s on the list will be marked as local, or remote depending on the boundary that you have connected to it.
5 MP The list with available DP’s is send back to the client.
6 Client Tries to connect to the DP’s (of the list) in the following order, first for the local DP’s and then for the remote DP’s: Same IP subnet, Same AD site, remaining. In every category the client prefers DP’s with BITS enabled.

Then where does it go wrong?? Well, often the assumption is that the client searches for the DP’s by itself. But instead you have to tell your MP which boundaries you have and connect them to your DP’s by protecting them.

For extra information:


Certificates needed for Native Mode

The biggest problem, for me, with Native Mode were all the certificates that were needed. That’s why I created an table for myself with the basic certificates that are needed for Native Mode and where to add them. The “Where to add” column is based on Windows Server 2008.

ConfigMgr Component Use Where to add
Primary Site Server Document Signing ConfigMgr > Site Management > Site Database > Properties Primary Site > Tab Site Mode
Management Point, Proxy Management Point, Distribution Point, Software Update Point en (State Migration Point) Server Authentication (Web Server Template) IIS > -Right-click- Sites > Edit Bindings > HTTPS -Edit-
Client computers Client Authentication (Computer Template) GPO > Policies > Computer Configuration > Windows Settings > Security Settings > Public Key Policies > -Right-click- Certificate Services Client –Auto-enrollment
Operating System Deployment/PXE Client Authentication (Workstation Template) Don’t forget the option: Allow Private Key to be exported ConfigMgr > Site Management > Site Database > Primary Site > Site Settings > Site Systems > Properties ConfigMgr PXE Service Point > Tab Database
Root CA for OSD Root ConfigMgr > Site Management > Site Database > Properties Primary Site > Tab Site Mode > Specify Root CA Certificates…


For more detailed information:


Rename your ConfigMgr Primary Site

Once you have installed your ConfigMgr Primary Site it is not possible to change the name of your Primary Site. At least not through the console… But what if you made a mistake or your company changes it’s naming conventions?? Well there is one way to change it. First off all stop the SMS_EXECUTIVE Service. After that open the site control file (<Installation directory>\Microsoft Configuration Manager\inboxes\\Sitectrl.ct0) and search for BEGIN_SITE_DEFINITION. Close to that you will find your Primary Site name and you can change it (do not change anything else!!). After this save the file and start the SMS_EXECUTIVE Service again. Then after a few site refreshes your Primary Site name wil be changed.

In some cases it could be possible that you also have to change the value of the regkey: HKLM\Software\Microsoft\SMS\Identification.

Update: Keep in mind that editing the sitectrl.ct0 is not supported by Microsoft!


ConfigMgr Backup in combination with WSUS

I noticed that the scheduled backup of ConfigMgr can conflict with the installation of WSUS. When you have WSUS 3.0 SP1 installed on the same machine as your ConfigMgr Site you can, at random occassions, get problems with your WSUS installation. This is what happens: During the execution of the ConfigMgr Backup it does some kind of a healthcheck. When it then notices that the SUP/WSUS is not responding good it will try to do an repair action of WSUS. At this point the problem starts, bacause the installer of WSUS 3.0 SP1 doesn’t have a repair function, so WSUS will get uninstalled… After this has happened you can get errors like “Sync failed: WSUS server not configured. Source: CWSyncMgr::DoSync SMS_WSUS_SYNC_MANAGER” in the ConfigMgr Site Status.

There are two ways to workarround this:

  • Disable the backup of ConfigMgr (not really an option).
  • Make sure that the ConfigMgr Backup can’t find the WSUS 3.0 SP1 installer. You can do this by editting (just change the name or the location of the MSI) the following registrykey [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\<Random number>\InstallProperties] “LocalPackage”=”C:\\WINDOWS\\Installer\\<Random number>.msi” “DisplayName”=”Microsoft Windows Server Update Services 3.0”

They say it is getting solved in WSUS 3.0 SP2. When your interested in that you can join the RC Program on:


App-V future ready???

Let’s start my first post about App-V being future ready (or not). When I was trying to deploy an App-V Sequence on a Windows 7 Client (with App-V Client 4.5 CU1) the application didn’t seem to work… At first I thouhgt it was just me, so I recreated everything from scratch, but still no luck. The next step was to search on Google and here I found a very helpfull link:

The solution is this: During the proces of making a sequence with the App-V Sequencer you get to tab Deployment. In this tab you can specify the Operating System (OS) on which this sequence can run. Before the App-V 4.5 CU1 version you didn’t have the option to select Windows 7. This means that the sequence will not be able to run on Windows 7. The sequence can only run on the OS that is selected on the Deployment tab (it is possible to change the OS directly in the OSD-file, for this you have to add an extra line like: <OS VALUE=”Win7″>).

After all this you can say that App-V is future ready, because by adding Windows 7 to the Deployment tab it was possible to deploy the sequence on Windows 7. Just a shame that you have to make changes to already excisting sequences…