Secondary Site vs Distribution Point vs Management Point

It’s the million dollar question for all companies who are lucky (or lucky) enough to potentially have a need for a secondary site, do I need a secondary site? In this post I want to walk through the pros and cons between having a secondary site, not having a secondary site and share some tips for when they are required.

First of all I want to go back to basics, let’s have a look at what the distribution point and management point are used for and some of the key capabilities within Configuration Manager.

Management Points

Your management point is used by clients to communicate with the site, any policy you create or deployment you create is sent to management points for your clients. In Configuration Manager 2012 you can have multiple management points in your hierarchy and clients will pick a management point based on the capabilities of the client and the management point, for example if the client has a certificate it will preference HTTPS management points first (only if your site is set to HTTP and HTTPS communication).

With distribution points you can tie them to boundary groups, you cannot do this with management points so clients in one location may well end up going over the WAN to find the appropriate management point, you cannot do much about this (I think it would be great if you could treat management points in the same way as distribution points in this manner).

Distribution Points

As you know, distribution points are used for serving out content to clients, this is any type of content in your site from boot images to software updates. As we have already established above you can force clients in a specific boundary group to request content from a specific distribution point, then a whole other process will take place to determine which one is suitable (see this post). Clients use the distribution point only for content, no other reason.

Factors Impacting Infrastructure Choice

I get asked a lot of questions along the lines of “why can’t we find a definitive source of information about using a secondary site?”. The simple answer to this is every environment is different, be this setup of Active Directory, DNS, DHCP but mainly network. It is how the network is setup and configured that will ultimately decide which bit of infrastructure you place at a remote location. The major factor with my customers is network speed and number of clients at some remote sites.

Other factors might include political reasons, I have had to deploy secondary sites down 100 Mbps pipes with only 50 users at the end because of a previously poorly configured environment. Sometimes no matter how hard you try to explain why you don’t need one, the internal IT team you are working with would rather be safe than sorry. I have no problems with this as long as people understand how much more administrative effort is required.

Hello Secondary Sites

The secondary site is much improved in Configuration Manager 2012. The main reason for this is replication. We now replicate portions of the database down to the secondary site (more on this in my next post). The secondary site sometimes got a bad rep in previous versions, it is now much more reliable and efficient. We replicate the database not using SQL replication but using the SQL Server Broker Service. The broker provides native support for messaging and queuing making it a perfect candidate for the job and takes the need to perform replication out of Configuration Managers remit and put’s it back into native SQL functionality.

Decision Factors for Placing Secondary Sites

While I have said that no network is the same (which it isn’t), I do have some standard design rules I stick to when I am designing hierarchies. These rules are fairly simple:-

  • Remote locations have more than 500 clients and less than 5,000 clients
  • I need to compress traffic going to the site
  • I need to control the traffic flowing up
  • I need a local management point
  • I need a local software update point

I just want to look at these a bit deeper to explain. These rules are pretty much identical to those of Kent Agerlund (awesome MVP), they are like this because they have worked for me the most, I have lost count of the number of discussions I have had around secondary sites, and these have always served me well.

Let’s have a look at these in a bit more detail.

Client Count

First of all client count, this is very important. Don’t forget you have scalability limits anyway, yes some of these are based on hardware configurations but always bear them in mind. Ask yourself, do I really want 500 clients getting policy over the network from this location? If the answer is no then you need a secondary site. I also use the upper limit of 5,000 for the same reason. For one location 5,000 is a decent size, and the supported limit of a secondary site anyway! No brainer for that one.

Compress Traffic/Control Traffic

The next two rules are all about the network, do I have enough physical pipe to support this amount of traffic? It goes hand in hand with the rule about client count as well but I still use it on it’s own. Regardless of client numbers, I don’t want to saturate the link with management traffic.

Local Management Point/Software Update Point

As I mentioned right at the beginning, we cannot force a client to a specific management point, so if you need to have a remote location do this then you need a secondary site. The same goes with a software update point, they are services of the hierarchy, and like a management point we cannot control which one clients use so again, if this configuration is required then you need a secondary site.


In reality I probably haven’t told most people anything new here, the goal of this post is to reiterate what rules I use out in the field. You will notice each of these rules could apply, my simple outcome is if any rules are true then I put a secondary site in. If after applying this logic you are still unsure, put a distribution point in and then see how it goes and monitor the link. I would rather put a distribution point down any day, only from a management perspective but sometimes secondary sites are needed and you need to be prepared for that.


Tags: , , , , , , ,

About Martyn

Martyn is one of the Senior Cloud Architects and DevOps Team Leader at one of the worlds leading Cloud Transformation Specialists Inframon. Martyn is responsible for the architecture of some of the largest Azure deployments in EMEA and is a advisor to a many businesses on their strategies. Martyn is a regular speaker at Microsoft events and community events on Azure and DevOps, giving his insight to a growing number of audiences.

One response to “Secondary Site vs Distribution Point vs Management Point”

  1. Andy says :

    Hi Martyn, thanks for your thoughts and this post. Well to be honest the criteria are fine for me, but on the other hand no so easy to use. How would you argue that 500 clients is the limit and not say 600? What is bandwidth utilization that forces a secondary site? (I put the line at usage of 85 percent) What line did you draw?
    It would be interesting for me to get your thoughts on that,

    Kind regards,


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: