Azure Infrastructure Services with PowerShell Quick Start Kit (http://aka.ms/QSK) Release Note

 

This quick start kit is available for download at http://aka.ms/QSK for self-studies of Microsoft Azure Infrastructure Services and Microsoft Azure PowerShell. It deploys a simple, yet well-structured, Microsoft Azure Infrastructure Services instance including:

• Affinity Group
• Storage Account
• Cloud Service
• VMs with attached data disk
• Availability Set
• Load-Balancer

Additional information of Windows Azure IaaS deployment methodology is available at:

• http://aka.ms/AzureIaaS1
• http://aka.ms/AzureIaaS2

The conceptual model of a Windows Azure Infrastructure Services deployment with QSK is showed as below:

Notice since the storage account is auto-created with PowerShell in QSK, by default Windows Azure optionally enables geo-replication of a storage account. Therefore the synchronization may take a little bit longer for creating or deleting a VM and its attached disks.

For each deployment, the RDP files of each deployed VM is also automatically downloaded to a designated local folder. Namely a VM user can access a deployed Windows Azure VM using the RDP file and VM user credentials, and without the need to log in Windows Azure management portal or acquire the Windows Azure subscription information. Further, accessing a deployed Windows Azure VM will be based on a self-signed certificate, if no PKI has been pre-configured for the VM.

QSK uses a user-specified prefix and a timestamp as a tag to eliminate any possible naming conflict within Windows Azure. This tag also makes resources in one deployment unique and easily identifiable by matching the tag. Hence, a user can execute the script multiple times to deploy multiple services and consume resources within what the subscription allows and without a naming conflict.

The following are additional resources and the history of a sample PowerShell session where I deployed two services by executing the script twice.

• Windows Azure IaaS Deployment Methodology
  http://aka.ms/AzureIaaSMethod
• Windows Azure Fault Domain and Upgrade Domain
  http://aka.ms/waFdUd
• Windows Azure cost estimation
  http://aka.ms/calculator
• Windows Azure pricing at a glance
  http://aka.ms/pricing
• Windows Azure support FAQ and SLA
  http://aka.ms/AzureFAQ
  http://aka.ms/AzureSLA

In Windows Azure Management Portal, the following shows what were deployed.

And the RDP files of deployed VMs were also downloaded to the local SQL folder as shown here.

To remove all deployed resources, the 4-step clean up routine as included in the script was run in sequence and one step at a time.

Azure IaaS Deployment Methodology with PowerShell (Part 2 of 2): Processing NetworkConfig.xml File

 

In Part One, I showed you important artifacts in Windows Azure IaaS. Why they are needed and the sequence to create and deploy them. To better manage all resources in a deployment, my best practice is to tag all deployed. I normally create a tag based on the current timestamp and add the tag as a prefix to all resources associated with a deployment.

Below as an example is a function I wrote to process and add a prefix to the Affinity Groups appear in a NetworkConfig.xml file which defines the virtual network configuration of a Windows Azure subscription. An Affinity Group is an artifact to be created and associated with a virtual network such that all VMs deployed to the virtual network will be in the region specified by the Affinity Group. I use this function as a template for processing a node in NetworkConfig.xml or other xml files.

To test this function, you can simply use the NetworkConfig.xml you downloaded form Part One or will need to first export the NetworkConfig.xml file from an intended Windows Azure subscription, and provide it as a parameter of this function which you can download from here.

The Tag should be something which once is added to a resource name will make the resource identifiable with a deployment. This will help and drastically simplify, for example, decommissioning resources of a deployment where by removing all resources with the same Tag. Particularly for demos, pilots, test runs, etc. it becomes very easy to process/delete a deployment as a whole. A sample call of the function while putting a target NetworkConfig.xml file in the root of c drive and using a timestamp as the Tag is like:

Tag_AffinityGroup –theNetcfgFile ‘c:\myNetworkConfig.xml’ –Tag (get-date –format ‘mmss’)

Here the Tag is a 4-byte string indicating the current minute and second. Since this Tag is to prefix an AffinityGroup name which in Windows Azure has a limit of 15 characters, the Tag can not be too long in size. The following shows a sample result that after calling the function, the Affinity Group is prefixed with a 4-character tag.

In Windows Azure Infrastructure Services (IaaS) Quick Start Kit (QSK), I will provide a routine for cleaning up deployed Windows Azure IaaS resources based on a specified prefix or pattern.

Windows Azure Infrastructure Services Deployment Methodology with PowerShell (Part 1 of 2)

 

[Part 2]

This blog post series is to examine key Windows Azure Infrastructure Services, (i.e. IaaS) concepts and deployment methodology. Part One presents the artifacts which together constitutes an IaaS deployment by walking through a scenario to configure a virtual network and deploy a VM to a target virtual subnets. Upcoming posts will introduce the considerations for automating a Windows Azure IaaS deployment with PowerShell. The content assumes a reader has and does not cover basic operations of PowerShell.

The samples presented in this post are for demonstration. A similar PowerShell script is available at http://aka.ms/QSK which is easier to run and without the dependency of virtual network.

Cloud Computing and IaaS Concept

• NIST SP 800-145
• Chou’s 532 Principle of Cloud Computing
• A supplement to NIST SP 800-145
• A memorandum to IT Professionals

Prerequisites

• To carry out the labs requires a Windows Azure subscription to deploy VMs. A free trial subscription is available at http://aka.ms/R2. Click the dropdown list to select “Windows Server 2012 R2 Datacenter on Windows Azure.”
• The PowerShell script examples shown in this post require Windows Azure PowerShell Cmdlets configured. Follow the instructions at http://aka.ms/AzureCmdlets to set up Windows Azure PowerShell Cmdlets and establish the connectivity between Windows Azure and the local device.

Windows Azure IaaS Artifacts and Deployment Methodology

There are a number of artifacts in Windows Azure IaaS to be considered for an deployment. The follow highlight the significance and presents a recommended sequence of creating and configuring them for a deployment. Not discussed in this post is how to decommission a deployment which should follow the sequence in a reverse order to remove the resources.

Affinity Group

This is a logical construct associated with a geo-region and defined at the subscription level. An Affinity Group is to keep specified services running in the same specified data center to minimize the latency, potentially lower the costs while achieving optimal performance. In Windows Azure Management Portal, go to SETTINGS workspace, as shown below, to configure Affinity Groups.

An Affinity Group has a fundamental impact on the performance of a deployment. For instance, associating an Affinity Group with a virtual network will ensure that all VM instances deployed to the virtual network are placed in the same data center of the region specified in the affinity group. Meanwhile, associating a storage account (which is where the VHDs are kept) with an Affinity Group will ensure that all resources using the same storage account are stored in the same data center in the region specified in the Affinity Group.

In the above examples, both a virtual network and a storage account are linked to the same Affinity Group. Which ensures both the VM instances deployed to the virtual network and the VHDs which the VM data are stored are in the same data center to optimize the performance.

An Affinity Group is a geo-location setting with performance implication and should be first planned in a deployment effort. Windows Azure PowerShell module provide four cmdlets relevant to managing an Affinity Group as shown on the left.

In a deployment project, create an Affinity Group first so all subsequently configurations and placements can reference the Affinity Group throughout the lifecycle. The next step is to ensure all deployment resources will be stored in the same data center of a region specified by the Affinity Group. When deleting an Affinity Group, must first delete the associated storage accounts.

Storage Account

A storage account provides the access to Windows Azure storage within a geographic region. There are three types of storage: Blob, Queue, and Table in Windows Azure. For Windows Azure IaaS, a VM must be stored in Page Blob which has a maximal size of 1 TB. By default, geographically redundant storage (GRS) is optional and enabled at a storage account creation time. GRS replicates data to a data center in a secondary location of the same geo-region. When turning off geo-replication, a storage account then becomes locally redundant storage (LRS) which stores data in a single data center location. 

Windows Azure creates two 512-bit management keys at a storage account creation time. An application will use one of the two keys to access the storage account. The monitoring and logging of a storage account will need to be enabled before activities are monitored and data is collected. Only then the charts on the dashboard and monitor page will present usage information . The following is a screen capture of the user experience of operating on a storage account with Windows Azure Management Portal.

On the right are the four Windows Azure PowerShell cmdlets frequently used in managing a storage account. Notice before deleting a storage account can be removed, first delete all VMs instances and disks deployed with this storage account.

Cloud Service

This is a logical container presented as a single URL to include application code and configurations, while together form a cloud service or simply a service. For Windows Azure IaaS, each VM is deployed to a service, however a service can contain multiple VMs. Placing multiple VMs into a service makes these VMs connected and visible to one another. Considering a multi-tier application, a cloud service can therefore be employed to host multiple tiers of VMs which form the application architecture or architectural component, while manage all VMs which are connected as one entity. This concept is revisited when examining VM deployment later in this post.

Notice when deploying a VM, one can choose to have Windows Azure create a cloud service which by default inherits the FQDN of the VM as the service name, or add the VM into an existing service which connects all VMs in the same service to form a target application/service architecture. One particular is worth mentioning that when there is only one VM in a cloud service, this cloud service will not be listed in CLOUD SERVICES workspace of Windows Azure Management Portal. A cloud service becomes visible in CLOUD SERVICES workspace when the service contains either no VM at all, or two or more VMs. And when deleting the only VM in a service, it takes a moment for the service to surface in CLOUD SERVICES workspace due to the synchronization of al the bookkeeping within Windows Azure.

The following screen capture depicts an application or service architecture formed with four cloud services while the frontend service is with two VM instances configured in separate upgrade and fault domains to minimize downtime.

From operational point of view, for better housekeeping and to avoid phantom services, i.e. those services with no resource deployment and no longer referenced, do delete a service after removing the last VM. There are also programmatic approach to manage a cloud service using Windows Azure PowerShell cmdlets including those shown on the right.

Two important artifacts of cloud computing are the so-called Fault Domain and Upgrade Domain. A fault domain is a single point of failure of hardware, while an upgrade domain is a logical grouping where an application is upgraded one upgrade domain at a time. Additional information is available at http://aka.ms/FaultDomain. Both will minimize, if not eliminate, the down time due to hardware outage or application upgrade. When a service are deployed with more than one VM instance, the SLA become effective and Windows Azure IaaS automatically configure fault domains and upgrade domains to ensure no single point of failure and minimize possible downtime. In a Windows Azure PaaS deployment, using service definition (.csdef) file a cloud service deployment can have up to twenty upgrade domains, while if not explicitly specified, a cloud service is defaulted to five upgrade domains.

With Affinity Groups, storage accounts, and services in place, the architectural components are in place and it is now to decide which servers goes where and how these components are connected, i.e. design the network topology which brings the process to deploying a virtual network.

Virtual Network

Windows Azure employs a configuration file, NetworkConfig.xml, to define the settings of a virtual network. A Windows Azure virtual network is essentially a customized set of network configurations implemented on demand at a data center of a geo-region explicitly specified or implied by an Affinity group. A virtual network is as the name suggested virtual and this network virtualization is isolated at a subscription level.

One productive way to acquire a NetworkConfig.xml file is to first in Windows Azure Management Portal interactively create a sample virtual network with Windows Azure Management Portal followed by exporting the configurations as shown below.

This NetworkConfig.xml file can be edited offline and later either interactively imported while creating a new virtual network or use PowerShell cmdlets to upload into an intended Windows Azure subscription.  A virtual network configuration encompasses a  name, DNS servers, cross-site connectivity, address space, subnet, name and masks, and gateway information. A sample NetworkConfig.xml without gateway connectivity is shown below:

Notice in the above configuration, the DNS server, foodns, is assigned with 10.2.1.4. The DNS settings are to be finalized at virtual network creation time, while no VM has been deployed yet. Here the address, 10.2.1.4, is specified since a DNS is planned to be the first VM deployed to 10.2.1.x subnet. Note that for a brand new subnet, Windows Azure IaaS reserves the first three IP addresses and 10.2.1.4 is the first IP address valuable for a VM deployment. This behavior is consistent with all virtual subnets. For instance, the first IP address available for a VM deployment in 192.168.x.x will be 192.168.x.4 since the first three applicable IP addresses are reserved by Windows Azure. The following screen capture illustrates a virtual network design based on the address, 10.2.0.0./16 with four subnets while in each subnet the first available IP address for deployment is 10.2.x.4.

Prior to any VM deployed to a virtual network, the associated DNS settings are changeable. Once a VM has been deployed to a virtual network, the DNS settings of the virtual network are no longer editable. Should there be a change needed the DNS settings, the virtual network will need to be recreated. Much planning does need to put in before deploying a virtual network. This is just like deploying a physical DNS, once in production with resources deployed, it can be very costly, if feasible at all, to change the DNS’ IP address.

The virtual network shown above employs the address space, 10.2.0.0/16, and is with 4 configured subnets: infra, data, collab, and service. This network is a simple branch office or business unit environment where: infra subnet holds infrastructure servers like domain controllers, DNS, DHCP Servers, Update Servers, etc.; data subnet hosts data stores like Microsoft SQL Servers; collab subnet is for placing collaboration servers like SharePoint; and service subnet runs the frontend IIS servers to receive and process incoming HTTP requests. A virtual network with various servers (i.e. VMs) deployed into target subnets and grouped into services can be automated using Windows Azure PowerShell. The following screen capture illustrates a partial deployment of an AD forest to a virtual network with six servers deployed into four target subnets. A Windows Azure PowerShell script carries out the deployment from zero to all in about thirty five minutes. An upcoming post will present the script used for this deployment.

Importing a NetworkConfig.xml and managing virtual network are fairly easy by employing the following Windows Azure PowerShell cmdlets below. Note that the Remove-AzureVnetConfig will delete the configuration from the current Windows Azure subscription.

A user can interactively or programmatically construct  a virtual network and deploy VMs to target subnets in minutes without the need to pull a single cable, nor be concerned with any server hardware. All needed is a browser, Internet connectivity, and a Windows Azure subscription. The requirements and time needed for an infrastructure deployment have been minimized to a unforeseen level by Windows Azure IaaS, while the capabilities have become global and exponential with cloud computing.

Windows Azure Virtual Network is a powerful feature and a crucial skill to have. For training, prototyping, or short-term networking needs, Windows Azure virtual networking offers tremendous capability and flexibility. For businesses of all sizes, branch office, and business units, Windows Azure IaaS and site-to-site or point-to-site connectivity introduces many new scenarios and exciting opportunities to extend, integrate, and transform an on-premises deployment into a hybrid cloud scenario. There is much information readily available in Windows Azure IaaS documentation and is not repeated here. IT professionals however must recognize that there is no other way to master Windows Azure IaaS without practicing, practicing, and practicing more on creating a virtual network, deploy VMs, and build an application architecture.

Virtual Machine

In this post-virtualization era, a VM has been come a baseline for constructing infrastructure. For deploying VMs, Windows Azure IaaS supports both Microsoft Operating Systems and non-Microsoft ones. The VM image gallery in Windows Azure Management Portal, as shown below, includes the latest releases and previews of  Windows Server, SQL Server, SharePoint, BizTalk Server, and many non-Microsoft workload like openSUSE, SUSE Linux, Ubuntu, OpenLogic, etc.

The creation of a VM with Windows Azure IaaS is a rather straightforward process and http://aka.ms/AzureVM outlines the tasks and operations. In general, a VM can be deployed in a matter of minutes. Deploying individual servers from hardware requirements to a running VM instance in minutes is now a reality and will soon become a new normal of IT server deployment.

One interesting observation of a Windows Azure IaaS deployment is that multiple VMs can be included in the same cloud service. This offers an opportunity to logically group specific VMs to form an application architectural component or architecture itself. For instance, a three-tier web application architecture like frontend, mid-tier, and backend can be all included in a cloud service such that all VMs are connected via the service to deliver the application. Alternatively each tier can be a service such that the frontend VMs are in a frontend service, mid-tier VMs are placed in a mid-tier service, and the backend are organized into a backend service while all three services collectively form the application/service architecture. The following schematic illustrates this concept.

On the right, this is a list of Windows Azure PowerShell cmdlets relevant to operating on VMs. Some perhaps need more practices are New-AzureVMConfig and Add-AzureProvisioningConfig. The former is for creating a VM configuration object which can be part of a new deployment or used for adding a VM to an existing deployment, while the latter provisions a configuration of a VM. A the end of this post, a Windows Azure PowerShell sample script is included to demonstrate the usage of these two statements.

From training, assessment, prototyping, development, to production, Windows Azure IaaS can shorten the go-to-market of an infrastructure deployment literally from months and weeks into hours and minutes. An application architecture can now be deployed as a service. And infrastructure deployment is becoming a facilitator to fast-forward an infrastructure project.

Availability Set

This is an essential part of a cloud deployment. An Availability Set is a logical group to signify the need for Windows Azure to prevent a single point of failure for all VMs included in the set. A single point of failure of hardware is the so-called Fault Domain. In Windows Azure a Fault Domain is a server rack. Those VMs instances added into an Availability Set in essence demand Windows Azure to deploy those instances to at least two or more fault domains, i.e. two or more server racks. Windows Azure IaaS makes configuring an Availability Set a very simple interactive mouse-clicking process while configuring a VM or after a deployment. The following is a screen capture depicting the user experience to configure a new service and an Availability Set during an interactive session of a VM deployment.

An Availability Set is an effective tool to ensure service availability. For instance, two Domain Controllers, DC1 and DC2, are paired as a backup to each other. At least one of the two servers should always be available for user authentications. Placing DC1 and DC2 into an Availability Set will guarantee there is no single point of failure of hardware between DC1 and DC2.

With Windows Azure PowerShell module, an Availability Set can be specified as part of the VM configuration as shown in the example at the end of this post. To create an Availability Set after a VM deployment, one can use Set-AzureAvailabilitySet.

Load Balancer

Typically a production web application will place a load balancer before the frontend web servers to distribute the incoming traffic for better server utilization and more predictable performance. In a traditional deployment, adding,  maintaining, and scaling a load balancer is a significant part of a web application since it adds additional hardware, software, complexities, security, maintenance, vendor dependency, etc. besides just costs.

Windows Azure IaaS offers a basic load balancer with a round robin algorithm. The process to create a load balancer is to first specify/open a standalone endpoint, i.e. a port and mark the checkbox to also create a load-balanced set with this endpoint of a VM followed by configuring the load-balanced set. The above right shows Windows Azure PowerShell cmdlets for adding a load-balanced set which is part of the operations of adding an endpoint. While shown below is the user experience to configure a load-balanced set.

Later when configuring additional VMs to be added into the load-balanced set, for each VM add an endpoint and specify this endpoint to be added to an existing load-balanced set.

And the result as shown below is a load-balanced set created in minutes by a few mouse-clicks. The process and operations are almost too simple and quick to believe.

Windows Azure PowerShell Skeleton for IaaS Deployment

The following is a sample script to demonstrate the methodology of deploy a Windows Azure IaaS VM. The script is supplemented with the NetworkConfig.xml shown earlier in this post. Before executing the script, I first established connectivity between My PowerShell ISE session and Windows Azure by following the instructions at http://aka.ms/AzureCmdlets.

Of the script, the first 19 lines are simply to assign values to variables. I separated out all variables from the main program to make it easier to test what-if scenarios. The main program starts from line 21 to line 51 following the methodology outlined in this post from creating an Affinity Group, a storage account, a service, to configuring and deploying a VM from line 35 to line 51. The VM configurations include an Availability Set at line 38 and a Load-Balanced Set at line 48. And finally, at line 53 the RDP file of the VM is also downloaded for accessing the VM remotely.

An execution of the above Windows Azure PowerShell script deployed the following resources. And notice the script configures and deploys a VM with dependency of the virtual network defined in the NetworkConfig.xml file. This script is a skeleton for demonstrating the deployment methodology.

 

Announcing Windows Azure Infrastructure Services with PowerShell Quick Start Kit (http://aka.ms/QSK)

This quick start kit is for learning or demoing Windows Azure Infrastructure Services and Windows Azure PowerShell cmdlets. I am making it available for download and asking you to tweet/facebook the landing page, http://aka.ms/QSK, for other IT pros to access this tool and better understand Windows Azure Infrastructure Services. Here is  a sample tweet:

• Download this Quick Start Kit  http://aka.ms/QSK by @yungchou & learn #Windows #Azure Infrastructure Services & #PowerShell. #AzureQSK

My intent is to get more IT pros aware of Windows Azure Infrastructure Services, and I thank you all for tweeting and helping more better learn Windows Azure. To demonstrate the user experience, I am also including a set of screen captures of two runs of QSK within the same PowerShell session in this post.

#region [synopsis] 
#————————————————————————-
# Windows Azure IaaS Quick Start Kit (http://aka.ms/QSK)
#————————————————————————-
#
# Copyright 2014. Yung Chou
# http://yungchou.com
# http://twitter.com/yungchou
#
# The content of this post is provided AS IS; with no warranties, and confers no rights.
#
# This script is available for download at http://aka.ms/QSK.
# It deploys a set of Windows Azure VMs and each with a data disk.
# For demonstrating a complete configuration, all VMs are configured
# with a load-balancer on port 80, and placed into a service.
# This deployment shows how to form the base of a multi-tier
# application architecture by deploying a set of VMs to a Windows
# Azure cloud service. BY default, the script assumes the QSK
# script is extracted into the folder, _QSK.
#
# Virtual network is not employed in this script.
#
# Initially, recommend validating only:
# (1) the id of this session,
# (2) the location of the extracted QSK, and
# (3) the Windows Azure subscription name.
# and running the rest of the script as it is and troubleshooting it
# as needed, till a successful run has been achieved before further
# customizing the script.
#
# Within a PowerShell session, this script allows multiple deployments,
# namely repeated executions. While each execution of the script,
# like pressing F5 in ISE, deploys a service of a specified number of
# VMs, while each VM with an attached data disk and all VMs are placed
# in a load-balancer on port 80.
#
#  +—————–< cloud service >————————–+
#  |                                                                                   |
#  |  Load-Balancer { VM-1, VM-2, … etc. } on port 80     |
#  |                                                                                   |
#  +—————————————————————–+
#
# So, for instance, executing the script twice will deploy two
# services and two sets of resources, while for each deployment
# the service and the resources are identified by the same tag
# with their names.
#
# ——–
# Note
# ——–
#
# The script has neither error handling, nor optimization of any kind.
# This package is intended for and only for facilitating on learning
# Windows Azure IaaS deployment methodology and Windows Azure PowerShell.
# Recommended improvements of this script include wait-time and return
# code handler.
#
# Please use the hash tag, #AzureQSK, in tweeter for discussing
# and sharing your enhancements made on this script.
#
# ——————–
# Pre-requisites
# ——————–
#
# 1. Windows Azure Subscription acquired from the dropdown of http://aka.ms/TakeAzure
# 2. Install and configure Windows Azure PowerShell based on http://aka.ms/AzureCmdlets
# 3. Download and extract the package to a local drive
#
# ———
# Usage
# ———
#
# 1. Open a web browser session, access http://manage.windowsazure.com, and
#    log in Windows Azure for verifying the results of executing the script.
#    Once the script is validated and a successful run, logging into the
#    management portal is optional.
#
# 2. Bring up PowerShell ISE on the local OS session and run, for example,
#    get-AzureLocation to test the connectivity with Windows Azure.
#    The connectivity between Windows Azure and your the local PowerShell
#    session must be in place, else the script obviously will not work.
#
# 3. Open this script and validate the required parameters.
#
#    Test particular statements of the script by highlighting the selected
#    statements followed by pressing F8 in ISE.
#
# 4. When ready, run the entire script by pressing F5 in ISE
#
#    And after having already produced a successful run, review and make
#    changes of the [optional customization] section, as preferred.
#
# 5. To remove deployed resources, run the statement one by one
#    by following the instructions in the clean-up routine.
#
# Recommend subscribing Yung’s blog, http://aka.ms/rss, and following him in
# Twitter, http://twitter.com/yungchou, to get the updates and additional
# content of Windows Azure IaaS and Windows Azure PowerShell.
#
# ————————–
# Additional Reading
# ————————–
#
#    http://aka.ms/AzureIaaSMethod
#
#endregion

Here’s the history of a PowerShell session where I deployed two services by executing the script twice.

In Windows Azure Management Portal, the following shows what were deployed.

          

To remove all deployed resources, the 4-step clean up routine was run on step at a time.

Windows Server 2012 R2 Installation Options and Features on Demand (Part 5 of 5)

This 5-part blog post series details the concepts, processes, and operations of Windows Server 2012 R2 installations options and the underlying technology, Features on Demand, as the following:

1. Introduction
2. Using DISM Command Line
3. Using Server Manager PowerShell Cmdlets
4. Switching Server Installation Options
5. Minimal Server Footprint (This article)

A quick review of these capabilities in Windows Server 2012 is included in http://aka.ms/7ways.

Server Installation Facts

There are two default installations offered by Windows Server 2012 R2 setup program: Server Core and Server with a GUI for either Standard or Datacenter edition. When performing a clean install of either installation option of the Datacenter edition, the hard disk space consumptions are around:

• Server Core: 4 GB
• Server with a GUI: 8 GB

The above measures were observed upon the initial login after a clean installation of respective server installation options. So the difference between the two is about 4 GB.

Roles and Feature Install State

There are three install states of a role or feature in Windows Server 2012 R2, namely Available, Installed, and Removed. When the payload of a role or feature is removed from current installation, the Install State in the output of Get-WindowsFeature is “Removed.”  In earlier build of Windows Server 2012, you may have seen the state as “Disabled with payload removed” instead.

To verify a specific install state of roles and features, simply filter out the output of Get-WindowsFeature accordingly. The following statement displays those roles and features have been installed, for example.

Get-WindowsFeature | where {$_.installstate -eq ‘installed‘ }

The following are the install states of roles and features for the two installation options.

Server Core

Server with a GUI

Based on the above two outputs Server with a GUI have three components which Server Core does not install. Graphical Management Tools and Infrastructure, Server Graphical Shell, and Windows PowerShell ISE. The two graphical components are relevant to server installation options as presented in Part 4.

Side-by-Side Store

This is the folder where the payload of a Windows server 2012 role or feature is stored. When a feature’s payload is removed from an installation, it is deleted form the side-by-side store at %SystemDrive%:\Windows\WinSxS. In such case, the output of Get-WindowsFeature will list the feature as  “Removed” state. Similarly, when a feature with a “Removed” state is added from an installation source, the payload is placed into the WinSxs folder. Consequently, the size of this folder varies as features workloads are removed or added.

The default size of the site-by-site store, i.e. c:\windows\winsxs, of a Server Core installation is around 3 GB with the following query directly executed in a Server Core command prompt, as shown below.

powershell “ls c:\windows\winsxs –r | measure –s length”

where ls and measure are aliases of Get-ChildItem and Measure-Object, respectively, in PowerShell.

Here the folder size of  is taken by running Get-ChildItem on recursively, i.e. while crawling through the directory structure, it sums up the size of each ChildItem in each folder.

While a Server with a GUI installation, the side-by-side store has a size of 5.3 GB  as shown below, Here since the GUI is in place we can easily get a folder size reading from the folder properties using File Explorer.

And we can run the same PowerShell statement in a command prompt as well as the following.

Minimal Server Footprint Example

With Features on Demand, we can now develop minimal server footprint by removing the payloads of all unwanted roles and features from a target configuration. Here is a sample process to develop a server image with minimal footprint for VM deployment. 

Step 1 – Define a target server configuration

Here, for example, the target server configuration is a clean install of Windows Server 2012 R2 Server Core VM as a baseline with the following roles and features removed.

Display Name	Name
Active Directory Certificate Services	AD-Certificate
Active Directory Domain Services	AD-Domain-Services
Active Directory Federation Services	ADFS-Federation
Active Directory Lightweight Directory Services	ADLDS
Active Directory Rights Management Services	ADRMS
Application Server	Application-Server
DHCP Server	DHCP
DNS Server	DNS
Fax Server	Fax
Hyper-V	Hyper-V

Step 2 – Build the target server configuration

In this example, freshly install of Windows Server 2012 R2 Server Core, followed by running Get-WindowsFeature to verify the roles and features put in place as shown below.

Step 3 – Remove the payloads of unwanted roles and features 

On a server instance with the target baseline configuration, run Uninstall-WindowsFeature with –Remove to remove the payloads of unwanted roles and features. The process is to run Uninstall-WindowsFeature with the parameter, –Whatif, first as shown below and examine the output with the expected results. Once all are confirmed, run the same statement without –Whatif to actually remove the payloads of unwanted roles and features.

Uninstall-WindowsFeature `
  AD-Certificate, `
  AD-Domain-Services, `
  ADFS-Federation, `
  ADLDS, `
  ADRMS, `
  DHCP, `
  DNS, `
  Hyper-V `
-Remove –Restart -Whatif

Notice in this example, to facilitate the operations in a Server Core VM, I placed the above PowerShell statement in two script files (one with and the other without –Whatif) in a VHD and dynamically attached the VHD to the VM using iSCSI controller in the VM settings of Hyper-V Manager. Then, in the VM used diskpart to take the VHD online, erased the readonly setting of the disk with diskpart’s attributes command as needed, then started a PowerShell session to run the uninstall-windowsfeature.with-whatif.ps1 and then uninstall-windowsfeature.without-whatif.ps1. As shown below, E: drive was where the VHD with the script files mounted.

The following is a screen capture of a PowerShell session where I:

1. first examined the side-by-side store of a Server Core installation before removing the payloads of unwanted roles and features,
2. performed a what-if test to verify removing payloads and the expected results,
3. carried out the actual payload removal, and
4. verified the number of files removed and the reduced size of the side-by-side store

And the output of Get-WindowsFeature also set the install state of the unwanted roles and features as “Removed” as shown below.

In this example, the side-by-side store of a clean install Server Core had 41,967 files with a total size of 3,136,861,233 bytes. And after removing selected payloads of unwanted roles and features, the side-by-side store then had 41,284 files and a total size of 3,082,661,112.

The significance of employing Features on Demand is not only the opportunity to develop a minimal footprint based on a target configuration and reduce the size, but the elimination of unwanted code is a strategic step for better securing servers, developing applications, and managing an IT environment.

Step 4 – Produce a deployment image with minimal server footprint

Run c:\windows\system32\sysprep\sysprep.exe in an admin command prompt and select Generalize and Shutdown to produce a deployment image with minimal server footprint of the target configuration specified on Step 1.

There are times for business needs, productivity, or a personal preference an administrator may want to restore selected roles or features on a deployed server instance. In this case, if the roles or features have been removed from the instance, i.e. with an install state, Removed, the Install-WindowsFeature statement must then include the –Source parameter with one or more installation sources. An installation source can be restored only to a server instance with the same version of source code. By default, Features on Demand uses Windows Update if not able to resolve any installation source.

Feature File Store

In a managed environment, we can set up file shared folders, as installation sources, to store the files required for installing the payloads of roles and features on server instances running Windows Server 2012 or later.They are in essence remote side-by-side stores. In this way, these shared folders can be employed as installation sources, as needed, and as well specified in Group Policy as the designated installation sources to better manage the installation process.

To create a remote side-by-side store, simply copy the Sources\SxS folder from a target version of Windows Server installation media to a folder followed by sharing it out with proper access rights for target users.

Group Policy of Features on Demand

A Group Policy setting is available in Windows Server 2012 R2 for configuring an installation source for Feature on Demand. In Administrative Templates\System node as shown below, look for “Specify settings for optional component installation and component repair.” This policy setting provides network locations for:

• Reinstalling the payload of a role or feature
• Repairing a broken OS installation

For multiple installation sources, use a semicolon to separate each. A location here must be either folder or a WIM file with fully qualified path. Notice that the latter must be with the prefix, win: and include the index of a target image in the WIM file in the format of win:<fully qualified path to WIM file>:index as illustrated below. In an event, this setting is needed, however not configured or it is disabled or not resolvable, the process will try to download source files from Windows Update.

A final note on Feature on Demand, when installing or removing a role or feature, Windows will observe dependencies on the administrator’s behalf. It is a best practice to first test the cmdlets, Uninstall-WindowsFeature and Install-WindowsFeature, by including the parameter, –Whatif, and verify the changes with expected results as demonstrated earlier in step 3.

Part [1, 2, 3, 4]

Windows Server 2012 R2 Installation Options and Features on Demand (Part 4 of 5)

This 5-part blog post series details the concepts, processes, and operations of Windows Server 2012 R2 installations options and the underlying technology, Features on Demand, as the following:

1. Introduction
2. Using DISM Command Line
3. Using Server Manager PowerShell Cmdlets  
4. Switching Server Installation Options (This article)
5. Minimizing Server Footprint

A quick review of these capabilities in Windows Server 2012 is included in http://aka.ms/7ways.

Windows Server 2012 R2 Installation Options

In Part 1, I talked about at server installation time, there are two installation options: Server Core and Server with a GUI, available. And the third installation option, Minimal Server Interface, is configurable after an installation is completed. Minimal Server Interface is basically a Server Core installation with Server Manager and MMC. And as needed, an administrator can switch among the three installation options with Features on Demand as detailed  in Part 1.

Key Components

The operations to switch installation options are on mainly two components: Graphic Management Tools and Infrastructure and Server Graphical Shell. The following shows where the two components are listed in Server Manager “Add roles and features” wizard and an output of PowerShell Get-WindowsFeature cmdlet, respectively.

Notice in Server Manager wizard, what we see are display names. When Server Manager is available, i.e. either in a Server with a GUI or Minimal Server Interface, we can simply use checkboxes of the two components to change installation options.

The output of Get-WindowsFeature as shown above on the other hand returns a table of Display Name,  (Class or Object) Name, and Install State listing out all the roles and features with their states. And the highlighted items are the corresponding part to what is shown in Server Manager wizard.

The following depicts the two components involving server installation options. The two components are with (class or object) names: Server-Gui-Mgmt-Infra and Server-Gui-Shell. 

Switching a Server Installation

In production, Server Core may be employed as a deployment standard. Which does not provide the server graphical UI like Server Manager or MMC at all. There are times it is more productive or as a preference to operate with the server graphical UI. In such case, an administrator can enable or disable the server graphical UI, namely switch the installation options by enabling or disabling the above mentioned components.

The process of switching from one installation option to another is very straightforward. There are four facts to remember:

• Server-Gui-Shell requires Server-Gui-Mgmt-Infra. Under the hood, these two components are installed together. However Server-Gui-Mgmt-Infra can be enabled without enabling Server-Gui-Shell, not vice versa.
• Enabling only Server-Gui-Mgmt-Infra does not enable Server-Gui-Shell, which resolves in Minimal Server Interface, i.e. Server Core with MMC, Server Manager, but not full graphical shell.
• Enabling Server-Gui-Shell automatically enables Server-Gui-Mgmt-Infra, the two together resolve in Server with a GUI, i.e. full graphical UI.
• Disabling only Server-Gui-Mgmt-Infra also implicitly and automatically disables Server-Gui-Shell, which resolves in Server Core user experience.

Operations

Using Server Manager PowerShell cmdlets as detailed in Part 3 below is the most straightforward way to switch a server installation option. Here are four sample statements to all possible scenarios.

• Switching to full server GUI regardless

  Install-WindowsFeature Server-Gui-Shell -Restart

• From Server Core to Minimal Server Interface (i.e. Server Core with Server Manager and MMC)

  Install-WindowsFeature Server-Gui-Mgmt-Infra -Restart

• From Minimal Server Interface or full GUI to Server Core

  Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -Restart

• From full GUI to Minimal Server Interface

  Uninstall-WindowsFeature Server-Gui-Shell –Restart

Notice that the above statements can include the parameter, –Source, to specify installation sources if the workload of an operated feature has been previously removed as shown below. By default, if an installation source is needed and not found or not specified, it will try to download the source from Windows Updates.

• Switching to full server GUI and installing the bits from the installation source on D: drive

  Install-WindowsFeature Server-Gui-Shell –Source d:\source\sxs

Or use the parameter, –Remove, as in the following sample to in addition to disabling the feature remove the associated workload from the side-by-side store as well.

• Switching to Server Core and completely remove the server graphical component from the installation

  Uninstall-WindowsFeature Server-Gui-Shell –Remove -Restart

Part [1, 2, 3, 5]

Windows Server 2012 R2 Installation Options and Features on Demand (Part 3 of 5)

This 5-part blog post series details the concepts, processes, and operations of Windows Server 2012 R2 installations options and the underlying technology, Features on Demand, as the following:

1. Introduction
2. Using DISM Command Line
3. Using Server Manager PowerShell Cmdlets  (This article)
4. Switching Server Installation Options
5. Minimizing Server Footprint

A quick review of these capabilities in Windows Server 2012 is included in http://aka.ms/7ways.

Server Manager PowerShell Cmdlets

For daily system administration, Features on Demand is available via Server Manager PowerShell cmdlets. To find out which PowerShell models are loaded or available, simply run:

get-module

get-module –listAvailable

as shown here:

If Server Manager PowerShell module is not already installed, it can be imported with

import-module ServerManager -passthru

Use get-command to list out and there are three cmdlets in ServerManager module as shown below..

Notice that Install-WindowsFeature and Uninstall-WindowsFeature replace Add-WindowsFeature and Remove-WindowsFeature, respectively. The latter two cmdlets were used to install features in Windows Server 2008 R2 and are now as aliases.

Identify Current State

The first thing to do is to always use Get-WindowsFeature to find out what roles and features are available and the current state of the machine. The output also reveals the precise Feature Names to use with Server Manager PowerShell cmdlets as shown below.

Display Name shows what we see in Server Manager graphical UI when adding or removing roles and features. The actual class or object names are listed under Name. The object name is what to use with Server Manager cmdlets. A checkmark preceding a display name means that the role or feature is currently installed as indicated by what is shown in the Install State column as well.

Install/Uninstall Windows Roles and Features

To disable a Windows feature, use the Uninstall-WindowsFeature cmdlet. This makes a feature unavailable, however the associated payloads are still in place. Basically the feature is disabled, nevertheless the associated code is still there. This also means the feature can be easily restored by Install-WindowsFeature without reinstalling the source code.

The following are PowerShell examples to disable and later re-enable the feature with the display name, Server Graphical Shell, and Server-Gui-Shell (which is a feature component under User Interfaces and Infrastructure) as the corresponding parameter name on the local machine. In Part 4 of this series, it will become evident that this particular component is relevant to a server installation option. 

Uninstall-WindowsFeature Server-Gui-Shell -Restart

Install-WindowsFeature Server-Gui-Shell -Restart

Again the above operations basically make Server Graphical Shell unavailable without actually removing the associated code from the local machine, or enable Server Graphical Shell based on already installed code on the local machine. Since there is no code being removed or added, the footprint of the installation is not changed.

Conceptually, the uninstalling and installing a Windows feature with PowerShell work similarly to the Remove Roles and Features Wizard in Server Manager. However contrary to the Wizard which installs management tools by default, neither Uninstall-WindowsFeature nor Install-WindowsFeature installs the management tools for roles, role services, and features unless the parameter, IncludeManagementTools, is specified. In addition, since changing a Windows feature requires elevation, both cmdlet must be running in a Windows PowerShell session as an administrator. For more information, run Get-Help on these cmdlets with the parameter, Full, as the following:

Get-Help Uninstall-WindowsFeature –Full

Remove Payloads

To remove the payloads of a Windows feature, use the Uninstall-WindowsFeature cmdlet with the parameter, Remove, similar to the statement below. Here, payloads of the component, Server-Gui-Shell, is removed from the local installation.

Uninstall-WindowsFeature Server-Gui-Shell –Remove -Restart

This cmdlet uninstalls features and removes the payloads from a specified computer. Notice that with the parameter, Remove, it now uninstalls and deletes the features from the side-by-side store, located at %SystemDrive%:\Windows\WinSxS

Running Uninstall-WindowsFeature with the parameter, Remove, brings the feature to a state, “Disabled with payload removed.” You will see this shown in the “Install State” column of those roles and features with payloads removed from the output of Get-WindowsFeature.

Reinstall Payloads

To reinstall features with the state, “Disabled with payload removed”, an administrator runs Install-WindowsFeature cmdlet with the parameter, Source, for specifying the location of an installation source. And the source must be from the exact same version of Windows for the reinstallation to work. Without the parameter, Source, PowerShell will use Windows Update by default to look for an installation source. The following statement restores server graphical shell from a side-by-side folder is in D drive, for example.

Install-WindowsFeature Server-Gui-Shell –Source d:\source\sxs

The cmdlet restores specified roles, role services, and features on a computer that is running Windows Server 2012 and later, or on an offline virtual hard disk (VHD) on which Windows Server 2012 and later is installed. With the parameter, Source, referencing either a network path or the path to a Windows image file (WIM), Install-WindowsFeature can reinstall the associated payloads to the local side-by-side store.

[To Part 1, 2, 4, 5]

Windows Server 2012 R2 Installation Options and Features on Demand (Part 2 of 5)

This 5-part blog post series details the concepts, processes, and operations of Windows Server 2012 R2 installations options and the underlying technology, Features on Demand, as the following:

1. Introduction
2. Using DISM Command Line (This article)
3. Using Server Manager PowerShell Cmdlets
4. Switching Server Installation Options
5. Minimizing Server Footprint

A quick review of these capabilities in Windows Server 2012 is included in http://aka.ms/7ways.

Features on Demand

This is available for Windows Server 2012 and later and Windows 8 and later as well. Features on Demand signifies the ability to not only disable Windows features, but remove the payloads of Windows features from an OS installation or a system image. Payloads here is referred as the binaries for all components, permissions, registry settings, etc. of a feature. When uninstalling features in Windows Server 2012 and later there are now two options. One is to disable (i.e. uninstall) them while keeping the payloads in place, and the other is to uninstall and remove the payloads completely.

By removing the payloads of unwanted features from a target configuration, one can develop a minimal footprint, maintain a minimal attack surface, and conserve disk space. In addition, a feature once completely removed can still be restored by installing the associated binaries back from installation sources which includes a Windows WIM file, an expanded DVD, and a network location with Windows installation files and Windows Update. Features on Demand essentially enables Windows Server 2012 R2 with an ability to dynamically add or remove source files. This offers an opportunity to minimize an OS footprint of a target configuration as later examined in Part 5.

Using DISM Command Line

Features on Demand can be realized with the Deployment Image Servicing and Management (DISM) command line interface as well as DISM PowerShell cmdlets. Here are samples of using DISM online cmdlet relevant to Features on Demand are:

• dism /online /get-features /format:table
  dism /online /get-featureInfo /featureName:iis-asp
• dism /online /get-packages /format:table
  dism /online /get-packageInfo /packageName:Package_for_KB2880289~31bf3856ad364e35~amd64~~6.3.1.0
• dism /online /enable-feature /featureName:iis-asp /all [/source]
  dism /online /disable-feature /featureName:iis-asp [/remove]

Here I am using iis-asp as an intended feature and Package_for_KB2880289~31bf3856ad364e35~amd64~~6.3.1.0 as a target package, for example.

Identifying Current State

The first thing to do is to always use dism /online /get-features to find out what features are available and the current state. The output also reveals the precise Feature Names to use with a DISM online command as shown below. For additional feature information, use /get-featureInfo with the argument, /featureName:.

Here a feature shown as Disabled indicated that the feature is not available however the payload is still in place. And one important capability of Features on Demand is to not only disable, but also remove or restore the payload of a feature as presented later in this article.

Regarding packages, run  dism /online /get-packages /format:table to list out the packed names as illustrated below. And use /get-packageinfo with the argument, /packagename:, to display additional package information like dism /online /get-featureinfo /featureName:tftp to display TFTP feature information.

Removing Payloads

To disable or enable features, use /disable-feature or /enable-feature with the argument, /featureName: , to specify an intended feature for DISM to process. Multiple /featureName arguments can be used if the features are components in the same parent package. Add /remove to remove the payloads without removing the feature’s manifest from the image. Once the payload is removed, a feature will have the status, ‘Disabled with Payload Removed.’

To find out the status of a feature, use /get-features or /get-featureInfo. The following is a sample of disabling the features, iis-asp and iis-cgi, followed by issuing a /get-feature to verify the status. Notice now the status of these two features are showing as Disabled with Payload Removed.

Restoring Payloads

With Features on Demand, a feature at the status, Disabled with Payload Removed , can be restored and enabled using /enable-feature with the following arguments.

• /source

This is required to specify the location of the source files for restoring the feature which has previously been removed from an installation or image. And multiple /source arguments can be used.

• /limitAccess

This optionally prevents DISM from contacting Windows Updates or WSUS.

• /all

This optionally enables all parent features of the specified feature.

• /packageName

There is no need to specify this argument, if a feature is part of the Windows Foundation Pac. Otherwise, use /packageName to specify the parent package of a feature.

For example, the following DISM statement issued by a domain administrator, as shown below and in the screen capture, enables the feature, iis-asp, and all required parent features on the local installation, while referencing the source of an existing installation at \\dc\c$\windows\winsxs. The /limitAccess option is here to ensure Features on Demand will not try to access Windows Update if the specified source file is not found.

dism /online /enable-feature /featureName:iis-asp /all

/source:\\dc\c$\windows\winsxs /limitAccess

Now the feature, iis-asp, has a new status, Enabled, as opposed to earlier as Disabled with Payload Removed.

This is simply for demoing a functional statement, and of course by no means a recommended practice to remotely access the Windows directory of a Domain Controller for restoring a Windows feature of a machine. The locations of Windows sources should be part of the rollout planning and can be better managed with Group Policy.

Group Policy Option for Features on Demand

In Windows Server 2012 and later, a Group Policy option is available for configuring an installation source for domain joined clients. This setting, is at Administrative Templates\System node and named “Specify settings for optional component installation and component repair” as shown below.

Notice if an installation source is not found, Features on Demand by default will attempt to acquire the files from Windows Update. The following illustrated a setting with a source from the third image of the Windows Server media.

Here, the third indexed image is a Windows Server 2012 R2 Datacenter edition Server Core image as revealed by querying the image information with the statement, shown below, where a Windows Server DVD is placed in drive H:.

dism /get-imageInfo /imageFile:h:\sources\install.wim

[To Part 1, 3, 4, 5]

Windows Server 2012 R2 Installation Options and Features on Demand (Part 1 of 5)

This 5-part blog post series details the concepts, processes, and operations of Windows Server 2012 R2 installations options and the underlying technology, Features on Demand, as the following:

1. Introduction (This article)
2. Using DISM Command Line
3. Using Server Manager PowerShell Cmdlets 
4. Switching Server Installation Options
5. Minimizing Server Footprint   

A quick review of these capabilities in Windows Server 2012 is available at http://aka.ms/7ways.

Introduction

Either Windows Server 2012 R2 Standard or Datacenter Edition is available with two installation options, Server Core and Server with a GUI, as shown below taken during a server setup process using a Windows Server 2012 R2 evaluation iso file.

Server with a GUI is an installation option that many IT professionals are familiar with. It has the desktop shell and GUI components with applications including Server Manager, Internet Explorer, File Explorer, Microsoft Management Console, etc. While Server Core, first introduced in Windows Server 2008, is an installation without GUI components and intended for running with limited server roles and features.

Prior to Windows Server 2012, an installation option is committed at the server setup time. The selection of an installation option made during the setup process cannot be changed, once a server installation is completed. In other words, if Server Core is selected as the installation option, once it is installed, an administrator will not be able to change a Server Core installation into a Server with a GUI one without reinstalling the server. This limitation has been removed in Windows Server 2012 and later.

Either a Server Core or Server with a GUI installation of Windows Server 2012 R2, an administrator can change from one to the other, and back and forth as needed. In fact, there is another installation option called Minimal Server Interface which is configurable after an installation is completed and basically a Server Core installation with Server Manager and MMC. And an administrator can switch among the three installation options: Server Core, Minimal Server Interface, and Server with a GUI in an ad hoc fashion as illustrated below. This ability of changing a server installation option without reinstalling the server itself is a benefit from a capability called Features on Demand.

[To Part 2, 3, 4, 5]