Freigeben über


Configure feature on demand and side by side feature store on Windows 2012 R2

 

Features on Demand is a feature, introduced in Windows® 8 and Windows Server 2012, that allows you to remove role and feature files (sometimes called feature payload) from the operating system to conserve disk space, and install roles and features from remote locations or installation media instead of from local computers. You can remove feature files from running physical or virtual computers. You can also add feature files to or remove feature files from Windows image (WIM) files or offline virtual hard disks (VHDs) to create a reproducible copy of Features on Demand configurations. For more information on Windows features on demand please refer : https://technet.microsoft.com/en-us/library/jj127275.aspx

In a Features on Demand configuration, when feature files are not available on a computer, if an installation requires those feature files, Windows Server 2012 R2 or Windows Server 2012 can be directed to get the files from a side-by-side feature store (a shared folder that contains feature files, and is available to the computer on the network), from Windows Update, or from installation media.

This article talks about installing the Windows roles and features from side-by-side feature store containing the WinSxS folder and the SxS folder on a network share.

You can use the Uninstall-WindowsFeature cmdlet both to uninstall roles, role services, and features from servers and offline VHDs that are running Windows Server 2012 R2 or Windows Server 2012, and to delete feature files.

For e.g. as you see in the below screenshot I have removed the WINS feature from the server in my lab. "Install State" column shows the feature status as removed once the feature is removed from the server. When I try to install the feature I get the error "provide the path of the source files to install the roles or features".

clip_image001

When we configure the side-by-side feature store, we can have a install.WIM file that contains the full image of the operating system or WinSxS folder hosted on a network share. We also need to copy the SxS folder from operating system media to the network share for installation.

Install.WIM file contains multiple OS images in it, to find the image that you want to use for installation of roles and features you can use the below command. It provides the index for each OS image available in the Install.WIM file. Also as you will notice in the below screenshot you can have the WIM file either on the local server or on a remote network share, I have WIM file hosted on my file server.

clip_image002

Or I can have a install.WIM file hosted locally. Both the commands used in the above screenshot and the below screenshot provide the same result.

clip_image003

I want to use the Windows Server 2012 R2 ServerStandard image for installation of features. Let me try installing the WINS feature again this time by giving the source WIM file path and the image index.

Install-WindowsFeature -Name WINS -source "WIM:\\adfs1\sw\windows 2012 r2\install.wim:2

You add prefix WIM to the source file path, when providing the path for the WIM file. We don’t need to add this prefix if we give the direct path to the WinSxS folder on a network share.

clip_image004

Or install it from the local WIM file

Install-WindowsFeature -Name WINS -source "WIM:\\z:\sw\windows 2012 r2\install.wim:2"

clip_image005

We can also configure the source path to the WinSxS share or the WIM file through Group Policies. When configured, we don’t need to provide the source path while installing the feature, as it automatically picks the source path configured in group policies. Configuring optional installation path via GPO helps administrators to install the services that they need without having knowledge of the source file path.

clip_image006

Apply the GPO

clip_image007

Remove the WINS feature and Install it again, this time without specifying the source path location for WIM file as that is already configured in Group Policies.

clip_image008

We can also try this for .NET framework feature.

Uninstall and remove the .NET framework 3.5 from the server.

clip_image009

Now try to install the .NET 3.5 feature from PowerShell, as currently GPO is not configured to point to SXS folder it gives error and doesn’t install the feature. Existing setting in GPOS only contains the path to the WIM file.

clip_image010

Now let's add the network path to the SXS folder as well in the GPO settings for "optional component installation and component repair". So now I have two paths configured in GPO setting, one pointing to the WIM file and other pointing to the SxS folder.

clip_image011

Run gpupdate /force on the target server to ensure the GPO is applied

clip_image012

After GPO is updated you can verify the same from GPresult or RSOP.

Try installing the .NET 3.5 feature now, this feature is installed from the SxS folder on a network share for which path is now configured in the GPO. You don’t have to specify the source path in the command as its configured via GPO. Configuring the optional installation path in GPO helps administrators to install the services that they need without having knowledge of the source file path.

clip_image013

We can perform same tasks from Add server roles and features wizard:

  1. Go to Remove roles and features to uninstall the .NET framework 3.5
  2. Uninstall the .NET framework 3.5 features
  3. Restart the machine to complete the removal.
  4. Remove the location to SxS folder from the GPO and run Gpupdate /force on the Windows server machine to apply the new GPO settings

Now try installing the .NET framework 3.5 features back using Add Roles and services.

clip_image014

clip_image015

For testing, we don’t specify the source file path for installation

clip_image016

Installation fails as expected because the source file path was not given neither its configured in the GPO

clip_image017

Let's modify the GPO again, to add the network path to the source file folder.

clip_image018

Run Gpupdate/ Force on the server to ensure GPO setting is updated. Run RSOP to verify the applied GPO on target server

clip_image019

You can also verify if the GPO is applied to the server and the network path is populated in Regedit.

clip_image020

Try installing the feature again

clip_image021

clip_image022

clip_image023

This time the installation succeeds on the server.

clip_image024

Similar process can be followed to install the other server roles and features which were removed earlier from the server.

Comments

  • Anonymous
    March 02, 2015
    Hi Amit, thank you for these detailed explanations! What I'm wondering is if you have multiple editions of Windows Server 2012 R2 in place (that's the suffix after the .wim, correct?), do we just need to add all possibilities to the policy (i.e. WIM:\install.wim:2;WIM:\install.wim:4;\sourcesSxS), and Windows will automatically choose the correct one when installing Roles and Fetures?
    KR, Dominik
  • Anonymous
    March 06, 2015
    Hi Dominik, its been long time since I wrote this article. I think that's right, as you see in the above example we have given two paths one for the WIM file and other for the Sxs folder separated by semi colon. Also If you read through the specific GPO details, it clearly mentions multiple locations can be provided when each path is separated by semicolons. However I have not tested it so I would suggest you to first test it in the lab before you implement this in production. Hope this helps.