Kevin Remde's IT Pro Weblog
Welcome to another main installment of our “20 Key Scenarios with Windows Azure Infrastructure Services”. For those of you who are just now starting to follow along, make sure to start your FREE TRIAL of Windows Azure, so that you can follow along.
Those of you who are familiar with System Center 2012, and in particular the Configuration Manager component, are already familiar with the concept of Distribution Points. But for those of you who are new to it, here is a very brief definition that will make it all clear: Ahem… : A Distribution Point is a point from which things are distributed.
“Oh yeah, crystal-clear, Kevin.”
It’s really not complicated (or at least, the idea isn’t complicated). In a large organization, with centralized IT Management, and perhaps with many locations around the globe, it’s important to be able to define locations from which those far-flung users are getting their software or updates from. So System Center 2012 Configuration Manager has
But consider this: What if I were able to use Windows Azure – a cloud-based, highly available and globally scalable service - to act as my distribution points?
“You mean, give immediate, secured, authenticated global reach to your organization’s operating system deployments and software distributions? That would be amazing, Kevin.”
I knew you’d like it. This capability is new in System Center 2012 SP1, and was first announced on the System Center Configuration Manager Team Blog here : New Distribution Points in Configuration Manager SP1.
It is further documented at TechNet here: Install Cloud-Based Distribution Points in Windows Azure. NOTE: The cloud-based distribution point is going to be used deployments other than Microsoft updates. Updates are already available “in the cloud” through Microsoft Update, and it’s just as easy to configure your company’s devices to use Microsoft for operating system and application updates.
For the rest of this article, I’ll break the task of installing and testing this into these steps:
Install System Center 2012 SP1 Configuration Manager
To test creating a cloud-based distribution point, I installed the evaluation of System Center 2012 SP1 Configuration Manager on a local virtual machine in my test domain. My installation was a new Configuration Manager standalone primary site:
(Prior to this installation I had installed the evaluation of SQL Server 2012 on the same machine, but I could have used the “typical installation” option to also install SQL Express to use as the local database. For a good write-up on installing a test machine like this as a Windows Azure Virtual Machine, read THIS EXCELLENT ARTICLE by Keith Mayer.)
After installing and configuring the prerequisites, I also just took the defaults from that point on.
Of course to make an authenticated, secured (SSL) connection between your Configuration Manager installation and your Windows Azure subscription, you’re going to need to generate use a management certificate. And like most situations where we’re just trying new capabilities out that require certificates, there is a simple way, and there is a recommended-for-production way. The recommended-for-production way is to use a PKI, and use the templates and certificate types for Server and Client authentication as described in this document: PKI Certificate Requirements for Configuration Manager
For my purposes, just to get the distribution point created and the trust established between my local Configuration Manager site server and the Azure subscription, I exported both a .CER and a .PFX file from the local machine certificate that was created for my SCCM server and its relationship with SQL Server. It was already of the proper type (from the proper template), so worked fine for my test. Here’s how I did that…
Open MMC (On the start screen, type MMC and run MMC.EXE).
On the File Menu, choose Add/Remove Snap-in… then in the left-hand list, select Certificates, and click Add.
When prompted for what your want to manage certificates for, select Computer Account, click Next, and then click Finish. Click OK to close the Add/Remove Snap-ins form.
Now, in the MMC, navigate to Certificates (Local Computer) –> Personal –> Certificates. You should find a Server Authentication certificate there with the name of your server in the Issued To column.
We’re going to do two export operations on this certificate; one to get a .cer file that we’ll upload to Windows Azure, and the other to create a password-protected .pfx file that we’ll use to configure the connection from our local Configuration Manager to create the cloud-based distribution point.
First we’ll export a .cer file:
Now we’ll export a .pfx file:
Upload the .cer file to our Windows Azure subscription. (If you don’t have one, it’s easy to START A FREE TRIAL HERE.):
And there you go. The certificate for our test is in place. Now we’re ready to create and connect Configuration Manager to a new cloud-based distribution point.
Create the Distribution Point
And now you’ll see your new Cloud Distribution Point listed in the main part of the page, that will have a status of Provisioning. Eventually that status will change to Ready.
Go back to your browser and to your Windows Azure administration page. Navigate to the Cloud Services section on the left. It will take several minutes but eventually you will see a new cloud service with a long-and-ugly name show up.
Note toward the right that you have a value in the URL column. That value (which is essentially <your service name>.cloudapp.net) is the DNS name that your clients will use for connecting to the distribution point and getting their software.
Below Cloud Services, find and click on Storage. Here you’ll see that a new storage account has been created with the same ugly name that the new cloud service has.
As I’m sure you’ve guessed, this is the storage account that will hold all software and other items that you’ve deployed to your distribution point.
And now you’re ready to distribute some software to your new distribution point in the clouds. Try it out by distributing the Configuration Manager Client Package up to the your distribution point.
Now let’s see if that package is being distributed.
Another way to show that you’ve succeeded is to go back to your Windows Azure administration page, click on Storage, click on the your storage account, and select the Containers tab. You’ll see new containers being created that you can drill-down into and actually see the files and their URLs.
Considerations for Client Access
“So.. is that it?”
Almost, but not quite. The Planning for Content Management in Configuration Manager document has an important section describing how and when clients will access your cloud based distribution points: Client to Cloud-Based Distribution Point Communication. Make sure you read and understand the points made there.
System Center 2012 SP1 Configuration Manager adds the ability to configure and use a Windows Azure-base service to hose a Distribution Point as what is now known as a “Cloud-Based Distribution Point”. Once certificates are in place, the actual creation of the distribution point in your Windows Azure subscription is fairly straight-forward, and for distributing content, it becomes just another option when choosing where to distribute your deployed applications and packages.
What do you think? Are the wheels turning as you’re now envisioning all of the flexibility that this new capability will give you? If not, you’d better read this article again.
Great and very interesting blog. I think it’s also an informative. Thanks for sharing.