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!

Friday, June 15, 2012

Planning an SCCM 2012 Migration - Untrusted Domains

Probably one of the biggest shifts in the SCCM 2012 Heiarchy is the requirement for two-way trusts when supporting other domains and/or forests.  This can have major implications for those companies who employ a DMZ domain which is not trusted by the internal domain for security reasons.

I came across this blog post about a way to get around this.  Please note that this is NOT supported by Microsoft!  As I have yet to test this myself, I cannot vouch for its accuracy so your mileage may vary.  Let me know in the comments below if you are able to get this working in your environment.

Friday, June 8, 2012

Planning an SCCM 2012 Migration - Pre-requsites

Here are a few of the things you should take care of on your network / things you should know before you begin to Deploy or Migrate to ConfigMgr 2012:

1) Extending the AD Schema.

If this is a new deployment for you, or if you are migrating from SMS 2003, then you will want to seriously consider extending the AD Schema for ConfigMgr 2012.  If you already have ConfigMgr 2007 deployed in your environment then you do not need to extend the schema again as the extensions are the same.  Extending the Schema allows ConfigMgr to publish parts of its configuration to AD for the benefit of the SCCM Client.  You MUST extend the schema if you plan on using Network Access Protection.

Here is a link to the TechNet documentation:

2) App-V Client

If you use App-V in your environment, you MUST use version 4.6 SP1 otherwise the ConfigMgr Client will not install.

3) Clean up your Collections / Software Packages

If you are using ConfigMgr 2007 then this information will apply to you.  The migration process has a couple of limitations when it comes to Collections and Software Packages.  On the collection side of things, if you have collections that have both users and comptuers as members they will not migrate.  Also, if you have a collection query that is limited to searching inside a specific collection, the query will not come over.  All your Software Packages must use a UNC path for its source directory.

4) SQL Here? Here? ... how about over Here ?

Placement of your SQL Database really depends on the size of your environment.  If you manage a large number of devices, over 50'000, then you will be better served to use a stand-alone SQL server or SQL Cluster.  If your environment is smaller than that, you can install it on the same server as ConfigMgr.  Also consider that Secondary Sites will use SQL as well, though they can get by with having SQL Express installed on the local machine.

5) Site Codes

You cannot re-use side codes from your ConfigMgr 2007 environment, so plan for new Site Codes for your CAS, Primary, and Secondary Sites

More to come!

Planning an SCCM 2012 Migration - Secondary Sites Vs. Distribution Points

As I've been reading up on how to migrate from ConfigMgr 2007 to 2012 (hint: there is no upgrade option), one common theme that keeps coming up is wether you need to use a Secondary Site to regional offices or just to use a Distribution Point.  With ConfigMgr 2012, MS is trying to simplify the hierchy by requiring less site systems to do the same amount of work.  A couple things to keep in mind when trying to decide between the two:

1) The Distribution Point role has been expanded on in ConfigMgr 2012 to do a lot more than in 2007, but it doesn't do everything!
2) Since Distribution Points does not include the Management Point role, you must take into account the extra bandwidth used by client systems when they connect with an MP in an associated Primary Site (or Secondary Site)
3) Same thing with the Software Update Point role, its checks will go up to the assigned Primary Site (or Secondary Site) to check for approved Updates
4) State Migration is not a part of the Distribution Point Role!  If you plan on using USMT directly within ConfigMgr, this is something that you will have to consider

In the case of my envornment, I don't think the heiarchy is going to change very much, except for the introduction of a Central Administration Point and a 2nd Primary Site (right now I run a single Primary Site and 14 Secondary sites under ConfigMgr 2007).