Today I will discuss scenarios under which you might require multiple primary sites.
As a thumb rule use a stand-alone primary site to support management of all of your systems and users. This topology is also successful when your company’s different geographic locations can be successfully served by a single primary site. To help manage network traffic, you can use multiple management and distribution points across your infrastructure to optimize network traffic.
A stand-alone primary site supports:
- 175,000 total clients and devices, not to exceed:
- 150,000 desktops (computers that run Windows, Linux, and UNIX)
- 25,000 devices that run Mac and Windows CE 7.0
For mobile device management:
- 50,000 devices by using on-premises MDM
- 150,000 cloud-based devices
For example, a stand-alone primary site that supports 150,000 desktops and 10,000 Mac or Windows CE 7.0 can support only an additional 15,000 devices. Those devices can be either cloud-based or managed by using on-premises MDM.
For more information on sizing check https://docs.microsoft.com/en-us/sccm/core/plan-design/configs/size-and-scale-numbers
Now let’s get into scenarios of considering more than 1 Primary sites
- Load balancing across two Primary Sites
This scenario comes into play when you will have a Central Administration Site (CAS), and 2 or more Primary Sites with the thought of splitting the clients across multiple primary sites, in this scenarios if you lose one Primary site, you could still support half of your environment until the other Primary is recovered.
Below are pros and cons of this design:
- If you lose the CAS or One Primary, then at least one Primary is still functional, as are its Secondary Sites until the CAS or other Primary is brought back online.
The deciding factor for this is if you have a tight SLA in bringing up SCCM sites then this is your best bet.
Typically, it takes around 3 hours to bring back SCCM sites if you have SCCM DB as SCCM site backup available.
- Removes the Single Point of Failure scenario from the design, as clients assigned to other primaries would still be able to report in and be managed.
If need be, you can also manually switch clients to report to the available primary sites and continue to manage them
- Increased Licensing costs
- Increased hardware costs
- Increased SQL Replication
- Change latency across the Infrastructure as well as Locking due to replication latency
- Redundancy and High Availability
The data from Primary Sites and the CAS replicates among sites in the hierarchy. The CAS also provides centralized Administration and reporting.
Note that automatic Client Re-assignment does not occur when a Primary Site fails.
The result of a Primary Site failure is that the Primary Site and its Secondary sites communication are now broken, and the Secondary Sites cannot be re-parented. This coupled with the fact that the Client cannot be easily re-assigned in the time it would take to recover the failed Primary Site means there is really not a valid reason to do this unless the time it will take you to recover the Primary site, is greater than the time it would take to reassign and reinstall all of the Secondary sites the failed primary had.
However, this becomes valid when the scenario of Natural Disaster or War Type precautions for redundancy are being considered where the other location won’t be coming back online for quite some time.
- Geographic Boundaries
In some scenarios, companies across different countries require that each continent or country can share data, but that they also must be able to still support their country or continents clients must still be manageable. In this case, which is a business case for continuity; it would be feasible to have more than one Primary Site. Making the choice to use another Primary site in this case should be based on connectivity and client count because just using a Secondary site or remote Distribution point should be good enough for Geographic separation.
- Political or just that your clients want it
In some scenarios, your client you want multiple primary sites and segregate clients between them just because they are being managed by different departments or heads.
There can also be situations where they want to segregate data clients between and do not want everybody in the organization to have to access to all information.
Practically this cannot be a good reason to have multiple primary sites as SCCM user roles permissions can take care of it. And CAS by default will have access to all the information across primary sites.
However, there are situations that I have come across where this is required for client satisfaction.