...building hybrid clouds that can support any device from anywhere
Time for Part 2 of the Automating Hybrid Clouds with Windows Azure and PowerShell blog series (find Part 1: Intro & TOC here). And yes, this post actually has PowerShell Examples! But first, the list of what examples will be provided…
As covered in the intro post of the blog series, the following is the list of high level concept commands that will be covered in this post:
Here is the short list of pre-requisites for this example solution:
Automation often requires “trust”, especially between two endpoints in any given process/scenario solution. This example is no exception. The connection between the “On-Prem” Windows Server and Windows Azure need to share a “trust”. For Windows Azure (and for this example), one of the most common ways to accomplish this is through “the certificate method” (outlined in this Windows Azure tutorial: How to install and configure Windows Azure PowerShell).
Basically, it leverages the following:
Note I recommend running these commands individually (not all at once) by the groups above.
As part of this process, you will notice a new Management Certificate in the Windows Azure Portal:
If everything was successful, the Get-AzureSubscription results should look similar to this:
Now that we have established a good connection to Windows Azure, we can take care of the rest of the automated steps to build out the environment.
Reminder Obviously, there are other methods and concepts to be automated for Windows Azure - these are just the ones I chose for the examples in this blog series.
There is one variable that impacts the entire script and resulting environment. This needs to be set first, and will be used throughout:
Note If you run this example all the way through as a test, you will see how pervasive this variable���s value actually is. Even if you just look through the “Execution Results” from each step it is apparent. This is for example purposes only. I wanted to simplify the scripts and number of variable inputs.
First step for these examples is to create a Windows Azure Affinity Group within Windows Azure for the environment being built. There is one variable that you will want to consider updating to fit your environmental needs/requirements:
Note All variable values were chosen for this example only, and can be changed to fit your project needs.
Next up, is to create a Windows Azure Cloud Service within Windows Azure for the environment being built. There are no new unique variables that require value updates.
Note This portion of the script depends on the previous two.
Next, is to create a Windows Azure Storage Account within Windows Azure for the environment being built. There are no new unique variables that require value updates.
Note This portion of the script depends on the previous three.
Next, is to create Two Windows Azure Storage Containers within Windows Azure for the environment being built. There are no new unique variables that require value updates.
Note Creation of two Storage Containers in this example was to ensure I always had a “known good” copy of the uploaded VHD/Blob.
Note This portion of the script depends on the previous four.
Next, is to upload the “On-Prem” VHD to the Generic Windows Azure Storage Container within Windows Azure for the environment being built. This portion of PowerShell does require some customization, as it references the previously mentioned, “…VHD file that meets the requirements to be uploaded to Windows Azure”:
Note This portion of the script depends on the previous five.
The following is an image (not that it is really needed, but for proof), of the file and path of the VHD I am uploading in this example:
Because this step takes a while, when you run the example PowerShell above, you have the opportunity to see the ongoing status within the PowerShell console. Here is a screenshot of the process, mid-execution:
Note Over a fast connection, a file of this size (7.5GB) takes about 10 minutes to upload (as seen in the results below).
Next, is to copy the uploaded VHD (now a Windows Azure Blob) from the Generic Container (vhds) to the Project Specific Container within Windows Azure for the environment being built. There are no new unique variables that require value updates.
Note Usage of two Storage Containers in this example was to ensure I always had a “known good” copy of the uploaded VHD/Blob.
Note This portion of the script depends on the previous six.
Next, is to create an Azure VM Image from copied blob within Windows Azure for the environment being built. There are no new unique variables that require value updates as $VMImageOS likely will remain “Windows” for the VHDs uploaded.
Note This portion of the script depends on the previous seven.
Next, (what we all have been waiting for!) is to create a Windows Azure VM from the Windows Azure VM Image within Windows Azure for the environment being built. This portion of PowerShell does require some customization:
Note This portion of the script depends on the previous eight. Also, the method used to create the Windows Azure VM in this example was New-AzureQuickVM, there are other methods – Please see some examples below (after the "Putting it all together" section).
Because this step takes a while, you have the opportunity to see the ongoing status within the Windows Azure Portal. Here is a screenshot of the Windows Azure VM creation, mid-execution:
Note "Provisioning" durations vary.
Once provisioned, it is simple to connect directly to the Windows Azure VM to test its contents.
Note Obviously nothing was done to customize the network for this VM. Windows Azure Virtual Network was out of scope for this example. For more information, please refer to the following: Windows Azure Virtual Network Overview.
I realize this is more than “like 5 lines of PowerShell”. But in reality, if you had the Windows Azure environment already created, that number isn’t that far off. Either way, here are all the above PowerShell script portions, rolled up into one script example:
Note As stated above, the method used to create the Windows Azure VM in this example was New-AzureQuickVM, there are other methods – Please see the following for a couple of those alternate methods.
I would like to take the time to share something that came from the MVP Community recently – Another Alternate Windows Azure VM Creation Example… (Thank you Christopher Keyaert!)
This example highlights the ability to create a Windows Azure VM from a Disk with a VNet and Subnet defined.
Note This is an example that builds on the other scripts within this blog post. Be sure you have all pre-requisite steps completed before you attempt to implement this example.
Important If you attempt to create a new Windows Azure VM in an existing deployment with the above script you will likely get a warning like this:
Warning Text: WARNING: VNetName, DnsSettings, DeploymentLabel or DeploymentName Name can only be specified on new deployments.
Once again, a big Thanks to Christopher for expanding on what I published here and suggesting that I share it with the rest of the community!
During the "Conversion" process from Orchestrator Runbooks to Windows PowerShell, I ran up against a few things that I had to figure out. Here are a two of those learnings (outside what you have seen above), for just in case:
Before I learned about Setting the Azure Subscription with a "Current Storage Account", I tried my hand at creating and leveraging a Storage Context. Once you have created a Storage Context, you can reference it and pass it as a variable to commands requiring some level of specificity when it comes to Windows Azure Storage. While I did not use Storage Context in the examples above, I figured I would give you some example PowerShell, if you decide that is the route you want to take:
I ran into quite a few exceptions during the build out of this example solution. Needless to say, when the PowerShell screen turns red, frustration rises just a little bit (if not more than a little bit). The following command helped me dig deeper on some of the more vague errors being returned by the command failure exceptions:
Note While it will not work in all cases, and while it is very generic, I found that if this is run right after a "Bad Request (400)", the "InnerText" of the Exception helped tremendously with what was actually going on. I found this originally referenced here.
To get some proof of this working, I attempted to recreate the scenario where I needed to use the above commands. In my attempt to reproduce the "Bad Request (400)", I was met with actually useful and accurate errors:
That’s it! If I have any more learnings, I will add them to the upcoming blog posts.
So, what’s next? On to increasing complexity – Part 3 of this blog series takes what we have in this post, and transports it to a new world – Windows PowerShell Workflow!
I broke this “Automating Windows Azure” topic up into four posts – primarily to make it easier to reference externally (based on varied interest levels).
As promised, the following is the link to the TechNet Contribution and Download for the examples (from all parts of the blog series).
The download (Hybrid Cloud Automation Toolkit - Windows Azure and PowerShell.zip) includes the following (4) files:
Download the Hybrid Cloud Automation Toolkit - Windows Azure and PowerShell from TechNet Gallery here:
Thanks for checking out this blog series! For more information, tips/tricks, and example solutions for Automation within System Center, Windows Azure Pack, Windows Azure, etc., be sure to check out the other blog posts from Building Clouds in the Automation Track!
Thank you for your post and sharing all this info !
Just a link about how to convert a VHDX to VHD for Azure with PowerShell
@Christopher - Thanks!
For inline blog reference, I have also added the link you provided to the "Pre-Requisites" section above under bullet #2.
Do you see any blocking point to not consume your script with SMA ?
Could be a great solution to replace App Controller.
@Christopher - No real blockers, just a little bit more work to get these scripts into PowerShell Workflow. And then, of course, testing for anything SMA specific.
Part 3, has all the above scripts refactored as PS Workflow, which can be used with SMA.
I did have a question, something I was wondering - What are the primary use cases for these scripts + SMA? I am happy to do another blog post to take advantage of any synergies, just trying to work through the use cases.
I mean, from an Admin standpoint, it makes sense (we can expose the parameters to be filled in from the WAP Admin portal), but the Tenant Portal would not really be usable for execution of these scripts. Of course, a front end that calls into the WS API
for SMA would be perfectly fine as well...