Hi, I'm currently planning an SCCM hierarchy. We have in our company several small remote locations, each having between 50 to 70 users. These remote locations have some administrative autonomy. For instance, they decide when and to whom they want to advertise Software and re-image machines. I also don't want them to be able to manage clients at other remote locations. My question is: Do I create Secondary sites for these locations in order to give them this administrative autonomy? Or should I create Primary sites? Or may be I can achieve this administrative autonomy by assigning all the clients in these remote locations to the primary site and simply setting the right permissions on the different SCCM classes? Thank you,

I would not install a primary site in each of of those locations. Depending on how you want to control Application deployment, you can grant them permissions to add users/computers to predefined application groups in Active Directory. that whay, the local admin do not need configmgr. console permissions and you can deploy secondary site in the remote locations instead of primary sites.Kent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund

Hi, As Kent said you can use secondary site. But as you don't want them to be able to manage clients at other remote locations then you can install Admin console for them on machine from where they can add the user to collection to advertise Software and re-image machines (Make sure that you only give them rights to Add machines to those collection which you want them to mange. And to overcome the bandwidth issue you can install branch DP on 2 machines for those remote location as you have a very few machines in the remote locations. Pelase let me know if my information is incorrect related to you remote location scenario. Cheers!!!!!!!!!!

As Kent said you can use secondary site [...] then you can install Admin console for them on machine Admin consoles on secondaries are not supported if I am not mistaken.Torsten Meringer | http://www.mssccmfaq.de

Hi Kent, i really apologies for the confusion. I was trying to say that we can install the Admin console for the Central server on any other OS platform example Vista or XP machine.

Probably the easiest (and least expensive) way to do this would be a single SCCM Primary Site and then put a server on the inside of each of those remote sites to make as a Distribution point. The reason for this is relatively simple: if you have 50-70 clients and 3 remote sites and you get a Windows patch that all applies to them, you essentially have n * r * s. Just for arguments sake, the's take the following cases: n = Number of Clients per Remote Site r = Number of Remote Sites s = Size of Patch 20MB patch = (50-70) * 3 * 20 = 3GB-4.2GB 100MB patch = "" = 15GB-21GB So, theoretically, your remote site clients could be using large portions of bandwidth for patching to come across their WAN links to pull patches from your central site. However, if you have Distribution Points behind each one of those WAN links, you could create separate Packages/Advertisements for each of those sites which ONLY target Collections of computers specific to that site. What you'll effectively change is each patch gets pushed once to the distribution point and then all of those remote site clients will only pull data from that local Distribution point. This could drastically reduce your patching traffic. As far as permissions go, you need to be careful with this and truly understand how SCCM permissions work. As someone already stated, in the scenario above, you could create Security Groups for each remote site and give grant administrative control inside of SCCM for each group but where I'd like to caution you is with Collections. Because there is no understood hierarchy with SCCM Collections like there is for Active Directory OUs, even if you were to create separate Collections for each remote site, if you give them the ability to CREATE Collection objects, they can effectively create a collection under the collection they have rights to which could "recreate" an All Systems type collection and create packages/advertisemens that target them. You have two options in this instance: 1) Give them Collection CREATE rights and hope they don't figure this out OR educate them on the vulnerability and instruct them not to abuse it. 2) Do not give them Collection creation rights but then if they have a requirement to create collections, your central SCCM Administrators will need to create collections for these remote sites on demand.

1 single Primary Site. scope out collection rights, and use a status filter rule to copy the rights, so that only location A has rights to location A's collections: http://mnscug.org/home.html?start=10 That example is more for how to setup Software Updates, but the status filter rule script for collection inheritance is what you'd want.Standardize. Simplify. Automate.