Subscribe via Email

Subscribe via RSS/JSON


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan


Useful offline Windows troubleshooting/ fixing tricks

Had a Windows Server 2008 R2 server that started giving a blank screen since the recent Windows update reboot. This was a VM and it was the same result via VMware console or RDP. Safe Mode didn’t help either. Bummer!

Since this is a VM I mounted its disk on another 2008 R2 VM and tried to fix the problem offline. Most of my attempts didn’t help but I thought of posting them here for reference. 

Note: In the following examples the broken VM’s disk is mounted to F: drive. 

Recent updates

I used dism to list recent updates and remove them. To list updates from this month (March 2017):

To remove an update:

I did this for each of the updates I had. That didn’t help though. And oddly I found that one of the updates kept re-appearing with a slightly different name (a different number suffixed to it actually) each time I’d remove it. Not sure why that was the case but I saw that F:\Windows\SxS had a file called pending.xml and figured this must be doing something to stop the update from being removed. I couldn’t delete the file in-spite of taking ownership and full control, so I opened it in Notepad and cleared all the contents. :o) After that the updates didn’t return but the machine was still broken. 


I used sfc to check the integrity of all the system files:

No luck with that either!

Event Logs

Maybe the Event Logs have something? These can be found at F:\Windows\System32\Winevt\Logs. Double click the ones of interest to view. 

In my case the Event Logs had nothing! No record at all of the VM starting up or what was causing it to hang. Tough luck!

Bonus info: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog contains locations of the files backing the Event Logs. Just mentioning it here as I came across this.


Could drivers cause any issue? Unlikely. You can’t use dism to query drivers as above but you can check via registry. See this post. Honestly, I didn’t read it much. I didn’t suspect drivers and it seemed too much work fiddling through registry keys and folders. 

Last Known Good Configuration

Whenever I’d boot up the VM I never got the Last Known Good (LKG) Configuration option. I tried pressing F8 a couple of times but it had no effect. So I wondered if I could tweak this via the registry. Turns out I can. And turns out I already knew this just that I had forgotten!

Your current configuration is HKLM\System\CurrentControlSet. This is actually a link to HKLM\System\CurrentControlSet01 or HKLM\System\CurrentControlSet02 or HKLM\System\CurrentControlSet03 or … (you get the point). Each of the CurrentControlSetXXX key is one of your previous configurations. The one that’s actually used can be found via HKLM\System\Select. The entry Current points to the number of the CurrentControlSetXXX key in use. The entry LastKnownGood points to the Last Known Good Configuration. Now we know what to do. 

  1. Mount the HKLM\SYSTEM hive of the broken VM. All registry hives can be found under %windir%\System32\Config. In my case that translates to the file F:\Windows\System32\Config\SYSTEM.
  2. To mount this file open Registry Editor, select the HKLM hive, and go to File > Load Hive. (This is a good post with screenshots etc).  
  3. Go to the Select key above. Change Current to whatever LastKnownGood was. 
  4. That’s all. Now unload the hive and you are done.

This helped in my case! I was finally able to move past the blank screen and get a login prompt. Upon login I was also able to download and install all the patches and confirm that the VM is now working fine (took a snapshot of course, just in case!). I have no idea what went wrong, but at least I have the pleasure of being able to fix it. From the post I link to below, I’d say it looks like a registry hive corruption. 

Since I successfully logged in, my machine’s Last Known Good Configuration will be automatically updated by Windows with the current one. Here’s a blog post that explains this in more detail. 

That’s all! Hope this helps someone. 

Fixing a Windows Server that was stuck on “Preparing to configure Windows”

This is something that I fixed a few months ago at work but didn’t get a chance to blog about then. Coz of the gap I might not post much verbosely about it as I usually may.

The situation was that we had a Windows Server 2012 R2 that was stuck on a “Preparing to configure Windows” loop. I didn’t take a screenshot of it but you can find an example of it for Windows 7 here. All the usual troubleshooting steps like automatic repairs and last known good configuration etc didn’t make a dent. The problem began after the server was rebooted following Windows Updates so I focused on that. Here’s what I did to fix the server:

  1. I rebooted the server and pressed F8 before the Windows logo screen.
  2. This got me to the recovery options screen, where I selected the option to get a command prompt.
  3. Next I found the drive letter that corresponds to the C: drive of the server. This was through trial and error by typing each drive letter and find the one with the Windows folder.
    1. In my case the drive letter was E: so keep that in mind while viewing the screenshots replace. Replace with the drive letter you find.
  4. I entered the following command to get a list of all Windows updates, both installed and pending. 1
  5. The output was as below. 2
  6. I noted the names of the updates that were in a “Staged” state and uninstalled them one by one. 3
  7. Then I exited the command prompt. This rebooted the server and it was stuck at the following screen for a while. 4
  8. I stayed on this screen for about 15 mins. The server rebooted itself and stayed on the screen again, for about 10 mins. After this it proceeded to the login screen and I could login as usual. :)

ReAgentC: Operation failed: 3

The other day I mentioned that whenever I run ReAgentC I get the following error – 

I posted to the Microsoft Community forums hoping to get a solution. The suggested solutions didn’t seem to help but oddly ReAgentC is now working – not sure why. 

One thing I learnt is that the error code 3 means a path is not found. My system didn’t have any corruptions (both sfc /scannow and dism /Online /Cleanup-image /Scanhealth gave it a clean chit) and I did a System Restore too to a point back in time when I know ReAgentC was working well but that didn’t help either. Windows RE itself was working fine as I was able to boot into it. 

In the end I shutdown the laptop and left it for a couple of days as I had other things to do. And when looked at it today ReAgentC was surprisingly working!

I am not sure why it is now working. One theory is that a few updates were applied automatically as I was shutting down the laptop so maybe they fixed some corruption. Or maybe when I booted into Windows RE and booted back that fixed something? (I don’t remember whether I tried ReAgentC after booting back from Windows RE. I think I did but I am not sure). 

Here’s a little PowerShell to find all the updates installed in the last 3 days. Thought I’d post it because I am pleased I came up with it and also maybe it will help someone else. 

This will only work in Windows 8 and above (I haven’t tried but I think installing the Windows Management Framework 4.0 on Windows 7 SP1 and/ or Windows Server 2008 R2 SP1 will get it working on those OSes too). 

Update: And it stopped working again the next day! The laptop was on overnight. The next day I rebooted as it had some pending updates. After the reboot we are back to square one. Of course I removed those two updates and rebooted to see if that helps. It doesn’t. 

 Fun! :)


Notes of SFC and Windows Servicing (Component Based Servicing)


SFC (used to be “System File Checker” but is now called Windows Resource Checker) is an in-built tool for verifying the integrity of all Windows systems files and also replacing them with good versions in case of any corruptions. It has been around for a while – I first used it on Windows 2000 I think – though am sure there’s many differences from that version and the latest ones. For instance, XP and prior used to store a copy of the system protected files in a folder called %WINDIR%\System32\DLLCache (but it would remove some of the protected files as disk space became scarce resulting in SFC prompting for the install media when repairing) while Vista and upwards use the %WINDIR%\System32\WinSxS folder (and its sub-folder %WINDIR%\System32\WinSxS\Backup).

The WinSxS folder

Here is a good article on the WinSxS folder. I recommend everyone read it.

Basically, the WinSxS folder contains all the protected files (under a “WinSxS\Backup” folder) as well as multiple version of DLLs and library components needed by various applications. In a way this folder is where all the DLLs of the system are actually present. The DLLs that you see at other locations are actually NTFS hard links to the ones in this location. So even though the folder might appear HUGE when viewed through File Explorer, don’t be too alarmed as many files that you think might be taking up space elsewhere are not actually taking up space because they are hard links to the files here. But yes, the WinSxS is huge also because it has all those old DLLs and components, and you cannot delete the files in here because you never know what application depends on it. Moreover, you can’t even move the folder to a different location as it has to be in this known location for the hard links to work.

In contrast to the WinSxS folder, the DLLcache folder can be moved anywhere via a registry hack. Also, the DLLcache folder doesn’t keep all the older libraries and such.

The latest versions of SFC can also work against an offline install of Windows.

Here’s SFC on my computer complaining that it was unable to fix some errors:

It is best to view the log file using a tool like trace32 or cmtrace. Here’s a Microsoft KB article on how to use the log file. And here’s a KB article that explains how to manually repair broken files.


Rather than open the CBS.log in trace32 it is better to filter the SFC bits first as suggested in the above KB articles. Open an elevated command prompt and type this:

Open this file (saved on your Desktop) in trace32 and look for errors.


Servicing is the act of enabling/ disable a role/ feature in Windows, installing/ uninstalling updates and service packs. You can service both currently running and offline installations of Windows (yes, that means you can have an offline copy of Windows on a hard disk or a VHD file and you can enable/ disable features and roles on it as well as install hot fixes and updates (but not service packs) – cool huh!). If you have used DISM (Deployment Image Servicing and Management) in Windows 7 and upwards (or pkgmgr.exe & Co. in Vista) then you have dealt with servicing.

File Based Servicing

Windows XP and before used to have File Based Servicing. The update or hotfix package usually had an installer (update.exe or hotfix.exe) that updated the files and libraries on the system. If these were system files they were installed/ updated at WINDIR%\System32 and a copy kept at the file protection cache %WINDIR\System32\DLLcache (remember from above?). If the system files were in use, a restart would copy the files from %WINDIR\System32\DLLcache to WINDIR%\System32. Just in case you needed to rollback an update, a backup of the files that were changed was kept at C:\Windows\$Uninstall$KBnnnnnn (replace “nnnnnn” with the KB number). Life was simple!

Component Based Servicing

Windows Vista introduced Component Based Servicing (CBS). Whereas with File Based Servicing everything was mashed together, now there’s a notion of things being in “components”. So you could have various features of the OS be turned off or on as required (i.e. features and roles). The component itself could be installed to the OS but not active (for example: the files for a DNS server are already installed in a Server install but not activated; when you enable that role, Windows does stuff behind the scenes to activate it). This extends to updates and hotfixes too. For instance, when you install the Remote Server Admin Tools (RSAT) on Windows 7, it installs all the admin tool components but none of these are active by default. All the installer does is just add these components to your system. Later, you go to “Programs and Features” (or use DISM) to enable the components you want. CBS is the future, so that’s what I’ll be focussing on here.


From this blog post:

A component in Windows is one or more binaries, a catalog file, and an XML file that describes everything about how the files should be installed. From associated registry keys and services to what kind security permissions the files should have. Components are grouped into logical units, and these units are used to build the different Windows editions. Each component has a unique name that includes the version, language, and processor architecture that it was built for.

Component Store

Remember the %WINDIR%\System32\WinSxS folder above? That’s where all these components are stored. That folder is the Component Store. (As an aside: “SxS” stands for “Side by Side”. It is a complete (actually, more than complete) install of Windows that lives side by side to the running installation of Windows). When you install a component in Windows Vista and above, the files are actually stored in this component folder. Then, if the component feature/ role/ update is activated, hardlinks are created from locations in the file system to the files here. So, for instance, when you install a Server its component folder will already contains the files for the DNS role; later, when you enable the role hard links are created from WINDIR%\System32 and elsewhere to the files in %WINDIR%\System32\WinSxS.


Microsoft refers to the files (binaries such as libraries etc) in the WinSxS folder as payloads. So components consist of payloads that are stored in the WinSxS folder and manifests (not sure what they are) that are stored in the WinSxS\manifests folder.

Component Stack

Here’s a post from the Microsoft Servicing Guy on CBS. Like we had update.exe on XP and before, now we have trustedinstaller.exe which is the interface between the servicing stack and user-facing programs such as “Programs and Features”, DISM, MSI, and Windows Update. The latter pass on packages (and downloads them if necessary) to trustedinstaller.exe who invokes other components of the CBS stack to do the actual work (components such as CSI (Component Servicing Infrastructure), which you can read about in that link).

It is worth pointing out that dependency resolution (i.e. feature Microsoft-Hyper-V-Management-PowerShell requires feature Microsoft-Hyper-V-Management-Clients for instance) is done by the CBS stack. Similarly, the CBS stack is what identifies whether any files required for a feature/ role are already present on the system or need to be downloaded. All this info is passed on to the user-facing programs that interact with the user for further action.

Related folders and locations

Apart from the Component Store here are some other folders and files used by the CBS:

  • %windir%\WinSXS\Manifests – Sub-folder of the Component Store, contains manifests
  • %windir%\Servicing\Packages – A folder that contains the packages of a component. Packages are like components, they contain binaries (the payloads) and manifests (an XML file with the extension .MUM defining the payload as well as the state of the package (installed and enabled, only installed, not installed)). When you run Windows Update, for instance, you download packages that in turn update the components.

    A component might contain many packages. For instance, the Telnet-Client feature has just one package Microsoft-Windows-Telnet-Server-Package~31bf3856ad364e35~amd64~en-US~6.3.9600.16384.mum on my machine, but the HyperV-Client role has more than a dozen packages – Microsoft-Hyper-V-ClientEdition-Package~31bf3856ad364e35~amd64~en-US~6.3.9600.16384.mum being the package when the OS was installed, followed by packages such as Package_1033_for_KB2919355~31bf3856ad364e35~amd64~~ and Package_13_for_KB2903939~31bf3856ad364e35~amd64~~, etc for various updates that were applied to it. (Remember: In XP and before updates targeted files. Now updates target components. So updates apply to components).

    An update that you install – say KBxxxxxxxx – might have multiple packages with each of these packages targeting different components of the system. The payload in a package is copied to the Component Store; only the .MUM defining the package is left in the %windir%\Servicing\Packages folder. Moreover, each component is updated with details of the package which affects it – this is what we see happening when an update is applied to the OS and Windows takes a long time configuring things. (Remember components are self-sufficient. So it also knows of the updates to it).

    You can get a list of packages installed on your system using the /Get-Packages switch to DISM:

    To get the same info as a table rather than list (the default):

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing – A registry key tree holding a lot of the servicing information.

    For instance, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageDetect\Microsoft-Hyper-V-ClientEdition-Package~31bf3856ad364e35~amd64~~ on my machine tells me which packages are a part of that component.

    Note that the above component name doesn’t have a language. It is common to all languages. There are separate keys – such as HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageDetect\Microsoft-Hyper-V-ClientEdition-Package~31bf3856ad364e35~amd64~en-US~ – which contain packages for that specific language variant of the component.

  • %windir%\WinSXS\Pending.xml – An XML file containing a list of commands and actions to be performed after a reboot for pending updates (i.e. files that couldn’t be modified as they are in use)
  • %windir%\Logs\CBS\CBS.log – The CBS log file.

Here’s a blog post from The Servicing Guy talking about the above locations. Unfortunately, it’s only part 1 as he didn’t get around to writing the follow-ups.


Here’s a high-level summary of many of the points I touched upon above:

  • Windows Vista and upwards use Component Based Servicing. A component is a self-sufficient unit. It includes binaries (files and libraries) as well as some metadata (XML files) on where the files should be installed, security rights, registry & service changes, etc. In Windows Vista and upwards you think of servicing in terms of components.
  • The files of a component are stored in the Component Store (the WinSxS folder). Everything else you see on the system are actually hard-links to the files in this Component Store.
  • When a component is updated the older files are not removed. They stay where they are, with newer versions of any changed files being installed side by side to them and references to these files from elsewhere are now hard-linked to this newer version. This way any other components or applications that require the older versions can still use them.
  • Components can be thought of as being made up of packages. When you download an update it contains packages. Packages target components. The component metadata is updated so it is aware that such and such package is a part of it. This way even if a component is not currently enabled on the system, it can have update packages added to it, and if the component is ever enabled later it will already have the up-to-date version.
  • Remember you must think of everything in terms of components now. And components are self-sufficient. They know their state and what they do.

Just so you know …

I haven’t worked much with CBS except troubleshooted when I have had problems or added/ removed packages and such when I am doing some basic servicing tasks on my machine/ virtual labs. Most of what I explain above is my understanding of things from the registry key and the folders supplemented with information I found in blog posts and articles. Take what you read here with a pinch of salt.

Service store corruptions

The Component Store can get corrupted, resulting in errors when installing updates and/ or enabling features. Note: this is not corruption with the system – which can be fixed via tools such as SFC – but corruptions to the Component Store itself.

Windows 8 and later

Windows 8 and upwards can detect and fix such corruptions using DISM /Cleanup-Image (don’t forget to specify /Online for online servicing or /Image:\path\to\install for offline servicing):

  • DISM /Cleanup-Image /ScanHealth will scan the Component Store for errors. It does not fix the error, only scans and updates a marker indicating the Store has errors. Any errors are also logged to the CBS.Log file.
  • DISM /Cleanup-Image /RestoreHealth will scan as above and also fix the error (so it’s better to run this than scan first and then scan & repair).
  • DISM /Cleanup-Image /CheckHealth will check whether there’s any marker indicating the system has errors. It does not do a scan by itself (so there’s no real point to running this, except to quickly check whether any tool has previously set the marker).

If PowerShell is your weapon of choice (yaay to you!), you can use Repair-WindowsImage -ScanHealth | -RestoreHealth | -CheckHealth instead.

If corruptions are determined and you have asked for a repair then Windows Update/ WSUS are contacted for good versions of the components. The /LimitAccess switch can be used to disable this; the /Source switch can be used to specify a source of your own (you must point to the WinSxS folder of a different Windows installation; see this TechNet article for some examples). (Update: WSUS is not a good source so it’s better to use gpedit.msc or GPOs to temporarily specify a Windows Update server, or use the /LimitAccess switch to not contact WU/ WSUS at all and specify a WinSxS folder to use).


Windows 7 and prior

Windows 7 and below use a Microsoft tool called CheckSUR (Check System Update Readiness).

Here’s a blog post on using CheckSUR to repair corruption. Note that CheckSUR can only repair manifests while DISM /Cleanup-Image can do both manifests and payloads.

Managing the component store size

The Component Store will keep growing as more updates are installed to a system. One way to reduce the size is to tell Windows to remove all payloads from older Service Packs. For instance, say the machine began life as Windows 7, then had updates applied to it, then a Service Pack. You know you will never uninstall this Service Pack so you are happy with removing all the older payloads from WinSxS and essentially tell the OS that from now on it must consider itself as Windows 7 Service Pack 1 for good – there’s no going back.

Here’s how you can do that for the various versions of Windows:

  • Windows Vista Service Pack 1 uses a tool called VSP1CLN.EXE to do this.
  • Windows Vista Service Pack 2 and Windows Server 2008 SP2 use a tool called Compcln.exe
  • Windows 7 Service Pack 1, Windows Server 2008 R2 Service Pack 1, and above use DISM /online /Cleanup-Image /SpSuperseded (for Windows 7 Service Pack 1 with update KB2852386 you can also use the Disk Cleanup Wizard (cleanmgr.exe)).

Automatic scavenging

Windows 7 and above also automatically do scavenging to remove unused components from the Component Store. Windows Vista and prior do scavenging on a removal event, so you can add and remove a feature to force a scavenging.

Windows 8 has a scheduled task StartComponentCleanup that automatically cleans up unused components. It waits 30 days after a component has been updated before removing previous versions (so you have 30 days to rollback to a previous version of the update). You can run this task manually too:

Check this blog post for some screenshots.

Windows 8.1 and Server 2012 R2 extras

Windows 8.1 and Windows Server 2012 R2 include a new DISM switch to analyze the Component Store and output whether a clean up can be made.

The clean up can be done automatically or manually run via the task scheduler entry as previously mentioned. DISM too has a new switch which does the same (but doesn’t follow the 30 days rule like the schedule task so it is more aggressive).

The above switch is available in Windows 8 and Windows Server 2012 too.

Note that the scavenging options above (Windows 7 and up) only remove previous versions of the components. They are not as aggressive as the options to re-base the OS to a particular service pack. Once the previous versions of the components are removed you cannot rollback to those older versions but you can still uninstall the update you are on.

Windows 8.1 and Server 2012 R2 introduce a new switch that lets you re-base to whatever state you are in now. This is the most aggressive option of all as it makes the state of the system permanent. You cannot uninstall any of the existing updates after you rebase (any newer updates made hence can be uninstalled) – the state your system is in now will be frozen and become its new state. This new switch is called /ResetBase:

Windows Server 2012 and Server 2012 R2 extras

Windows Server 2012 introduces the concept of “features on demand”.

Remember I had said by default all the payloads for all the features in Windows are present in the WinSxS folder. When you enable/ disable features you are merely creating hard-links for the files in WinSxS. What this means is that even though your Server 2012 install may not use a feature its files are still present and taking up space in the WinSxS folder. Starting with Server 2012 you can now uninstall (rather than remove) a feature so its files from the WinSxS folder are deleted.

Of course once you remove the files this if you want to enable the feature later you must also specify a source from where they can be downloaded. Check this blog post for more info.

Update: A Feb 2015 post from the PFE team that goes into pretty much the same stuff I mention above in terms of reducing the WinSxS folder size.

Notes of UEFI, GPT, UEFI boot process, disk partitions, and Hyper-V differencing disks with a Generation 2 VM

In my previous post I had talked about creating differencing VHDs for use with Hyper-V. While making that post I realized that what I what I was doing doesn’t work with Generation 2 VMs. Investigating a bit into that bought me to my old friend UEFI. I say “old friend” because UEFI is something I have been reading off and on the past few months – mainly due to my interest in encryption. For instance, my laptop with Self Encrypting SSDs can only be managed by BitLocker if I install Windows 8 in UEFI mode. By default it had installed in BIOS mode (and was continuing to when I re-installed) so a few months ago I had read about UEFI and figured how to install Windows 8 on that laptop in UEFI mode.

Then at work we started getting UEFI computers and so I spent some time going through the firmware on those computers just to get a hang of UEFI.

And then last month I bought a Notion Ink Cain tablet, and to get encryption working on it I had to enable Secure Boot (which is a part of UEFI) so once again I found myself reading about UEFI. That was a fun exercise (and something I am yet to post about) so I have been meaning to write about UEFI for a while just that I never got around to it. Since I stumbled upon UEFI again today, might as well do so now.

So what is UEFI? Simply put UEFI is a firmware specification that’s meant to replace BIOS. Most modern laptops and desktops come with UEFI but it looks and behaves like BIOS so you might not notice the difference until you delve in. In this post I’ll focus on the boot process of BIOS and UEFI as that’s what I am interested in.

BIOS boot process

With BIOS you have an MBR (Master Boot Record). In BIOS you specify the boot order of disks, and each of these disks is searched for the MBR by BIOS. The MBR is the first sector of a disk and it contains information on the partitions in the disk as well as a special program (called a “boot loader”) which can load OSes from these partitions. Since the MBR is at a standard location the BIOS can pass control to the boot loader located there. The BIOS doesn’t need to know anything about the OSes or their file systems – things are dumb & simple.

BIOS has limitations in terms of the size of disks it can work with, the limited space available to the boot loader (because of which you have to use quirks like “chain loaders” and such), and so on. BIOS is good, but its time has come … its replacement is UEFI.

What is UEFI?

BIOS stands for “Basic Input/ Output System”. UEFI stands for “Unified Extensible Firmware Interface”. UEFI began as EFI, and was developed by Intel but is now managed by the UEFI Forum. Both BIOS and UEFI aren’t a specific piece of software. Rather, they are specifications that define the interface between the firmware and OS. The UEFI specification is more managed. There are many versions of the specification, with each version adding more capabilities. For instance, version 2.2 added the Secure Boot protocol stuff. Version 2.1 added cryptography stuff. As of this writing UEFI is at version 2.4.

In contrast, BIOS doesn’t have a specification as such. Various BIOS implementations have their own feature set and there’s no standard.

For backward compatibility UEFI can behave like BIOS. The UEFI specification defines a Compatibility Support Module (CSM) which can emulate BIOS. Bear in mind, it is still UEFI firmware, just that it behaves like BIOS firmware without any of the additional UEFI features or advantages. You can’t have both UEFI and BIOS on a computer – only one of them is present, after all they are both firmware!

UEFI classes

The UEFI forum defines four classes for computers:

  1. Class 0 – The computer has no UEFI, only BIOS.
  2. Class 1 – The computer has UEFI with CSM only. So it has UEFI but behaves in a BIOS compatible mode.
  3. Class 2 – The computer has UEFI and CSM. So it can behave as BIOS compatible mode if need be.
  4. Class 3 – The computer has UEFI only, no CSM.

It’s important to be aware of what class your computer is. Hyper-V Generation 2 VMs, for instance, behave as Class 3 computers. They have no CSM. (Moreover Hyper-V Generation 2 does not have a 32-bit implementation of UEFI so only 64-bit guest OSes are supported).


UEFI has a different boot process to BIOS. For starters, it doesn’t use the MBR. UEFI uses a newer partitioning scheme called GPT (GUID Partition Table) that doesn’t have many of MBRs limitations.

If your disk partitioning is MBR and you system has UEFI firmware, it will boot but in CSM mode. So be sure to choose GPT partitioning if you want to use UEFI without CSM.

Also, even though your machine has UEFI, when trying to install Windows it might boot the Windows installer in CSM mode. When you press F9 or whatever key to select the boot media, usually there’s an option which lets you boot in UEFI mode or BIOS/ CSM mode. Sometimes the option isn’t explicit and if the boot media has both UEFI and BIOS boot files, the wrong one may be chosen and UEFI will behave in CSM mode. It is possible to detect which mode Windows PE (which runs during Windows install) is running in. It is also possible to force the install media to boot in UEFI or CSM mode by deleting the boot files of the mode you don’t want.

My laptop, for instance, is UEFI. But each time I’d install Windows 8 onto it it would pick up the BIOS boot loader files and boot in CSM mode. Since I wanted to use UEFI for some of its features, I used Rufus to create a bootable USB of the media (be sure to select “GPT partitioning for UEFI computers”) and when I booted from it Windows installed in UEFI mode. The trick isn’t the GPT partitioning. The trick is that by telling Rufus we want to boot on an UEFI computer, it omits the BIOS specific boot loader files from the USB. It is not necessariy to use Rufus – the process can be done manually too.

UEFI and GPT work with both 32-bit and 64-bit Windows. The catch is that to booting from GPT is only supported for 64-bit Windows running in UEFI. So while you can have 32-bit Windows running in UEFI, it will need an MBR partition to boot from. What this means is that such a system will be running as UEFI Class 2 as that’s the only one which supports UEFI and MBR partitions (essentially the system has UEFI but behaves as BIOS compatible mode).

UEFI classes and MBR/GPT partitioning

With Windows you can use MBR or GPT partitions on your computer depending on its class. From this Microsoft page:

  • UEFO Class 0 – Uses MBR partitions.
  • UEFI Class 1 – Uses GPT partitions.
  • UEFI Class 2 – Uses GPT partitions. This class of UEFI support includes CSM so if MBR partitions are present UEFI will run in compatibility mode.
  • UEFI Class 3 – Uses GPT partitions.

I am not clear why Class 1 only uses GPT partitions. Considering Class 1 is UEFI with CSM only and CSM supports MBR, I would have thought Class 1 supports only MBR partitions.

UEFI boot process

The UEFI boot process is more complicated than BIOS. That doesn’t mean it’s difficult to understand or unnecessarily complicated. What I meant is that it isn’t as simple as having an MBR with a boot loader, as in the case of BIOS. You can’t expect to pass along a VHD file created with BIOS in mind to a machine having only UEFI and expect it to work (as was my case). You need to tweak things so the boot process works with UEFI.

An excellent blog post on the UEFI boot process is this. If you have the time and inclination, go read it! You will be glad you did. What follows are my notes from that post and some others.

  • The UEFI specifications define a type of executable (think .exe files) that all UEFI firmware must support. Each OS that wishes the UEFI firmware to be able to boot it will provide a boot loader of this type. That’s it. OS provides such a boot loader, UEFI loads it.
  • In BIOS the boot loader was present in the MBR. Where is it present in UEFI? In order to be not limited by space like BIOS was, UEFI defines a special partition where boot loaders can be stored. The partition doesn’t have to be of a specific size or at a specific location. The spec requires that all UEFI firmware must be able to read a variant of the FAT file system that’s defined in the spec. (UEFI firmware can read other file system types too if they so wish, but support for this variant of FAT is a must). So UEFI boot loaders are stored in a special partition that’s of file system type FAT (the variant defined by UEFI). And to denote this partition as the special partition it has a different type (i.e. it doesn’t say FAT32 or NTFS or EXT2FS etc, it says ESP (EFI System Partition)). Simple! (Oh, and there can be multiple ESP partitions too if you so wish!)

The above design makes UEFI much more reliable than BIOS. Whereas with the latter you could only store a very limited boot loader at a specific space on the disk – and that boot loader usually chain loaded the OSes – with UEFI you can store boot loaders (in the EFI executable format) of each OS in the ESP partition that’s of file system type FAT (the variant defined by UEFI). Already you have a lot more flexibility compared to BIOS.

To tie all these together UEFI has a boot manager. The boot manager is what looks at all the boot loader entries and creates a menu for booting them. The menu isn’t a static one – the firmware can create a menu on the fly based on boot loaders present across multiple disks attached to the computer. And this boot manager can be managed by tools in the installed OS too. (Sure you could do similar things with Linux boot loaders such as GRUB, but the neat thing here is that the functionality is provided by the firmware – independent of the OS – which is really where it should be! It’s because BIOS was so limited that we had fancy boot loaders like GRUB that worked around it).

If you go down to the section entitled “The UEFI boot manager” in the post I linked to earlier you’ll see an example of a boot manager output. No point me paraphrasing what the author has said, so best to go and check there. I’ll mention one interesting point though:

  • Remember I said there are ESP partitions and they contain the OS boot loaders? So, for instance, you could have an UEFI boot manager entry like HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi) which points to the partition called HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d) (the naming convention follows a EFI_DEVICE_PATH_PROTOCOL specification) and specifically the \EFI\fedora\grubx64.efi file as the boot loader.
  • What you can also have, however, is a generic entry such as HD(2,0,00). Note there’s no boot loader specified here, and probably no specific ESP partition either. What happens in such cases is that the boot manager will go through each ESP partition on that disk, check for a file \EFI\BOOT\BOOT{machine type short-name}.EFI, and try loading that. This way the UEFI spec allows for one to boot from a hard disk without specifying the OS or path to the boot loader, as long as the disk contains a “default” boot loader as per the naming convention above. This is what happens, for instance, when you boot a Windows 8 DVD, for instance. If you put in such a DVD in your computer and check, you’ll see the root folder has a folder called EFI that contains a sub folder called BOOT which contains a file called bootx64.efi.

Another example and screenshot of the UEFI boot manager can be found at this link.

Tying this in with my WIM to VHD case

If you have read this far, it’s obvious what’s wrong with my VHD file. When the Gen 2 VM boots up – and it uses UEFI as it’s a Gen 2 VM – it will look for a ESP partition with the UEFI boot loader but won’t find any (as my VHD has only one partition and that too of type NTFS). So what I need to do is create an ESP partition and copy the boot loaders to it as required. Also, I am using MBR style partitioning and a Gen 2 VM firmware is Class 3, so I must switch to GPT.

In fact, while I am at it why don’t I partition everything properly. When I install Windows manually (server or desktop) it creates many partitions so this looks like a good opportunity to read up on the Windows partitioning scheme and create any other required partitions on my base disk.

Understanding (GPT/UEFI) disk partitions for Windows

There are three Microsoft pages I referred to:

Read those for more details than what I post below.

The following partitions are required:

  • System partition: This is the EFI System Partition (ESP). Minimum size of the partition is 100 MB, FAT32 formatted. For Windows, the ESP contains the NTLDR, HAL, and other files and drivers required to boot the system. The partition GUID for ESP is DEFINE_GUID (PARTITION_SYSTEM_GUID, 0xC12A7328L, 0xF81F, 0x11D2, 0xBA, 0x4B, 0x00, 0xA0, 0xC9, 0x3E, 0xC9, 0x3B) (on an MBR partition the ID is 0xEF; but remember, Windows doesn’t support booting into UEFI mode from MBR partitions). The type of this partition is c12a7328-f81f-11d2-ba4b-00a0c93ec93b. Windows does not support having two ESPs on a single disk.
  • Microsoft Reserved Partition (MSR): Whereas with BIOS/ MBR one could have hidden sectors, UEFI does away with all that. So Microsoft recommends a reserved partition be set aside instead of such hidden sectors. The size of this partition is 128 MB (for drives larger than 16GB; else the size is 32 MB). It does not have any data – think of the MSR as free space set aside for future use by Windows – it is used when any disk operations require extra space and/ or partitions and they can’t use the existing space and/ or partitions. The partition GUID for MSR is DEFINE_GUID (PARTITION_MSFT_RESERVED_GUID, 0xE3C9E316L, 0x0B5C, 0x4DB8, 0x81, 0x7D, 0xF9, 0x2D, 0xF0, 0x02, 0x15, 0xAE). The type of this partition is e3c9e316-0b5c-4db8-817d-f92df00215ae.

The order of these partitions is: ESP, followed by any OEM partitions, followed by MSR, followed by the OS & data partitions. (See this link for a nice picture).

Apart from the two above, Microsoft recommends two other partitions (note: these recommended, not required):

  • Windows Recovery Environment (Windows RE) tools partition: This must be at least 300 MB, preferably 500 MB or larger, and contains the Windows RE tools image (winre.wim) which is about 300 MB in size. It is preferred that these tools are on a separate partition in case the main partition is BitLocker encrypted, and even otherwise to ensure the files in this partition are preserved in case the main partition is wiped out. The type of this partition is de94bba4-06d1-4d40-a16a-bfd50179d6ac.
  • Recovery image partition: This must be at least 2 GB, preferably 3 GB, and contains the Windows recovery image (install.wim) which is about 2 GB in size. This partition must be placed after all other partitions so its space can be reclaimed later if need be. The type of this partition is de94bba4-06d1-4d40-a16a-bfd50179d6ac.

Finally, the disk has basic data partitions which are the usual partitions containing OS and data. These partitions have a GUID DEFINE_GUID (PARTITION_BASIC_DATA_GUID, 0xEBD0A0A2L, 0xB9E5, 0x4433, 0x87, 0xC0, 0x68, 0xB6, 0xB7, 0x26, 0x99, 0xC7). The minimum size requirement for the partition containing the OS the 20 GB for 64-bit and 16 GB for 32-bit. The OS partition must be formatted as NTFS. The type of these partitions are ebd0a0a2-b9e5-4433-87c0-68b6b72699c7.

The order of all these partitions is: Windows RE tools, followed by ESP, followed by any OEM partitions, followed by MSR, followed by the data partitions, and finally the Recovery image partition.

It is worth pointing out that when you are installing Windows via an answer file it is possible to create all the above partitions via an answer file. But in my scenario, I am applying a WIM image to a VHD partition manually and creating all the partitions myself so I need a way to do this manually.

Let’s make some partitions!

Now back to my VHDs. To recap, previously I had shown how I apply an OS image from a WIM file to a (base) VHD and then make differencing VHDs off that base VHD for my Hyper-V VMs. The VHD thus created works well for Generation 1 VMs but fails for Generation 2 VMs. As we have learnt from the current post that’s because (a) I was using MBR partitions instead of GPT and (b) I hadn’t created any ESP partitions for the UEFI firmware to pick a boot loader from. Hyper-V Generation 2 VMs have a Class 3 UEFI firmware, so they don’t do any of the CSM/ BIOS compatibility stuff.

As before, create a new VHD and initialize it. Two changes from before are that I am now using a size of 25 GB instead of 20GB and that I initialize the disk as GPT.

Confirm that the disk is visible and note its number:

By default the newly created disk has a 128 MB MSR partition. Since the ESP has to be before this partition let’s remove that.

Then create new partitions:

Just double-checking:


Next I apply the image I want as before:

That takes care of the data partition. Let’s look at the other ones now.

WinRE tools partition

This is the first partition on the disk. I will (1) format it as FAT32, (2) mount it to a temporary drive letter, (3) copy the WinRE.WIM file from E:\Windows\System32\Recovery (change E: to whatever letter is assigned to the OS partition), (4) register the Windows RE image with the OS, and (5) dismount it.

Thanks to this TechNet article on how to register the Windows RE image. The WinRE.WIM image can be customized too with drivers and other tools if required but I won’t be doing any of that here.

Thanks to one of my readers (Exotic Hadron) for pointing out that the winre.wim file is only present in %SYSTEMROOT%\System32\Recovery if Windows was installed by expanding install.wim (like in the above case). On a typical system where Windows is installed via the setup program the file won’t be present here.

Just double-checking that Windows RE is registered correctly:

EFI System Partition

This is the second partition on the disk. As before I will format this as FAT32 and mount to a temporary drive letter. (Note: I use a different cmdlet to assign drive letter here, but you can use the previous cmdlet too).

Format the partition as FAT32. The Format-Volume cmdlet doesn’t work here (am guessing it can’t work with “System” partitions) so I use the usual format command instead:

Get the boot loaders over to this drive, confirm they are copied, and remove the drive letter:


Recovery Image partition

Last thing, let’s sort out the recovery image partition.

I am going to skip this (even though I made the partition as an example) because there’s no point wasting the space in my use case. All one has to do to sort out the recovery image partition is to mount it like with the WinRE tools partition and copy over the install.wim file to it. Then use the ReAgentc.exe command to register that image with that installation of Windows. (See steps 5-7 of this link).

That’s it!

Now dismount the VHD, make a differencing VHD as before, create a VM with this VHD and fire away!

And voila! It is booting!



Update: I came across this interesting post by Mark Russinovich on disk signature collisions and how that affects the BCD. Thought I should link it here as it makes for a good read in the context of what I talk about above. 

Notes on Hyper-V differencing disks

I am using Hyper-V again to setup a lab on one of my laptops. Most of the VMs are going to be Server 2012 (GUI or Core) and rather than “waste” space for each VM I decided to create a base VHD and use.

Generation 1 VM only!

The steps below only work for a Generation 1 VM. If you want to use a Generation 2 VM read this post to get an idea of what I am doing, but don’t follow all the steps. Instead, check out my next post where I go into UEFI and GPT and the boot process there, and follow the steps there.

Using the VHD created below in a Generation 1 VM gives the following error when booting: Boot failed. EFI SCSI Device. No Operating System was Loaded. Press a key to retry the boot sequence ...

Here’s how I went about doing it. (None of this is new material, the below is just notes to my future self). Also, all these steps are on my Windows 8.1 with Update laptop, so it might not work on older versions of Windows (I know for sure that these won’t work on Windows 7).

First, mount the Server 2012 ISO:

The ISO is mounted at F: drive. The sources\install.wim file in this drive contains the WIM file with all the Server 2012 images. A WIM file (short for “Windows IMaging” file) is a file-based image. Unlike a block-based image (which is what most of us are familiar with from tools such as Ghost) a file-based image contains the files and file-system as it. In addition to that the files are compressed, and duplicate file names point to one actual file, so you could have a WIM file that contains all the editions of Server 2012 but the size of the WIM file isn’t equal to the size of one of these multiplied by the number of editions. Since Vista WIM files are what Microsoft’s been using to install the OS. The install program sets up your hard disk and then dumps a WIM file onto it. After a reboot, the machine boots into this dumped image and continues configuring and customizing.

The beauty of this is that one can dump a specified image from a WIM file onto a virtual hard disk too – which is what I am going to do here. I select an image from my WIM file, create a VHD file, and apply this image to the VHD file. Then when I boot up from this VHD file in a newly created VM the setup process continues as it is. The difference here is that I am going to apply to the image to a VHD file, and then use that VHD file as a base image and create new “differencing” VHD files off that. This way each newly created VM uses the differencing VHD file, and the size of that is more or less equal to the changes I make in the VM. That’s way better than having multiple VHD files all of which contain the same OS and similar files and together take up a lot of space!

Back to the WIM file, find the image that we are interested in:

I am interested in the first image here (Serer 2012 R2 Standard Core). I want to apply this image to a VHD. So I create a 20GB VHDX file:

Mount the VHDX file:

Note that I use Get-Disk above. That’s because the VHDX doesn’t have a file system yet, and hence no volume. I will have to prepare the VHDX before I can apply the previous WIM image onto it. So let’s do that.

Create a partition and format it as NTFS. Assign a drive label while we are at it.

NOTE: It is possible to combine all the cmdlets above from New-VHD to Format-Volume into one long pipe. That way easier to copy paste than the multiple cmdlets above. Here’s the combo version:

Now I apply the WIM image to this drive letter (which is actually the VHDX file I created earlier):

This cmdlet will take a while to complete (and it doesn’t offer much by way of a progress bar)

NOTE: You can use the DISM command too instead of the cmdlet above. That has a more informative progress bar:

Install a boot loader on the VHD so it boots.

Don’t forget the boot loader!

I had missed this step when I first wrote this post. Apologies if anyone followed the steps and ended up with non-bootable VHD. I realized this omission only after I tried booting the VHD and got the following error:


Finally dismount the VHDX:

Dismount the ISO file too if you are done with it:

Finally, I make a new differencing VHD:

That’s it. Now I can create a VM and assign the WINDC01.vhdx disk to it. As far as the VM (or even us if we mount the VHDX file directly) are concerned the WINDC01.vhdx file is identical to the 2012R2.vhdx file it is based up. Just that what the file actually contains is only the differences from the base file. Any references to files in the base VHD file are looked up there transparently; any references to new/ changed files are looked up in the differencing VHD file.

Generation 1 VM only!

As mentioned at the beginning of this post, the VHDX file created using the above steps only works with a Generation 1 VM. With a Generation 2 VM you get an error like this:


This is because Generation 2 VMs are using UEFI and they have a different boot process. Check my follow-up post on what to do with a Generation 2 VM. .

[Aside] Creating a Windows USB to Go drive

Starting today I plan to make posts like these which are just links to other blogs. I find myself referring to this blog nowadays just to check out my notes on a topic or to see the links I refer to. It’s more convenient than my browser bookmarks as there’s more context in a blog post and it’s quicker to search.

Initially I thought of having a separate blog to post such “asides” but that’ll just be one more blog to maintain and search and make a decision when I want to post something. So I’ll just stick to this blog, but put these posts in a separate category and mark them so in the title.

Get-WindowsFeature missing

I always open up PowerShell on $randomcomputer and type Get-WindowsFeature expecting to get a list of Windows features. Sometimes it doesn’t work and then I Google on why that’s the case, forgetting that I’ve been down this route umpteen times. So here’s a post for myself.

The *-WindowsFeature cmdlets are available via the Server Manager module which in turn is either present by default (on servers) or installed via the Remote Server Admin Tools (on clients).

  1. Windows Server 2012: Modules are loaded automatically on demand so the *-WindowsFeature cmdlets are available without any additional steps.
  2. Windows Server 2008 R2: Import the Server Manager module and then the *-WindowsFeature cmdlets can be used.
  3. Windows 8: Install the Server Manager via RSAT. This makes the Server Manager module available for automatic loading and then the *-WindowsFeature cmdlets can be used. Windows 8 also provides (Get|Enable|Disable)-WindowsOptionalFeature cmdlets as part of the DISM module (which is present by default). These provide similar functionality to the *-WindowsFeature cmdlets (doesn’t work on remote computers though!). Add the -Online when using these cmdlets as they can work with the running instance or a mounted Windows image.
  4. Windows 7: Installing the Server Manager via RSAT doesn’t help. It doesn’t include the Server Manager module and so the *-WindowsFeature cmdlets are not available. An alternative is to install the 3rd party Client Manager module which gives the *-ClientFeature cmdlets.

DISM in Windows Server 2012 (part 1)

After writing yesterday’s post I wondered what switches DISM would have to install a new feature from a specified source. I played around a bit with DISM and realized that the version (6.2.9200.16384) in Server 2012 has more features compared to the version (6.1.7600.16385) in Server 2008. I haven’t obviously explored them all out, but as and when I do I’ll make subsequent posts to document them.

An interesting new feature that stands out for me is the fact that the /enable-feature switch now supports an /all switch that automatically installs all the needed dependency features.

Unfortunately the /disable-feature doesn’t have a corresponding switch to remove all the automatically installed dependencies so be sure to keep track of these.

The /disable-feature does have a /remove switch though which can be used to disable a package and remove all its binaries. This is one step ahead of what the /disable-feature in the previous DISM version offers. There you could only disable the feature but the binaries (the installed files) would still be on the system; now you have an option to remove them too.

Features whose binaries are thus removed (or were never installed in the first place) are marked differently when you use /get-features:

Note the “Disabled with Payload Removed” status.

If you are trying to install a feature whose binaries (the payload) are not present /enable-features complains about that. You can use the /Source switch to specify a source for these binaries.

The /Source switch must point to a path similar to the one required by the -Source switch of the Add-WindowsFeature (see my previous blog post or this TechNet article). It must be the C:\Windows folder in a WIM file image or on a running Windows installation anywhere else on the network.

And that’s it, the feature is installed!

I think I’ll stick to DISM instead of PowerShell for a while while managing features. PowerShell has a DISM module now and hence a subset of the DISM commands, but it’s easier working with DISM exclusively for these sort of tasks as DISM has more features and eventually you will need to depend on DISM for some of these features (managing WIM images, for instance) and so I feel sticking with it exclusively will help breed more familiarity with DISM.

DISM mounted images are persistent across reboots so be sure to /unmount-wim them. You can get a list of mounted WIM images via the /get-mountedwiminfo switch.

The /discard switch is required while un-mounting to tell DISM it doesn’t need to save any changes (not that we made any changes in this case, but one could potentially make changes and save them using DISM). If you wanted to save changes instead use the /commit switch.

That’s all for now!

Installing MinShell on Windows Server 2012 Core

Inspired by this great post on improvements in Windows Server 2012 I decided to give MinShell a go.

Unlike that post, however, I was starting from Server Core and wanted to add on MinShell (not start with Server regular and remove the additional components to be left with just MinShell). Not a problem, PowerShell can be used to install the “Graphical Management Tools and Infrastructure” feature.

Hmm, bummer. That was unexpected!

In retrospect this is not surprising. It happens because (obviously) the binaries for the Server Manager GUI bits are not present in the installed system and so one must point the Add-WindowsFeature cmdlet to a source where it can get these from.

Had it been a non-GUI feature such as DNS or DHCP, the binaries would already be installed as part of Server 2012 Core – but not enabled – and so all the cmdlet needed to do would be to enable the feature. (However: if it were a non-GUI feature whose binaries were removed via the Uninstall-WindowsFeature cmdlet with the –Remove switch, then we would have had to point Add-WindowsFeature to a source if we wanted to install these features later).

The Add-WindowsFeature cmdlet has a –Source switch which lets you specify a path from where it can pick up the binaries. This must point to the c:Windows folder and that’s where the binaries are copied over from. If you have another Windows Server 2012 (non-Core) you can share its c:Windows folder and point –Source to that. Or you can mount the Windows Server 2012 (non-Core) install image from WIM file in the installation DVD and point –Source to that. If you have the WIM file from the installation DVD on a network location, you can also point to the Windows Server 2012 (non-Core) install image in that by prefixing the path with WIM: like this: –Switch wim:pathtowimfile.wim:2 (where 2 is the index of the image in this WIM file).

WIM files are sort of like containers for disk images. A single WIM file can contain many disk images – often with overlapping files – and so the size of the WIM file isn’t necessarily equal to the size of all the disk images combined. It is also a file based disk image format – meaning the images contain the actual file system and files within, not just binary data like a sector based format (such as ISO or VHD files). This is why you can actually “mount” an image from the Windows Server 2012 DVD on a folder and then browse this image as a regular file system – because it is a regular file system! The Windows installation DVDs usually contain the installation WIM file – called install.wim – in the Sources folder.

The DISM (Deployment Image Servicing and Management) command is your friend when it comes to WIM files. We met DISM earlier in the context of enabling/ disabling features and while it has a pretty straight-forward syntax it’s kind of ugly. Apart from enabling/ disabling features, you can also use DISM to inspect WIM files, mount the images within them, make changes to these images, and so on.

Before mounting an image in a WIM file, we need to inspect it to see what images are present. The /getwiminfo switch is your friend for that:

As you can see, there are four images in this WIM file. Two of these images are 7GB in size, two are nearly 12GB in size. So one would expect the WIM file containing these images to be around (7*2+12*2=)36GB in size, but in reality the WIM file is just 3.1GB. This is because all these images share the files within them and in addition to that the files are compressed. We want to install the “Graphical Management Tools and Infrastructure” feature which is present in the Windows Server 2012 Standard image (index : 2) and so that’s the image we are interested in.

To mount this image, create a folder and invoke DISM with the /mount-wim switch:

Mind you, DISM is very finicky when it comes to syntax. There is no space between the /wimfile: switch and its arguments; similarly no space between /mountdir and its arguments.

If we navigate to the c:\Offline folder we can see a regular file system with a Windows folder. Navigate through this and you’ll see its just like the Windows folder in a live Windows system. This is the folder we are interested in.

So back to Add-WindowsFeature we now pass the above mentioned folder via the -Source switch:

Success! Restart, and type servermanager in the command prompt that you get to launch MinShell!

DISM mounted images are persistent across reboots. So once you are done with it be sure to unmount the image with the /unmount-wim switch:

The /discard switch tells DISM we are not interested in it saving any of our changes to the image (not that we made any changes here; but in theory one could and save it back to the image).

Have fun with MinShell!


Windows Server 2008 R2 Core initial setup (part 2)

Once your Server Core network etc are configured it’s time to enable/ disable Windows features and roles.

To enable/ disable/ list Windows features and roles it’s probably easiest to import the ServerManager module into PowerShell and use the three cmdlets provided. But just in case you are not into PowerShell, or don’t want to install PowerShell and it’s dependency .NET (you are on Server Core and PowerShell & .NET aren’t installed by default there) there are two alternatives.


DISM is short for Deployment Image Servicing and Management. As the name suggests, it’s a tool for managing the disk image using which you deploy Windows. Starting with Windows Vista the installation files of Windows are stored in a (file based) disk image called the Windows Imaging Format (WIM). DISM is a tool that can manage this disk image before it’s deployed to a computer. But DISM is not just about managing disk images before they are deployed; it can be used also to manage a running instance of a deployed image. The latter is what we are interested here.

Disk images prior to deployment are known as offline images. Disk images that are currently running as the OS within which DISM is invoked are called online images. When you are dealing with an online image you also pass the switch /online to DISM.

DISM was introduced with Windows 7/ Windows Server 2008 R2 and has a pretty straight-forward syntax:

The switches of interest to use are /Enable-Feature, /Disable-Feature, and /Get-Features.

To get a list of available features:

To enable a feature:

As you can see, feature names are case sensitive (eugh!!), and DISM doesn’t automatically enable dependent features – we have to enable them ourselves (good in a way coz DISM won’t enable a whole bunch of dependencies without me realizing, but I wish there were a way to say go ahead and enable whatever’s required). In contrast, if you try enabling a feature using PowerShell with the ServerManager module, dependencies are automatically taken care of.

(Update: DISM in Windows Server 2012 and Windows 8 has a /all switch that automatically installs all the dependencies.)

The feature names are also not very intuitive – for instance to enable AD DS you need to enable the DirectoryServices-DomainController-ServerFoundation feature but that’s not very obvious coz of the ServerFoundation tacked at the end of the feature name, which makes you think it might be a scaled down version of AD DS. (Just as an aside: in the specific case of AD DS, even if you don’t enable the afore-mentioned feature yourself, dcpromo automatically enables it as part of its tasks). This TechNet article is helpful in understanding what the feature names are.

I also hate the fact the fact that there are so many switches to type, but hey, at least the names are logical and I am glad DISM doesn’t have any dependencies and works out of the box on Server Core too. PowerShell has much better switches, but you need DISM sort of to enable PowerShell and the ServerManage module features.

Apart from enabling and disabling features, it’s worth knowing that DISM can be used to upgrade between editions. Say if you are running Server Core Standard and want to move to Server Core Enterprise, DISM can do that.

Read more about DISM and upgrading images at this TechNet article and blog post.

Lastly, DISM can also be used to query the installed drivers:

Unfortunately while there is a /Add-Driver switch for adding drivers, it doesn’t work against an online image.


OCSetup is short for Optional Components Setup. This tool was introduced in Windows Vista/ Server 2008 specifically for Server Core. Windows Vista/ Server 2008 had the new modular architecture of roles and features, along with the Server Manager tool (GUI and command line) to manage these. However, Server Manager depends on .NET which is not enabled by default on Server Core, and so the OCSetup tool was provided for Server Core. This tool has a counterpart called OCList that gets a list of the optional components.

The names returned by OCList are same as the ones given by DISM.

Once you’ve identified the features you’d like, enable them using OCSetup:

Similar to DISM, OCSetup too is case sensitive and doesn’t automatically install dependent features. Moreover, it doesn’t give any output. To see whether the feature was enabled, you run OCList again and verify that it’s installed.

OCSetup has a much simpler syntax than DISM, but also doesn’t have the additional features that DISM has. Moreover, DISM is a useful tool to know for creating offline images for deploying on other machines, so it’s worth familiarizing oneself with DISM.