witnessing a clear cloudy day
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:
A quick review of these capabilities in Windows Server 2012 is included in http://aka.ms/7ways.
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.
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:
Here I am using iis-asp as an intended feature and Package_for_KB2880289~31bf3856ad364e35~amd64~~18.104.22.168 as a target package, for example.
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.
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.
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.
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.
This optionally prevents DISM from contacting Windows Updates or WSUS.
This optionally enables all parent features of the specified feature.
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
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.
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