I have an SCCM hierarchy with one Primary site and 9 secondary sites. One of those secondary sites has its own IT department and they want to start handling their own software/OS deployments. I can either replace their secondary site with a primary site that will be a child of the existing primary site, or I can cut them loose an let them create their own heirarchy.What is the best practice? I recall reading somewhere that we could run into boundary issues and/or problems with traveling users if we have two separate hierarchies.

This is an "it depends" type of scenario. It all depends on how you guys handle your software packaging and OS deployments. Is there a master image and packaging standard where the packages are all checked into the central site? If so, having a separate hierarchy would mean that these apps and OS images would have to be checked in twice, once to the main hierarchy, and again for the other one. From a technical management point of view, having separate hierarchies sucks because you have to do duplicate work. You won't have boundary issues since you can always just specify the boundaries, just don't put the same boundary within both hierarchies, then you'll have boundary issues. If these guys are making their own packages, OS images, and want to manage when the pushes go, then they probably should have their own primary under your central site. This will allow them to use your centrally checked in software as well as utilize their custom software as well. The other option is to give them access to the console on the central site and let them do their work from there.

You definitely do not want them to create their own hierarchy. Doing so could mean that in the future, if not immediately, both of you could define overlapping boundaries, and your two hierarchies will start stepping on each other. Definitely don't go there!If it were me, I would not make a child primary but would setup security on the Central site (it's a big pain, but it can be done) to lock those lower-level admins down to only those areas of the console to which you want to give them access, as a bare minimum, at least revoke CLASS rights to site settings (class read only might be fine, and there's another class right to site settings that OSD users need, so check technet for OSD & Security, I don't have it memorized...) so they don't inadvertently change site-wide settings on you.I wouldn't setup a separate Primary site, that's extra licensing (SQL and ConfigMgr) and isn't really necessary. However, that is just my opinion. There are of course several technical and political reasons for many companies where a separate Primary (as a Child Primary) would make the most sense for that particular company. For example, if the other group was in a different country, and needs to use different languages, that might be a reason; or that other group is so far far far away (network connectivity wise) that you can only "allow" traffic between your central and their child primary a few hours at night.Standardize. Simplify. Automate.