Hello, I've noticed something odd at a secondary site this morning. The clients have chosen a domain controller in the same AD site that hosts the primary SCCM site as its management point. This server has never had a SCCM site role installed on it as far as I'm aware. The secondary site is hosted on the DC at the remote site (I know this isnt ideal) and runs PMP, DP, PXE. I could almost understand it choosing the primary site MP but I dont really understand why it would choose a DC over here. I dont know if it matters but this is a single domain forest and the DC it chose holds the PDC emulator FSMO role (along with a few of the others). Maybe this is a hole in my understanding, so if anybody can offer an explanation I'd appreciate it very much. Is there something I can check in the directory to get a list of MP's or something like that? Cheers Steve

Check the boundaries for both sites and the client. The client will select a Management Point within it's own defined boundaries.Kent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund

Hi Kent, Thanks for your post- I thought it might have something to do with that myself (although I dont get why it would choose a DC that isnt part of the SCCM infrastructure, but anyway) but I can find anything wrong with them, unless I misunderstand how they are supposed to be configured. The boundaries configured in SCCM are AD site boundaries and I've checked the subnet config for each of them in dssite.msc and they look fine. Cheers Steve

There can only be one active MP pr. site. Can you check that you the correct one marked as active?Kent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund

Not that I particulrly thought it would help, but anyway, I've just reset the secondary site. For a few minutes it went back to using the primary site management point then once again configured itself to use the irrelevant DC. Is it feasible to just use ADSIEdit or something similar to remove reference to the DC, or at least check the list of MP's in the directory? Cheers Steve

Double check the System Management container in AD to see if there are wrong entries.Torsten Meringer | http://www.mssccmfaq.de

Hi Kent, In <Site Name>\Site Settings\Component Configuration\Management Point Component there is only one option for the MP at each site and in each case its set to the correct one (there isnt another option listed) If I open C:\Program Files (x86)\SMS_CCM\Logs\ClientLocation.Log on the primary site server I see "Current Management Point is <FQDN of correct MP for this site> with version 6487 and capabilities: <Capabilities SchemaVersion="1.0"> </Capabilities>." If I open C:\WINDOWS\SysWOW64\CCM\Logs\ClientLocation.log on the secondary site server I see "Current Management Point is <forest root domain controller FQDN> with version 6487 and capabilities: <Capabilities SchemaVersion="1.0"> </Capabilities>." Just to reitterate the forest root DC has never held a SMS/SCCM role and it located at the same place as the primary site servers. Thanks for your help Steve

Hi Torsten, I checked yesterday in the System Management container using ADSIEdit and the correct entities (CN=SMS-MP-<site code>-<Server Name>) for each site were there. There was no mention of the rogue server. Is there anywhere else in the directory this information could be coming from? I removed and reinstalled the secondary site last night- I'm going to reinstall the MP/DP/PXE roles on it this morning and I'll let you know if it makes any difference. Currently at least the site server is using the correct MP (the MP of the primary site). Cheers Steve

Hello, It seems wiping out the site and recreating it has had a positive effect, albeit a slightly limited one. The client location log on the site server of the secondary site now lists its own IP address (not FQDN!) as its current management point. I'm going to keep my eye on that log and the location services log, repopulate the DP and make sure PXE, etc. is still working and I'll post back if/when everything returns to normal. Cheers Steve *edit* It seems the secondary site server is locating the MP through WINS (there is no WINS server, so I'm guessing this is most likely by broadcast). I'm assuming that once the directory has replicated to the DC at the site then the MP will be located by SLP again and the FQDN will be shown rather than the IP address.