locked
Cross forest client installation RRS feed

  • Question

  • Hello,

    We have SCCM 2007 R3 SP2 native mode installed in Forest A.  We need to manage clients in Forest B.  There is s trust relationship, not forest level.  We have installed a subordinate CA in Forest B, created and deployed a client cert to a couple of client test systems.  I am able to manually install the SCCM client (using options) on the systems in Forest B from a share located in Forest A.  We will be installing SCCM client via GPO as we can't do AD system discovery without the forest trust.

    The two client test systems in Forest B have not reported back to the SCCM console in Forest A.  It looks like the client install was successful (log files look OK).  I've tried refreshing the collection membership.  Do I need to configure anything specific to allow the clients from Forest B to report back?

    Thanks in advance!

    Monday, July 4, 2011 7:17 PM

Answers

  • Have you seen the below thread, there is a good discussion on the same topic and I am sure, it will help you...

    http://social.technet.microsoft.com/Forums/en-US/configmgribcm/thread/7d0aec41-c8b8-4da0-862e-069ce32e11a0


    Anoop C Nair - This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Proposed as answer by Sabrina Shen Wednesday, July 6, 2011 8:10 AM
    • Marked as answer by Garth JonesMVP Thursday, December 31, 2015 9:10 PM
    Tuesday, July 5, 2011 1:50 AM
  • The clients in forest B are not communicating with the management point in forest A. I initially thought the client installed successfully as components show as installed (none are enabled or disabled).  MSoft engineer calls this a "skeleton" install. 


    This sounds like installed but not successfully assigned.  Check LocationServices.log on the client for site assignment errors.  I don't think this is a CRL issue - the /native:FALLBACK means the client will not check the CRL for the management point certificate, and I think the reg key means the management point (via IIS) will not check the CRL of the client certificate.

    One thing I don't see in the command line is setting the site code directly - so maybe the client is in a boundary that isn't defined in the hierarchy.  Try reinstalling with SMSSITECODE=<value> added to the list of options.

    • Marked as answer by Garth JonesMVP Thursday, December 31, 2015 9:10 PM
    Friday, July 15, 2011 6:23 PM
  • Thank you Carol.  We have a resolution for the client installation issues.  We needed to import the subordinate CA certificate in Forest A to the clients in forest B (to Trusted root Certification authority and Intermediate Certification authority on local systems).  Also needed to include the sitesigning certificate located in Forest A on the installation command line as noted in previous post.  Also deleted the "default MP certificate" stopped sccm services, restarted to let the cert autogenerate. MSoft Engineer indicated there was a mismatch with the cert and the clients in Forest B.

     

    Now I'm trying to deploy the client via GPO to systems in Forest B.  I realize I can only use options for the client.msi (not ccmsetup).  I've configured the adm template, added my options and successfully deployed to a handful of test machines (using only supported options for client.msi).  I need to somehow define /native:FALLBACK - I've found a reference to CCMHTTPSSTATE=95 in the client.msi log file.  Found and read your article "The Case of the Mysterious Disappearance of the CCMHTTPSSTATE Client Installation Property".  I haven't been able to find out what 95 equals too or how to get around this when deploying via GPO.

    Is my only option to use another deployment method?  Or can I use CCMHTTPSSTATE= property  on my command line even though it's unsupported?  Or does the value of 95 correct for what I'm trying to do?

     

    Thanks very much

    HRuttan

    • Marked as answer by Garth JonesMVP Thursday, December 31, 2015 9:10 PM
    Wednesday, July 20, 2011 4:05 PM

All replies

  • Have you seen the below thread, there is a good discussion on the same topic and I am sure, it will help you...

    http://social.technet.microsoft.com/Forums/en-US/configmgribcm/thread/7d0aec41-c8b8-4da0-862e-069ce32e11a0


    Anoop C Nair - This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Proposed as answer by Sabrina Shen Wednesday, July 6, 2011 8:10 AM
    • Marked as answer by Garth JonesMVP Thursday, December 31, 2015 9:10 PM
    Tuesday, July 5, 2011 1:50 AM
  • Thanks for the reply.  I have seen the thread and I think the issue is with communication with the MP.  I have an open case with Microsoft and we are working on the issue now.  The firewall folks assure me that the required ports are open for communication to the MP from forest B.  Will post resolution once we have it.

     

    Tks,

    HRuttan

    Wednesday, July 6, 2011 12:12 PM
  • Hi HRuttan,

    Config MGr clients use Active Directory Domain Services (ADDS) as theier primary method for service location and configuration. Since you have clients that reside in a separate forest, they will not be able to retrieve information that is published to ADDS by theier assigned server.

    You should configure these clienst as if Active Directory Domain Services is not extended for Configuration Manager 2007.

    Thanks

    • Proposed as answer by DoitRight39 Tuesday, July 12, 2011 3:16 PM
    • Unproposed as answer by HRuttan Wednesday, July 13, 2011 3:32 PM
    Monday, July 11, 2011 3:46 AM
  • Thanks for the reply.  In forest A, we use AD for discovery and client installation.  In forest B, we are installing the client manually for testing purposes (will be using GPO once we have things working).  We are specifying options on the command line for the client installation in forest B (ccmsetup.exe /NOSERVICE /native:FALLBACK SMSSLP=SERVERNAMEFQDN FSP=SERVERNAMEFQDN DNSSUFFIX=FORESTA).

    The clients in forest B are not communicating with the management point in forest A. I initially thought the client installed successfully as components show as installed (none are enabled or disabled).  MSoft engineer calls this a "skeleton" install.  We are installing from a drive mapped to a share in forest A.

    In another post I saw something about the clients need to be able to resolve the CRL listed in the cert.  Does this also apply if CRL checking is turned off in SCCM? 

    A reg key was also changed (HKLM\system\currentcontrolset\services\HTTP\Parameters\sslbindinginfo\0.0.0.0:443 - DefaultSSLCertCheck was changed from 0 to 1).

     

    Thanks,

    HRuttan

    Wednesday, July 13, 2011 3:18 PM
  • The clients in forest B are not communicating with the management point in forest A. I initially thought the client installed successfully as components show as installed (none are enabled or disabled).  MSoft engineer calls this a "skeleton" install. 


    This sounds like installed but not successfully assigned.  Check LocationServices.log on the client for site assignment errors.  I don't think this is a CRL issue - the /native:FALLBACK means the client will not check the CRL for the management point certificate, and I think the reg key means the management point (via IIS) will not check the CRL of the client certificate.

    One thing I don't see in the command line is setting the site code directly - so maybe the client is in a boundary that isn't defined in the hierarchy.  Try reinstalling with SMSSITECODE=<value> added to the list of options.

    • Marked as answer by Garth JonesMVP Thursday, December 31, 2015 9:10 PM
    Friday, July 15, 2011 6:23 PM
  • Thanks for the reply.  We have tried installing with the following command line as part of our troubleshooting:

    ccmsetup.exe /NOSERVICE SMSSITESIGNCERT=C:\WINDOWS\SITESIGNING.CER SMSSLP=FQDN FSP=FQDN SMSSITECODE=XXX SMSMP=FQDN CCMHTTPPORT=443 CCMHTTPPORT=80 DNSSUFFIX=suffix of site servers in forest A.

    We have tried this with the SMSMP and without with the same result.  I have included some info from the LocationServices.log and the ccmexec.log file.  I have also confirmed that the clients are in a defined boundary.  We have removed and reinstalled the MP as well.  Week number 3 working with support....IIS configuration has been verified by MSoft Engineer.

    Thanks for the help.

    Location Services log:

    Failed to update security settings over AD with error 0x80004005.    LocationServices    7/17/2011 7:00:09 PM    1668 (0x0684)
    The 'Certificate Store' is empty in the registry, using default store name 'MY'.    LocationServices    7/17/2011 7:00:09 PM    1668 (0x0684)
    No security settings update detected.    LocationServices    7/17/2011 7:00:09 PM    1668 (0x0684)
    Attempting to retrieve default management point from AD    LocationServices    7/18/2011 9:12:05 AM    3048 (0x0BE8)
    Attempting to retrieve default management point from DNS    LocationServices    7/18/2011 9:12:05 AM    3048 (0x0BE8)
    Retrieved Default Management Point through DNS: nbedscpsc06.nbed.nb.ca    LocationServices    7/18/2011 9:12:05 AM    3048 (0x0BE8)
    Persisting the default management point in WMI    LocationServices    7/18/2011 9:12:05 AM    3048 (0x0BE8)
    Persisted Default Management Point Location locally    LocationServices    7/18/2011 9:12:05 AM    3048 (0x0BE8)
    Attempting to retrieve local MP from AD    LocationServices    7/18/2011 9:12:06 AM    3048 (0x0BE8)
    DhcpGetOriginalSubnetMask entry point not supported.    LocationServices    7/18/2011 9:12:06 AM    3048 (0x0BE8)
    Current AD site of machine is NBSS    LocationServices    7/18/2011 9:12:06 AM    3048 (0x0BE8)
    The 'Certificate Store' is empty in the registry, using default store name 'MY'.    LocationServices    7/18/2011 9:12:06 AM    3048 (0x0BE8)
    Refreshing client operational settings over AD    LocationServices    7/18/2011 9:12:06 AM    3048 (0x0BE8)
    Failed to update security settings over AD with error 0x80004005.    LocationServices    7/18/2011 9:12:06 AM    3048 (0x0BE8)
    The 'Certificate Store' is empty in the registry, using default store name 'MY'.    LocationServices    7/18/2011 9:12:06 AM    3048 (0x0BE8)
    No security settings update detected.    LocationServices    7/18/2011 9:12:06 AM    3048 (0x0BE8)

    CCMexec log file:

    [CCMHTTP] HTTP ERROR: URL=http://nbedscpsc06.nbed.nb.ca/ccm_system_windowsauth/request, Port=80, Protocol=http, SSLOptions=0, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE    CCMEXEC    7/18/2011 10:46:39 AM    3048 (0x0BE8)
    Raising event:

    instance of CCM_CcmHttp_Status
    {
        DateTime = "20110718134639.757000+000";
        HostName = "nbedscpsc06.nbed.nb.ca";
        HRESULT = "0x8004027e";
        ProcessID = 1328;
        StatusCode = 404;
        ThreadID = 3048;
    };
        CCMEXEC    7/18/2011 10:46:39 AM    3048 (0x0BE8)
    HandleRemoteSyncSend failed (0x80040231).    CCMEXEC    7/18/2011 10:46:39 AM    3048 (0x0BE8)
    CForwarder_Sync::Send failed (0x80040231).    CCMEXEC    7/18/2011 10:46:39 AM    3048 (0x0BE8)
    CForwarder_Base::Send failed (0x80040231).    CCMEXEC    7/18/2011 10:46:39 AM    3048 (0x0BE8)
    SystemTaskProcessor::QueueEvent(Logon, 0)    CCMEXEC    7/18/2011 11:16:26 AM    340 (0x0154)
    [CCMHTTP] HTTP ERROR: URL=http://nbedscpsc06.nbed.nb.ca/ccm_system_windowsauth/request, Port=80, Protocol=http, SSLOptions=0, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE    CCMEXEC    7/18/2011 11:18:40 AM    3048 (0x0BE8)
    Raising event:

    instance of CCM_CcmHttp_Status
    {
        DateTime = "20110718141840.136000+000";
        HostName = "nbedscpsc06.nbed.nb.ca";
        HRESULT = "0x8004027e";
        ProcessID = 1328;
        StatusCode = 404;
        ThreadID = 3048;
    };
        CCMEXEC    7/18/2011 11:18:40 AM    3048 (0x0BE8)
    HandleRemoteSyncSend failed (0x80040231).    CCMEXEC    7/18/2011 11:18:40 AM    3048 (0x0BE8)
    CForwarder_Sync::Send failed (0x80040231).    CCMEXEC    7/18/2011 11:18:40 AM    3048 (0x0BE8)
    CForwarder_Base::Send failed (0x80040231).    CCMEXEC    7/18/2011 11:18:40 AM    3048 (0x0BE8)
    Monday, July 18, 2011 2:40 PM
  • So in this line:

    ccmsetup.exe /NOSERVICE SMSSITESIGNCERT=C:\WINDOWS\SITESIGNING.CER SMSSLP=FQDN FSP=FQDN SMSSITECODE=XXX SMSMP=FQDN CCMHTTPPORT=443 CCMHTTPPORT=80 DNSSUFFIX=suffix of site servers in forest A

    - I no longer see the  /native:FALLBACK option, which is needed for the client to talk to the HTTPS management point that it found from DNS.  Try this before the /NOSERVICE option.

    Tuesday, July 19, 2011 2:44 AM
  • Thanks.  I did have the /native:FALLBACK option on the command line after NOSERVICE - I missed it when I typed in the command (I should have done a copy and paste).

    We are looking again at the certificate chain.  The default management point cert was deleted and recreated at well.  Going to test with a few systems now.

     

    Thanks,

    HRuttan

     

    Tuesday, July 19, 2011 12:22 PM
  • Thank you Carol.  We have a resolution for the client installation issues.  We needed to import the subordinate CA certificate in Forest A to the clients in forest B (to Trusted root Certification authority and Intermediate Certification authority on local systems).  Also needed to include the sitesigning certificate located in Forest A on the installation command line as noted in previous post.  Also deleted the "default MP certificate" stopped sccm services, restarted to let the cert autogenerate. MSoft Engineer indicated there was a mismatch with the cert and the clients in Forest B.

     

    Now I'm trying to deploy the client via GPO to systems in Forest B.  I realize I can only use options for the client.msi (not ccmsetup).  I've configured the adm template, added my options and successfully deployed to a handful of test machines (using only supported options for client.msi).  I need to somehow define /native:FALLBACK - I've found a reference to CCMHTTPSSTATE=95 in the client.msi log file.  Found and read your article "The Case of the Mysterious Disappearance of the CCMHTTPSSTATE Client Installation Property".  I haven't been able to find out what 95 equals too or how to get around this when deploying via GPO.

    Is my only option to use another deployment method?  Or can I use CCMHTTPSSTATE= property  on my command line even though it's unsupported?  Or does the value of 95 correct for what I'm trying to do?

     

    Thanks very much

    HRuttan

    • Marked as answer by Garth JonesMVP Thursday, December 31, 2015 9:10 PM
    Wednesday, July 20, 2011 4:05 PM