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.
- SCCM Client requests a DNS lookup for CloudDPEast.contoso.com
- The DNS server gets an alias of ContosoCDP.trafficmanager.net
- The DNS server queries the Name Server for trafficmanager.net
- The Traffic Manager checks to see which endpoints are up and have the best performance for the client source IP Address
- The Traffic Manager returns a CNAME for the <GUID1>.cloudapp.net CDP in the East US region
- DNS responds with the <GUID1>.cloudapp.net IP address to the client
- 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:
- Provision each Cloud Distribution Point (note: you need a new Management Certificate for each CDP)
- Create the public/private DNS entries for each CDP
- Create a Traffic Manager in Azure
- Add each CDP as an endpoint for the Traffic Manager
- Configure Monitoring for the Traffic Manager
- Distribute Content to the CDPs
- Configure your clients to support CDPs
- Configure the content deployment to support fallback content locations
- 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]

Ned Bellavance
Director, Cloud Solutions and Microsoft MVP: Cloud (Azure/Azure Stack) & DC Mgmt
Ned Bellavance is an IT professional with over 15 years of experience in the industry. Starting as a humble helpdesk operator, Ned has worked up through the ranks of systems administration and infrastructure architecture, and in the process developed an expansive understanding of IT infrastructure and the applications it supports. Currently, Ned works as the Director of Cloud Solutions for Anexinet in the Philadelphia metropolitan area, specializing in Enterprise Architecture both on-premise and in the cloud. Ned holds a number of industry certifications from Microsoft, VMware, Citrix, and Cisco. He also has a B.S. in Computer Science and an MBA with an Information Technology concentration.
Let’s get the conversation started
Reach out now to begin your digital transformation
+ 16,659
ZOOM MEETINGS
+ 9,789
HAPPY CLIENTS
+ 5,075
FINISHED PROJECTS
+ 133,967,432
LINES OF CODE
© 2000 - 2021 Anexinet Corp., All rights reserved | Privacy Policy | Cookie Policy
This website uses cookies
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL cookies.
Manage consent
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.