Partager via


Understanding Features on Demand and role persistence in Windows Server 2012

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: https://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

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

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

  • Anonymous
    January 01, 2003
    LOL, I know what you mean.

  • Anonymous
    January 01, 2003
    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

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    October 17, 2012
    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.
  • Anonymous
    October 18, 2012
    The comment has been removed
  • Anonymous
    November 19, 2012
    The comment has been removed
  • Anonymous
    November 19, 2012
    please ignore the above i just saw you made a more recent post on this issue.