Let’s Build a Cloud… With PowerShell! - Part 1: Deployment and Configuration

clip_image001Windows Server 2012 introduces vastly improved Windows PowerShell support with over 2,300 cmdlets to manage just about everything in the platform. This means you can now use Windows PowerShell to automate all of the IT tasks around cloud datacenter management, starting from deploying your cloud infrastructure servers, through on-boarding virtual machines onto that infrastructure, and ending with monitoring your datacenter environment and collecting information about how it performs. Practically everything is automatable!


We expect automating common IT tasks to be a very common practice among IT pros managing Windows-based clouds, which is why we’ve been busy creating sample scripts showing how to use the different cmdlets in Windows Server 2012 to achieve full datacenter automation. We’ve just uploaded the first bulk of these samples onto the TechNet Script Center, and in this first among a series of Windows PowerShell-related blog-posts, we’re going to provide some additional information on how to use these samples and customize them for your needs, and help you understand them so that you can build your own set of scripts based on the practices demonstrated in these samples.


So, before we talk about the actual scripts, let’s understand the environment in which they will run. In every cloud datacenter, there will obviously be servers that will host virtual machines, servers that will act as storage nodes (which could be SAN appliances but could also be Windows Servers), and of course, the necessary network infrastructure to connect them all. In addition to that, you’ll need some infrastructure servers such as an Active Directory server. Last but not least, in order to be able to remotely automate common tasks, you’ll have a management server with the primary purpose of controlling and managing all of the infrastructure components from a single point. In some cases, you may run this automation directly from an admin desktop, but more commonly, you’ll use your desktop to remotely connect to the management server, and perform tasks from there.


Based on that, our simulated mini-cloud environment designed to demonstrate the use of PowerShell to automate cloud management IT tasks would look something like the following diagram:




Note that in this environment, the sample scripts should be installed and executed on the management server, which have been configured properly to manage the servers that will act as the “cloud”. The management server will in turn invoke PowerShell scripts on the target servers themselves. The management desktop does nothing more than to connect to the management server and trigger execution of common tasks, and in the code samples case, we’re not exposing any special APIs for that, but simply assuming you’ll establish a remote connection into the management server (you can do so by simply entering the Enter-PSSession command in the desktop’s PowerShell command prompt), and run the scripts from there. Of course, in a full blown cloud deployment, you could expect that the management server will have some kind of a portal or expose some other functionality to enable more advanced scenarios, such as in the case of using System Center Virtual Machine Manager as your management server.


Most common datacenters will have basic infrastructure such as Active Directory servers and other management servers. So, once you have that set up, and some servers that you have set up to act as your cloud infrastructure, the next question is what common tasks you’d want to automate. We think that the following key tasks are the key to full datacenter automation and almost everything else builds upon them and extends them:


  1. Deployment of Hyper-V and File Server clusters as needed. We will look at the deployment of servers, configuring them properly, configuring storage and networking as needed. Basically we start from a plain vanilla servers and end with a properly configured cloud infrastructure ready to host virtual machines. In our samples, this will be based on the same set of representative cloud configurations that you’re probably already familiar with by now, and which are documented on TechNet as the non-converged configuration and the converged, file-server based configuration.
  2. On-boarding virtual machines. The samples will focus on placing pre-prepared virtual machine images (VHDs) on top of one of the configurations you have. On-boarding could be“simple” placement of VMs on a free node (although in real life you’ll likely have some advanced algorithm for smart placement), but it might also be tied to Windows Server network virtualization, which requires some additional logics and configuration to map virtual machines IP address space to the cloud infrastructure address space. We’ll have samples for both cases.
  3. Migrating virtual machines around the datacenter (or the cluster) for the purpose of balancing the load on your servers, or servicing servers without interruption to the running workloads.
  4. Monitoring virtual machines, which will mostly be used for checking health of workloads and physical servers, and for chargeback scenarios (understanding how much compute, storage and network resources a single VM or a group of VMs have consumed).



Once you understand how to achieve these 4 common tasks with Windows PowerShell, it’s very reasonable to assume that you can practically automate any other datacenter management tasks you need, because these are the core building blocks that allows you to “touch” all components that will be running in your datacenter.



So, without further ado, let’s take a look at what’s in the first set of samples which will be focused on deployment, and in the upcoming of blogs, we will dive into other tasks.


If we take as an example the configuration that uses a cluster of Hyper-V servers and another cluster of File servers connected to JBODs, our goal with deployment would be to set up our racked servers as two clusters and get to a configuration that looks like this:




As you can see, there are many different features to configure, and they have cross dependencies and need to be configured in a specific order to achieve fully automated deployment. For that, we need to first have those servers racked and stacked, get them set up with Windows Server 2012 and some pre-requisite minimal setup (which could also be automatable, but you most likely already have the tools for provisioning initial images onto your racked servers, so in the samples we assumed these as pre-requisites), and once the servers are there and ready to be configured, you will be able to run the deployment script from the management server that will cycle through this servers using Windows PowerShell remote invocation and perform all of the necessary configurations on them.



Let’s first understand the pre-requisites. These are also documented as comment in the master “ConfigureCloud.ps1” script:


1. Appropriate hardware is connected, including server machines, network wiring, and physical connections to storage – according to the diagram you choose to configure, of course.


2. Windows Server 2012 is installed on all nodes, and servers are domain-joined.


3. NICs are properly named. This is needed to make it easy for the scripts to find the right NICs to configure. Note that Windows Server 2012 actually supports a very cool new feature called Consistent Device Naming, which will make the need for this pre-requisite go away!


4. Windows PowerShell remoting is enabled on all nodes and the execution policy allows scripts to run. Otherwise, we can’t remotely control them, right? (Note that PowerShell remoting uses WinRM, and WinRM is actually on by default in Windows Server 2012).


5. Hyper-V role is installed on the appropriate nodes, and servers are rebooted as necessary. Note that this could easily be automated as well, but in our samples, we chose to assume the Hyper-V role is already there to avoid waiting for the necessary restart.


6. MPIO is installed -Depending on how you configure your access to storage, you might need to have MPIO installed and configured on the file server nodes.


So far, these are straightforward steps that you probably can do with any bare metal deployment system you have already in place. Now let’s get into the interesting part – how to make these servers be configured to act as a cloud.



In order to do that, it’s time to run the Windows PowerShell configuration script, and before you do, you may need to do some customization to the scripts, so let’s take a look at when you can find inside the package:


The Master Script


ConfigureCloud_Converged.ps1is the master script file that you should run on the management server. It contains the basic flow of configuring the different servers, with a flow that is roughly as follows:




The Settings File


The Settings_Converged.ps1 file contains the settings that ConfigureCloud_Converged.ps1 uses to know which nodes to configure and with what parameters. If you wanted to customize the configuration, that’s the file you’d have to edit.



Within the settings file, you can find two types of configurable items. The first is simply a series of PowerShell variables that you can use to tweak the environment. For example, if you choose to call your domain differently than the default “HCP” the samples use, you will want to edit these:


## Master Settings


$Domain       = 'HCP' # just the domain name, not the FQDN


$DNSDomain    = 'hcp.com'


$Gateway      =''


$DNSServer    = ''


$PrefixLength= 16


$DNSSuffix    = $DNSDomain




# Account whose credentials will be used to connect via CredSSP.


# Gets full cluster access to both clusters.


# Must be an administrator on all servers





Or, if you want to change the nodes that will be configured to be Hyper-V hosts, you can edit this section:


# Nodes of the Hyper-V compute cluster


$HVNode= @{


    Node1 =@{


        Name ="HC2N1"


        Address =""




    Node2 =@{


        Name ="HC2N2"


        Address =""






    Node3 =@{


        Name ="HC2N3"


        Address =""




    Node4 =@{


        Name ="HC2N4"


        Address =""








Last, there’s a section at the settings file dedicated to describing some additional metadata about the configuration. You will only need to change that if you want to change the way nodes are clustered, or use these generic scripts to configure a different configuration altogether.



# Per-cluster settings


$Cluster= @{


    HyperV =@{


        Name =$HyperVClusterName


        StaticAddress =$HyperVClusterAddress


        ClusterAccess =@(ClusterAccess -User@($ClusterFullAccessList) -Full)    


        QuorumDiskNumber =$HVNode[ $HVNode.keys ] |


            foreach-begin { $QuorumDiskNumber= @{} } -process{




                } -end { $QuorumDiskNumber }




        SpaceSettings =$Null



    } # End of Hyperv 


    . . .




} # End of Cluster


Helper Scripts

Within the “Helpers” folder, you’ll find the scripts that do the actual work of configuring a given node. This includes the ConfigureNetworking.ps1,ConfigureHyperVCluster.ps1 and other generic helpers.


You can find a short description of each of them in the readme file that’s inside the package.

These helpers are actually executed on the relevant target servers, and if you’d like, you can manually run them on the target servers without having to run the master script (ConfigureCloud) from remote.


For example, if you want to install the Hyper-V role on the Hyper-V nodes, you can just run InstallHyperV.ps1, which simply adds the necessary roles using this PowerShell:


Param ([string[]]$Features)


# Install necessary server features






$featurelist= @('Hyper-V','Hyper-V-PowerShell','RSAT-Clustering-PowerShell','Failover-Clustering')


if ($features) { $featurelist +=$features }


Add-WindowsFeature@( $FeatureList )






That’s it for today. In the next blog, we’ll take a look at the next package of scripts which will be focused on operational aspects of a cloud – on-boarding virtual machines, moving and monitoring them.


I hope you’ll find the scripts useful and valuable. If you do, please know that the TechNet ScriptCenter is actually a community site, which means you can and are encouraged to submit improvements to these scripts or additional scripts that you believe will be useful to the PowerShell community for cloud management.




One PowerShell to Rule Them All… Smile


Yigal Edery


Principal Program Manager


On behalf of the Windows Server 2012 Cloud Infrastructure Team


UPDATE: If you've read this far, then you're probably interested in part 2 of this series, which discusses managing virtual machines:



Go Social with Private Cloud Architecture! Private Cloud Architecture blog Private Cloud Architecture Facebook page Private Cloud Architecture Twitter account Private Cloud Architecture LinkedIn Group Private Cloud TechNet forums TechNet Private Cloud Solution Hub Private Cloud on the TechNet Wiki