Summary: Guest blogger, Yung Chou, talks about using Windows PowerShell to develop a minimal footprint with Features on Demand.

Microsoft Scripting Guy, Ed Wilson, is here. Today I have another guest blog post from my fellow Microsoftee, Yung Chou. Yung is a developer experience evangelist; and therefore, he spends a decent amount of time talking to developers who are using Windows PowerShell. He maintains a blog on WordPress that contains some very useful information: YungChou: Witnessing a Clear Cloudy Day. Take it away Yung…

Since Windows 8 and Windows Server 2012, IT has the capability to not only disable features, but to actually remove the associated payload—that is, the binaries or source files from a Windows image, an offline VHD file, or a running Windows instance. This capability is also referred as Features on Demand.

For more information, see Windows Server 2012 R2 Installation Options and Features on Demand.

DISM and Server Manager include Windows PowerShell cmdlets. IT can easily use Windows PowerShell cmdlets to customize and develop a deployment image with a minimal footprint by removing the payloads of all unwanted features, based on business requirements.

This post presents a sample process and operations for developing a minimal server footprint by using Features on Demand with Windows PowerShell cmdlets for Server Manager. I will first describe a few important artifacts.

Side-by-side store

This is a repository of source files for Windows roles and features. Hereafter, I will use “roles and features” interchangeably with “Windows features” or simply “features.” When Windows installs, selected features are installed and a default set of source files are populated from an installation media to the side-by-side store. This store is located at: C:\Windows\WinSxS. Later, as Windows features are removed or restored, source files are deleted or copied back into the store from an installation source. Therefore, a change of the folder size of a side-by-side store is the main indicator of the change made by Features on Demand on the footprint of an associated Windows installation.

Installation source

When the source files of a Windows feature are removed from a side-by-side store, an administrator must specify an installation source when trying to restore the feature. By default, Features on Demand looks for an installation source in the following order:

• The side-by-side store (C:\Windows\SxS of a destination server or specified locations)
  An installation source location can be a reference to: the side-by-side store of a Windows installation, the Sources\SxS folder of a Windows installation media, a network share with a copy of Sources\SxS, or a Windows image file.
• An associated Group Policy setting, as applicable
  In a managed environment, an administrator can standardize the source file locations of Windows features in a Group Policy Object (GPO), as shown in the following image. When there is a need to restore a Windows feature, Features on Demand will reference designated locations for an installation source.

• Windows Update
  This can be prevented by using the previous GPO setting.

The considerations of an installation source is well documented in the Add Roles and Features Wizard in Server Manager as shown in the following images:

Notice that in a default installation of Windows, .NET Framework 3.5 is removed, and it needs to be installed from Windows Update or a specified installation source using Features on Demand. I will further discuss this later in this post.

Windows PowerShell cmdlets for Server Manager

There are three cmdlets that are directly relevant to Features on Demand:

• Get-WindowsFeature
• Install-WindowsFeature
• Uninstall-WindowsFeature

For more information, see Server Manager PowerShell Cmdlets.

Get-WindowsFeature is used to query the current states of features that are included in the manifest (metadata or all features recognized by a Windows installation). This should always be the first cmdlet run in a Features on Demand process to verify the states and object names of target features.

Install-WindowsFeature is used to install a feature or to restore one if it was previously removed (with the source files deleted).

Uninstall-WindowsFeature is used to uninstall a feature or remove the feature including source files from a Windows installation.

Install-WindowsFeature and Uninstall-WindowsFeature include the important -Source parameter and a number of useful switches, including –Remove, -WhatIf, -Confirm, -Computer, -VHD, -IncludeAllSubFeature, and -IncludeManagementTools.

This post focuses on the overall process and operations of Features on Demand, and it does not repeat what has already well been documented. If you need a better understanding of how these three cmdlets work, take time to review the Windows PowerShell Help file. It provides a great and convenient reference about the usage, including available parameters, switches, and examples.

Minimal footprint of a Windows installation

Let's consider Server Core as an example. Assume the objective is to produce a minimal footprint of a default Server Core installation. One approach is to do a clean Server Core installation followed by installing and removing features, based on business requirements. For simplicity, here I simply do a clean Server Core installation followed by removing all the features that are not installed by default. This demonstrates producing a minimal server footprint by removing the source files of all unwanted features.

Notice that this scenario is hypothetical, and it is designed to demonstrate the effectiveness and operations of Features on Demand. It is not necessarily a typical or recommended approach. In a real-world implementation, IT should verify that target functionality is continually performing as expected in a Windows installation as unwanted Windows features are incrementally removed or added. IT should also examine the size of a destination server’s side-by-side store to conclude a minimal footprint, based on business requirements.

Features on Demand process and operations

Before making any changes, we should always review and document the before and after states of target features and the sizes of the side-by-side store of a destination server. First, record the current sizes of the side-by-side store (C:\Windows\SxS) in a clean Server Core installation. This information is for later confirming the changes made. The following image shows the results of dir/s from the command prompt of a clean Windows Server 2012 R2 Server Core installation.

Then run Get-WindowsFeature to review the states of target features, as shown here:

Notice that there are three columns in the output of Get-WindowsFeature:

• On the left are the display names, which are those names displayed in the Add Roles and Feature Wizard of Server Manager.
• In the middle, Name, is the class or object name of a role or a feature. An object name is how to specify a feature with the three Server Manager Windows PowerShell cmdlets.
• The Install State column includes three regular states. Available implies the source files of a feature are locally available in the side-by-side store. Installed is self-explanatory. Removed denotes that the source files of a feature are removed from the side-by-side store.

The following image shows using Get-WindowsFeature with a Where clause to filter the InstallState to easily verify what features are installed by default in a Server Core installation.

After identifying the features and changes to be made, it is a time to take a snapshot of the destination server. This ensures that the destination server can fall back to the state before changes were made, if necessary. In this example, the changes are to remove all features that are not currently installed, and this can be carried out with the following statement:

Get-WindowsFeature | Where {$_.InstallState -Match "Available"} | Uninstall-WindowsFeature  -Remove -Confirm -WhatIf

It first pipes all features of a destination server into the Where clause. Then all those features not installed yet with source code in the side-by-side store (that is, with the state as Available) are passed to the Uninstall-WindowsFeature statement for deletion.

When you use the Uninstall-WindowsFeature cmdlet to delete source files of a feature, all features that depend on the files being deleted are also removed. If you delete source files and no other dependencies for the parent feature remain installed, files for the entire parent feature are deleted. There are a number of switches important to consider with Uninstall-WindowsFeature, including:

• -Remove
  Use to uninstall and delete source files of specified features from the current side-by-side store.
• -IncludeManagementTools
  Use to uninstall associated management tools of a feature.
• -Confirm
  Use to prompt for user confirmation before running the cmdlet.
• -WhatIf
  Use to show what would happen if the cmdlet runs.
• -VHD
  Use to provide the path to an offline VHD file.
• -Restart
  Use to specify that the destination computer is to be restarted automatically.

Importantly, Uninstall-WindowsFeature works similarly to (yet, not exactly the same) as Server Manager Remove Roles and Features Wizard, which is shown in the following image.

Unlike the Remove Roles and Features Wizard, the cmdlet by default does not remove the management tools and snap-ins for a feature. To remove associated management tools, you must include the -IncludeManagementTools switch with the cmdlet. When uninstalling features from a Server Core installation beginning with Windows Server 2012, this switch removes the command-line and Windows PowerShell management tools for the specified features.

To remove features from an offline VHD, the best practice is to include both -ComputerName and -VHD. The former specifies the server for mounting the VHD file, and the latter provides a path to the VHD file on the specified server. Providing the server name and the VHD file location ensures that the mount operation is carried out as specified for accessing the VHD file.

The best practice for implementing Uninstall-WindowsFeature is to always use the –WhatIf switch to verify and document the changes to be made. Then run the statement without –WhatIf and with –Confirm. The following images show a test run followed by an implementation.

Now examine the side-by-side store information with dir/s after the deletion, as presented in the following image:

The following table shows statistics for the side-by-side store when we compare the clean installation with the removal of all uninstalled features:

So the size reduction of the side-by-side store is about 641 MB after removing 8,270 files. The physical size of the VHD file is reduced by 65 MB. In addition:

• The installation is cleaner, without extraneous code (hence, the minimal footprint of current configuration).
• Removed features can be restored on demand.

If we compare the overall delta of drive C, the increased free space is about 942 MB. The 300 MB difference between the increased free space and the reduced size of the side-by-side store is due to user profile, temp storage, application data, and so on. Hence, these numbers may vary case by case. Above all, a fundamental strategy to minimize the footprint of a standardized Windows installation is to eliminate the source code of unwanted Windows features, based on business requirements.  

Minimal server interface

With Features on Demand, one capability is that an administrator can switch among installation types on demand. For more information, see Windows Server 2012 R2 Installation Options and Features on Demand (Part 4 of 5).

In addition, there is a Minimal Server Interface option available by changing Windows GUI components after an initial installation is completed. The Minimal Server Interface is similar to a server with a GUI installation, but Internet Explorer, Windows Explorer, the desktop, and the Start screen are not installed. However, the Microsoft Management Console (MMC), Windows PowerShell ISE, Server Manager, and a subset of Control Panel are in place.

Here’s how to change from Server Core to Minimal Server Interface by adding the GUI component, server-gui-mgmt-infra. For more information about Windows installation types and GUI components, see my series: Windows Server 2012 R2 Installation Options and Features on Demand.

In the previous example, I used Windows installation media to demonstrate how to reference a particular installation type with –Source. Notice that a Server Core installation does not include the GUI components, so referencing index 1 or index 3 for installing a GUI-related feature will result in an error message. This message warns the system is not able to locate the installation source as specified by –Source; although when adding other features, the same location seems to be working fine.

After the server-gui-mgmt-infra component is installed with a Server Core installation, Minimal Server Interface is in place. After a reboot, Server Manager will start automatically. This is by design. At this time, the MMC and the Windows PowerShell ISE, which have a dependency on server-gui-mgmt-infra are also available as shown here:

Installing .NET Framework 3.5

Another vivid example of Features on Demand is the installation of .NET Framework 3.5. Beginning with Windows 8 and Windows Server 2012, installations do not include the source files of .NET Framework 3.5. However, it is listed an add-on in Programs and Features on the Control Panel of Windows 8 and in the Add Roles and Features Wizard from Server Manager in Windows Server. The following two images show these menus:

Beginning with Windows 8 and Windows Server 2012, the source code for .NET Framework 3.5 is included in folder, Sources\SxS.

Essentially, in a default installation of Windows, .NET Framework 3.5 is installed by design from Windows Update, based on Features on Demand. Therefore, without accessibility to Internet, or more specifically Microsoft Windows Update, installation of .NET Framework 3.5 will fail unless an alternative installation source is provided and available without accessing Internet.

By using Windows PowerShell cmdlets for Server Manager, the following statement will install .NET Framework 3.5 at a destination server in an isolated environment. Here Windows installation media is available on drive D.

Features on Demand enables IT pros to minimize the footprint of a Windows installation by eliminating the source code of unwanted Windows features, based on business requirements. Windows PowerShell is a productive and readily available tool to use with Features on Demand. Features on Demand is essential to better deliver and secure the workload, and Windows PowerShell scripting is becoming a critical skill for performing day-to-day work.

~Yung

Thank you, Yung, for a most interesting and comprehensive post. Join me tomorrow for more way cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy