Primary site with secondary site

This scenario goes a step further. With a secondary site, we tell the clients in satellite offices/branches to report to the secondary site instead of the primary one. The reason we want a secondary site is that our primary site has very bad wide area network (WAN) connections with branches; additionally, during the day, we prefer not to fill this link with ConfigMgr traffic.

Imagine a situation where we have New York, which is our primary site, and Philadelphia, where we have an office with approximately 5,000 computers, and we have a really slow WAN link between these two offices (which may be considered any link slower than 10 MB) in addition to some latency issues. Having computers reported to New York might be a real bottleneck, not just for workstation to ConfigMgr communications, but it will surely impact applications that try to send data over this WAN link, so it may have serious repercussions for your business. Secondary sites come into play when one of the following factors is important:

• Traffic compression between sites
• Scheduling time for data exchange between the primary and secondary site

Usually, you won't need a secondary site; as I mentioned, even in global enterprise deployments, people often choose to have one primary site with distribution points in satellite offices: