DNS lookups are a last resort after AD lookups and simply bootstrap the MP location process; they and are not used to assign an MP to the client. This bootstrapping process merely identifies an initial MP to query for the MPLIST(s). Once a client has been assigned an MP, it uses that MP to query for the MPLIST(s) unless that MP is offline at which point it will fallback to AD and then DNS is needed to once again bootstrap the process. Assigned MPs are only chosen from a valid MPLIST list which only ever provided by an MP.
Not sure exactly how that fits in with the issue being described in this thread though. J From: [email protected] [mailto:[email protected]] On Behalf Of P.T. van der Woude Sent: Friday, October 24, 2014 2:58 PM To: [email protected] Subject: RE: [mssms] MP selection and MP Affinity The fun thing is that when you're running HTTPS on all your MPs the client needs to query something like DNS to find out that it needs to use HTTPS. This is even the case when you're using the SMSMP parameter during the installation of the client, because after the client is installed it still knows the MP, but "forgot" about the HTTPS. Regards, Peter van der Woude From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Justin Chalfant Sent: vrijdag 24 oktober 2014 19:14 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] MP selection and MP Affinity This may make sense. I will ping a few contacts to check if this is expected. I do know the AllowedMPs will *Only* work if the management point is in the MP List on the client. That *May* be why it's only working when the MP is published to DNS because the client will then put it in the MP List. I will let you know when I hear something back to confirm. In the meantime, LocationServices and CCMMessaging with Verbose and Debug logging may tell you a little more information about what's going on. Thanks, Justin Chalfant Premier Field Engineer - Configuration Manager Public Sector Microsoft Services Tel : (303) 846-2701 Email: [email protected]<mailto:[email protected]> If you have any feedback about my work, please let either myself or my manager Rusty Gray know at [email protected]<mailto:[email protected]> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Tim Amico Sent: Friday, October 24, 2014 7:05 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] MP selection and MP Affinity Hi Justin, Yes I am seeing 2 "MP list is forced" lines in location services for both of the MPs on the intranet. Read through your blog a number of times to make sure I didn't miss anything as well. And verified the registry key is a REG_Multi_SZ with the FQDN of the DMZ MP. These are new clients and I'm using the PATCH switch in the ccmsetup line. I can see in the client msi log that the client is installed and the patch is being applied successfully. CCMsetup log shows a successful error code. When I go into control panel and open the Config manager client I see a client version of .1401. Below is the command line I'm using: ccmsetup.exe /source:"C:\SCCM Client Install" /UsePKICert /NoCRLCheck SMSMP=<FQDN of DMZ MP> SMSSITECODE=123 PATCH=C:\SCCM Client Install\hotfix\i386\.msp When I look in ccm messaging there are 2 errors looping and in another log it shows trying to connect to a MP on the intranet even though location services lists the same MP as being skipped. Not in front of a client right now so I'll get the exact logs and errors when I get in the office. This is only when the DMZ MP is not being published in DNS. Once published almost immediately the client uses the DMZ MP and shows up in the console as a managed client and I can push content to it. Am I not using MP Affinity the way it was designed? Or do I have to publish all the MPs and set the "AllowedMPs" reg key on all my intranet clients and just leave out the DMZ MP like MS support suggested? Thanks, Tim Email: [email protected]<mailto:[email protected]> Cell: 352-322-8588 From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Justin Chalfant Sent: Friday, October 24, 2014 1:07 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] MP selection and MP Affinity Hi Tim, What are you seeing in location services? Are you seeing lines like "MP list is forced" like in my blog http://blogs.technet.com/b/jchalfant/archive/2014/09/22/management-point-affinity-added-in-configmgr-2012-r2-cu3.aspx? Also, It sounds like this is a new install of a R2 client. You are also installing the CU3 patch right for the client? Did you verify the registry is a REG_Multi_SZ? Thanks, Justin Chalfant Premier Field Engineer - Configuration Manager Public Sector Microsoft Services Tel : (303) 846-2701 Email: [email protected]<mailto:[email protected]> If you have any feedback about my work, please let either myself or my manager Rusty Gray know at [email protected]<mailto:[email protected]> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Tim Amico Sent: Thursday, October 23, 2014 10:13 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] MP selection and MP Affinity Hello, Just trying to get a little clarification here on publishing management points, selection, and the new feature for MP affinity in CU3. Background on the setup: SCCM 2012 R2 with CU3 2 HTTPS MPs on the intranet 1 HTTPS MP in the DMZ Since I have all the management points published to DNS clients will randomly try to reach out to the MP in the DMZ, but since the ports aren't open on 443 for the clients they don't connect. No big deal they just move on and connect to one of the MPs on the intranet, but the network team doesn't want to see all the blocked attempts. As a fix I decided to not publish the MP that sits in the DMZ so that none of the clients would know about it and set the "AllowedMPs" registry field for all the clients in the DMZ to use the MP in the DMZ. However when I install a new client (domain joined or workgroup) in the DMZ with CU3, the SMSMP switch, and set the registry value the client will fail to communicate and never use the DMZ MP. The client keeps trying to use a MP on the intranet and the ports are not opened to the intranet. In the locationservice.log it shows the MP list is forced and to ignore the intranet MP so it looks like the registry value is working properly, but it will never try to use the DMZ MP. Once I turn publishing back on for the DMZ MP within minutes the client connects automatically and sends the record info in so I can see it in the console and manage the device. Spoke with Microsoft support and they said the MP had to be published in DNS for a client to use it (which I didn't think was true) and that if I wanted my clients to not use the DMZ MP I would have to set the "AllowedMPs" registry key for all my intranet clients and just leave out the DMZ MP. Now I know that wouldn't be too hard with a GPO or Compliance Settings, but it just seems like a lot of extra effort to hit all my intranet clients rather than hitting the 30 or so DMZ clients. Is what they are recommending the correct use of MP Affinity? And does the MP really need to be published in DNS before a client will use it? What's the point in using SMSMP for the initial MP selection if the client won't use it when the MP isn't published? And why do they give you the option not to publish a MP in DNS if the client can't use it, unless it's only for a WINS setup?
