locked
Client trying to access MP from untrusted forest RRS feed

  • Question

  • The client site I'm working at has 4 forests/domains. The SCCM site server resides at the top level and trusts are in place to the other three. At each of the three domains there are MP and DP but no trust between those three

    Problem at one domain is issue with SCCM client initializing properly and therefore able to start deploying software

    Looking at locationservices.log I see that the clients seem to rotate through the MPs at the untrusted site. In each domain's System Management container the MPs for all sites appear because of the trust to the "top level" forest i.e. the SCCM primary site server. Is there a way to set a preferred MP as this appears to be causing problems.


    Ian Burnell, London (UK)

    Wednesday, April 23, 2014 2:49 PM

All replies

  • Management Point selection by a client for management points within the same SCCM site is random, that is to say that boundaries/boundary groups are not respected.  You would need to provision Secondary Sites in each domain if you cannot put trusts in place.

    My Personal Blog: http://madluka.wordpress.com

    Wednesday, April 23, 2014 2:58 PM
  • Management Point selection by a client for management points within the same SCCM site is random, that is to say that boundaries/boundary groups are not respected.  You would need to provision Secondary Sites in each domain if you cannot put trusts in place.

    My Personal Blog: http://madluka.wordpress.com


    Or centralize the MP. How many clients are there?

    John Marcum | http://myitforum.com/myitforumwp/author/johnmarcum/

    Wednesday, April 23, 2014 3:33 PM
  • As Andy says the MP selection is random, you cannot specify. As a temporary measure you can use tools such as this http://gallery.technet.microsoft.com/ConfigMgr-SwitchMP-87d61073 

    For a more perm fix I think you may need to review the design.

    Wednesday, April 23, 2014 3:36 PM
  • Taking a step back, you said "at each of the 3 of the domains". What about the 4th? Is that where you're having issues with MP selection?

    Are the MPs members of those other domains?

    Also, as John asked, how many systems are in each forest/domain and are they physically co-located or separated by firewalls or other network rules that prevent connectivity?


    Jason | http://blog.configmgrftw.com

    Wednesday, April 23, 2014 4:52 PM
  •   You would need to provision Secondary Sites in each domain if you cannot put trusts in place.

    That won't work. A trust is needed if you want to place secondaries there (reason: Kerberos / DRS replication).

    It is true that MP selection cannot be controlled by boundary/groups, but the domain membership of clients / MPs should be honoured though.


    Torsten Meringer | http://www.mssccmfaq.de

    Wednesday, April 23, 2014 9:37 PM
  • Taking a step back, you said "at each of the 3 of the domains". What about the 4th? Is that where you're having issues with MP selection?

    Are the MPs members of those other domains?

    Also, as John asked, how many systems are in each forest/domain and are they physically co-located or separated by firewalls or other network rules that prevent connectivity?


    Jason | http://blog.configmgrftw.com


    Yes - the actual issue - which I've logged in a different thread is that at this one domain/site the builds sometime fail to install one or more applications more often then not the first application in the install applications step fails with an 8004005 error - the app tries 3 times at 5 minute intervals and then states "Exhausted retry attempts - giving up". Frequently the next two apps install perfectly. I notice however, that after the build locationservices.log states that the MP is set to one of the other (untrusted) domains and the client doesn't properly initialize until the MP rotates to the local site (which is simply a DP and MP). The top level domain/forest where the SCCM primary site exists is simply a resource domain i.e. there are no clients there and and that's where the two way trusts have been set up. So for the other two forests domains they can also communicate to the SCCM domain but not to this other domain. I tried removing MPs since you only need one, but hit problems with application installs and had to quickly reinstate since we are in the middle of a live Win 7 rollout. The funny thing is that at the other two sites builds (the same OSD task sequence) works perfectly with no issues. I'm convinced there is a network issue at this site but need to work out how to troubleshoot it and my step was to try to restrict which MPs the local clients can access at that site

    Ian Burnell, London (UK)

    Thursday, April 24, 2014 6:50 AM
  •   You would need to provision Secondary Sites in each domain if you cannot put trusts in place.


    That won't work. A trust is needed if you want to place secondaries there (reason: Kerberos / DRS replication).

    It is true that MP selection cannot be controlled by boundary/groups, but the domain membership of clients / MPs should be honoured though.


    Torsten Meringer | http://www.mssccmfaq.de


    That's what I thought - yes the site server containing the local MP and DP and clients are all in the same domain so I would have assumes that the MP selection would use the domain first rather than randomly selecting

    Ian Burnell, London (UK)

    Thursday, April 24, 2014 6:54 AM
  •   You would need to provision Secondary Sites in each domain if you cannot put trusts in place.


    That won't work. A trust is needed if you want to place secondaries there (reason: Kerberos / DRS replication).

    It is true that MP selection cannot be controlled by boundary/groups, but the domain membership of clients / MPs should be honoured though.


    Torsten Meringer | http://www.mssccmfaq.de


    That's what I thought - yes the site server containing the local MP and DP and clients are all in the same domain so I would have assumes that the MP selection would use the domain first rather than randomly selecting

    Ian Burnell, London (UK)

    Sorry, yes of course, my mistake - it's site systems that can go in untrusted domains, not site servers.

    As your MP's are all in the same SCCM Site, MP selection will consider them all and randomly select one of them irrespective of the domain they are in.

    It looks like the issue is covered in Anoops blog here, and there may not be much we can do about this: http://anoopcnair.com/2014/03/07/configmgr-sccm-2012-mp-selection-forest-trust-related-bug/

    My Personal Blog: http://madluka.wordpress.com


    • Edited by MadLuka Thursday, April 24, 2014 1:28 PM
    Thursday, April 24, 2014 1:28 PM
  • A network issue is a likely culprit here and is why I asked about restrictions between the forests/domains.

    Ultimately, if the forests/domains are co-located and they have no network restrictions between them, then there is no reason to use anything more than a single MP (or two in the same domain for HA). If there are network restrictions between them, then your results will always be problematic.

    Clients first categorize MPs (by domain and forest) and then choose randomly from the MPs giving preference based on the category. In general, clients should always choose MPs in their own domain or forest but this is not strictly guaranteed (although in my [limited] testing it is always the outcome).

    If of course there is no MP in the local domain or forest of client, then selection among the rest is completely random. So, assuming the clients having issues are in the domain/forest without an MP, you should stand up and MP in that domain/forest.


    Jason | http://blog.configmgrftw.com

    Thursday, April 24, 2014 3:37 PM
  • As your MP's are all in the same SCCM Site, MP selection will consider them all and randomly select one of them irrespective of the domain they are in.



    Nope. See Jason's reply. Forest and domain membership will be taken into account!

    Torsten Meringer | http://www.mssccmfaq.de

    Thursday, April 24, 2014 7:30 PM
  • Thanks for the replies - Yes Anoop's article exactly described the issue. Indeed when you look at locationservices.log there is never and entry saying ForestTrust:Y. I would suggest therefore that if this is the case the clients are not deemed to be in the local forest and hence why they don't select their "local" Domain MP

    Ultimately there are three issues

    1. Whether there is a MS bug over the selection of MP in the local firest as per the article.

    2. The inability to force an MP - unless you don't publish to AD and use DNS searching

    3. I need to test removing all mps except the top level forest domain where each site/forest has two-way trusts. Therefore in theory all domains should be happy then since they use the "central" MP


    Ian Burnell, London (UK)

    Friday, April 25, 2014 8:40 AM
  • As your MP's are all in the same SCCM Site, MP selection will consider them all and randomly select one of them irrespective of the domain they are in.



    Nope. See Jason's reply. Forest and domain membership will be taken into account!

    Torsten Meringer | http://www.mssccmfaq.de

    Apparently not in Ian's case.

    My Personal Blog: http://madluka.wordpress.com

    Friday, April 25, 2014 8:45 AM
  • Apparently not in Ian's case.



    Yeah, that's what he wrote. I just wanted to point out that he's not seeing expected behavior.

    Torsten Meringer | http://www.mssccmfaq.de

    Friday, April 25, 2014 10:00 AM
  • I have undertaken some testing by standing up another Forest (no trust in place) in my lab environment and provisioning a DP and MP (using site database) on the only new Domain Controller in that Forest.  The MPControl.log on the new Forest DC shows status 200 so I was good to go.

    I discovered the New forest DC using system discovery into my ConfigMgr 2012 R2 environment and used client push to install the client using credentials for the new forest.  The client push went OK, and I know I'd have to approve this untrusted client, however the client was stuck pending registration with the resource showing as Client=No.  I waited a short while however nothing changed.  If I removed the MP from the new forest then the client updated it's resource in the console and I could approve it.

    Once the new forest client was operational, I then added the MP back to the server in the new forest and the client rotated to that MP, showing me this in the LocationServices.log

    Name: 'sccm-mp.contoso.com' HTTPS: 'N' ForestTrust: 'N'

    Name: 'sccm-mp.fabrikam.local' HTTPS: 'N' ForestTrust: 'Y'

    So it does seem that clients obey MP selection based on being in a different forest, however I haven't yet tried with a client in a child/tree domain in the same forest as my SCCM Server.

    There is now a question of whether the MP in the new untrusted forest can actually handle client registration requests at all, or is there a significant delay due to MP replication?  Client registration was instantaneous without an MP in the new forest.


    My Personal Blog: http://madluka.wordpress.com

    • Marked as answer by Ian Burnell Friday, May 2, 2014 8:07 AM
    • Unmarked as answer by Ian Burnell Saturday, May 3, 2014 7:20 AM
    Friday, April 25, 2014 12:49 PM
  • I spoke too soon. I thought this was resolved. Forest discovery was not setup correctly hence the clients were not "seeing" the MP as ForestTrust. Once I resolved the discovery I could clearly see ForestTrust: 'Y' in locationservices.log. Builds appears to be working fine.

    However, same error is occurring in that although the correct MP is selected initially it tries to get an MP lookup and fails

    "Failed to send request to /SMS_MP/.sms_aut?SITESIGNCERT at host error 0x2ee7"

    After this it tried to resolve DNS and then wins. DNS is not setup and WINS is still there but doesn't have the FQDN of the MP and this then screws up application installs in the Task sequence

    • Edited by Ian Burnell Saturday, May 3, 2014 7:20 AM Stiil a problem
    Friday, May 2, 2014 8:09 AM