In this article I'd like to share information gleaned from a quarters worth of support incidents as regards Configuration Manager 2007 Client Site Assignment. The goal is for this article to help by providing details on common problems driving calls to support.

It is worth noting here many of these details will assist in Client Installation failures as well even though that is a topic for another day. It is also worth noting that many of the problems perceived to be Client Installation failures are in fact successfully installed clients which are unable to assign to a site. In the Admin console when the property Client = No, you may have a successfully installed client that like E.T. cannot phone home. Actually, unlike E.T. it does not yet know where Home is...

The online TechNet library for Configuration Manager has a wealth of data covering site assignment and related subjects so please check out the relevant links at need.

Before beginning, ensure your familiar with the topic: About Client Site Assignment in Configuration Manager http://technet.microsoft.com/en-us/library/bb681005.aspx.

The common theme here is that clients are not always on the subnets we expect, or have defined. It's easy to target an installation to a resource which is not assigned to the current site and the expectation may be that it will find its local site and join. It is also common for clients to be beyond any sites defined boundaries resulting in site assignment failure.

1. Simple omissions. Failure to define a subnet is one of the most common call triggers. This can include: a simple oversight when defining subnets, clients appearing on previously unknown subnets, or can be due to network reconfigurations having occurred. This also applies to IP Ranges. Find more here: Choose Configuration Manager Boundaries

2. Active Directory omissions. Beware the AD Site which at the time does not contain the expected subnet. Validate that the AD Site used by Configuration Manager defines all the expected subnets. It is also wise to validate that the AD Site name was not entered incorrectly. The fat fingered AD Site name is not an unseen beast and is not validated against AD when entered.

3. Omissions of a VPN Scope. When clients connect through a VPN and have an IP address from that VPN's scope, it is important that the scope be defined in the expected sites defined boundaries. Too often it is not. Find more here: Example Roaming Scenarios for Configuration Manager: Complex

4. Overlapping Boundaries. These come in two flavors worth noting:

a) Doubling Up: When multiple sites publish to Active Directory or a removed (deleted) site has orphaned its data in Active Directory, the potential for a conflict exists. Please review the contents in Active Directory for such conflicts removing orphaned site data and resolving active overlap configurations. Find more here: How to Verify Site Information is Published to Active Directory Domain Services

b) Piling On, or Hidden Overlaps: Active Directory sites may be leveraged by one Configuration Manager site while an IP subnet which is in that AD Site has been defined to a different Configuration Manager site. Here the conflict is not as obvious but the potential problem is worth keeping in mind. The client will find it belongs to both; one site by IP and the next by AD Site membership.

More on Boundary Validation: A tool which may help investigate suspected boundary issues is the SMSBoundaries tool by Russ Slaten which you can find here: http://blogs.msdn.com/rslaten/archive/2007/03/20/finding-overlapping-boundaries-in-sms-smsboundaries-v1-42.aspx.

With boundaries well defined and covering existing subnets, it is still not uncommon for a sites data to not have been published to AD:

1. Publishing to Active Directory. A common driver is a sites failure to publish data to Active Directory when the Clients are expected to leverage that data. Ensure relevant sites are enabled for publication, and that the site also has permissions to update Active Directory. This will require granting of the required permissions. Find more here: How to Publish Configuration Manager Site Information to Active Directory Domain Services.

2. Active Directory. Assuming data is published successfully, ensure Active Directory is able to replicate data correctly. While uncommon such a situation usually is resolved before Configuration Manager site assignment failures leads to its discovery.

When all the other ducks are lined up remain aware that sometimes clients just can't get where they need to go and locate the servers they expect to locate.

1. Name Resolution. Common for Workgroup systems lacking WINS, name resolution failures can block a client from completing site assignment. While this is uncommon, it usually takes access to a problem client to pin down as such issues can be local to a given subnet or location and not easily identified.

A Note on Site Code Changes:

It’s often overlooked but the Configuration Manager 2007 client is not designed to change site codes based upon location. If the client was previously assigned to one site, it takes a dedicated act to reassign that client - and this is often overlooked prior to a support call. Find more here: How to Assign Configuration Manager Clients to a Site.

The following are links you may find of use when approaching site assignment issues and strategies:

· Configuration Manager Site Assignment Data Flow: http://technet.microsoft.com/en-us/library/bb932178.aspx

· You can find more about the SLP role for Native Mode Clients in this posting from Carol Bailey: http://blogs.technet.com/configmgrteam/archive/2009/01/21/clarifying-native-mode-clients-and-the-server-locator-point-slp.aspx

Note: This information was originally contributed by Brent Dunsire on the Configuration Manager Support Team blog.