Disk Cleanup and the joys of Features-on-demand

Features-on-demand - it’s a great new “feature” - when it works. However, the rest of the time it is a real headache.

A couple of months ago I decided I wanted to trim down the size of my Windows Server 2012 R2 VM’s. Disk Cleanup (cleanmgr.exe) is one tool that I’ve often found really useful to have on a server install, especially when preparing OS VM images to ensure the install is as lean and clean as possible.

However, by default the tool isn’t installed on Windows Server 2012. To get access to Disk Cleanup on a server OS you need to install the Desktop Experience feature:

Install Desktop Experience using Add Roles and Features Wizard Install Desktop Experience using Add Roles and Features Wizard

Because I had used features-on-demand to remove any disabled packages from the system I received a message telling me I might need to specify an alternate location for the source files:

Specify an Alternate Source path Specify an Alternate Source path

Anyone who has used features-on-demand should be familiar with this:

Desktop Experience Feature-on-demand removed Desktop Experience Feature-on-demand removed

Because I haven’t got a GPO restricting my servers from downloading updates and packages from Windows Update I thought I wouldn’t have a problem and didn’t need to specify a source.

I was wrong:

Failed to install the Desktop Exprience Failed to install the Desktop Experience

That is a bit odd - the server has access to Windows Update - it had downloaded updates earlier that day. Other removed features-on-demand features had been installed on this server without an issue, downloading the source files directly from Windows Update. So I was a little puzzled as to why this was different.

No problem, I thought! All that needs to be done is specify a source. In case this is useful, the following TechNet article covers the different ways of specifying a source when installing features that have been removed:

Configure Features on Demand in Windows Server

There are several different sources that can be provided to the Add Roles and Features Wizard:

  • Specify a WIM file (and index) containing the windows installation files for the OS version that was installed on the server. This is usually a file called install.wim that can be found in the Sources folder of the Windows Server2012R2 installation media.

    Install Feature using a WIM source Install Feature using a WIM source

  • Specify the windows folder of a working OS install containing the files for this feature. This is usually done by mapping a drive to a share or by mountingaVHD/VHDx file as a drive to the OS.

    Install Feature using a shared Windows Folder on a machine with the Desktop Experience feature installed Install Feature using a shared Windows Folder on a machine with the Desktop Experience feature installed

I tried both of the above methods but neither of them seemed to work for the Desktop Experience feature. The same error occurred every time:

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 http://go.microsoft.com/fwlink/?LinkId=243077. Error: 0x800f0906

I also tried installing the feature using PowerShell, using no alternative source, using a WIM source and using a Windows folder source:

Install-WindowsFeature -name Desktop-Experience -IncludeAllSubfeature -Restart -Source z:

But each time I received the same error message:

Install Feature with PowerShell and specifing a valid source - failure. Install Feature with PowerShell and specifying a valid source - failure.

At this point I had all but given up. Luckily I didn’t. I thought I’d give it one last try - but this time instead of using commands from the PowerShell DISM module I’d use DISM.EXE directly:

DISM /online /enable-feature /featurename:DesktopExperience /all /source:z:\\

Success! DISM worked!

DISM for the WIN! Back of the net! DISM for the WIN! Back of the net!

This screenshot and the one above of the PowerShell install-windowsfeature failing to install the feature are from the same machine with the same source mapped.

Z: drive here was mapped to a share of the c:\windows folder of a server that has the Desktop Experience feature correctly installed.

It looks like DISM may operate in a slightly different way to PowerShell DISM Module and the Add Roles and Features Wizard when it comes to installing features.

So, if Add Roles and Features Wizard and PowerShell Install-WindowsFeature fail, try DISM - it might work!

Additional Notes

I have also run into the same problem when installing the AD DS feature on a different server - so I don’t think this is specific to the machine or the feature. It has also occurred on machines that I want to convert from a core install to a gui install.

I have tried installing the feature on a clean install of the OS and it works fine - but as soon as all the latest windows hotfixes for the OS are installed from Windows Update the feature can no longer be installed (if it has been removed).

From my investigation, many other people have experienced this problem with varying degrees of success in solving it. Some have said that patching the WIM file with all the latest hotfixes worked for them - but it didn’t for me (but it did inspire me to write a PowerShell module to ease the WIM patch process - more on this in another post). I was certainly in the “tearing my hair out” group until I randomly tried this.

Also, I did try DISM without specifying a source as well, and it failed with the same error code as the PowerShell did:

Install Feature using DISM fails with no Source specified. Install Feature using DISM fails with no Source specified.

At first I actually thought the soution was using DISM with the /LimitAccess switch to prevent DISM from using the internet to download the packages, but after further tests it doesn’t seem to make any difference - DISM works with and without this switch. The equivelent to the /LimitAccess switch also doesn’t appear to be available in the PowerShell Install-WindowsFeature cmdlet.