How to install a ConfigMgr Client on a WORKGROUP computer, when the ConfigMgr Site is in Native Mode.

NativeModeWorkgroup To install a ConfigMgr Client on a WORKGROUP computer is always a nice battle, when the ConfigMgr Site is in Native Mode. I think I am not the only one who didn’t work that much with certificates before ConfigMgr. So to make the basics of this process for everyone a bit easier I wrote down these seven steps for implementing the correct certificates and installing the ConfigMgr Client on a WORKGROUP client. These same steps can also be used for separate forests.

Step 1. Export the Root Certificate for use on the WORKGROUP computer

  1. Logon to the Certification Authority server and create a folder to contain your certificate files (eg C:\Certificates).
  2. Open a command prompt and go to the just created folder.
  3. Use the following command to export the Root Certificate: certutil -ca.cert RootCertificate.cer

 

Step 2. Create a Certificate Template for the WORKGROUP computer

  1. Open the Certification Authority Console, right-click Certificate Templates, and click Manage to load the Certificates Templates console.
  2. Select Windows Server 2003 Enterprise and click Ok.
  3. Right-click the Workstation Authentication template and click Duplicate Template.
  4. In the Properties of New Template dialog box, type the name for Template display name. As my normal Client Certificate Template is named ConfigMgr Client Certificate, I will name this one ConfigMgr Client Certificate for Export.
  5. Click the Request Handling tab and select Allow private key to be exported.
  6. Click the Subject Name tab, select Supply in the request.  This allows you to supply each FQDN of the client in the separate WORKGROUP at the time you request the certificate.
  7. Click OK to close the Properties of New Template and close the Certificates Template Console.
  8. In the Certification Authority Console, right-click Certificate Templates, click New, click Certificate Template to Issue, select the certificate template name you just created (eg ConfigMgr Client Certificate for Export), and then click OK.

 

Step 3. Request and Install the Client Certificate for the WORKGROUP computer

  1. Open a text editor and copy and paste the following text into the file (replace< FQDN> with the fully qualified domain name of the server that has to use this certificate):

    [NewRequest]
    Subject = "CN=<FQDN>"
    MachineKeySet = True
    Exportable = TRUE
    KeyLength = 2048
    [RequestAttributes]
    CertificateTemplate = ConfigMgrClientCertificateforExport

  2. Save the file as ConfigMgrClientCertificate.inf in the folder created in Step 1.
  3. Open a command prompt and go to the same folder as the saved file.
  4. Use the following command to create a certificate request: certreq –new ConfigMgrClientCertificate.inf ConfigMgrClientCertificate.req
  5. Use the following command to submit the certificate request: certreq –submit ConfigMgrClientCertificate.req ConfigMgrClientCertificate.cer
  6. In the Select Certification Authority dialog box, select the CA, and then click OK.
  7. Use the following command to accept the requested certificate: certreq –accept ConfigMgrClientCertificate.cer

 

Step 4. Export the Client Certificate for the WORKGROUP computer

  1. Open the Certificates Console for the local computer, right-click the certificate that is issued to <FQDN>, click All Tasks, and then click Export to launch the Certificate Export Wizard.
  2. On the Welcome page, click Next.
  3. On the Export Private Key page select Yes, export the private key and click Next.
  4. On the Export File Format page confirm that Personal Information Exchange – PKCS #12 (.PFX) is selected and click Next.
  5. On the Password page specify a password and click Next.
  6. On the File to Export page specify the path and name of the file and click Next.
  7. On the Summary page click Finish and click OK to close the confirmation popup.

 

Step 5. Import the Root Certificate in the WORKGROUP computer

  1. On the computer in the WORKGROUP, open the Certificates Console for the local computer and navigate to Trusted Root Certification Authorities\Certificates.
  2. Right-click Certificates select All Tasks and click Import to load the Certificate Import Wizard.
  3. On the Welcome page click Next.
  4. On the File to Import page click Browse and select the root certificate file that you created. After that click Open and then click Next.
  5. On the Certificate Store page click Next.
  6. Click Finish to close the wizard and click OK to close the confirmation popup.

 

Step 6. Import the Client Certificate in the WORKGROUP computer

  1. Open the Certificates Console for the local computer and this time navigate to Personal\Certificates.
  2. Right-click Certificates select All Tasks and click Import to load the Certificate Import Wizard.
  3. On the Welcome page click Next.
  4. On the File to Import page click Browse and select the exported certificate file that you created. Next click Open and then click Next.
  5. On the Password page type the password that you specified earlier and then click Next.
  6. On the Certificate Store page click Next.
  7. Click Finish to close the wizard and click OK to close the confirmation popup.

 

To confirm that the certificates got imported well, navigate to Personal\Certificates and select the certificate that is issued to <FQDN>. Double-click the certificate and click the Certificate Path tab, this checks that the certificate successfully chains to the issuing root CA certificate.  You should see the certificate and the root CA certificate, with the Certificate status displaying This certificate is OK.  Click OK to close the certificate properties.

Step 7. Install the ConfigMgr Client on the WORKGROUP computer

  1. Open a command prompt and go to the location of the ccmsetup.exe.
  2. Use the following, or similar, command to install the ConfigMgr Client: ccmsetup.exe  /Native:FALLBACK SMSSITECODE=<SiteCode> SMSSLP=<SLP>

 

Reminder: Don’t forget to add a Boundary to your ConfigMgr Site that includes the WORKGROUP computer.

24 thoughts on “How to install a ConfigMgr Client on a WORKGROUP computer, when the ConfigMgr Site is in Native Mode.

  1. Hi Peter, thanks for the helpful article. Question for you, is there a way via command line to export and import the certificate as outlined in steps 4-6 Thank you!

  2. I’m sorry, but I can’t help you with that one… I’m not familiar with a commandline that does something like. It could be that there are some scripts around the web that does what you want…

  3. How can an FSP be specified and can the FSP also be the same Primary site? From the workgroup client FSPStateMessage.log:

    Making mixed-mode style fallback request to
    HTTP ERROR: URL=HTTP:///SMS_FSP/.sms_fsp, Port=80, Protocol=http, SSLOptions=31, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE

    Note that FSP is not the site code entered on the command line but that it what shows up in the log. All other client functions work properly.

    I do not think the FSP can work in Native mode when clients are required to communicate via HTTPS.

  4. Hi Tom,
    Actualy the FSP is most usefull in Native Mode configuration. The only thing you have to keep in mind is that the FSP is the only role that doesn’t communicate over HTTPS, but over HTTP. So security wise you defenitly shouldn’t put the FSP on the Primary Site when running in Native mode, as it will kill your (secure) configuration.
    Peter

  5. Hi Peter
    I follow your steps to install cmm agent on workgroup clients.
    But on my clients properties is stands Client Certificate none.
    On my domain joined clients is says PKI.
    So do you have any ide where I should start looking for my problems, to get my Workgroups computer connected to my sccm server.

    thx for a great blog

    Best regards
    Andreas

  6. Brilliant! Thank you so much for this article! This is exactly what I needed to install and manage clients outside the domain in SCCM 2012. Only had to slightly modify the command to install the Client (installation folder copied to C:\). This is what’s worked for me: C:\CLIENT>ccmsetup.exe /Source:C:\CLIENT /Native:FALLBACK SMSiteCode:yoursitecode SMSSLP:SLP

  7. Peter, great article, I’ve been struggling with this issue for a week now and I’ve made more progress in one day after reading this article. However still no luck. Here’s my setup SCCM2012 one primary site running in http/https mode. I have a wild card cert installed on my Management IIS server for internet only clients (workgroup clients). I’m stuck there. My question is do I export that wildcard cert on my internet facing management point and just install in the root ca on the workgroup laptops? My working of knowledge of certs is limited as you can tell also. Also, I’ve created the certs in your article but step 4 I’m unsure of the “local computer” you are referring to. Is that the CA Server I generated the certs on ? I feel i’m missing something. Any help is appreciated.

  8. Thank you for a great article. In our case, I was able to install successfully SCCM Client on the extranet domain (different than the intranet domain where the central site resides).
    However, we have a few problems. One, some clients don’t show all items in Configuration Manager applet in the Control Panel in the Action tab (some show only two). Second, in the SCCM Management Console in the Collections/All Systems we cannot get the server showing as installed client (in the Client column still shows No). Third, although looks like the agent has been installed successfully, we don’t see that any updates are flowing from the central SCCM site to the extranet servers. All our intranet clients (servers and workstations) are receiving updates as expected. I would appreciate any help in getting the extranet servers configured for receiving and installing Microsoft updates properly.
    Thank you.
    Zijo

  9. Hi Zijo,
    Let’s start with the first thing, when a client doesn’t get all the actions, make sure it’s successful assigned and approved to the site. For the second and third thing, are the clients getting policies?
    Peter

  10. Thanks Peter for this article.

    Want to know what will be boundaries to manage only Internet clients and if these clients are working without boundaries then how site code discovery is happening.

    Kindly suggest.

    Thanks,
    Parag

  11. Really useful article, thanks. Have normally been able to install SCCM 2012 client to our DMZ workgroup servers ok, without any certificate issues, until we installed a wildcard certificate onto several web servers…now those clients get the same SCCM GUID and only one of them will talk to SCCM properly.

    Your procedure should fix that issue allowing them to have their own computer certificate, so thank you for this.

    Quick question as I am still struggling with certificates 🙂 I assume once the certificate is created on the CA and then exported, it’s ok to delete it from the personal certificate store on the CA, to keep things tidy?

    Once again thanks

  12. Yes, reusing a certificate will cause problems like you described. A certificate has to be unique as it will be used to identify the client.

    Yes, you can also delete the requested certificate from the personal store on the CA.

  13. Peter, great article! This has helped so much for all my DMZ non-domain joined clients. I do have a question regarding access to the internal CA to check cert revocation? Is that needed, how is that handled? I’m somewhat confused on this process
    Thank you so much

  14. Peter,
    So I talked with MS and they stated I needed to open port 80 to our website due to these errors when installing the client on a DMZ server behind firewalls with only the ports opened for SCCM
    Getting CRL errors –
    Failed “AIA” Time: 0
    Error retrieving URL: The server name or address could not be resolved 0x80072ee7 (WIN32: 12007)
    and
    Failed “CDP” Time: 0
    Error retrieving URL: The server name or address could not be resolved 0x80072ee7 (WIN32: 12007)

    The cert needs to reach http://cdp.domainname.com/CertData/DNSname_dnsname%dnsname%20dnsname%20Root%20CA.crt
    and
    http://cdp.domainname.com/Certdata/dnsname%name%20dnsname%20Root%20CA.crl

    (took out the employers name for obvious reasons)
    1) this may be an issue opening port 80 (the entire reason I had to move our environment to HTTPS, was to eliminate port 80 being opened on the FW
    2) I’m not sure I understand how I can prevent this from what you replied with

    response was “Since ports are blocked from this box, opening port 80 from this client to cdp.domain.com server should help.
    Once the ports are opened, you can try accessing these URLs from client & they should work as expected.”

    Thanks again for your reply, I appreciate this. I’ve been working on this for the past month as it’s something i’ve never done in all the environments i’ve had to architect.

Leave a Comment