locked
installing SCCM 2012 client on an isolated network problem RRS feed

  • Question

  • As per the title, we are having problems installing the SCCM 2012 client on an isolated network.

    Here's an overview of our environment:

    We have internal network where we have the primary, a mp, a dp, sup installed (lets call the server sccm1) - all the the internal clients are working fine and have no issues installing the client. In the isolated network we have (sccm2) this is a dp, mp and sup - the roles are installed succesfully, packages are replicating over to the remote site server, mplist and mpcert checks works on both management points and the logs looks clean on both site servers. Name resolution is working properly. Also there's no trust between the forest. Communication between sccm1 and sccm2 are open, all necessary ports are passing through.

    Our problem is that we cannot get any of the clients in the DMZ to get a site assignment, the client instals succesfully but it fails on assigning to a site. We have tried a variety of ways to install the client in the isolated network to no avail. This is what we have tried so far

    1. Via DNS - published the mp info on DNS and installed the client with this command line ccmsetup dnssuffix=ourinternaldom.com, we also tried ccmsetup smssitecode=pr1 dnssuffix=internaldom.com
    2. Tried creating a LMHOST file with mp information
    3. Tried specifying the site code and management point directly ccmsetup smssitecode=pr1 smsmp=sccm2

    In all cases a variation of this is what we are getting in the locationservices.log

    Assigning to site 'pr1' LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    LSIsSiteCompatible : Verifying Site Compatibility for <pr1> LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    Retrieved lookup MP [sccm2] from Registry LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    Attempting to retrieve lookup MP(s) from DNS LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    DNS Suffix not specified LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    No lookup MP(s) from DNS LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    Retrieved lookup MP [SCCM2] from Registry LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    Attempting to retrieve lookup MP(s) from DNS LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    DNS Suffix not specified LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    No lookup MP(s) from DNS LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    Attempting to retrieve site information from lookup MP(s) via HTTP LocationServices 9/3/2013 5:12:36 PM 5752 (0x1678)

    Failed to verify message. Sending MP [sccm2] not in cached MPLIST. LocationServices 9/3/2013 5:12:38 PM 5752 (0x1678)

    MPLIST requests are throttled for 00:54:57 LocationServices 9/3/2013 5:12:38 PM 5752 (0x1678)

    Failed to verify message. Sending MP [SCCM2] not in cached MPLIST. LocationServices 9/3/2013 5:12:38 PM 5752 (0x1678)

    MPLIST requests are throttled for 00:54:57 LocationServices 9/3/2013 5:12:38 PM 5752 (0x1678)

    Failed to send site information Location Request Message to SCCM2 LocationServices 9/3/2013 5:12:38 PM 5752 (0x1678)

    LSIsSiteCompatible : Failed to get Site Version from all directories LocationServices 9/3/2013 5:12:38 PM 5752 (0x1678)

    Won't send a client assignment fallback status point message because the last assignment error matches this one. LocationServices 9/3/2013 5:12:38 PM 5752 (0x1678)

    On the certificatemaintenance.log

    Failed to verify signature message reeived from MP using name 'sccm2'

    Any help/guidance will be much appreciated. Thanks.

    Wednesday, September 4, 2013 12:27 AM

Answers

  • Thanks for all the help - we have passed this problem. The fix was indeed joining the site site sytem server to a domain.  We had to remove all the roles, rebuild the site system server from scratch, install the roles and the clients started to start reporting in.  I did have to turn off PKI (we dont need it anyway) since the clients in the DMZ were trying to use certificates if it had one on the Personal store, otherwise if there was no certificates in the Personal store everything was working fine. 

    I still have to observe the MP assignment but so far the clients are finding the correct one.

    I do have have another problem with the SUP/WSUS assignment for the clients in the DMZ but that would be going to another thread.  Even though the SUP seems to be healthy on the internal network and the DMZ, the clients in the DMZ does not seem to find the SUP in the DMZ, it keeps on trying to communicate to the internal SUP.  I expect the behavior to be like this http://blogs.technet.com/b/configmgrteam/archive/2013/03/27/software-update-points-in-cm2012sp1.aspx but its not happening yet.

    Thanks again for the help.


    • Edited by richardrr Thursday, September 12, 2013 12:10 AM correction
    • Marked as answer by Juke Chou Thursday, September 12, 2013 6:58 AM
    Wednesday, September 11, 2013 11:56 PM

All replies

  • What command-line exactly are you using to install the client agent on the systems in the DMZ?

    Are you using HTTPS client communication?

    Is port 80 or 443 (depending upon whether or not you are using HTTPS client communication) open *to* the (internal) MP from *all* of the clients in the DMZ?

    Can you actually ping SCCM2 (short name, not FQDN) from a client in the DMZ and get name resolution to the proper IP address (not worried about the actual ping result)?


    Jason | http://blog.configmgrftw.com

    Wednesday, September 4, 2013 2:19 AM
  • Hi,

    From the log Failed to verify signature message reeived from MP using name 'sccm2', seems the trusted root key stored in Client does not match the key in MP. Please verify this first.


    Juke Chou
    TechNet Community Support

    Wednesday, September 4, 2013 7:26 AM
  • We have tried the following command lines with the same result:

    ccmsetup dnssuffix=internaldom.com

    ccmsetup smssitecode=pr1 dnssuffix=internaldom.com

    ccmsetup smssitecode=pri smsmp=sccm2

    We are using port 80.

    Yes, we can ping SCCM2 with the hostname and the FQDN from all the clients in the DMZ.

    In addition the MPLIST and MPCERT test both work on all the clients in the DMZ.  IIS logs on the MP looks clean as well.

    Thanks.

    Wednesday, September 4, 2013 2:58 PM
  • Can you please perform a clean install on a system in the DMZ (uninstall the client agent first if necessary using ccmsetup /uninstall) using ccmesetup SMSMP=sccm2 SMSSITECODE=PRI and post the results of locationservices.log and clientlocation.log?

    Jason | http://blog.configmgrftw.com

    Wednesday, September 4, 2013 3:18 PM
  • Ok, I did verify the Trusted Root Key. The clients have the same Trusted Root Key as defined in the management point. 

    The way I verified is to wbemtest on the client and compared the "TrustedRootKey" value to the what is defined in mobileclient.tcf file SMSPublicRootKey.

    What would be the nex thing to look at as I'm running out of ideas. 

    Thanks.

    Wednesday, September 4, 2013 3:34 PM
  • Hello,

    Here is the locationservices.log with the ccmesetup SMSMP=sccm2 SMSSITECODE=PRI install.

    <![LOG[A Fallback Status Point has not been specified.  Message with STATEID='500' will not be sent.]LOG]!><time="08:47:30.928+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="fspclientdeployassign.cpp:55">
    <![LOG[Processing pending site assignment.]LOG]!><time="08:47:30.928+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:3219">
    <![LOG[Assigning to site 'PRI']LOG]!><time="08:47:30.928+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:3225">
    <![LOG[LSIsSiteCompatible : Verifying Site Compatibility for <PRI>]LOG]!><time="08:47:30.928+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:5061">
    <![LOG[Retrieved lookup MP [SCCM2] from Registry]LOG]!><time="08:47:30.928+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2104">
    <![LOG[Attempting to retrieve lookup MP(s) from DNS]LOG]!><time="08:47:30.928+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2148">
    <![LOG[DNS Suffix not specified]LOG]!><time="08:47:30.928+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:3052">
    <![LOG[No lookup MP(s) from DNS]LOG]!><time="08:47:30.928+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2177">
    <![LOG[Retrieved lookup MP [SCCM2] from Registry]LOG]!><time="08:47:30.944+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2104">
    <![LOG[Attempting to retrieve lookup MP(s) from DNS]LOG]!><time="08:47:30.944+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2148">
    <![LOG[DNS Suffix not specified]LOG]!><time="08:47:30.944+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:3052">
    <![LOG[No lookup MP(s) from DNS]LOG]!><time="08:47:30.944+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2177">
    <![LOG[Attempting to retrieve site information from lookup MP(s) via HTTP]LOG]!><time="08:47:30.975+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lssecurity.cpp:6022">
    <![LOG[Refreshing the Management Point List for site PRI]LOG]!><time="08:47:31.194+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lssecurity.cpp:848">
    <![LOG[Raising event:
    
    instance of CCM_CcmHttp_Status
    {
    	DateTime = "20130904154731.257000+000";
    	HostName = "SCCM2";
    	HRESULT = "0x00000000";
    	ProcessID = 4196;
    	StatusCode = 0;
    	ThreadID = 1368;
    };
    ]LOG]!><time="08:47:31.257+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="event.cpp:706">
    <![LOG[Refreshing trusted key information]LOG]!><time="08:47:31.257+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lssecurity.cpp:912">
    <![LOG[Raising event:
    
    instance of CCM_CcmHttp_Status
    {
    	DateTime = "20130904154731.335000+000";
    	HostName = "SCCM2";
    	HRESULT = "0x00000000";
    	ProcessID = 4196;
    	StatusCode = 0;
    	ThreadID = 1368;
    };
    ]LOG]!><time="08:47:31.335+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="event.cpp:706">
    <![LOG[Persisting the management point authentication information in WMI]LOG]!><time="08:47:31.350+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lssecurity.cpp:921">
    <![LOG[Persisted Management Point Authentication Information locally]LOG]!><time="08:47:31.366+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lssecurity.cpp:928">
    <![LOG[Failed to verify message. Sending MP [SCCM2] not in cached MPLIST.]LOG]!><time="08:47:31.366+420" date="09-04-2013" component="LocationServices" context="" type="2" thread="1368" file="lssecurity.cpp:1744">
    <![LOG[MPLIST requests are throttled for 00:59:59]LOG]!><time="08:47:31.366+420" date="09-04-2013" component="LocationServices" context="" type="2" thread="1368" file="lssecurity.cpp:1747">
    <![LOG[Failed to verify message. Sending MP [SCCM2] not in cached MPLIST.]LOG]!><time="08:47:31.366+420" date="09-04-2013" component="LocationServices" context="" type="2" thread="1368" file="lssecurity.cpp:1744">
    <![LOG[MPLIST requests are throttled for 00:59:59]LOG]!><time="08:47:31.366+420" date="09-04-2013" component="LocationServices" context="" type="2" thread="1368" file="lssecurity.cpp:1747">
    <![LOG[Failed to send site information Location Request Message to SCCM2]LOG]!><time="08:47:31.366+420" date="09-04-2013" component="LocationServices" context="" type="2" thread="1368" file="lssecurity.cpp:5558">
    <![LOG[LSIsSiteCompatible : Failed to get Site Version from all directories]LOG]!><time="08:47:31.366+420" date="09-04-2013" component="LocationServices" context="" type="3" thread="1368" file="lsad.cpp:5115">
    <![LOG[A Fallback Status Point has not been specified.  Message with STATEID='608' will not be sent.]LOG]!><time="08:47:31.366+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="fspclientdeployassign.cpp:55">
    <![LOG[Won't send client assignment fallback status point message because last assignment message was sent too recently.]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="fspclientdeployassign.cpp:180">
    <![LOG[Processing pending site assignment.]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:3219">
    <![LOG[Assigning to site 'PRI']LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:3225">
    <![LOG[LSIsSiteCompatible : Verifying Site Compatibility for <PRI>]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:5061">
    <![LOG[Retrieved lookup MP [SCCM2] from Registry]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2104">
    <![LOG[Attempting to retrieve lookup MP(s) from DNS]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2148">
    <![LOG[DNS Suffix not specified]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:3052">
    <![LOG[No lookup MP(s) from DNS]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2177">
    <![LOG[Retrieved lookup MP [SCCM2] from Registry]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2104">
    <![LOG[Attempting to retrieve lookup MP(s) from DNS]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2148">
    <![LOG[DNS Suffix not specified]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:3052">
    <![LOG[No lookup MP(s) from DNS]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lsad.cpp:2177">
    <![LOG[Attempting to retrieve site information from lookup MP(s) via HTTP]LOG]!><time="08:52:30.933+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="lssecurity.cpp:6022">
    <![LOG[Failed to verify message. Sending MP [SCCM2] not in cached MPLIST.]LOG]!><time="08:52:31.011+420" date="09-04-2013" component="LocationServices" context="" type="2" thread="1368" file="lssecurity.cpp:1744">
    <![LOG[MPLIST requests are throttled for 00:55:00]LOG]!><time="08:52:31.011+420" date="09-04-2013" component="LocationServices" context="" type="2" thread="1368" file="lssecurity.cpp:1747">
    <![LOG[Failed to verify message. Sending MP [SCCM2] not in cached MPLIST.]LOG]!><time="08:52:31.011+420" date="09-04-2013" component="LocationServices" context="" type="2" thread="1368" file="lssecurity.cpp:1744">
    <![LOG[MPLIST requests are throttled for 00:55:00]LOG]!><time="08:52:31.011+420" date="09-04-2013" component="LocationServices" context="" type="2" thread="1368" file="lssecurity.cpp:1747">
    <![LOG[Failed to send site information Location Request Message to SCCM2]LOG]!><time="08:52:31.011+420" date="09-04-2013" component="LocationServices" context="" type="2" thread="1368" file="lssecurity.cpp:5558">
    <![LOG[LSIsSiteCompatible : Failed to get Site Version from all directories]LOG]!><time="08:52:31.011+420" date="09-04-2013" component="LocationServices" context="" type="3" thread="1368" file="lsad.cpp:5115">
    <![LOG[Won't send a client assignment fallback status point message because the last assignment error matches this one.]LOG]!><time="08:52:31.011+420" date="09-04-2013" component="LocationServices" context="" type="1" thread="1368" file="fspclientdeployassign.cpp:197">

    The clienlocation.log is filled with this repeating messages after debug logging was turned on.

    CCM::LocationServices::CcmGetHomeMPFromWMIEx( &sAMP, &sProtocol, &dwVersion, &sCap ), HRESULT=80004005 (e:\nts_sccm_release\sms\client\smsclient\smsclientclass.cpp,1901) ClientLocation 9/4/2013 10:38:37 AM 3260 (0x0CBC)
    GetAssignedManagementPoint(sMPName, dwTempVersion, sCapabilities), HRESULT=80004005 (e:\nts_sccm_release\sms\client\smsclient\smsclientclass.cpp,1142) ClientLocation 9/4/2013 10:38:37 AM 3260 (0x0CBC)
    CCM::LocationServices::CcmGetHomeMPFromWMIEx( &sAMP, &sProtocol, &dwVersion, &sCap ), HRESULT=80004005 (e:\nts_sccm_release\sms\client\smsclient\smsclientclass.cpp,1901) ClientLocation 9/4/2013 10:43:37 AM 4124 (0x101C)
    GetAssignedManagementPoint(sMPName, dwTempVersion, sCapabilities), HRESULT=80004005 (e:\nts_sccm_release\sms\client\smsclient\smsclientclass.cpp,1142) ClientLocation 9/4/2013 10:43:37 AM 4124 (0x101C)
    CCM::LocationServices::CcmGetHomeMPFromWMIEx( &sAMP, &sProtocol, &dwVersion, &sCap ), HRESULT=80004005 (e:\nts_sccm_release\sms\client\smsclient\smsclientclass.cpp,1901) ClientLocation 9/4/2013 10:48:37 AM 4856 (0x12F8)
    GetAssignedManagementPoint(sMPName, dwTempVersion, sCapabilities), HRESULT=80004005 (e:\nts_sccm_release\sms\client\smsclient\smsclientclass.cpp,1142) ClientLocation 9/4/2013 10:48:37 AM 4856 (0x12F8)
    CCM::LocationServices::CcmGetHomeMPFromWMIEx( &sAMP, &sProtocol, &dwVersion, &sCap ), HRESULT=80004005 (e:\nts_sccm_release\sms\client\smsclient\smsclientclass.cpp,1901) ClientLocation 9/4/2013 10:53:38 AM 1372 (0x055C)
    GetAssignedManagementPoint(sMPName, dwTempVersion, sCapabilities), HRESULT=80004005 (e:\nts_sccm_release\sms\client\smsclient\smsclientclass.cpp,1142) ClientLocation 9/4/2013 10:53:38 AM 1372 (0x055C)
    

    Thanks.

    • Edited by richardrr Thursday, September 5, 2013 12:25 AM added information
    Wednesday, September 4, 2013 3:57 PM
  • Just to give an update on this problem:

    We have opened a ticket with MS support and so far they don't see anything wrong with the configuration, we all think this should be working. They enabled debug logging on the client and the mp then gathered the logs, and also captured netmon traces on both the client and the server.

    Thanks.

    Thursday, September 5, 2013 12:06 AM
  • Please keep us updated. Thanks.


    Juke Chou
    TechNet Community Support

    Thursday, September 5, 2013 3:31 AM
  • I'm waiting for MS to get back to me and I'm double checking everything on our end:

    Does anyone know what this message mean in the locationservices.log? Should this be our focus in troubleshooting

    Failed to verify message. Sending MP [SCCM2] not in cached MPLIST.

    I know for a fact that the MP is responding properly if we try the following:

    Thanks.

    Thursday, September 5, 2013 3:08 PM
  • MPLIST is the list MPs actually returned by the mplist URL. Have you looked at those results to see if the MP is listed in there?

    It's a piece of puzzle yes.

    Can you describe your overall ConfigMgr architecture a little more please?

    You said this is an isolated network; is SCCM2 the MP for the primary site? And is it across the DMZ border firewall?


    Jason | http://blog.configmgrftw.com

    Friday, September 6, 2013 12:20 PM
  • Yes the MPList URL is working and showing both MPs (SCCM1 and SCCM2)

    Our environment is very basic:

    We have an internal network and the isolated network. There is domain in the internal network and the external network but NO trusts between them.  The Primary is in the internal network on SCCM1 - this is also a MP, DP, SUP and Endpoint Protection point. The internal clients are working fine and reporting in properly. Then on the isolated network we have SCCM2 - which is a MP, DP, SUP.  SCCM2 is intended to serve the isolated network. The client that we are trying to configure is on the same subnet as SCCM2 so all the network communications is open between them.  As far as we can tell and verified with MS all the communication between SCCM1 and SCCM2 is working, also the communication between SCCM2 and client is working as well.  We have gone through IIS logs on the MP, netmon logs between SCCM2 and the client and so far no luck figuring out the root cause.

    Interesting enough SCCM2 is a valid client, so it seems SCCM2 can report to itself and we used this to install the client. ccmesetup SMSMP=sccm2 SMSSITECODE=PRI.

    Thanks.


    • Edited by richardrr Friday, September 6, 2013 2:59 PM additions
    Friday, September 6, 2013 2:54 PM
  • Can clients in the isolated network reach SCCM1?

    Is the client approved in the console?

    Is all of this using HTTP Client communication?

    Are these clients in the isolated network in a trusted domain with respect to the primary site server?

    (Sorry if you've already stated a couple of these answers already -- it's hard wading through a long thread sometimes.)


    Jason | http://blog.configmgrftw.com

    Friday, September 6, 2013 3:34 PM
  • No problem - I'm the one in need of assistance here :)

    Can clients in the isolated network reach SCCM1?

    The clients in the isolated network cannot reach SCCM1.  They can only talk to SCCM2.

    Is the client approved in the console?

    The clients in the isolated network does not show in console - this is the main problem, the client in the isolated network cannotget  the site assignment properly. When SCCM2 reported in the console it was not approved and I had to approve it manually as expected. All the internal clients gets automatically approved.

    Is all of this using HTTP Client communication?

    Yes this is all through HTTP.

    Are these clients in the isolated network in a trusted domain with respect to the primary site server?

    No, there is no trust between the clients in the isolated network an the primary site server.

    Thanks.

    Friday, September 6, 2013 3:41 PM
  • Can clients in the isolated network reach SCCM1?

    The clients in the isolated network cannot reach SCCM1.  They can only talk to SCCM2.

    OK. This may not be your explicit issue right now, but the design is invalid then. Client selection and use of MPs is not in any way location aware; all MPs must be accessible to all clients.

    Multiple MPs within a single primary site are for HA and cross-forest scenarios only. So, unless there is a forest in the isolated network that the clients and the MP are members of, what you have won't work in the long run anyway.


    Jason | http://blog.configmgrftw.com

    Friday, September 6, 2013 5:12 PM
  • Yes we are aware that mp selection is not location aware unlike the DP, but MP selection should still work. If the client on the isolated network tries to reach sccm1 its going to fail and then try sccm2 which should be reachable. The same goes for the internal clients trying to reach sccm2, it would fail and try sccm1 which is reachable. When you say "unless there is a forest in the isolated network" does that mean the sccm2 and the client needs to be part of the forest in the isolated network? What if they are just standalone machines? There is a forest in the isolated network, just right now both sccm2 and the test clients are standalone. Thanks.
    Friday, September 6, 2013 5:39 PM
  • Yes and no. It's not an immediate fail and therein lies the problem. I *think* it's 10 minutes and I know it's completely random which MP it would fail to. So it's possible that it tries to use the same MP every time or 10 times in a row or any permutation without trying to switch to the other MP.

    You can selectively control the publication of MPs to alternate forests. Thus if the clients are part of that alternate forest, you could restrict MP publication to just that single MP in that forest so the clients would only ever try to use that MP.

    SCCM2 is standalone?

    Are you saying it's in a workgroup?


    Jason | http://blog.configmgrftw.com

    Friday, September 6, 2013 5:46 PM
  • Yes sccm2 is standalone machine and not part of any domain. The client we are trying to manage is also standalone. I do see the client talking to sccm2 via the iis logs, even verified that it got the trusted root key back from sccm2.
    Friday, September 6, 2013 5:53 PM
  • Yes sccm2 is standalone machine and not part of any domain.

    From http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigAdDomains :

    "All System Center 2012 Configuration Manager site systems must be members of a Windows Active Directory domain"

    I have no idea how you got any of the roles installed as I thought it wouldn't even let you.

    Going back to the failover though, just because it's connecting now, doesn't mean it won't try to switch in the future and then fail. I don't remember the timeframe, but clients do change MPs on occasion and in a random fashion.


    Jason | http://blog.configmgrftw.com

    Friday, September 6, 2013 6:31 PM
  • Ill take a look at this and join sccm2 to a domain and reinstall all the roles once its part of the domain. I totally missed this requirement for the site server. Ill verify with MS as well since they have been looking at the setup for a few days and did not bring this requirement up. Thanks for the pointers.
    Friday, September 6, 2013 6:41 PM
  • Thanks for all the help - we have passed this problem. The fix was indeed joining the site site sytem server to a domain.  We had to remove all the roles, rebuild the site system server from scratch, install the roles and the clients started to start reporting in.  I did have to turn off PKI (we dont need it anyway) since the clients in the DMZ were trying to use certificates if it had one on the Personal store, otherwise if there was no certificates in the Personal store everything was working fine. 

    I still have to observe the MP assignment but so far the clients are finding the correct one.

    I do have have another problem with the SUP/WSUS assignment for the clients in the DMZ but that would be going to another thread.  Even though the SUP seems to be healthy on the internal network and the DMZ, the clients in the DMZ does not seem to find the SUP in the DMZ, it keeps on trying to communicate to the internal SUP.  I expect the behavior to be like this http://blogs.technet.com/b/configmgrteam/archive/2013/03/27/software-update-points-in-cm2012sp1.aspx but its not happening yet.

    Thanks again for the help.


    • Edited by richardrr Thursday, September 12, 2013 12:10 AM correction
    • Marked as answer by Juke Chou Thursday, September 12, 2013 6:58 AM
    Wednesday, September 11, 2013 11:56 PM