Features on Demand in Server 2012

Windows 8 and Server 2012 introduce a new concept of Features on Demand whereby each installation contains only basic components. Adding new components requires the OS to gather source files from an external location for installation. This is a move away from Server 2008 and Server 2008 R2 where an installation contained everything necessary to service the installation. When adding new features, Windows would simply use its locally cached installation sources.

This was a great concept for home users who no longer needed to worry about having source media, and it resolved a lot of problems for IT administrators having to deal with missing files for patching. The problem was that it drastically increased the size of every installation in the datacenter, chewing up tons of un-needed space. With Server 2012, Microsoft has found a decent balance between the two – provided you configure your environment appropriately.

By default, Server 2012 will go out to Windows Update any time it’s looking for a feature for which it does not have the source files. For example, a common feature that many programs still use for which Windows does not cache installation files locally is the .NET Framework 3.5. Under normal circumstances, you’ll simply use Server Manager to add the new features and never notice the difference. However, if you have a WSUS configured or if the server does not have Internet access, you might see the following error:

Update NetFx3 of Package Microsoft .NET Framework 3.0 failed to be turned on. Status: 0x800f0906.

The error means that Windows was unable to find appropriate source installation files to add the feature. This is because WSUS doesn’t currently support the new Features on Demand functionality in Server 2012. There are a few ways to workaround this issue.

First, you can specify a source from the command line using the Enable-Feature and Source switches for the DISM tool (or -Source parameter from the Install-WindowsFeature powershell command). You can then point to the X:\Sources\Sxs directory to proceed with the installation. The GUI will also allow you to specify this alternate source via the Add Roles and Features Wizard via a yellow warning banner on the confirmation screen.

Second, you can use a GPO or modify the registry to tell Windows to by-pass your WSUS server and go directly to Windows Update when servicing your Server 2012 installation. There are two REG_DWORD values that control this behavior located under [Software\Microsoft\Windows\CurrentVersion\Policies\Servicing]. The first is UseWindowsUpdate – setting this to 2 tells Windows to NEVER go to Windows Update for enabling features. The second is RepairContentServerSource – setting this to 2 tells Windows to go to Windows Update for repair source only (does not affect servicing). Both of these can be controlled via GPO (new Servicing.admx template) under Computer Configuration > Administrative Templates > System > Specify settings for optional component installation and component repair.

Last, you can use a GPO or modify the registry to point Windows to a list of installation source locations – similar to functionality in Server 2003 and XP. These can either be a copy of the X:\Sources\Sxs directory from installation media, or the actual WIM file (either install.wim from installation media or a copy of your company’s customized WIM image). Again, the value is located under [Software\Microsoft\Windows\CurrentVersion\Policies\Servicing]. Setting the REG_EXPAND_SZ value named LocalSourcePath allows you to specify one or more installation source locations (separated by a semicolon). To point to a WIM file, use the following format:

WIM:[path to wim]:[index]

You must specify the index so Windows knows where to find the appropriate installation files for your Server 2012 instance. The nice thing about using a WIM file is that you can perform offline servicing of the image to ensure that it always contains the latest patches and updates.

Error creating Server 2012 cluster on 2008 domain

We worked with Microsoft extensively throughout the Server 2012 TAP program providing feedback in various areas. We encountered an issue late in the program when creating a Server 2012 cluster on our production domain. We did not see this same issue in any lab environment, or in our development environment which mirrors production.

When attempting to create the cluster, the wizard would fail when creating the AD objects. We confirmed that the user had proper permissions, and did not encounter the same issues creating 2008 or 2008 R2 clusters on our production domain. After working with Microsoft, they recommended we install KB 976424 on our production domain controllers. After installing this hotfix and rebooting all of the domain controllers, we were able to create a Server 2012 cluster on our 2008 domain without issue.