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.

39 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!

    Reply
    • 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…

      Reply
  2. 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.

    Reply
    • 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

      Reply
  3. 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

    Reply
  4. 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

    Reply
  5. 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.

    Reply
  6. 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

    Reply
    • 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

      Reply
  7. 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

    Reply
  8. 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

    Reply
    • 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.

      Reply
  9. 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

    Reply
      • 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.

        Reply
  10. Hi, Peter,

    I’ve been following these instructions to attempt to configure some DMZ servers to be managed by our internal SCCM server and I’ve run into a couple of issues.

    First, in Step 2, item 2, I do not have any option in my Cert Authority’s Certificates Template Console to choose “Windows Server 2003 Enterprise”. This CA was built on Server 2019.

    In Step 4, item 4, I am unable to export the cert I’ve generated for my workgroup server as a .PFX. P7B is the best I can get out of it and it appears this is not good enough. My workgroup computer is failing to accept the cert as a valid PKI cert during install of the client. It finds it, begins validation, but then says “Allowing use of CNG key storage” followed by “Failed to acquire certificate private key”. I’m sure this has to do with how I exported the cert from the cert authority, but I saw no other options available.

    I can provide logs if necessary.

    Thanks!

    Brett

    Reply
  11. Hi, Peter,

    As a follow-up to my previous post, I figured out what I was doing that was causing the certs not to work. I figured out how to request the cert from a domain-joined machine, using the Workgroup template, and then I was able to export it as a PFX from my computer. I copied it to the machine with the Root CA and Subordinate CA’s certs along with it, and the whole cert chain reads good on the machine. The errors I was getting about “private keys” during install are gone now, but now I have a new problem.

    The certs are not working to connect to the management point. I’m getting these errors:
    WINHTTP_CALLBACK_STATUS_SECURE_FAILURE encountered
    dwStatusInformationLength is 4
    *lpvStatusInformation is 0x8
    WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA is set
    Failed in WinHttpSendRequest API, ErrorCode – 0x2f8f

    As I said, the cert chain looks good on the workstation computer, and I am fairly sure I have updated the certs on my SCCM site systems so that they are issued by the same PKI infrastructure. Where am I going wrong?

    Brett

    Reply
  12. Hi Peter,
    Great post, I’m not the brightest spark, so would like some clarification if possible?
    I’ve setup our SCCM environment to use a PKI cert and have now been asked to manage the DMZ/workgroup devices. I’ve followed step 2, but need step 3 clarifying if I may? I’m assuming by using the FQDN you mean of the SCCM server which is on the domain and internal network, and manages our internal clients? So as an example:
    [NewRequest]
    Subject = “CN=SCCMSERVER.123.C0.UK”
    MachineKeySet = True
    Exportable = TRUE
    KeyLength = 2048
    [RequestAttributes]
    CertificateTemplate = SCCMWORKGROUPCERTIFICATE

    I’m assuming doing this will not affect the other PKI setup, and also, do I need to run through the steps for every workgroup server, or do I only need to go through this process once and import the same cert on each workgroup PC?

    Thanks in advance

    Reply
  13. Hi Peter,

    Thanks for this, OK, so now I’ve stumbled across something else.

    When I do step 3 point 4 and see a pop up saying template can’t be found, OK/Cancel? If I click OK it still creates the .req file, but I just wanted to make sure this is expected. The Workgroup PC’s are in a DMZ, and I don’t think there is a root to the cert server?
    Thanks
    Steve

    Reply
  14. hi Peter,
    Thanks for replying, by access, do you mean access from the workgroup device in the DMZ?
    I’ve created the above certs on a device on the domain, then imported them in to the workgroup PC. I’m assuming I don’t need to punch a hole in the firewall for the CA?
    Also, as we currently don’t have access, if I imported the intermediate CA Cert, would that get over this hurdle?
    Thanks

    Reply
    • Hi Steve,
      You’re correct. Creating the certs on a device in the domain and importing them on your workgroup device should be sufficient. And yes, you need to create a trusted chain (root > intermediate > cert).
      Regards, Peter

      Reply
  15. Hi Peter,

    Great article!
    I’m wondering if you know if it’s possible to use a combination of PKI (for clients that are AD joined) and self-signed/external certificates (for DMZ computers) or is the solution you describe the only possibility to manage DMZ computers, while Config manager is in native HTTPS mode?

    Regards, M4jor

    Reply
  16. Thanks for this Peter – extremely useful and much needed!

    These are some command lines which can do some of the manual steps I believe:

    -Import-PfxCertificate -FilePath “C:\Path\to\ConfigMgr-Workgroup-Cert.pfx” -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString -AsPlainText ‘Password’ -Force)

    -Import-Certificate -FilePath “C:\Path\to\RootCertFile.cer” -CertStoreLocation Cert:\LocalMachine\Root

    -Import-Certificate -FilePath “C:\Path\to\IntermediateCertFile.cer” -CertStoreLocation Cert:\LocalMachine\CA

    If it helps anyone else these are the other articles and posts about installing the sccm client on workgroup / alternative forest computers

    https://arungopinathit.wordpress.com/2019/10/09/adding-workgroup-machine-to-pki-enable-sccm/
    https://www.reddit.com/r/SCCM/comments/8bbny0/httpsonly_client_install_on_workgroup_computers/
    https://docs.microsoft.com/en-us/archive/blogs/askds/enabling-cep-and-ces-for-enrolling-non-domain-joined-computers-for-certificates
    https://www.reddit.com/r/SCCM/comments/frd9fz/installing_sccm_client_on_workgroup_computer_with/
    https://www.reddit.com/r/SCCM/comments/tqcwex/client_setting_for_office_management_not_applying/
    https://www.reddit.com/r/SCCM/comments/39bif1/trouble_installing_configman_client_on_workgroup/
    https://itpro.outsidesys.com/2017/12/20/sccm-certificates-for-windows-workgroup-clients/
    https://docs.microsoft.com/en-us/answers/questions/431223/use-certreq-amp-certutil-to-request-and-approve-a.html

    Reply

Leave a Reply to Brett Tesdall Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.