New Distribution Points in Configuration Manager SP1

[Yvette O'Meally]

First published on CloudBlogs on Jan, 31 2013

Hi everyone, my name is Kerim Hanif. I am a Program Manager in the Configuration Manager team responsible for content distribution.

In Configuration Manager SP1 we introduced two new distribution points, the Cloud-based Distribution Point and the Pull Distribution Point. In this blog post series I would like to talk about these new distribution points in Configuration Manager SP1 and give you information about them.

Here are the blog posts that you will see in this series.

1. Cloud-based distribution Point, a Configuration Manager Role in the Cloud
2. Introducing Pull Distribution Point
3. Caveats and things to watch out when planning and using new distribution points

So let’s start with the first blog of the series.

Cloud-based distribution Point, a Configuration Manager Site System Role in the Cloud

Much of the Configuration Manager topology is made up of distribution points, they are very helpful in many situations where bandwidth and geographical separation are the facts of life, but also hard to manage if you have hundreds or even thousands of them.

This feature started with the vision that it makes perfect sense to have big distribution points in the Windows Azure cloud where one should not worry about things like (but not limited to) size, performance, reliability, security, access from all around the world, hardware/software update issues etc.

Did we fulfill this vision promise in Configuration Manager SP1? Well, to answer that question, let’s take a look at each of these vision goals a little bit more closely;

1. Hardware/software updates and reliability: As I mentioned we are utilizing Windows Azure to host the cloud-based distribution point, so forget about maintaining your old distribution point server hardware. You no longer need to worry about the software updates and reliability issues either, Windows Azure gives you close to 99.9% uptime guarantee http://www.windowsazure.com/en-us/support/faq/ (for your reference, cloud-based distribution points use the “Hosted” and “Storage” services in Windows Azure)
2. Performance and Size: We create two “extra small” size “instances” in Windows Azure, to host our cloud-based distribution point service by default (we use two instances for fault tolerance). This is configurable by you, the owner, after the service is created using the Windows Azure portal (more on this in my 3 ^rd blog post). We don’t think it will be needed for most of you but for those of you that want to do it you can scale it up as you please based on your needs and Windows Azure’s support numbers.
3. Access from all around the world: During setup we automatically retrieve the geographies from Windows Azure and ask you to select a geographic region of the Microsoft data centers in which the distribution point content is to be stored. Your data is then kept in the Microsoft datacenters in this geographic region you selected. All the clients in that region will have fast access to the cloud-based distribution point. Other clients in different regions can get to this cloud-based distribution point as well. If your company is global you may need to have multiple cloud-based distribution points in different regions for faster access to the regional clients. By default we use the Windows Azure defaults when we create this service and today it is “geo redundant” storage. This means that your data will be additionally stored in a second sub-region within the same region (that you initially selected) for maximum durability and redundancy. If you are not happy with this type of storage, it is possible to change this from the Windows Azure portal (more on this in my 3 ^rd blog post)
4. Security: We thought hard about security and made sure that all the communications with the cloud-based distribution point use HTTPS and every package that is uploaded to distribution points in Windows Azure is encrypted with a key unique to your organization’s instance of Configuration Manager.

As you can see we got really close to our vision, so are there any limitations? Continue reading to find out, because before that I want to talk a bit about the cost.

You may have realized that in #2 above I mentioned that you are the “owner” for the hosted service. We thought this was essential when creating a service on the cloud. It is super important since we know we are asking you to create a distribution point that is outside your premises and keep your content on it. That’s why we designed the cloud-based distribution point as “bring your own Windows Azure” model. This way you are the one and only owner of this Windows Azure service; we are just merely helping you to securely utilize that service with Configuration Manager.

One important fact to mention is that since you are the owner of this service, you are also responsible for the charges that this service will generate. These are separate charges other than what you may have been paying for licensing Configuration Manager. Because of this we tried hard to add features in Configuration Manager to ensure that you have full control over the data you use and avoid what we call “bill shock”. Configuration Manager can generate alerts to inform you when your data usage exceeds a configured limit.

If you are using a cloud-based distribution point in Windows Azure, you are charged for four things, web role instances, storage size, storage transactions and bandwidth usage (only for “egress” e.g. clients downloading your content, uploading your content to Windows Azure “ingress” is free)

Here is what we have for you to monitor and control your alerts and data usage;

1. Storage alert threshold : Whenever you send data to a cloud-based distribution point, your data will occupy space and you will be charged for storing it there. You can create a Configuration Manager alert to warn you when the size of data that you store on Windows Azure exceeds a certain limit. Please note that this JUST generates a warning or critical alert in Configuration Manager, it will NOT stop the transfer of content to the cloud-based distribution point; you will have to do that manually. We let you stop the Windows Azure cloud-based distribution point service from within the Configuration Manager console, so it is very easy, you don’t even have to go to the Windows Azure portal to do that.
2. Transfer alert threshold: When your clients start downloading content, you will utilize bandwidth from Windows Azure and you will be charged for it. You can let Configuration Manager warn you when the amount of data that is transferred to the clients from Windows Azure passes a certain limit. Again this is JUST a warning or critical alert, Configuration Manager will NOT notify the Windows Azure service to stop transferring data, you will have to do that manually (by stopping the Windows Azure Cloud-based distribution point service from the Configuration Manager console)
3. Fallback logic : We use a fallback mechanism for cloud-based distribution points so that your clients will never utilize the cloud-based distribution point if they find the content in your on-premises “local” or “remote” distribution points. The order of fallback logic is local, remote and lastly cloud.
4. Software updates : For software updates that can be found on the Microsoft Update service, we never use the cloud-based distribution point, since the update is already in the cloud.
5. BranchCache: If you have BranchCache enabled on the server and client side then we automatically utilize BranchCache so that for a subnet (like branch office) you can reduce your Windows Azure bill. With BranchCache, only one client downloads the content for each subnet then shares this content with other clients in the same subnet. This way you only incur minimum “bandwidth” costs in Windows Azure. We use BranchCache in “Distributed Cache” mode, if you want to read more about BranchCache, see http://technet.microsoft.com/en-us/network/dd425028

I want to make sure that you understand the costs of using a cloud-based distribution point, therefore I want to give you a simple example “ just for demonstration purposes ” to show you how to calculate your own potential costs. Your capacity and utilization will determine your true cost, so I can’t stress enough to mention the disclaimer to use this example ONLY for guidance .

In this example let’s imagine that you have 100 clients in North America or Europe that are going to be using a cloud-based distribution point and you will be transferring 10 GB of content to these clients. One great tool to use is the Windows Azure online pricing calculator to do this calculation; it is simple to use and always up to date with the latest prices.

So open up the calculator http://www.windowsazure.com/en-us/pricing/calculator/?scenario=full and perform the following actions (note that all the costs below reflect the prices as of January 2013);

1. Web and Worker Role Instances
   1. As you know we use two extra small (XS) instances by default, this cost will not increase and will be a constant cost for you unless you specifically change the size of these instances (more on how to do this in my 3 ^rd blog post). So select XS and 2 instances in the calculator, you will see that the cost will be $28.80 each month
2. Storage (Geo Redundant)
1. Storage Size
1. You will need to select 10 GB under this control, but since it starts from 100 GB you will need to do some basic math, since 100 GB is $9.50 each month you can conclude that 10 GB will cost you $0.95
3. Bandwidth
1. Since in this example we are assuming that you are going to be distributing 10 GB to 100 clients per month, select 1000 GB in this control, which will give you a cost of $119.40. However, it is very important to note that that this is the cost if ALL 1000 clients download the 10 GB sized content one by one. If you have a branch office, enable and  utilize BranchCache, you will have only 1 client downloading this content per subnet, considering all clients are in the same subnet in this case, your bandwidth utilization will be down to 10 GB which is just $0.60. So the saving that BranchCache will bring is quite considerable.

In conclusion, If we add all of these up in this example you can expect to pay between $30.35 ($28.80+$0.95+$0.60) and $149.15 ($28.80+$0.95+$119.40) each month, depending on whether or not you are using BranchCache.

Now that we have covered the costs, I want to return to the question that I left unanswered about the limitations of the cloud-based distribution point in Configuration Manager SP1.

We can sort these limitations into two categories:

1. Limitations because of the nature of the beast

• Operating System Deployment (you can’t PXE boot a computer over the cloud)

Limitations because this is the first version of this feature and we wanted to make sure the basics work perfectly before tackling more advanced features:

• Task sequences (for operating system deployment and application deployment)
• App-V streaming over a distribution point on Windows Azure
• Using cloud-based distribution points as source distribution points for pull distribution points (more about this in my next blog post)

Finally, I want to share with you some links from our official documentation in TechNet where you can find some great information on how to plan, install and manage cloud-based distribution points;

1. Plan for Distribution Points
2. Install Cloud-Based Distribution Points in Windows Azure
3. Manage Cloud Services for Configuration Manager

I hope this blog was useful and helped you answer your questions about the cloud-based distribution point. If you have more questions or feedback, you have three choices;

1. Use the comments below
2. Use TechNet forums http://social.technet.microsoft.com/Forums/en-us/configmanagerapps/
3. Use Microsoft Connect https://connect.microsoft.com/ConfigurationManagervnext/feedback/CreateFeedbackForm.aspx?Feedb...

Use #1 or #2 for questions, but if it is a bug or a feedback please use the Microsoft Connect site. This is important because when you leave feedback there, it automatically creates a bug in our database and gets immediate attention from the engineering team.

In my next blog I am going to be introducing you to the pull distribution point.

-- Kerim Hanif

This posting is provided "AS IS" with no warranties and confers no rights.