There’s always a lot of confusion on exactly how to use CCMSETUP and the various switches and properties for it even though it’s fully documented on TechNet.
The first thing to note about CCMSETUP is that it is used for all client agent installation activity (except client agent installation from WSUS). Yes, even client push uses CCMSETUP. Basically, client push simply delivers CCMSETUP to target systems and starts it. What that ultimately means is that no matter how you install the client, it’s always the same process so there is no technical difference between any of the methods (except using WSUS as mentioned).
Next, it’s important to note that CCMSETUP is simply a bootstrapper that in turn initiates a handful of other things including the following (this isn’t an exhaustive list, just the main relevant points for this discussion):
- Copies itself to C:\Windows\ccmsetup, installs itself as a service, starts that service, and then immediately exits. Why would it do this? Reboot resilience. Thus, if the system reboots for whatever reason without CCMSETUP actually finishing the entire installation process, it will restart after the reboot automatically. The main ramification to keep in mind here is that that service runs as the local System account. That means that if CCMSETUP needs access to anything else on the network, it will use the AD computer account of the system. If the system is not a member of a domain, it has no AD computer account to use (obviously) and thus won’t be able to authenticate as anything other than anonymous.
- Downloads prerequisites –
like . Net Framework 4.0 client profile and Silverlight — and other files needed to install the client – like client.msi — and installs prerequisites not already installed on the system.Where does it download these from? By default (in 2012), CCMSETUP locates an MP using normal MP location rules (AD, DNS, WINS) and thenasks the MP for the closest DP. Then, using BITS, it downloads the files using BITS from the DP returned by the MP which follows normal content location rules which are purely based on boundaries within content distribution boundary groups. If for whatever reason, no valid DPs exist or are available for the target system based upon the boundaries, the files will be downloaded from the MP itself. Note that this BITS download will work fine for anonymous clients – like those in a workgroup or untrusted domain and does not require any special permissions or access. - Finally, it installs the client agent from the locally downloaded files by initiating the install using client.msi.
That brings us to /mp and SMSMP. Both are valid on the CCMSETUP command-line, but both are completely different in multiple ways.
/mp
“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 semi-colon (this enables the lookup to try each MP in order if the 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.
SMSMP
“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 any more parameters.
You can, of course, use both of 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.
Finally (yes finally), some of the behavior above can be overridden using the available parameters; e.g., use /noservice to prevent CCMSETUP from installing itself as a service (this changes the authentication discussion above because CCMSETUP is no longer running as the local System but is instead running as the user that initiated it so beware) and /source to explicitly specify a network UNC to download the necessary files from using SMB instead of a DP using BITS (this also changes the authentication discussion above because gaining access to an SMB share is not allowed by default to anonymous requestors). These additional parameters (and much more) is all detailed in the TechNet article I linked at the top. If you already have too many bookmarks, simply remember to search for “Configuration Manager 2012 ccmsetup”: it is always the first hit in real search engines (like Bing) and evil search engines also.
Very relevant blog post, as my colleagues and I were just talking about this! Thanks Jason!
Multiple MPs can be specified using /mp by separating them with a semi-colon.
Not a comma.
You are absolutely correct. I’ve corrected the error above, thanks.
Heya Jason LTNS :). just fyi you fixed the wording to semi-colon but it still shows a comma in the example 🙂
ccmsetup.exe /mp:mp1.mydomain.local,mp2,mydomain.local
DOH! Fixed now. Thanks!
Good info, need way to install it in forground with something that lets me know it is done. When I run the installer it takes anywhere from 5 to 50 minute. Needless to say that is unacceptable I need it to install IMEDIATLY when I tell it and to do the complete install right then and there letting me knew where it is in the install and when it is done. THERE MUST BE NO DELAYS!
Sorry, not sure what you mean here. When you run ccmsetup, it does install immediately — there is no delay. How long the installer itself takes definitely is variable but that depends upon the system itself and normal performance impacting factors. Once the client agent is installed, the client agent must also download policies. More or less the same story here as this is also variable depending upon many factors most of which are outside the control of ConfigMgr itself.
Hi Jason, I hope you are still checking this post (it’s been already a year since your last reply.
I would need your help to clarify for me what should I do nowadays, running SCCM 1610 with full HTTPS and running Windows 10 Baremetal using PXE.
I’ve got the Workstation Certs exported with Private Keys.
Problem:
Scenarios:
“Baremetalling” a current workstations which AD object and SCCM device object are present: ConfigMgr Client Certificate was already in place before Baremetal.
I am able to finish a baremetal, however the PC, however. even though the certificate is still in Certificate store (MMC), the SCCM client shows PKI: none.
Solution: Simply delete the current COnfigMgr Client Certificate and request it back from AD. Restart SMS_Agent Host, and finally SCCM client is back to PKI.
For some reason, I believe that During baremetal, the certificate doesnt get upgrade or overwritten by the OSD process (I can confirm that because when I first log in to the PC and I open MMC, the expiration date is wrong, it is old related to the first installation day of the PC. I expected the new certificate to be installed.
With refresh scenario where PCs in both AD and SCCM are active, I also have the same issue. OSD finishes 100%, however SCCM local client shows PKI=none.
Only a reboot doesnt fix the issue, I have to delete the old ConfigMgr Client certificate in order for the SCCM client to show PKI.
I might have missing something.
I believe I have to add the current Client workstation certificate to my boot image, which I havent done because I couldnt find how, instead I have created a new unattend.xml file from the 1607 Windows 10 image I am deploying which i am running certutil to install the certificate and using the private key and passwd. I have added that custom unattended.xml file to my “Apply operating system image” Step on my TS. (Is that right?)
I believe once I have done the unattended.xml file installing the PFX, I dont need to inject the PFX to my boot, right?
Now last question is regarding the ConfigMgr properties.
I have added this to my Set up Windows and ConfigMgr
/UsePKICert /NoCRLCheck /MP:https://mtl1-s-sccm-002.mgcorp.co DNSSUFFIX=mgcorp.co CCMHTTPSSTATE=31
I havent changed my SCCM client package, it is still using default properties (Should I also change there or Task Sequence properties will take precedence?
Thank you in advance if you ever see this post.
Hi Eden,
I’m not sure exactly what you are doing here. Each and every client requires its own, unique client authentication certificate. During bare metal, there are no certificates installed so I’m confused as to why you are saying they do have certificates or how they would be getting them.
Hi Jason, Thank you for taking the time to Reply this email.
What I tried to explain is that, It seems that whenever I perform a “refresh” to a PC, when I log in to that PC, the ConfigMgr client applet in Control panel, shows Certificate as “none”, even though when I go to MMC – Certificate – My Computer Store, my ConfigMgr client Workstation certificate is there, but based on the issued date, that certificate is old (Based on the first time the computer was baremetal, the certificate hasn’t been installed when the computer reboots or when the Computer was still in Windows PE, for instance.
What I have also read is that the certificate I see on the PC after the Refresh is not able to authenticate agains SCCM because it is corrupted. Have you heard that?
What is really bizarre is, the solution for this PC that has “none” in the certificate client is just delete the current certificate on the MY COMPUTER store and re-request it from AD. we are talking about the same ConfigMgr Client ceritifcate that was present before I delete it.
Another interesting thing I noticed on my log is that this
I Don’t know what part I am missing in order to finish a “refresh” and have the client fully PKI.
What I have read is:
In order to have HTTPS and PKI working during Windows PE I need to Import my ConfigMgr Client Workstation certificate to my MDT package and create a new unattended.xml file where I will use Certutil to import that cert during Windows PE.
I also read that I have to modify the properties of my ConfigMgr Client installation either on the package itself or in the TS.
From your experience, Should I actually do that in order to have my Clients fully PKI after a baremetal or a refresh?
Thank you for taking your time again.
Few Errors from logs:
ClientAuth.log
CCMCreateAuthHeaders – failed to read authenticator from registry.
CCMCreateAuthHeaders failed (0x80004005).
Error signing client message (0x80004005).
ClientIDManagerStartup.log
Certificate [Thumbprint Exxxxxxxx] issued to ‘MTL1PC’ doesn’t have private key or caller doesn’t have access to private key.
Unable to find PKI Certificate matching SCCM certificate selection criteria. 0x87d00283
RegTask: Failed to refresh MP. Error: 0x80004005
*CertificateMaintenance.log
CCMSignData failed (0x80090015).
Client is set to use HTTPS when available. The current state is 448.
Creating Signing Certificate…
Successfully created certificate
Certificate [Thumbprint xxxxB46676D3] issued to ‘SMS’ is Exportable
Certificate [Thumbprint 72EExxxxxxD3] issued to ‘SMS’ has a sufficient key length of 2048
**LocationServices.log
Failed to retrieve compatible DNS service record using _mssms_mp_xxx._tcp.xxx.co lookup
Failed to retrieve Default Management Points from lookup MP(s)
Failed to resolve ‘MP_MTL’ from WINS
Failed to retrieve AMP for site code ‘MTL’ with error (0x80004005)
LsRefreshManagementPointEx failed with 0x80004005
SMSClientMethodProvider.log
Invoking method SetClientProvisioningMode
Failed to stop the service ccmexec, hr=8007045b
SetClientProvisioningMode failed
Method SetClientProvisioningMode failed with error code 8007045B
CCMEval.log
Client is set to use HTTPS when available. The current state is 448.
GET: Host=xxx-002.xx.co, Path=/SMS_MP/.sms_aut?MPLIST, Port=443, Protocol=https, Flags=512, Options=448
Failed in WinHttpReceiveResponse API, ErrorCode = 0x2f0c
[CCMHTTP] ERROR: URL=https://xx-002.xx.co/SMS_MP/.sms_aut?MPLIST, Port=443, Options=448, Code=12044, Text=ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED
[CCMHTTP] ERROR INFO: StatusCode=600 StatusText=
Failed to queue event on HTTP/HTTPS failure for server xx-S-x-002.x.co’. Error 0x87d00202
Can’t get MP list from MP
Hello, we are seeking advice on installing the SCCM client on servers that have a SHA2 cert installed. All was working fine before when using SHA1 certs, but now there is a failure when the client is trying to register.
Has anyone experienced issued like this and can recommend the ccmesetup command to install clients?
There’s nothing special here and ConfigMgr supports SHA2 certs without having to do anything in ccmsetup or otherwise. What I suspect is that your certs were actually created using v3 templates meaning that they use a KSP instead of a CSP to generate and store the key material. ConfigMgr does not support v3 templates and certs using a KSP (yet).