ConfigMgr: Cloud Distribution Points Behind Traffic Manager

Cloud Distribution Points (CDP) are a new feature added in SCCM 2012.  These Distribution Points are hosted in the Azure cloud under an existing or new Azure subscription.  CDPs can provide access to content for clients that are either outside of the intranet or at a remote branch office that does not have a local distribution point.  Imagine a remote office with 50 clients and no distribution point, and its connection to the closest datacenter with a distribution point is over a 2Mbps MPLS link.  The office also has a 100Mbps link through a local ISP to the internet.

“Cloud Distribution Points live in Azure. So does Traffic Manager. Can you put the two together to achieve global load balancing for your internal and external ConfigMgr clients? You betcha!”

When a new application or package is pushed to the clients in the remote office, they can easily saturate the 2Mbps link back to the datacenter with their traffic.  BranchCache in distributed mode could be used to help alleviate the traffic, but it would be nice if the clients would pull the content across the 100Mbps link instead of the MPLS line.  Enter the Cloud Distribution Point.  CDPs are configured as a fallback content source, so if there is no preferred distribution point with the content, the client will download it from a fallback source.  If the only fallback source is a CDP, then the client will pull the content from there.
Now let’s say you have geographically disperse clients, and you would like to deploy CDPs in several regions so that the content is served by a local CDP.  Normally you would set a preferred distribution point by using boundary groups, but CDPs are configured as fallback content locations, and there is no way of setting preferred failback content points.  So the client will randomly pick a CDP that has the required content.  Instead of relying on the client to determine the optimum CDP, two or more CDPs can be placed behind an Azure Traffic Manager.  The Traffic Manager will use performance metrics to determine which CDP a client should use and then provide the client with the aliased CDP name.  CDPs are configured in Azure as a Cloud Service with a public DNS entry of <GUID>.cloudapp.net.  When a CDP is provisioned, it is given an FQDN such as CloudDPEast.contoso.com which is configured as a CNAME to the Cloud Service URL.  The Traffic Manager adds another layer to the DNS configuration.  The following graphic describes the process for a client to find the correct CDP.
 
 

1. SCCM Client requests a DNS lookup for CloudDPEast.contoso.com
2. The DNS server gets an alias of ContosoCDP.trafficmanager.net
3. The DNS server queries the Name Server for trafficmanager.net
4. The Traffic Manager checks to see which endpoints are up and have the best performance for the client source IP Address
5. The Traffic Manager returns a CNAME for the <GUID1>.cloudapp.net CDP in the East US region
6. DNS responds with the <GUID1>.cloudapp.net IP address to the client
7. The client reaches out to the IP address to download content from the CDP

 
 
 
 
 
This assumes that the client is getting the best performance from the CDP in the East region.  From a DNS perspective, each CDP will have its own FQDN.  So let’s say you deploy a CDP in the East, West, and Northern Europe.  The DNS entries would look like this:

• contoso.com IN CNAME ContosoCDP.trafficmanager.net
• contoso.com IN CNAME ContosoCDP.trafficmanager.net
• contoso.com IN CNAME ContosoCDP.trafficmanager.net

These DNS entries should be public and private if you’re running a split-DNS scenario.
So how do you actually set all this up?  Here’s a high-level list of tasks to get things working:

1. Provision each Cloud Distribution Point (note: you need a new Management Certificate for each CDP)
2. Create the public/private DNS entries for each CDP
3. Create a Traffic Manager in Azure
4. Add each CDP as an endpoint for the Traffic Manager
5. Configure Monitoring for the Traffic Manager
6. Distribute Content to the CDPs
7. Configure your clients to support CDPs
8. Configure the content deployment to support fallback content locations
9. Configure client boundaries as needed

 
That is a high-level look.  For a step-by-step guide in deploying a CDP, I recommend this excellent guide from TechNet.  Some of the graphics are out of date, but the information is still relevant.  One of the things I discovered the hard way is that each CDP requires a unique management certificate.  You cannot reuse the same one for each.
Likewise, creating a Traffic Manager is well documented on TechNet, so I won’t rehash it here.  Traffic Manager is now available in Resource Manager, so I recommend using that instead of the Classic model.  The configuration should use the following settings for endpoint monitoring.  You can set the DNS TTL to whatever makes the most sense.  Performance routing is used to determine which endpoint has the lowest latency for the client’s source IP address, as detailed here.
 
 
 
 
Once you have the Traffic Manager deployed, you can add the CDPs as endpoints as illustrated below.

 
Distributing content to the CDPs is as simple as creating a Distribution Point Group and adding all you CDPs to it.  Ideally, the content in the CDPs should be the same since Traffic Manager may provide the client with a connection to any of the endpoints in its pool.
By default, clients are not configured to pull content from cloud distribution points.  That setting is controlled by the Default Client Settings, or any Custom Device Client settings that may have been configured.  You can either change it in the default, or create a custom device client setting for specific collections.  Within the custom device client setting, the Cloud Service category should be added.

And in the Cloud Services section the Allow access to cloud distribution point drop-down should be set to Yes.

Individual content deployments must be configured to support a fallback content location.  Depending on the content type, the location of the setting varies.
For Applications that will be deployed from CDPs, select the Application and open its properties.  Select the Deployment Types tab and edit the first Deployment. Select the Content tab and make sure the following settings are selected.

 
Repeat for each additional Deployment Type.
For Packages that will be deployed through the CDPs, select the package.  In the bottom window, select the Deployments tab, and open the Properties of the first deployment.  Select the Distribution Points tab and make sure the following settings are selected.

Repeat for each additional Deployment.
Software Updates will not be using CDPs, instead they will download directly from Microsoft.  In order to configure this setting, select a Software Update Group.  In the bottom window open the Properties of the first Deployment.
Select the Download Settings tab and make sure the following settings are selected.

Since CDPs will not service Software Update requests, if there are no other fallback sources then the client will go out to Microsoft Update.  There may be some environments where this is not preferred, but that is up to you.
Now that the content and clients are configured, the last thing to do is configure boundaries.  If the clients are currently being serviced by a distribution point in their boundary/boundary group then you’ve got two options.  You can leave the current configuration, but stop deploying content to the distribution point.  Or you can remove the distribution point from the boundary so that the client always goes to its fallback source.
One last disclaimer, Cloud Distribution Points are part of an Azure subscription and are subject to billing for CPU cycles and data egress.  Make sure to take that into account when planning a CDP deployment strategy.

About Anexinet

Anexinet is a leading professional consulting and services company, providing a broad range of services and solutions around digital disruption, analytics (and big data), and hybrid and private cloud strategies. Anexinet brings insight into how technology will impact how business decisions will be made and how our clients interact with their customers in the future.
Ned Bellavance, [email protected]