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:
- Introduction
- Using DISM Command Line
- Using Server Manager PowerShell Cmdlets
- Switching Server Installation Options
- Minimizing Server Footprint (This article)
A quick review of these capabilities in Windows Server 2012 is included in https://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 |
DHCP Server |
DHCP |
DNS Server |
DNS |
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:
- first examined the side-by-side store of a Server Core installation before removing the payloads of unwanted roles and features,
- performed a what-if test to verify removing payloads and the expected results,
- carried out the actual payload removal, and
- 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.
This is a cross posting from https://yungchou.wordpress.com.