Features on Demand in Windows 8 and Windows Server 2012

This was written by a co-worker of mine, Jim Collins.

Features on Demand is a new feature in Windows 8 and Windows Server 2012 that will allow you to remove files associated with specific roles and features, typically referred to as payload files. The major benefit of this feature is to conserve disk space. Once removed, these binaries will need to be added back from a valid installation source before the feature can be used again. Unlike the stage and un-stage process used by the component store, Features on Demand removal results in a permanent removal of those binaries. Available sources include Windows 8/Windows Server 2012 WIM files, an expanded Windows 8/Windows Server 2012 DVD (flat), an available network location with Windows 8/Windows Server 2012 installation files and Windows Update.

Removing Roles/Features from a computer using Features on Demand

First let’s talk about removing Roles and Features from an installed Operating System. Features on Demand is exposed via the DISM command line interface as well as the new DISM and Server Manager Windows PowerShell cmdlets. Below are examples of the new DISM and Server Manager Windows PowerShell cmdlets.

DISM PowerShell Cmdlet

Server Manager PowerShell Cmdlet

It’s important to note that in Windows 8 features on demand is only exposed via DISM and DISM PowerShell cmdlets. This is important because DISM does not understand the parental dependencies. So DISM will only remove the packages you specify and will not remove any dependent packages, if they exist. For this reason it is highly recommended to only use the Server Manager PowerShell cmdlets to remove features in Windows Server 2012.

Below I will give an example of how you would remove the payload for the Windows Server Backup feature using all three methods:

DISM:

DISM.exe /Online /Disable-Feature /Featurename:WindowsServerBackup /Remove

To verify the payload has actually been removed you would run the following:

You can see from the above screenshot, that the State is Disabled with Payload Removed

DISM PowerShell Cmdlet:

Disable-WindowsOptionalFeature –Online –FeatureName WindowsServerBackup –Remove

To verify the payload has actually been removed you would run the following:

You can see from the above screenshot that the State is DisabledWithPayloadRemoved

Server Manager PowerShell Cmdlet:

Remove-WindowsFeature Windows-Server-Backup –Remove

To verify the payload has actually been removed you would run the following:

You can see from the above screenshot, that the Install State is Removed

To get a list of all Roles/Features that have been Removed you can run the following command

Get-windowsfeature | Where-Object {$_.InstallState -eq "Removed"}

Removing Roles/Features from an installation source

An administrator can also remove Roles and Features from an installation source so that they can reduce the size of their image as well as limit the Roles and Feature a specific group will have available to them. In this scenario, administrators must consider some factors to ensure the removal does not inversely effect the environment. First you will need to know what type of installation source will be used when adding roles or features back to the image. You will also need to take into account how much disk space will be needed for the addition of Roles and Features. Administrators will want to keep at least 10 GB of space free for potential component store growth.

Below are the steps to remove the Windows Server Backup feature from an installation source

1. Copy the installation WIM to a local directory (in this example C:\)

2. Create a mount directory to mount the WIM to (in this example C:\image)

3. Find the index of the image you will be editing:

DISM /get-imageinfo /imagefile:c:\install.wim

4. Mount the image to the folder created in step #2:

DISM /mount-image /imagefile:c:\install.wim /index:3 /mountdir:c:\image

5. Remove the Feature from the image:

DISM /image:c:\image /disable-feature /featurename:WindowServerBackup /remove

6. Verify the state of the feature is removed:

DISM /image:c:\image /get-featureinfo /featurename:WindowsServerBackup

7. Commit the changes to the WIM:

DISM /unmounts-image /mountdir:c:\image /commit

8. Prepare the image for deployment by adding it to a WDS or MDT deployment point.

--Joseph

Comments

• Anonymous
  January 01, 2003
  DISM is faster than WUSA because it doesnt check dependancies, it just does what you tell it to do.  Thats the advantage to WUSA, it will actually let you know if applicability fails via UI.  I'll bring this up the next time I talk to the PG though.

• Anonymous
  January 01, 2003
  @Drew, Mike knows far more about this area than I do, if he's even remotely involved then any fix will most likely come from his side.  I would use the workaround for now.

• Anonymous
  January 01, 2003
  @Jon; Not easily, no.  The best way to think about this would be how many dependencies does a certain role or feature have?  For example, something like IIS has a lot of dependents so it would take up more space than something like BitLocker.  You could theoretically walk all of the dependency chains backwards to find out how many manifests are involved but you still might not know the payload. I'll bring this up with the feature teams as a request though, makes a lot of sense. --Joseph

• Anonymous
  January 01, 2003
  Is there a way to find out the size impact (even roughly) of each feature? I'd like to remove features to recover hard drive space, but I don't know which features take up the most space.

• Anonymous
  January 01, 2003
  WUSA uses the WU API and this is slower. WU checks if the features are installed and if the updates is really needed and this takes some time. But a fix is to stop WU service each time before installing an update with WUSA. This speeds up the installation.

• Anonymous
  January 01, 2003
  Not convenient. That is why DISM should directly support installing MSUs (and do all the work of extracting CABs into a temp directory behind the scenes). Just adding that ability will speed up installation times of MSUs because DISM is faster than WUSA.

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  Everything needs a GUI. DISM is too unintuitive.

• Anonymous
  January 01, 2003
  Also DISM should support installing MSU files like it does for CABs. Can that be added? WUSA is too slow compared to DISM.

• Anonymous
  November 25, 2012
  Maybe a GUI would be nice, but DISM and the deployment toolset is pretty powerful at this stage, and one area of Windows where things are definately advancing all round. But me, i like commands and scripting, others don't. One problem that currently exists for me and others is this error: social.technet.microsoft.com/.../a9918617-200a-42b3-af80-bb27ddccc8fe This means that attempting to deploy Win7 from WinPE 4.0 can't be fully automated, as far as i know, due to this unavoidable error (related to short file names disabling). Problem is i really want to use the ADK version of DISM. So i learnt how to do this by starting with WinPE 3.1 and then copying the ADK ... Deployment Tools<arch>DISM folder to the PE 3.1 drive, in my case to S:ADK_DISM and then running S:ADK_DISMwimmountadksetupx86.exe /install Works like a treat. However, i also want to use PowerShell from WinPE. This requires WinPE 4.0. What should i do; just stop using Setup.exe for Win7 and do what Michael Niehaus suggests (in that thread)? I would more comfortable with continuing to use Setup.exe if possible. Joseph, please help! :-)

• Anonymous
  November 26, 2012
  Ok. Thanks Joseph. Thanks for the post, Jim.

• Anonymous
  February 08, 2013
  "Everything needs a GUI. DISM is too unintuitive." The dumbing down of the administrator. It's sad.