SCCM Experts: I'm newer to SCCM/SMS and am participating in a high-level design review of a proposed SCCM architecture. After reading the various documents available, I'm still a bit fuzzy on when one *should* be using primary sites versus secondary sites. Here is our rough layout: Office #1 - 2200 Clients Office #2 - 2000 Clients Office #3 - 3000 Clients Office #4 - 1000 Clients Office #5 to #10 - 20 Clients Each Our general philosophy will be have all the packages and collections managed from central location (i.e. there's no real need to configure packages / collections at the independent Office locations). The connections between those sites are all relativley speedy. Now the proposal on the table is basically to have 3 primary sites (one covers Office #1 and #2, one covers Office #3, and one covers Offices #4 through #20). One of the primaries would be designated the central site server. Distribution points would be available at each Office location. We will be using software metering, asset intelligence, imaging, software updates, and software distribution (pretty much all functionality). While this solution sounds feasible, would be the downside of using secondary sites instead of primary sites for the non-central sites? Any advice is appreciated.Bryan Berns

This solution is feasible. I will recommend you to do it. I will not recommend to have secondary sites. It's better to have the primary sites as they will have their own database. Go through this article :- Choose Between Primary Sites, Secondary Sites, and Branch Distribution Points http://technet.microsoft.com/en-us/library/bb693570.aspx Other Secondary Site Deployment Planning Considerations The following table lists additional pros and cons to consider when determining whether to install a primary or secondary site. Pro Con Secondary sites do not require additional Configuration Manager 2007 server licenses. Secondary sites do not require an additional SQL Server database at the secondary site. Clients can be managed across a slow network connection link, such as a wide area network (WAN) connection between sites, without the need to configure client agent settings. Secondary sites can have management points (called proxy management points) to help prevent client reporting information, such as inventory reports and status messages, from traversing slow network connections to the primary site. Remote sites can be managed centrally from a parent primary site without the need for an on-site administrator at the secondary site. Parent sites for secondary sites cannot be changed without uninstalling them and installing a new secondary site. Secondary sites cannot be upgraded to primary sites. To replace a secondary site with a primary site, you must uninstall the secondary site and install a primary site. Because Configuration Manager clients are always assigned to primary sites, client agent settings cannot be configured differently from the secondary site's parent site for clients located within the boundaries of secondary sites.

Thanks Ankur. I had read over that information before I posted, but I still had some open concerns. For instance, is a secondary site server that also carries the management point role cabable of servicing advertised programs should the intersite links go down? You reinforced the fact that the primary sites have seperate databases. If all data is untimately forwarded back to the central site, what does this really buy me? In my mind, an extra database is extra space, extra CPU, and extra liability.Bryan Berns

In a secondary site scenario. The management point role acts like a proxy. The clients located within the boundaries assigned to the secondary site will request policies from the proxy management point. When the proxy management point receives a client request for a policy, it requests any new policies from the default management point for the primary site that the client is assigned to and returns the policy body to the requesting client. To conserve network bandwidth, the policy body returned by the default management point is cached on the proxy management point and returned to other clients at the secondary site when the same policy version is requested. The intersite links will not go down. No administration can be done from a secondary site as it doesn't have any console and never install a console at the secondary site. I understand the fact that the primary site will require additional database and doesn't buy you a lot but it gives few other functionlity like you can have someone to administer a primary site in the other offices . If your central site goes down you can always make any primary site of yours as central by breaking the parent-child relationship and do the administration from there. It totally depends upon you. If you can afford the extra liablity of SQL server I'll recommend you to create primary sites otherwise you can go with 1 Primary and rest secondary site, the MP role will act like a proxy will do the trick for you.

Excellent information. As I mentioned, I'm doing a review on another's design so if both are functionally equivalent then the multiple primary design is fine. However, I do want to ensure that we pick the most maintainable setup that meets our requirements. Hopefully I'll get similiar feedback from the designer as you have provided. Thank you Ankur. Does anyone else have any opinion on the topic?Bryan Berns

Everyone designs things differently. I for one would recommend as few primary sites as possible. Go with secondary sites at the other locations. Unless you have political reasons, there is no reason to have multiple primary sites, you are just increasing your management overhead, along with have more SQL databases than necessary. Or if you need to have seperate client settings at those locatoins, then you would also need a primary. A DP can handle up to 4000 clients, So you could easily have a Secondary site with DP in the other locations and a primary/central in the main location. MCTS: ConfigMgr, MDT http://myitforum.com/cs2/blogs/cnackers/default.aspx

Thanks Chris. That's definately where my head is. We do have some "political reasons" not to use secondary sites if we live with the admins-all-over-the-place-doing-whatever-they-want culture, but we're hoping to use the SCCM migration to drive towards a consistent, common behavior. Does anyone else have any opinion on the topic?Bryan Berns

Everyone designs things differently. I for one would recommend as few primary sites as possible. Go with secondary sites at the other locations. Unless you have political reasons, there is no reason to have multiple primary sites, you are just increasing your management overhead, along with have more SQL databases than necessary. Or if you need to have seperate client settings at those locatoins, then you would also need a primary. A DP can handle up to 4000 clients, So you could easily have a Secondary site with DP in the other locations and a primary/central in the main location. MCTS: ConfigMgr, MDT http://myitforum.com/cs2/blogs/cnackers/default.aspx What would you suggest if you lost your primary SCCM server? I presume the secondary sites are not managable? no software deployment etc...

What would you suggest if you lost your primary SCCM server? I presume the secondary sites are not managable? no software deployment etc... Just restore it from backup.Torsten Meringer | http://www.mssccmfaq.de

Restore from backup is the only real built-in path as Torsten pointed out. I'm assuming you're asking because you have some sort of expectation from your management or an SLA. If so, there are other options including a hypervior cluster hosting the primary site server or boot from SAN. Neither of these is a supported Microsoft solution but both work. Both up the costs quite a bit though so it really depends on why you want your "fault-tolerance" and what's it worth to you.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys