none
Command Line options for SCCM client during OSD for On Domain and Workgroup machines. RRS feed

  • Question

  • Hello,

    I have converted my lab SCCM environment to PKI and added an IBCM server recently and wondering about client installation properties for On Domain and Workgroup machines during OSD for the clients to communicate with IBCM server when not connected to the network and intranet SCCM MP when connected to the network. There is no internet CRL distribution Point for this test lab.

    I am using MDT UDI to build the workstations. Also, I am planning to use different properties for client install using the Task Sequence Variable Option for different steps - On Domain (OSDJoinType = 1) and Workgroup (OSDJoinType = 0).

    As the workstation won't get a certificate until the OSD is completed, I am just wondering if passing /noCRLCheck /UsePKICert /CCMHOSTNAME=<FQDN of IBCM Server> would affect the build process. 

    Also, is there a way to deploy the client over internet to workgroup computer to communicate with IBCM server?

    What are command line options best suited for my situation?

    Wednesday, January 22, 2020 4:48 PM

All replies

  • As the workstation won't get a certificate until the OSD is completed

    That's only partially true. During OSD, the client uses the certificate embedded in the boot media when you created the boot media or configured on the DP.

    about client installation properties for On Domain and Workgroup machines during OSD

    There are no properties for this as ConfigMgr doesn't care about the domain join status of systems. The client agent automatically determines whether it needs to use an intranet or Internet facing client-facing site role (MP, DP, SUP) based on the reachability of a domain controller or an intranet MP.

    > Also, is there a way to deploy the client over internet to workgroup computer to communicate with IBCM server?

    Technically sure as there's nothing different about this from ConfigMgr's perspective; however, that assumes many things that won't be true for these type of systems like permissions and connectivity neither of of which ConfigMgr has any control over.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Wednesday, January 22, 2020 5:31 PM
  • Jason,

    Thanks for responding.

    >That's only partially true. During OSD, the client uses the certificate embedded in the boot media when you created the boot media or configured on the DP.

    Boot media is not configured to use the cert in my test environment. The DP used for OSD is still running on HTTP. Also, it looks like /noCRLCheck /UsePKICert can be used even if I don't have the cert. As the /UsePKICert is the default behavior and client would only use the cert if available for communication. I'm assuming using /noCRLCheck wouldn't harm either as this property is specifying the client to check for CRL for the cert before the client switching to PKI. Also, I don't have to use /CCMHOSTNAME=<FQDN of IBCM Server> in the OSD client install command line because IBCM MP is populated in client properties during the install after IBCM is configured

    There are no properties for this as ConfigMgr doesn't care about the domain join status of systems. The client agent automatically determines whether it needs to use an intranet or Internet facing client-facing site role (MP, DP, SUP) based on the reachability of a domain controller or an intranet MP.

    I might be wrong, I asked because I read that workgroup machines needs to be configured as CCMALWAYSINF=1 and will not work if not configured this way. 

    Technically sure as there's nothing different about this from ConfigMgr's perspective; however, that assumes many things that won't be true for these type of systems like permissions and connectivity neither of of which ConfigMgr has any control over.

    Does the internet client need to communicate with Intranet MP before getting it's policy or communicating only with Internet MP over the internet suffice? I have port 443 open from Internet MP to Public. Will that be sufficient or would it need any other ports/permissions?


    Jason | https://home.configmgrftw.com | @jasonsandys


    Wednesday, January 22, 2020 6:56 PM
  • > The DP used for OSD is still running on HTTP.

    It's not about whether the DP is configured for HTTP or HTTPS, it's about the certificate configured on the DP's properties as noted.

    > Also, it looks like /noCRLCheck /UsePKICert can be used even if I don't have the cert.

    Using switches/parameters and having them be valid or effective are two different things. Also, these switches only affect ccmsetup and not the client agent. And, none of this matters until the agent is installed which doesn't happen until after WIndows is finished installing during OSD.

    > Also, I don't have to use /CCMHOSTNAME=<FQDN of IBCM Server> in the OSD client install command line because IBCM MP is populated in client properties during the install after IBCM is configured

    Correct except it's not /CCMHOSTNAME as it's not a parameter, it's a property and is thus just CCMHOSTNAME.

    > I read that workgroup machines needs to be configured as CCMALWAYSINF=1 and will not work if not configured this way.

    This is not correct.

    > Does the internet client need to communicate with Intranet MP before getting it's policy or communicating only with Internet MP over the internet suffice?

    It would be of no value if the client had to communicate with an internal MP. That's the point of the client checking whether it can or cannot when determining if it is on the Internet or intranet.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Wednesday, January 22, 2020 7:17 PM
  • Jason,

    Really appreciate your time. 

    > It's not about whether the DP is configured for HTTP or HTTPS, it's about the certificate configured on the DP's properties as noted.

    Should have been clear. I did not configure the cert on DP properties. 

    > Using switches/parameters and having them be valid or effective are two different things. Also, these switches only affect ccmsetup and not the client agent. And, none of this matters until the agent is installed which doesn't happen until after WIndows is finished installing during OSD.

    Okay. I have built a machine without /noCRLCheck and /usePKICert in command line options of Client install OSD after IBCM setup and brought the device out of network, connected to internet and it was not able to communicate with Internet Management point. Doesn't the client check CRL before communicating everytime? I assumed that was the issue I had during my testing. It only worked after uninstalling and reinstalling the client on the network with that options on a On Domain Machine. I was able to deploy applications and software updates over internet. Hence my question if I can use those two command line options during the OSD client install (which does happen after Windows is finished installing) even without the cert either in DP properties or the machine so that the client would know not to check CRL at any point of time further in the future. If these options are only for CCMSetup, is there a way to configure the client afterwards?

    > Correct except it's not /CCMHOSTNAME as it's not a parameter, it's a property and is thus just CCMHOSTNAME.
    You are right. It's a public property. So there won't be a '/'. 

    > I read that workgroup machines needs to be configured as CCMALWAYSINF=1 and will not work if not configured this way. - This is not correct.
    Saw this statement "When you want to manage workgroup clients on the internet, you must install them as internet-only." in https://docs.microsoft.com/en-us/configmgr/core/clients/manage/plan-internet-based-client-management. If I am taking this statement out of context, do let me know. If that is not the case and workgroup would work without being configured as internet only, it's great.

    > It would be of no value if the client had to communicate with an internal MP. That's the point of the client checking whether it can or cannot when determining if it is on the Internet or intranet.
    I will test this and let know of the results.

    Wednesday, January 22, 2020 8:07 PM
  • I did not configure the cert on DP properties. 

    Then OSD won't work at all with HTTPS configured as a PKI cert is required for this.

    /noCRLCheck and /usePKICert

    As noted, these parameters are for ccmsetup and not the client agent and thus have zero impact on what the client agent does or uses.

    Doesn't the client check CRL before communicating everytime?

    By default yes, but this can be disabled in the site's properties.

    For Workgroup and the CCMALWAYSINF property, my answer was not specific to Internet connected workgroup clients because that wasn't the question. Perhaps that was implied, but I didn't initially read it that way. For workgroup systems that will be connected across the Internet, yes, that property must be used because as noted, the client uses connectivity to the domain to determine whether or not it is on the Intranet or Internet. Workgroup clients obviously can't do this so don't actually perform this check to my knowledge.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, January 23, 2020 1:01 AM
  • Jason,

    Below is how I configured the intranet SCCM site, MP and DP; OSD works as expected.

     

    >By default yes, but this can be disabled in the site's properties.

    As you can notice 'Clients check the Certificate Revocation list (CRL) for site systems' is unchecked. This is the setting you are talking about, Right?

    As for installing client over internet for a workgroup machine which was never built using this site, I used below properties and it installed fine. I was able to deploy applications and updates over the internet. I did import root cert and client cert on this computer that was exported from the internal domain controller.

    CCMSetup.exe /source:C:\Client /UsePKICert /NoCRLCheck SMSSITECODE=<XXX> CCMHOSTNAME=<FQDN of IBCMServer>

    You are right, setting CCMALWAYSINF=1 is not necessary for the workgroup client to work over internet. I really didn't want to set this property because I don't want the workgroup device to communicate with the Internet MP when in the network (Boundaries exist for all possible IP Ranges for the client which I would assume make the client communicate with the intranet MP)

    I still need to test the functionality over internet for on domain machine and workgroup machine built using this site and maybe need to play around with client installation properties to make sure that they work as expected. I will start with the minimal settings and work my way through. I will report back the findings.

    Thanks again.

    Thursday, January 23, 2020 2:05 AM
  • As you can notice 'Clients check the Certificate Revocation list (CRL) for site systems' is unchecked. This is the setting you are talking about, Right?

    Correct

    I did import root cert and client cert on this computer 

    I hope you didn't use the same client cert as the domain controller was using as this will cause issues with the client agents on both systems since the certificate establishes the identity of the client and thus you will have two client agents with the same identity.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, January 23, 2020 2:43 AM
  • > Correct

    Thanks.

    > I hope you didn't use the same client cert as the domain controller was using as this will cause issues with the client agents on both systems since the certificate establishes the identity of the client and thus you will have two client agents with the same identity.

    I did not use the same cert. I created a new certificate template on the CA (which is same as the DC) for workgroup machines, then requested the client cert for the workgroup machine using that template, then exported that cert from that server and imported it to workgroup machine. I do need to find a way to automate this process at least to part where I can request the certs for bunch of machines on the CA reading from a text file with machine names.

    Thursday, January 23, 2020 3:40 AM