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.
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;
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;
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);
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:
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;
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;
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.
This posting is provided "AS IS" with no warranties and confers no rights.
Great info, looking forward to part 2 and 3.
How do i know if i have enabled and utilized BranchCache ?
Sorry for the delay to reply to your question.
Basically first you need to setup BranchCache both on the server (in distributed caching mode) and the client.
On the server side (DP) you need to be running Windows Server 2008 R2 and the BranchCache feature installed.
On the client side you can either use group policy or run the following command on each client: netsh branchcache set service mode=DISTRIBUTED
You can then use "netsh branchcache show status" to see the BranchCache service status.
Say you have two clients and you installed an app to these two clients, once the job is completed and say your app/program installed on both but you want to make sure a client2 has downloaded the content from BranchCache, open up the event viewer on that client (client2), go to Applications -> Services logs -> Microsoft -> Bits-Client -> Operational, find the event ID "4" and open up the properties. Go to the details tab, if you find ‘bytesTransferred’ and ‘bytesTransferredFromPeer’ shows the same number, this means that this client2 downloaded the content from the distributed cache other client1 not from DP.
We are changing one small wrong information in the blog.
I had mentioned that "we create two 'extra small' size instances in Windows Azure each with 2 cores" but actually "extra small" instances in Windows Azure "share" cores, so we are removing the part about "2 cores"
For more information: msdn.microsoft.com/.../ee814754.aspx
Hey, Kerim, where are other 2 posts you promised in the beginning of this one? :)
Is the recommended max client count 4000 like an on premise DP? Or does this act as a service, a customer signs up for a cloud DP and all clients utilize the same URL for all needs?
Thanks a lot for these Greate Info.