Friday, June 22, 2012

Planning an SCCM 2012 Migration - Distribution Points Explained

In my first post on this subject I made a vague reference to the changes made with the Distribution Point role in SCCM 2012 but didn't put a lot of effort into explaining the differences between it and a Secondary Site Server.  With this post I hope to clear up the distinction a bit and provide some more useful information rather than my own 'brain droppings' on the subject.

Distribution Point - Then


In SCCM 2007 the Distribution Point role was very basic, it only provided the mechanism for distributing applications from an existing Primary Site, Secondary Site, or Branch server with minimal other features.  It allowed for the use of BITS to allow resumption of interrupted downloads, but was not used to throttle traffic between the Site Server and The DP.  In 2007, the DP was seen as more a companion to a server role but not on its own.  Now I know what you are thinking; Isn't the Branch Server Role basically a stand-alone Distribution Point?  The answer to that is No for the most part, as the Distribution Point was only one component (granted, a major one) to the Branch Server Role.

Distribution Point - Now

Before I get to the new Distribution Point Role, a little background explanation is required here.  With SCCM 2012, Microsoft has the right idea with trying to flatten the hierarchy so that less servers are required.  This is a rather interesting shift for Microsoft since they usually want a server for everything, a proper deployment of Exchange 2010 is a good example of server scaling gone crazy.  From what I can gather, Microsoft's goal with 2012 is too:

1) Reduce the number of physical/virtual servers required to maintain the environment while providing for a maximum number of supported objects

2) Remove the requirement for child sites for administrative or client configuration purposes by the use of Role-Based Administration and allow for collection-based client configurations

3) The ability to install the management products in Public Cloud configurations with no impact in performance due to bandwidth/latency issues

Point #3 is, I think, the main reason why Microsoft is trying to deter people away from installing servers in the local office, instead providing only the roles required to work without needing a full server, or even a server OS!  Lets take a look at the new Distribution Point features, keeping in mind that this can be installed as a stand-alone role on a Server or Desktop OS:

- Application Distribution
- Virtual Application Streaming
- Operating System Deployment (including PXE/SingleCast/MultiCast)
- Content Library and Validation
- Scheduling and Throttling
- State-based Distribution Groups
- Content Prestaging
- BranchCache support

With the Distribution Point Role they have moved beyond BITS to control network traffic and introduced Scheduling and Throttling which before was only available from a Primary Site or Secondary Site server.

As you can see, the Distribution Point role has been extended considerably in SCCM 2012, but its not perfect.  There are some key roles missing from the Distribution Point Role which can only be served by a Primary Site or Secondary Site:

- Software Update Point
- Management Point
- State Migration Point
- Control of data flow to and from the site server

All of these roles can generate a lot of traffic on your WAN (if you have a distributed environment) so may not be practical to centralize them in your data centers unless you have a very robust network.  Yes, BITS can help with the bandwidth impact, but if you have 1000 systems or more, that could easily take up a lot of traffic.

In my environment I do plan on utilizing the stand-alone Distribution Point role, though granted it will be limited to very small locations, site offices, where we have a very small headcount.

Happy Planning!

1 comment:

Stuart Spindlow said...

Thanks for sharing this good information about the software distribution tools. Keep me more updates.