Hi Thomas
In core CM12 there is no way that you can prevent a client from switching to another MP. All MPs are treated as equal and you will see this behaviour. You will also see this behaviour with SUPs since these also do not benefit from boundaries. Boundaries only affect site assignment and/or DP location requests. There are, however a few things that you can do: - Rob Marshall has a small utility that in essence checks for and overwrites the management point name - http://blogs.technet.com/b/jchalfant/archive/2014/09/22/management-point-affinity-added-in-configmgr-2012-r2-cu3.aspx From: [email protected] [mailto:[email protected]] On Behalf Of tgonzalez Sent: 25 September 2015 12:23 To: [email protected] Subject: [mssms] Pull dps in untrusted domains Here's something that has me going over and over. I'm managing 8 untrusted domains that result in disjoint and clients from a trusted domain, crossing over to use them as mps. Each of the untrusted domains habe a pull dp and mp (both roles on one server). Within the primary, I discovered the untrusted domain sites and assigned their respective ad site to a boundary group for each untrusted pull dp/mp. Now I'm seeing overlap boundaries. In the primary domain, all vlans are set properly. But I'm noticing the untrusted domains have the same vlans. I set the boundary groups for these untrusted domains but in the primary domain, I'm seeing devices selecting the mp in those untrusted domains. Question is, should I remove the mp in those untrusted domains and leave only the dp? I'm working very closely with our ad engineers, since these 8 untrusted domains where created to support specific infrastructure. As of last night, I'm seeing clients in the trusted domain going back and forth from choosing their correct mp and one of the pull dp as the mp. Any suggestion is appreciated. This has been a burden on me, 1 engineer managing over 20k clients and two admins doing the patching. Want to nip this since I have 6 more untrusted domains to add. If it doesn't make sense, it's because I've been up all night trying to resolve. Thanks Thomas
