The Windows Servicing Guy

Tips and tricks from a Windows support engineer on issues related to servicing

Understanding Features on Demand and role persistence in Windows Server 2012

Understanding Features on Demand and role persistence in Windows Server 2012

  • Comments 12
  • Likes

A new option in Windows Server 2012, Features on Demand, allows for the removal of unwanted feature payloads from a Windows Server 2012 image before or after deployment. The way Features on Demand works is that it takes the payload (binaries for all components and permissions, registry settings, etc. for previously installed and configured components) defined by the component and feature manifests and it removes them from the file system. What this means is that unwanted role and feature payloads can now be permanently removed from an online or offline Server 2012 image. In a typical Server 2012 with Gui installation, roles and features that are not installed are in a state known as staged or disabled. I've spoken about this in the past but this basically means that the files are not installed but are still cached locally on the disk in the component store (%Windows%\winsxs) and therefore are taking up disk space. When a feature is removed using Features on Demand, the payload is actually removed from the file system and that space is reclaimed. This is a great option for administrators looking to cut down on virtual disk space usage as it allows you to customize your images exactly how you want them. Features which have had their payload removed are shown as “disabled with payload removed” or “removed” in DISM and Windows PowerShell.

But how does this work in relation to features and roles installed on the system already? The answer here is, it depends. There is also a new interface option called Minimal Server Interface. This lives between Server Core and Server with GUI and offers administrators the ability to remove the shell while still administering the server with some user interface functionalities. So, here's what happens to roles and features as you move through the various stages of user interface.

Server Core

In Server Core, when installed from Setup, everything has been removed aside from the role and features supported by Core. This list can be found here: http://technet.microsoft.com/en-us/library/jj574158.aspx . Inside of Server Core, you can further remove the roles and features that it supports to continue to optimize the size of the image but everything else has already been removed.

Minimal Server Interface

Minimal Server Interface installs a lot of dependency features that are needed in order to support various user interface elements, with the exception of Desktop and Shell features. It gives you virtually all of the functionality available in the Server with GUI option, but without the patching cost of the Shell and Desktop features. The disk space savings is not as noticeable as with Server Core. With Minimal Server Interface, you benefit from a reduction in servicing and surface area. Minimal Server Interface is a great compatibility option if you are running legacy server applications that don’t support Server Core, but also don’t require the Shell. You also can’t install Minimal Server Interface directly; you must build up to it from Server Core or down from Server with GUI.

For information on configuring Minimal Server Interface, see Configuring the Minimal Server Interface.

Server with Gui

In Server with Gui, formerly called "Full Server", pretty much everything is either staged or installed. This has the largest of the three footprints, and similar to Minimal Server Interface, roles and features can be removed from the image to reduce the footprint.

With that out of the way, what happens to an installed role that is configured in Server with GUI but then I convert to Server Core using Features on Demand to reduce my footprint? Again, the answer is it depends. If the role is part of the Server Core role listing, nothing happens. The role stays installed but configuration options will obviously not include a user interface. If the role was NOT a part of the Server Core role listing, that role is removed via Features on Demand because it cannot exist in Server Core.

Here's an example, I install Server with Gui and then install the Active Directory Domain Services role and the Windows Deployment Services role. I later decide I would like to have a much smaller footprint for my Windows installation because I want to virtualize it. So I convert to Server Core using the –remove option to remove the binaries completely using Features on Demand. The AD-DS role continues to stay installed but the WDS role is removed as part of the transition to Server Core. If I were to later change my mind again and move to Minimal Server Interface or Server with GUI, the role will NOT be reinstalled, it will need to be reinstalled and (and possibly re- configured).

NOTE: You can also use the Windows PowerShell –WhatIf cmdlet to see what will be added/removed in an operation without actually doing the operation against the image

The main point to take away is this, when you're planning your Server 2012 infrastructure and you're considering space optimization, look over the various user interface options first and then pare back the roles and features accordingly. Server Core is a fantastic option for core infrastructure roles and you can make a virtual machine with a very small footprint using it. However if you want to use roles outside of the Server Core role listing, Minimal Server Interface is the best option and then features and roles should be removed from there. Only use Server with a GUI when you absolutely have to because of a dependency on the shell.

--Joseph

Comments
  • Hi Joseph,

    Thanks for your blog, I've been reading it for a while without commenting, though :) It seems you actually read comments to your old blog entries, so I'll give it a shot with my question. BTW, thanks for the servicing white paper on Server 2012, it's a great source of info! And my question is about... well, the source ;)

    Specifically, when enabling a removed feature in an offline image, what does servicing use as a source when the /Source parameter specified neither on the command line nor via the Group Policy?

    I couldn't find the answer in the white paper, and the DISM reference technet.microsoft.com/.../hh825265.aspx says: "If you do not specify a /Source for a feature that has been removed, the default location in the registry is used or, for online images, Windows Update (WU) is used." It doesn't list the registry parameter, and I can't seem to catch it with procmon.

    For example, I use the following command to enable the previously removed Hyper-V feature in a mounted Windows 8 WIM:

    enable-windowsoptionalfeature -path D:\mount -featurename Microsoft-Hyper-V-All

    After examining the DISM log, I suspect the local Windows directory is used as a source, as at some point after the operation starts I see the entries like:

    2012-10-10 00:25:48, Info                  CSI    00000024 Performing 1 operations; 1 are not lock/unlock and follow:

     (0)  LockComponentPath (10): flags: 0 comp: {l:16 b:afc8f7445ca6cd01870100006c19ac0d} pathid: {l:16 b:afc8f7445ca6cd01880100006c19ac0d} path: [l:234{117}]"\??\C:\Windows\WinSxS\amd64_microsoft-hyper-v-vstack.resources_31bf3856ad364e35_6.2.9200.16384_ru-ru_f989866a5e681247" pid: 196c starttime: 129942879367197251 (0x01cda65c3dc5f243)

    But the DISM log is pretty complex for a regular human being, hence I decided to ask the most knowledgable person I know :)

    Thanks for your time and attention to my question!

    Vadim

  • @Vadim;

    Thanks for reading the blog.  The -Source parameter needs to point to a valid Windows 8 or Windows 2012 WIM file that contains the payload for the item you're wishing to add.  If you don't specify a source, we'll attempt to use the local component store to see if it exists there (basically this acts the same as just enabling the feature online).

    What information are you looking to gather exactly?  Are you looking to see what registry entries are added during a Hyper-V install?

    As a side note, and I've said this on the forums, you're going to generally be better off using Windows PowerShell for these types of commands because it understands dependencies.

    --Joseph

  • Joseph, thanks for your instant reply that confirmed my assumption :) I was just playing around with the new Windows feature and trying to understand how *exactly* it works before I start explaining it to someone else.

    I did use PowerShell for my commands (thanks for the comment on dependencies). The reason I linked to the DISM.exe reference is that it contains a bit more detailed info on this particular item than the corresponding PS comandlet help.

    BTW, neither reference mentions an ability to use a source WIM without mounting it first that outlined in the document you authored. I'm talking about:

    • /source:wim:c:\install.wim:2 (DISM.exe)

    • -source c:\install.wim:2 (PS)

    I think it's a time saver, especially with relatively slow real-time antivirus monitors. Windows Defender is one of them, actually...

    Vadim

  • You're right, the auto-mounting of the WIM was something we added after the beta release (nice catch btw ;)

  • A great new feature set.

    Going semi-off-topic:

    1. I'm curious about how Microsoft builds WinPE. Does this OS benefit from the work on Server Core or Minimal Server Interface? I mean, to what extend is WinPE a client version of Server Core (SC with no roles installed)?

    2. Will client versions of Windows ever get something like Minimal Server Interface (as an alternative to having to bother with Windows Embedded)? So if you want a simple kiosk or point-of-sale or Media Center or Storage Spaces file server based system, you could configure it for Minimal Interface Mode, and enjoy the same servicing and security benefits as MSI.

  • @Drew;

    WinPE isn't really a version of Server Core, its WinPE :).  You can extend PE to have some of the same functionality as Core, things like BitLocker awareness, .Net support, etc.  But its really not meant to be an OS in and of itself.

    As for the second question, I cant comment on changes to future product.  Sorry.

    --Joseph

  • Thanks Joseph.

    "But its really not meant to be an OS in and of itself."

    Anyone who hung out with me for long enough, could be forgiven for thinking otherwise. :-)

  • LOL, I know what you mean.

  • So what's the max amount of space that can be removed via feature on demand? Are we talking gigs or MB? Is it practically enough to be worth the effort for a server os? I could see in regards to a client os and deploying it across a network.

  • It really depends on what you need the OS to do.  On a server that will only be a Hyper-V box for example, you can get things very, very small (saving GBs vs. a Gui install).

  • We're rolling out Windows 2012, and I've been having a bear of a time with Install-WindowsFeature.

    (This is on Datacenter Core)

    This all started when I tried to run "Install-WindowsFeature SMTP-Server".

    I got the error:

    install-windowsfeature : The request to add or remove features on the specified server failed.

    Installation of one or more roles, role services, or features failed.

    The source files could not be downloaded.

    Use the "source" option to specify the location of the files that are required

    to restore the feature. For more information on specifying a source location,

    see go.microsoft.com/fwlink. Error: 0x800f0906

    At line:1 char:1

    + install-windowsfeature server-gui-mgmt-infra

    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

       + CategoryInfo          : InvalidOperation: (@{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature], Exception

       + FullyQualifiedErrorId : DISMAPI_Error__Cbs_Download_Failure,Microsoft.Windows.ServerManager.Commands.AddWindowsFeatureCommand

    I eventually narrowed the issue down to:

    If you install KB2756872 or KB2770917

    and then try to "Install-WindowsFeature Server-Gui-Mgmt-Infra"

    you will get the above error

    I've tried all sorts of sources:

    both datacenter wim indexes (gui and core)

    sxs folder from dvd

    a merged sxs folder on the network (containing content from both of the above sources)

    I've also tried some different sequences.

    (FAIL) Install either patch then install gui

    (FAIL) Install gui then install either patch, then uninstall gui (with -remove option), then reinstall gui

    (FAIL) Install gui then uninstall gui (with -remove option), install either patch, then reinstall gui

    (WORKS) Install gui, then patch, then uninstall gui, then reinstall gui

    (WORKS) Install gui, then uninstall gui, then install patch, then install gui

    I'm guessing this has something to do with those patches upgrading that feature, so the sources no longer have a correct version of it. And it looks as long as the content is already on the server (even if not activated) it will be updated.

    So is there was a workaround here? I don't want to have to start from an unpatched freshly installed system every time I want to install a feature.

    Ben Herila suggested here:

    blogs.technet.com/.../using-features-on-demand-with-updated-systems-and-patched-images.aspx

    that you had written an article about a possible solution to this:

    "My colleague Joseph Conway has written a post about how to actually go about updating your Windows images (your installation sources) using patches from the Microsoft Update Catalog. Read more here: <link_coming_soon>"

    But I can't find it. It seems like a bit of a hassle to have to keep a SxS folder manually updated with all the patches in order to be able to add roles and features to a server. I wish it gave a bit more feedback on an install failure so I could tell which subcomponent & version are causing the problem.

  • please ignore the above i just saw you made a more recent post on this issue.