We are in the process of standing up a second SCCM 2007 SP2/R3 hierarchy (the new hierarchy will manage servers; the existing hierarchy manages workstations) in the same AD domain. I know the best solution is to share a single SCCM hierarchy – but for various reasons, this is not an option in our situation. From reading through all of the forum discussions on this topic, it is clear that overlapping site boundaries is the primary concern with having multiple SCCM hierarchies. We are planning to use a combination of IP subnets and IP ranges (only where neccessary) to mitigate the risk of overlapping boundaries. This leads into a couple questions: 1. To further mitigate (or prevent altogether) the risk of overlapping site boundaries, we are also considering the option of NOT publishing the new SCCM hierarchy to Active Directory. The PRO is that it would seem to prevent this site boundary overlap problem altogether. The CON is that we lose the benefits of publishing to Active Directory as explained in this article (http://technet.microsoft.com/en-us/library/bb694066.aspx). However, most of these benefits have workarounds. There are no workarounds for NAP and global roaming, but these features are not applicable to this new server SCCM hierarchy. I’m interested in others opinions – would this be an acceptable solution to mitigating the risk of overlapping site boundaries? Or maybe extra headaches? Will future releases of SCCM be even more AD integrated? 2. Another possible mitigation is to install the SCCM clients with explicitly defined site codes and management points, instead of using the auto assignment (i.e., SMSSITECODE=AUTO). This way the clients are assigned the correct site code/MP instead of having the client query AD to determine its site code/MP. I’m wondering – once a client has acquired a site code/MP, can these clients still run into problems if there are overlapping site boundaries? I know SCCM still checks the boundaries in AD (when publishing is enabled) to acquire package content, but once a client has an assigned site code, I’m guessing SCCM is smart enough to only query boundaries associated with the site code of the client (and thus avoiding the whole overlapping site boundary issue). The one possible exception I can think of is in a roaming SCCM client scenario (i.e., client determines what site it has roamed into by using its IP address to find the AD site). However, if a client gets routed to the incorrect distribution point because of overlapping boundaries, I’m thinking this will not be a problem – according to Microsoft, “if the package source files are not available in the site the client has roamed into, the client falls back to asking its default management point for distribution points.”

Option #1 is your best choice. Although... personally, NOT having two hierarchies is really the best, perfect choice. We have 1 hierarchy, several hundred thousand computers, 1 admin console for everyone: workstations and servers. It can be done. I'm guessing that the "various reasons" are simply political, the server team doesn't believe that workstations and servers can be managed from 1 hierarchy without security concerns of "workstation people" having rights to do things to "servers" and vice versa. It can be done, with judicious configuration of Collections (instance rights, not class rights), and a few status filter rules to automatically apply the correct instance rights to new objects when created by (for example) the team that manages just "marketing servers", their instance rights are copied when they make a new object in the console. If you think you can re-address the concerns and get everyone to play together under 1 hierarchy, feel free to contact me at mofmaster [at] myitforum dt com . Yes, it does take some work on your part to configure everything, setup the rules, and (here's the hard part) get your existing workstation console users to accept that they won't have 100% rights to all collections in the future. It'll annoy them simply because you're taking away something. But... it'll mean less hardware, and 1 completely unnecessary hierarchy. In the long run it'll be worth it.Standardize. Simplify. Automate.