We have 2 Primary Sites. We confirmed that the command line on the Client Push Installation pointed to the correct Primary Site. Then, logging into Primary Site 1 we right clicked on about 50% of our collections and picked INSTALL CLIENT. Then, logging into Primary Site 2 we right clicked on the rest of our collections and picked INSTALL CLIENT. 95% of all machines have Primary Site 1 has their Site Code. how can that be? mqh7

Overlapping boundaries? Which client push options have you used onboth sites?Torsten Meringer | http://www.mssccmfaq.de

We have 2 Primary Sites. We confirmed that the command line on the Client Push Installation pointed to the correct Primary Site. Then, logging into Primary Site 1 we right clicked on about 50% of our collections and picked INSTALL CLIENT. Then, logging into Primary Site 2 we right clicked on the rest of our collections and picked INSTALL CLIENT. 95% of all machines have Primary Site 1 has their Site Code. how can that be? mqh7 Yes We would require more details on this issue so that we can help you out. Did you check the log files from the client side ? are they able to do manual discovery of appropriate site code?Anoop C Nair - Twitter @anoopmannur MY BLOG: http://anoopmannur.wordpress.com SCCM Professionals This posting is provided AS-IS with no warranties/guarantees and confers no rights.

No, 100% sure we do NOT have overlapping boundaries. Everything is setup based on AD Site Name and we've had our AD team make sure each is unique. what else could cause this? We use this command on the Client Push Installation properties PRIMARY SITE 1: SMSSITECODE=PR1 SMSSLP=SCCMPRI01 FSP=SCCMPRI01 SMSMP=SCCMPRI01 PRIMARY SITE 2: SMSSITECODE=PR2 SMSSLP=SCCMPRI02 FSP=SCCMPRI02 SMSMP=SCCMPRI02 As I did RDC into each of these primaries when I did the push. Thanks. mqh7

There's no automatic discovery of the sitecode happening if you used "SMSSITECODE=xxx" as a client push parameter. Were did you check the sitecode? Are the sites two independent ones? Are they reporting to a common central site? Are the clients listed as "client = yes" in the console? Have you already checked ccmsetup.log on the client to see if the right command line was used?Torsten Meringer | http://www.mssccmfaq.de

I checked the site code in the collection. In the collections each machine says Client=yes, Approved, Assigned=yes I looked at the ccmsetup.log on many of these machines and they all say this: MSI properties: INSTALL="ALL" SMSSITECODE="PR2" SMSSLP="SCCMpri02" FSP="SCCMpri02" SMSMP="SCCMpri02" CCMHTTPPORT="80" CCMHTTPSPORT="443" CCMHTTPSSTATE="0" CCMFIRSTCERT="0" So they should be reporting to site code PR2 yet they all point to site code PR1 yes, both primaries point to up a central site. mqh7

I checked the site code in the collection. In the collections each machine says Client=yes, Approved, Assigned=yes I looked at the ccmsetup.log on many of these machines and they all say this: MSI properties: INSTALL="ALL" SMSSITECODE="PR2" SMSSLP="SCCMpri02" FSP="SCCMpri02" SMSMP="SCCMpri02" CCMHTTPPORT="80" CCMHTTPSPORT="443" CCMHTTPSSTATE="0" CCMFIRSTCERT="0" So they should be reporting to site code PR2 yet they all point to site code PR1 yes, both primaries point to up a central site. mqh7

We have 2 Primary Sites. We confirmed that the command line on the Client Push Installation pointed to the correct Primary Site. Then, logging into Primary Site 1 we right clicked on about 50% of our collections and picked INSTALL CLIENT. Then, logging into Primary Site 2 we right clicked on the rest of our collections and picked INSTALL CLIENT. 95% of all machines have Primary Site 1 has their Site Code. how can that be? mqh7 Yes We would require more details on this issue so that we can help you out. Did you check the log files from the client side ? are they able to do manual discovery of appropriate site code? Anoop C Nair - Twitter @anoopmannur MY BLOG: http://anoopmannur.wordpress.com SCCM Professionals This posting is provided AS-IS with no warranties/guarantees and confers no rights. Have you checked the above points ?Anoop C Nair - Twitter @anoopmannur MY BLOG: http://anoopmannur.wordpress.com SCCM Professionals This posting is provided AS-IS with no warranties/guarantees and confers no rights.

you wrote: able to do manual discovery of appropriate site code? how/what do I check to confirm this? Which log files? Thank you. mqh7

you wrote: able to do manual discovery of appropriate site code? how/what do I check to confirm this? Which log files? Thank you. mqh7

From control panel configmgr applet try to manually put in the site code which is required as per your requirement and click on Discover button. You may monitor the locationservices.log file.Anoop C Nair - Twitter @anoopmannur MY BLOG: http://anoopmannur.wordpress.com SCCM Professionals This posting is provided AS-IS with no warranties/guarantees and confers no rights.

From control panel configmgr applet try to manually put in the site code which is required as per your requirement and click on Discover button. You may monitor the locationservices.log file.Anoop C Nair - Twitter @anoopmannur MY BLOG: http://anoopmannur.wordpress.com SCCM Professionals This posting is provided AS-IS with no warranties/guarantees and confers no rights.

I would, Check for overlapping boundaries and objects in the System Management container (as suggested by Torsten) Check the CCM.log files on both site to see if someone by mistake installed the client on the wrong computers (things like tha happen) Check the clientlocation and locationservices.log on the clients (just a few) and see why they picked up the wrong site code. Check the oundaries, are you using AD Site or IPsubnets? I would change them to Ip ranges instead. Kent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund

Check for overlapping boundaries and objects in the System Management container (as suggested by Torsten) I have asked our AD guy to check into this. Check the CCM.log files on both site to see if someone by mistake installed the client on the wrong computers (things like tha happen). The correct collections were targeted by the manual Client Push. Check the clientlocation and locationservices.log on the clients (just a few) and see why they picked up the wrong site code. I checked this files on a few machines and the only thing I've seen is this. Unknown task LSProxyMPModificationTask in non-quarantine - ignoring. LocationServices 8/27/2011 8:44:00 PM 2132 (0x0854) DhcpGetOriginalSubnetMask entry point not supported. LocationServices 8/27/2011 11:19:27 PM 1820 (0x071C) Check the oundaries, are you using AD Site or IPsubnets? I would change them to Ip ranges instead. We are using all AD Site Names and we have so many boundaries there is no turning back now. Thanks for the help!! mqh7

Check for overlapping boundaries and objects in the System Management container (as suggested by Torsten) I have asked our AD guy to check into this. Check the CCM.log files on both site to see if someone by mistake installed the client on the wrong computers (things like tha happen). The correct collections were targeted by the manual Client Push. Check the clientlocation and locationservices.log on the clients (just a few) and see why they picked up the wrong site code. I checked this files on a few machines and the only thing I've seen is this. Unknown task LSProxyMPModificationTask in non-quarantine - ignoring. LocationServices 8/27/2011 8:44:00 PM 2132 (0x0854) DhcpGetOriginalSubnetMask entry point not supported. LocationServices 8/27/2011 11:19:27 PM 1820 (0x071C) Check the oundaries, are you using AD Site or IPsubnets? I would change them to Ip ranges instead. We are using all AD Site Names and we have so many boundaries there is no turning back now. Thanks for the help!! mqh7 If I would have in your position then I would have enabled debug and verbose logon and check the log files (locationservices.log) to get more details on this issue http://blogs.msdn.com/b/gabeb/archive/2008/08/06/enabling-debug-and-verbose-logging-in-configmgr-2007.aspxAnoop C Nair - Twitter @anoopmannur MY BLOG: http://anoopmannur.wordpress.com SCCM Professionals This posting is provided AS-IS with no warranties/guarantees and confers no rights.

I have asked our AD guy to check into this. Yuck. First, relying on another group, particularily AD guys who rarely clean up stale accounts in AD let alone keep up with network changes is not normally a good thing. Second, there is a known mismatch in defintion of what an AD site is to AD and what it is in ConfigMgr: http://blogs.technet.com/b/configmgrteam/archive/2009/12/21/known-issue-supernets-in-active-directory-sites-used-as-site-boundaries.aspx. That blog post isn't entirely accurate, but it does reflect the mismatch in expected behavior. Swicth your boundaries to IP Address Ranges (not IP Subnets, those are even worse) and completely rule out the boundaries as an issue.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Thank you. We don't have any SuperNets in our environment. Does this article still apply? And yes, our AD has many stale records, thousands in fact :(mqh7

Overlapping is always an issue in the environments as Jason rightly said, If you are using AD site or IP subnet as SCCM boundary and it will be hard to control overlapping of boundaries. Here, we are talking aout the stale entries of old SMS sites in System Management Container. Are you sure do you have a lot? Anoop C Nair - Twitter @anoopmannur MY BLOG: http://anoopmannur.wordpress.com SCCM Professionals This posting is provided AS-IS with no warranties/guarantees and confers no rights.

Yes, we have a lot of stale machines. and I don't think it is over lapping boundaries since so many machines were effect. About 5,000 workstations were set to PRI1 when they should have been PRI2. About 175 AD Site Names can't all be wrong and over lapping. Still looking.....mqh7

More on this topic: I created 4 collections. Each collection had No Members. Under each collection I created about 20 sub-collections. Each of the sub-collection was based on AD Site Name. All the clients were assigned to the Wrong Primary Site after the client push, as discussed in this long thread. I deployed a Site Reassignment script to all 4 parent collections and I picked "include sub-collections" 3 of the parent collections and all of their sub-collections got the Advert and ran it. About 97% of the machines now point to the correct site. The 4th collection and all of its sub-collections got the Advert but it's only run on about 1% of the machines. Why? I don't know yet. but......we have BlueCat on our network and I know it has caused other issues; can it be screwing up SCCM too? Reassigning NetBIOS names to the wrong DNS? Do any of you know of BlueCat and what it does to your network? I've done all the Microsoft recommended things so I am not thinking it could be something else. mqh7

More on this topic. I RDC into some of the machines that are not assigned properly. I choose "Discover" and they go out and find the correct site!! So the client does see where it should point too. mqh7

So the problem may be/could be in your command line?Anoop C Nair - Twitter @anoopmannur MY BLOG: http://anoopmannur.wordpress.com SCCM Professionals This posting is provided AS-IS with no warranties/guarantees and confers no rights.

More on this topic. I RDC into some of the machines that are not assigned properly. What about the command line that was used to install the client then? What does ccmsetup.log tell? A ConfigMgr client does not change its site assignment automatically.Torsten Meringer | http://www.mssccmfaq.de