IT Consultant Everyday Notes

Just some problems/solutions storage

Category Archives: SCCM Client

SCCM: Client certificate issue

I added an SSL MP/SUP in my lab environment and move a test client to the associated subnet. Unfortunately, the client did not register itself and the Client had “Self-Signed” certificate in SCCM Client General Properties. MP was switched correctly.

MP_Registration_Manager.log on the new MP showed:

“The certificate chain processed correctly but terminated in a root certificate not trusted per ConfigMgr CTL.”

I checked certificate storage on the new MP and found my Root certificate not only under “Trusted Root Certification Authorities” but also under “Intermediate Certification Authorities”. Not sure how SCCM put it there, but I deleted them in “Intermediate …” folder. After several minutes the client registered successfully.

SCCM: Side-by-side migration issue with client reassignment

I was busy with an SCCM migration recently. A Customer wanted to get gradual side-by-side migration from an old SCCM 2012 R2 to a shiny SCCM CB.

The issue I faced was related to a Client re-assignment from the old to the new SCCM site.

As recommended I tried Jason Sandy’s script to reinstall the old client and configure the new one for the new site.

The Client was successfully installed, but kept connect to the old site.

I tried to re-register site assignment in WMI as described and restart CCMEXEC service.

In ClientLocation log I saw the new site was assigned, MP found, but after that the site immediately was re-assigned to an old one and the Client tried to connect back to the old site Sad smile

I tried  completely uninstall the client, use push etc.. without success.

Finally I noted

LSRefreshSiteCode: Group Policy Updated the assigned site code <old site code>, which is different than the existing assigned site code <new site code >. Will attempt re-assignment.

I checked GPOs and found a disabled GPO containing SCCM ADMX template with a site assignment.

The matter in fact once applied GPO tattoes its settings in the registry and they remains there even if GPO is not active anymore.

So I opened GPO template (located in ConfigMgr installation folder\Tools\ConfigMgrADMTemplates and founf the registry key in question is “hklm\SOFTWARE\Microsoft\SMS\Mobile Client”. Originally I planned to change only site code value there, but found Henrik’s article where he recommended to remove all values from the key all together.

Probably both approaches can work, so I created a simple cmd script and pushed it from the SCCM

REG delete “hklm\SOFTWARE\Microsoft\SMS\Mobile Client” /v GPRequestedSiteAssignmentCode /f
REG delete “hklm\SOFTWARE\Microsoft\SMS\Mobile Client” /v GPSiteAssignmentRetryDuration(Hour) /f
REG delete “hklm\SOFTWARE\Microsoft\SMS\Mobile Client” /v GPSiteAssignmentRetryInterval(Min) /f
cscript set-site-code.vbs

first three commands are cleaning settings hardcoded by GPO, the forth one force SCCM site code using a VBS script from here

After the script finished I restarted ccmexec and fount the client registered in the new site successfully.

SCCM 2012R2: Manage CentOS 7.0 Clients

SCCM: What CCMSETUP does and difference between /mp and SMSMP

Found a nice article by Jason at


“Options” like /mp that are prefixed with a forward-slash are parameters for CCMSETUP itself. Thus, they control or affect the behavior of CCMSETUP and not the client agent. So, even though /mp contains the letters ‘m’ and ‘p’, this does not in any way mean that it sets the MP for the client agent. What /mp actually does is instruct CCMSETUP which MP to use to query for a DP (as mentioned above) thus bypassing the normal MP lookup.

Multiple MPs can be specified using /mp by separating them with a comma (this enables the lookup to try each MP in order if availability of the MPs is a concern):

ccmsetup.exe /mp:mp1.mydomain.local,mp2,mydomain.local

Additionally, if an MP requires HTTPS communication, you should specify the prefix in URL format including the protocol:

ccmsetup.exe /mp:https://securemp.mydomain.local

It is always a good practice to use the full FQDN and ensure that name resolution is working for this name on the target clients. If name resolution is not working, you’ve got bigger problems that CCMSETUP cannot magically solve. Note also that CCMSETUP setup parameters require a colon between the option name and the value specified for that option.


“Options” like SMSMP that are in all capital letters are public properties that are not processed or used in any way by CCMSETUP but are instead passed directly to client.msi when CCMSETUP executes it. Thus, these properties do directly affect the client agent and its configuration. Note that you don’t actually have to specify the properties in all capital letters on the command-line, but it is best to do this so that they clearly stand-out.

SMSMP specifies the initial MP that the client agent uses (“initial” because with 2012, we can have multiple MPs within a single primary site and this will rotate periodically on clients). Without SMSMP, the client agent relies on normal MP location processes (AD, DNS, WINS) just like CCMSETUP does to initially set the MP that the client agent will use.

As with /mp, you should use the full FQDN of the MP and if an MP uses HTTPS, you should also specify the name of the MP in URL format including the prefixed protocol:

ccmsetup.exe SMSMP=https://mp.mydomain.local

ccmsetup.exe SMSMP=https://securemp.mydomain.local

Unlike /mp, you can only specify a single MP with SMSMP. Also, public properties are not prefixed with a forward-slash and use an equals sign to set the value of the property.

One thing to make sure of is that you specify all CCMSETUP parameters on the command-line before you specify any public properties. This simply has to do with how CCMSETUP parses the command-line: it assumes that all parameters come first so as soon as it encounters a property, it stops looking for anymore parameters.

You can of course use both these options together which is common because the reason for using them is the same: you don’t want to (or can’t) rely on normal MP lookup. If MP lookup is working, then there’s no reason to use either. The only time to really expect any issues with MP lookup is when the target client is untrusted like when it’s in a workgroup. Remember that during a Build and Capture task sequence, the target/reference system should not be joined to a domain so specifying SMSMP in the Setup Windows and ConfigMgr task should be done – no need to specify /mp though because the source files needed by CCMSETUP are part of the client agent install package and thus already resident locally.

Although I haven’t tested explicitly and so I’m not sure of the exact ramifications, if a client is destined to be within a secondary site’s scope, you should still specify the MP for the primary site for both of these options instead of the MP at the secondary site. Remember, that clients always need to be able to communicate the MP in their primary site even if they are within the scope of a secondary.

SCCM: Install Client via startup script

Startup script for SCCM Client installation is updated: