SCCM: When to use a Secondary Site
SCCM 2012 allows administrators to create a secondary site. A secondary site differs from a child site in that users and devices in the secondary site appear in the SCCM console just like any other device. A child site is almost a totally separate site and can have a totally separate structure. A secondary site is mainly intended to be used when you have a slow WAN link between physical locations. If you have a reliable, fast link, then a secondary site is unnecessary. Official Microsoft documentation indicates this fact.
Components
A secondary site contains, at the very least, a management point and a distribution point. The management point must be backed up with a SQL database. Because this database does not hold much information, SQL Express can be used, and SCCM will even install it for you if it doesn’t detect a SQL instance. This SQL database is the advantage to a secondary site. SCCM replicates part of its database to this secondary site. This allows the secondary site to cache its client data and only send it over the WAN at certain times. This is why it is beneficial for slow WAN links. Administrators can also decide when content is sent to the distribution point. This is important for the same reasons – administrators do not want their entire pipe taken up during business hours.
With a secondary site, administrators can also specify which management point a client will connect too. This is important so that devices at the remote location do not try and contact the MP at the main location and vice versa. This is done on the boundary group. After you create a new group, you will be able to change the assigned site by opening the properties of the group and selecting the “References” tab.
Simply change the “Assigned site” to your child site. It’s also important to only have the site system for the secondary site listed below this under “Site system servers”.
Be sure to change the connection to “Slow”. Now, when a device joins the boundary group of the secondary site, it will get a new site assignment, thus limiting its traffic to that site.
Limitations
There are a few limitations to secondary sites. First, secondary sites only work if the servers are in the same domain, or your two domains have a two-way trust. This is not always viable, so it should be considered. Only the site server has to be in the same domain, not the clients. The clients will function just any other clients that are not on your domain. If the secondary site server is not in the same domain or does not have a two-way trust, a secondary site will not work. I even tried a PowerShell trick to add the primary site server account as an admin on my secondary site server, but to no avail. If you cannot get it in the same domain, you will have to find another solution, such as a child site, or another primary site.
The SQL server component can also be seen as a limitation, due to the resources it consumes. It’s good because it holds the client data for you, but you must budget enough resources on a box to hold the SQL server. The sizing is not quite as much as a primary site server, but it is still relative to the number of devices that connect to secondary site.
Summary
In short, secondary sites are designed to be used if you have slow WAN links. If you have fast, reliable links, the solution is to just stick a distribution point in all of your physical sites. You will have management point traffic going over the WAN, but that’s nothing compared to distribution point traffic.
