次の方法で共有

SMS Boundary Issues in Shared Subnet Scenarios

  • [アーティクル]

So in speaking with many of my University customers, I have found that many of them are in a complicated situation when it comes to trying to implement SMS due to overlapping IP/AD Site boundary constraints.  In certain situations, these folks would like to implement SMS for their departmental servers and workstations while not affecting other departments' resources or ability to implement their own independent SMS site.  The problem is that many times these separate departments share the same set of IP subnets, DHCP Scopes, and AD sites, and AD forest making this difficult as we all know that two SMS sites within the same security boundary (same forest/trusted set of domains) that designate the same IP subnet or AD site in their SMS site boundaries is a BIG no-no and will lead to SMS clients getting confused and talking to the wrong MP intermittently. 

In working with a few of my Universities, I have come to the conclusion that there are three general options that can be utilized to get around this seemingly large show-stopper to SMS implementation.  I have listed these options as 'BEST', 'BETTER', and 'OK'.

Option 1 (BEST): Centralize all departments to one central site. This is what I always recommend and push for (assuming a flat network).  The hard part is working through some of the security delegation limitations with SMS but many times compromises can be made.  I also promote that this is the least redundant hierarchy as it would save the organization as a whole from having to buy and support redundant site servers, MP’s, DP’s, etc. 

This is the best possible option and the way in which SMS design was intended.  One should strive to only split into multiple sites when it comes to bandwidth issues if at all possible.  However, this may not be possible depending on the organizational dynamic of the University.

Option 2 (BETTER): Build an SMS site hierarchy with one central site (think 'empty root') and child primary sites that represent each department. Make the central site a parent of all departmental sites. If we can make the following assumptions:

      • All SMS sites participate in one SMS site hierarchy (i.e. no independent central sites)
      • All Advanced clients
      • SMS is AD integrated (schema is extended)
      • All clients belong to the same forest that SMS is installed
      • All IP subnets are included in the boundary assignments of the SMS sites in the hierarchy WITH NO OVERLAP
      • Advanced clients are not installed to ‘auto’ discover their site but instead statically assigned to the proper departmental site upon installation

Option 2 is nice as it allows for a central IT organization to control the 'empty root' which can then consolidate and manage software packages and distributions for those packages that are the same for everyone (Office, base OS packages if using OSD, etc.) cutting down redundant effort on the part of the admins across the organization while allowing the departmental IT staff to have complete autonomy over their own SMS site. You also do have some residual roaming capabilities so that if a package is available in a site that is closer to the client at the time, they will make use of the available DP's at this site. Another advantage is being able to consolidate much of the reporting to the central site across the organization. The downside is that this design is probably a bit redundant as there will be multiple and redundant SMS sites and site systems on the same flat network. This means more hardware and more traffic produced versus a 1 Central site design as in Option 1. Keep in mind that you must ensure and work together so that no IP boundaries are the same across any of the sites in the hierarchy.

 

Option 3 (OK): Build SMS sites as needed but do NOT designate ANY site or roaming boundaries AT ALL in ANY of the SMS sites in the AD forest.  Yes, it is possible to have a completely functional SMS site with absolutely NO AD site, IP subnet, or IP subnet range boundaries and still service clients.  The catch is that you must ensure that you statically assign the proper SMS site assignment either upon installation time (i.e. use the SMSSITECODE= switch when installing the agent) or manually assign the client to the proper site by going to the Systems Management applet in the Control Panel or via programmatic means (there are a few add-ons I have seen on www.myitforum.com and elsewhere that allow you to change the site code designation via the console).  The major drawback here is that you lose all roaming capabilities – no matter where the client might be on the network, it will always go back to only the DP’s and MP designated to its site as there is no hierarchical relationship between its site and any others that might be on the network.  And since there is not parent-child relationship, you will not be able to centrally report or push software as you could in Option 2.

Overall, there are variations between Option 2 and Option 3 that can be employed as well.  The rules of thumb to keep in mind in all of this are the following:

 

- NEVER overlap boundaries under ANY circumstances

- The above applies only to Advanced Client support – no legacy!

- SMS Admins will need to keep in mind that they may have to statically define site assignments upon installation in order to get clients to report to and be managed by the proper SMS site.

 

For more general information on SMS boundaries and Advanced Client Roaming, please read the white paper found here:  https://www.microsoft.com/downloads/details.aspx?FamilyID=37ac2246-453a-4418-b026-f7140a6fce3c&DisplayLang=en.

 

That is all for now!

Comments

  • Anonymous
    January 01, 2003
    Hi This setup seems very intersting, agree that option 1 is the best. Have you tried option 2 in a sccm enviroment ? could you explain this a bit more: All IP subnets are included in the boundary assignments of the SMS sites in the hierarchy WITH NO OVERLAP = Do you mean that all bounderies are maintained at the central site only Br erik