Hi there. I am curious whether or not it is possible to force CCM clients to reevaluate the site they are assigned to. The consultants who initially set up my SCCM architecture had clients at secondary sites assigned to their secondary sites and also had the administration console installed on secondary sites. I have finally got the architecture sorted out and at this point I just need to figure out how to properly assign all the clients. Almost all clients have been properly installed as I have configured Client Push and extended the AD DS schema. While the 350+ clients are installed, only 250 have assignment status. I believe this is because they are still assigned to the secondary site codes but am not 100% positive. I cannot find any reports that would tell me why these 100 clients do not have assignment status. Some more information: Currently I am using the following installation properties for the Client Push installation: CCMLOGLEVEL=0 DISABLESITEOPT=TRUE DISABLECACHEOPT=TRUE I also have the Software Update Point Client Installation option configured via the SCCM software update infrastructure. The GPO for Windows Components/Windows Update has the following settings: Allow Automatic Updates immediate installation: Enabled Allow signed content from intranet Microsoft update service location: Enabled Specify intranet Microsoft update service location: Enabled (Both the update service and statistics server are the primary site server which is running a software update point) Thank you for your assistance! Shane

Are you getting your site assignment numbers from the console? Site assignment can be manually forced but is initially based upon the configured boundaries. What boundaries are in place? Have you compared these boundaries to the clients not assigned?Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys

Clients will not assign to secondary sites. If you see them assigned to secondary sites in the SCCM console it's probably because they are not assigned or installed at all. I hope you removed the console from those secondary sites, that's unsupported and it will break future SP installs. I would start looking at those clients one-by-one until you find something in common preventing them from assigning to the primary site. I assume you've checked the obvious but most likely it's a boundary issue. I hope those consultants don't ask you for a reference later ;-) John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

Jason: I am getting installation and assignment information from the following reports: Client Deployment Status Details (which states that there are 337 successfully installed computers) Client Assignment Status Details (which states that there are 337 deployed clients and 238 total computers with assignment status There are three boundaries in place. One for the primary site and one for each of the two secondary sites. Those boundaries are tied to AD DS sites and are configured properly via IP boundaries. There is no way for the clients who are not assigned to be outside of those boundaries and still function on our network. There is also an issue in that there doesn't appear to be a report for me to get a list of clients with the client but without assignment status and I do not know enough about the reporting feature to make one. I typically get lists of clients deployed and lists of assigned clients and cross-reference them by hand to sort out which ones are having issues.

John: If they cannot be assigned to a site that doesn't exist then I am confused about the discrepancy between deployed and assigned clients. I would assume in this case that it is because they are not assigned, but I am confused as to how that could be. I have verified that the AD DS schema extensions are properly being populated by the MPs at the very least. I did remove the consoles from the secondary sites as soon as I heard about the issue. I had to reinstall the sites to do that, however. I then updated them to the latest SP and attempted to install R2, which claims to have succeeded. However I do not see a "Yes" in the R2 field of the secondary site properties for either site. That is a separate issue which I have not begun to investigate as it should not have a bearing on the present problem. I suppose I will have to start looking at the clients individually unless something obvious comes up here. Like I said before, many of the clients were installed before I properly configured client deployment and the client installer used attempted to assign them to the secondary site codes. I am not sure if that is an issue in this case since I do not know which clients were installed that way or if they have switched to the proper site. As I said in the other reply, I have checked the boundaries several times after reviewing the documentation regarding assignment and have come up short. The systems which are having the problem seem to be random. Is there a report I can use to get a list of system with the client deployed that do not have an assignment status? That would make this much easier.

Also, a bit more information: If I use the "All Systems" portion in the console and get a list of systems with "Yes" in the Client field I get 274 systems. Every single one of those systems also has a "Yes" in the Assigned field and they are all properly assigned to the primary site. If I search for "Yes" in the Assigned field of "All Systems" I get a list of 387 of 390 systems and the ones without clients appear to be temporarily assigned to the site within which they are located. I read in another post that this is because the "Site Code" field pulls double duty in that it represents the site within which the management point it will report to is located when the client has not been installed. This means that all the systems are being properly squared away with their proper MPs. However, the discrepancy between client deployment numbers (337) and systems with "Yes" in the Client field (274) as well as with the numbers from "Total Computers with Assignment Status" (238) implies to me that some clients are installed but not properly reporting to their MPs. My initial suspicion was that they are set to report to a secondary site code, which is why I asked about forcing site assignment initially. But I am not sure if this is the case as I am not all that proficient with ConfigMgr yet.

WOW... that's a lot of info and I'm too lazy to read it all. :-) It is possible that the clients wouldn't understand the boundary as defined by the AD site if the subnet mask in the ad site doesn't match what's on the client. That confuses SCCM. How about you zip all the logs from one of the client and email it to me, I'll look it over and email you back. Once we figure out that client issue (which should be easy) we can look into whay you aren't seeing R2 for those sites. Actually maybe the two are tied to one another somehow? Have you confirmed that the MP is working on the secondary site and there's no comunication issue between the secondary and primary sites? Use MPList and MPCert or the MP Troubleshooter from the SCCM v2 toolkit to check your MP's Don't worry about forcing site assignment it will fix itself when we are done. Email those logs to john marcum at gmail dot com (no spaces or characters or anything in there) John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

That bit about subnet masks is interesting. I use a blanket subnet mask to collect all the smaller subnets at each site (/16 to collect /24s and /23s) so that may very well be a factor. I will make some changes tonight and see if that has any effect on assignment tomorrow. If it doesn't then I will work on collecting some logs for you. Thanks!

Change your boundaries for one of those seondary sites to use an IP range. I bet that fixes it. John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

I don't agree with the terminology that MS uses in the docs to describe this but here's the offical statement. They use the term "supernets" which is technically not accurate. Basically SCCM uses anding to find the network based off the IP and mask assigned to the client. If that doesn't match the boudnary then it's no good. http://technet.microsoft.com/en-us/library/bb632910.aspx "Do not use Active Directory site names if these contain supernets because Configuration Manager does not support supernets for boundary configuration." John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

At this point it doesn't appear that the boundary changes have had any effect so I suppose I will have to start scrounging through client logs.

Although this could have been because all the component threads on my primary site were stopped for some reason. I restarted the server and now we'll give it some time to see what happened.

Alright, I've finally got some new information on this one. Sorry for the long delay. After a bunch of forum hunting and tracking down issues I believe I have found the problem. It appears that the primary site is not properly publishing the boundaries for one of my secondary sites. Primary site is PGP, secondary site is SAC. Searching through PGP's hman.log file I found absolutely no reference to SMS-SAC anywhere in the logs, whereas the other secondary site (COR) has numerous entries, found with SMS-COR. In AD under the Systems Management object I have the following objects for SAC: mSSMSManagementPoint and mSMSSite. For the other two sites, I have the ManagementPoint, the Site, and the RoamingBoundaryRanges that fit those sites. It would appear that while the secondary site SAC is publishing its own Site and ManagementPoint entries, the primary site is failing to publish its RoamingBoundaryRanges. Before I discovered this information, I discovered that there were issues with SAC's MP and reinstalled it because the MP was not functioning properly (http://SACMP/SMS_MP/.sms_aut?MPLIST was returning a 404). Any ideas on what I should do to get the primary site to publish this sites boundaries in AD or do I need to reinstall the secondary site? Thanks, Shane

Those are only published for ranges I think not AD sites so it depends on your boudaries. I "think" you can see all types in adsitedit though. If you are using the same type boundaries for both sites you could try removing them and adding them back to see what happens. John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

Yeah, they should only be published for ranges. I converted all my boundaries to ranges on your recommendation, including the ones for the SAC site. From what I can tell, the primary site is what publishes the RoamingBoundaryRanges items and it is not publishing them for the SAC secondary site, only the COR secondary site. Unless I can find a way to determine whether or not there are issues with the SAC secondary site communicating with the primary site then I will probably reinstall the secondary site and see if that solves the issue. I am currently using AD Users & Computers in Advanced Features mode. I can still see the items under [domain]>System>System Management.

I think you can see the other ones if you use ADSIEdit. John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

The view in ADSIEdit and AD Users & Computers with Advanced Features on is the same. I am getting RoamingBoundaryRanges for two of my three sites. The third, which is supposed to have published boundaries, does not have any published records in AD. Edit: I take that back, it has some published records such as an mSSMSSite record and an mSSMSManagementPoint record but it lacks the mSSMSRoamingBoundaryRange records that the other two sites have. As I said, in the hman.log file on the primary site I see entries about publishing COR and PGP's boundaries but none for SAC. If I change/recreate COR and PGP's boundaries, these changes are published in the hman.log. If I change SAC's, the changes are not published and there is no log entry.

I reinstalled the MP at the secondary site in question, still experiencing the same problems. According to sender.log, the PGP site server is able to write to the SAC site server's shares without issue. In the hman.log on the primary site server (PGP) there are many entries which state: "Sent the proposed site control images to XXX" where XXX is a secondary site. Both COR and SAC appear to show up equally. There are no errors. When the boundaries for COR are changed, there is log activity and the boundaries in AD are updated. When the boundaries for SAC are changed, there is no activity and nothing is updated. What else should I be checking here?

So it wrote the MP object to the System Management container but it won't write the boudaries there? That's really strange. I'd think permissions but that can't be the case if it wrote some objects there. I assume you have given the secondary site full permission to the System Management container and all child objects? I'd try removing everything from the System Management container to make sure it writes back some objects for that site. If it does then I am at a total loss. Sorry. John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

Yep, that's exactly what is happening. All three site servers have full permissions to the System Management container and all child objects. I just deleted all the information in the System Management container and we'll see what happens. From what I was able to tell by looking at the logs, the secondary sites publish their own MP objects in the container however the primary site above them publishes their boundaries. For example, when I changed a COR boundary, the primary site PGP updated the boundary information for that site. The thing is, the primary site doesn't seem to care if I change SAC's boundaries. It shows them in the console but it doesn't actually update them in System Management. Either way I'll get back here in about an hour with the results of cleaning out the System Management container. Thanks for all your help John. Any idea where I should look next for fixing it, or should I just try reinstalling the entire site and seeing if that works?

I don't think reinstalling the site will help. Try adding a second boundary for the secondary, even a bogus one, just to see if that gets published. How are you making the boundary? I assume you are opening the console at the primary site, navigating to the secondary site in the console, boundaries, right click, new boundary. Is that correct? That's how I do it and it works fine. I do 4 or 5 a week. John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

Yep, that's how I do it. Everything showed back up in the System Management folder except for the SAC boundaries. I have removed/recreated the boundaries several times. I will attempt to create one I have not used before. Will report back in a bit.