Nigel Boulton's Blog

Tracking down registry changes made by Group Policy Objects

I was troubleshooting an issue a week or so ago in conjunction with a Citrix Technical Support Engineer, and thought I would blog a handy tip that my esteemed colleague Phil Reeve pointed out to me, which assisted in tracking down the problem.

So, let me set the scene for you. We had discovered a problem where one of our Citrix Web Interfaces was no longer notifying users of the impending requirement to change their password, during the period prior to the date on which they would be forced to do so by Active Directory.

Citrix Technical Support had been working on this problem on our behalf for a few weeks, and had been able to reproduce it successfully. I won't go into great detail here, as this is a post about troubleshooting Group Policy and not Citrix problems – suffice to say that Citrix had narrowed it down to an incorrectly set registry value on a Citrix Zone Data Collector (ZDC) that the Web Interface was reading and processing.

The value in question was HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\passwordexpirywarning. On the ZDC, it had been incorrectly set to 0. The next challenge was to find out what had done this in order to be able to change it back to the correct value, and make it stay that way.

The "passwordexpirywarning" value can be set by local or Active Directory Group Policy via the setting "Interactive Logon: Prompt user to change password before expiration". A quick check in the Local Group Policy Editor (gpedit.msc) on the affected ZDC indicated it was being set by Active Directory Group Policy, as it was greyed out:


So how to track down which Group Policy Object (GPO) was applying this incorrect value? "Try GPResult.exe or the Group Policy Results Wizard in the GPMC" I hear you shout! Of course, I tried these tools, but to no avail, as they have a "limitation" (shall we call it?) in that they don't reliably show all the registry values that Group Policy processes – and this was one such case. I have seen the same thing many a time over the years I have been working with Active Directory, and to be honest, am quite surprised that this is still the case after all this time.

So finally, to the point of this post. Below is the tip I mentioned, in the form of a procedure that can be used should you find yourself in a similar position (paths and GUIDs have been changed to protect the innocent!).

1. Open a Windows Explorer window on your domain's Sysvol folder. This will be something like "\\\Sysvol\"

2. In the Explorer Search field in this window, type the name of the registry value you are working with (in my case "passwordexpirywarning")


3. Press Enter and wait for the search to complete – it won't find anything, so you will then need to click Search in File Contents. Once the search completes, you should have one or more GptTmpl.inf files returned in the results, as shown below:


4. Open each of these files in turn in Notepad (or your preferred text editor), and search each for the registry value in question:


In the above screenshot, you can see that this is a "candidate" GPO as it is setting "passwordexpirywarning" to 0. Ignore any files that don't correspond to the value you are interested in

5. For each of the corresponding GptTmpl.inf files that contain the value in question, obtain the GPO GUID (Globally Unique Identifier) by inspecting the properties of the GptTmpl.inf file, as shown below, and copying and pasting the GUID part of the path, EXCLUDING the curly brackets {} into a temporary text file:


The aim of this is to build up a list of GUIDs for candidate GPOs

6. Now, if you are not already on a Windows 2008 R2 server with PowerShell and the Group Policy Management Console (GPMC) installed, log on to one, and open a PowerShell session

7. In the PowerShell session, type the following command:

Import-Module GroupPolicy

followed by


where <GUID> is the first GUID you collected in the text file above, for example

Get-GPO -GUID AD77FD0E-3E55-4B7B-AD7A-2C6B4E680F80

This should return the display name of the GPO corresponding to this GUID, as shown below:

PS C:\> Import-Module GroupPolicy
PS C:\> Get-GPO -GUID AD77FD0E-3E55-4B7B-AD7A-2C6B4E680F80

DisplayName      : Terminal Server Security Policy
DomainName       :
Owner            :
Id               : ad77fd0e-3e55-4b7b-ad7a-2c6b4e680f80
GpoStatus        : AllSettingsEnabled
Description      :
CreationTime     : 08/01/2011 11:17:44
ModificationTime : 27/01/2012 10:48:26
UserVersion      : AD Version: 1, SysVol Version: 1
ComputerVersion  : AD Version: 25, SysVol Version: 25
WmiFilter        :

PS C:\>

8. Copy the display name of the GPO into a text file and repeat the Get-GPO command for each of the other GUIDs you collected in the previous text file, collecting each GPO's name in the new text file as you go

All that remains is to determine which of these GPOs are applied to the affected machine:

9. Log on to the affected machine as an administrator and run gpresult /v > gpresult.txt in a command prompt. This will create a text file with a detailed output from GPResult.exe

10. Open the gpresult.txt file in Notepad (or your preferred text editor), and search for the name of each GPO collected from the Get-GPO cmdlet. Once located, this will confirm which GPO(s) are applied to the affected machine

Armed with the information determined by this procedure, I was able to update another GPO that was applied only to the ZDC in question and set the "passwordexpirywarning" value to the correct number of days, and password notifications then worked as expected.


Black Console and 100% CPU after restoring a Windows 2003 Virtual Machine

I was recently involved in a Disaster Recovery rehearsal. The idea behind this was to prove that we could recover our key systems at another site should a disaster occur. We came across an interesting issue which I thought I would blog about in case it is of help to anyone who may also encounter it in a similar situation. Let's face it, in a disaster recovery scenario, you need as few difficult issues to deal with as possible..!

This issue is only really likely to affect virtual servers (provided you are using identical hardware to recover your physical ones that is).

We were using IBM Tivoli Storage Manager (TSM) to restore C: drive and System State backups of virtual servers (taken in the live environment) into a separate isolated network.

The process involved creating a new VM (typically from a template), with the same virtual hardware version, number of vCPUs, amount of memory, disk layout and virtual NIC type as the live server. This VM would have the same operating system version, edition, architecture (x86/amd64) and service pack installed as the live server, plus the TSM client to facilitate the restore.

On restoring the first Windows 2003 server in this manner, the server wouldn't boot. The VM console displayed a black screen (no error message) and the VM CPU usage immediately spiked to 100% and stayed there. This happened immediately after power on, so it was not possible to get the VM to respond to the F8 key in an attempt to put it into safe mode, to assist with troubleshooting.

It really looked like a hardware incompatibility, but I'd been very careful to make sure the necessary parameters matched, so was a bit mystified. After some head scratching and time spent comparing the hardware that Windows thought was present in the template and live VM (good job it wasn't a real disaster!), I spotted that the Hardware Abstraction Layer (HAL) didn't match between the two (the HAL can be checked via Device Manager – Computer). The template VM had an ACPI Uniprocessor HAL (which I expected as it had been built with only one vCPU), but the live VM had an ACPI Multiprocessor HAL. I was pretty sure at this point that this would be the cause of the issue.

Like the template VM, the live VM also had one vCPU, so why did it have a multiprocessor HAL? The key difference between the two VMs was how they had been created. The live VM had originally been created by P2V'ing a physical server. This physical server would no doubt have had multiple processors and hence when Windows was originally installed, had been given a multiprocessor HAL. This didn't change on P2V, but the person who did this elected for the VM to only have one vCPU - quite understandably as it was a relatively lightly loaded server. So it was running a single vCPU with a multiprocessor HAL (which is clearly a valid configuration).

The problem was introduced by the restore process. I assume that some aspect of the restore didn't replace something in the template, and part of the template VM's uniprocessor HAL was still operational after the restore and reboot – or not operational in fact!

The supported/correct way of setting a multiprocessor HAL would be to install the OS from scratch on a VM with more than one vCPU. However, that would have been time consuming for the number of variations of servers that we had to restore, and the time available didn't allow for that.

So how did I rectify this? Well, a few years ago I ran into a (different) issue attempting to give a singe vCPU VM an additional processor, and in the process of troubleshooting that, came across this post on by Squall Leonhart. This describes how to change the Windows HAL without reinstalling. Note that this approach is, obviously, totally unsupported!

The method involved using DevCon, which is basically a command-line version of Device Manager. DevCon can be downloaded from Microsoft here.

By running the following commands within the template VM, prior to the restore, I was able to update the HAL to an ACPI Multiprocessor one:

devcon sethwid @ROOT\ACPI_HAL\0000 := +acpiapic_mp !acpiapic_up
devcon update c:\windows\inf\hal.inf acpiapic_mp

Squall recommends rebooting twice after doing this, to ensure that the device and IRQ tables get updated correctly.

After performing the steps above, a subsequent TSM restore was successful, and the server booted with no further problems. Result!

I have reproduced Squall's entire post below as this is such useful information which could be lost should the forum cease to exist for any reason – which would be a massive shame. It includes information on how to go to and from various HALs. Thanks for this incredibly helpful information Squall!

Heres some tips for upgraders!

You require the Devcon utility for this, unpack it to a folder, then navigate to the folder its in using Command prompt (command prompt on context menu PowerToy is handy for this)

How to enable APIC without repair installing windows
in device manager you will notice that under computer type it says Advanced Power and Control Interface PC.. this is a standard single processor HAL driver without APIC. to upgrade to the APIC driver you input the following:

devcon sethwid @ROOT\ACPI_HAL\0000 := +acpiapic_up !acpipic_up
devcon update c:\windows\inf\hal.inf acpiapic_up

after this, enable APIC in the bios if you haven't already, and reboot twice so windows can update the device and irq tables, it should now say ACPI Uniprocessor PC in the device manager

How to go back to PIC
if you wish to go back to PIC from APIC enter this:

devcon sethwid @ROOT\ACPI_HAL\0000 := +
acpipic_up !acpiapic_up
devcon update c:\windows\inf\hal.inf acpipic_up

and reboot twice to update the device and IRQ tables, and then disable APIC in the bios (the reason is, if you disable APIC before the device and irq tables update, windows will crash at startup.

How to Update from a Single Core APIC compatible cpu to a Multicore APIC compatible cpu

under the computer entry in the device manager, you will see it says ACPI Uniprocessor PC, to update to the multiprocessor HAL input this:

devcon sethwid @ROOT\ACPI_HAL\0000 := +acpiapic_mp !acpiapic_up
devcon update c:\windows\inf\hal.inf acpiapic_mp.

Then reboot twice again to update the device and IRQ tables.

How to go back to Single Core (should it be needed)
if you accidentally burn your processor and have to go back to a single core backup, you input this into the devcon:

devcon sethwid @ROOT\ACPI_HAL\0000 := +acpiapic_up !acpiapic_mp
devcon update c:\windows\inf\hal.inf acpiapic_up.

and always reboot twice.

Filed under: VMware, Windows 1 Comment

On-Demand Access to your Windows Live SkyDrive via Windows Explorer

My eldest is off to University later this year, and I had suggested that he upload any important documents to his Windows Live SkyDrive, for online backup and the ability to edit them if necessary from any machine with a browser.

I thought it would be worth finding a slick way of giving access to the SkyDrive via a mapped drive in Windows Explorer, ideally connecting only when required and without the annoyance of being prompted for credentials – that way the backups are more likely to happen! I was aiming to do this using what Windows 7 has to offer natively and avoiding installing any additional applications.

A quick search led me to this great post from Mike Plate. This gave me a good starting point.

I had previously used the Office 2010 method that Mike describes to successfully determine the correct path to the "My Documents" folder on the SkyDrive, but I ran into an issue (discussed below), and it has to be said that this method is slightly convoluted. Fortunately, as described in the update to the above mentioned post, Mike has developed a neat tool called the SkyDrive Simple Viewer, which is available on CodePlex to assist with this. The EXE can be run from a folder on your PC and doesn’t require installation.

Here are the steps required - you will need to perform these logged on as the user who will use the mapped drive. At the end of this process you will have a nice desktop shortcut looking something like this, that you can double-click and have your SkyDrive folder silently mapped to a drive letter on your PC:

Update 10 Dec 2011: The SkyDrive Simple Viewer no longer seems to work correctly. Please see the comment below for details, and a link to an alternative method of determining the WebDAV address.

1. Download the SkyDrive Simple Viewer for WebDAV (I used the WPF version, which requires .Net Framework 3.5 SP1)

2. Run the viewer and log in to your SkyDrive using your Windows Live credentials, then select the top-level folder you want to use to store your documents in. If this is anything other than the default "My Documents" folder you will have to log on to your SkyDrive via a browser and create it using the normal method before doing this

3. Copy the WebDAV address from the text field in the viewer and paste this into a new Notepad document. It should look something like this:^.Documents

In the above example, we’ll call "" the Server FQDN, "bc634a9b20da709c" the SkyDrive ID and "^.Documents" the Folder ID. Note that the Server FQDN will differ for each top-level folder on your SkyDrive

4. Edit the text document to create a new command line in the format shown below:

net use Drive Letter "\\Server FQDN@SSL\DavWWWRoot\SkyDrive ID\Folder ID" /SAVECRED /PERSISTENT:NO


net use s: "\\[email protected]\DavWWWRoot\bc634a9b20da709c\^.Documents" /SAVECRED /PERSISTENT:NO

A few key points here – I mentioned above that I’d run into an issue when following Mike’s article. Well, this was when attempting to map a drive to the default SkyDrive "My Documents" folder. For me, it is identified by WebDAV (as can be seen above) as "^.Documents", not "^2Documents" (perhaps Microsoft have changed this since Mike wrote his article?). Anyway, I was able to map the drive using "^.Documents", but ran into access denied errors copying files onto the SkyDrive via that route. To address this, I found that I had to enclose the entire WebDAV path in quotes, as shown in the command line above

The key to not being prompted to log on each time is to have Windows store your Windows Live credentials for you – the /SAVECRED switch does this, and the /PERSISTENT:NO switch avoids Windows mapping the drive at each logon, so that it can be done "on demand"

5. Open a Command Prompt and paste the command line you created in the Notepad document in after the prompt, and then press Enter. When prompted, provide your user name and password (i.e. your Windows Live credentials) and you should see the message "The command completed successfully". A quick check in Computer should show that the drive is mapped and the files on your SkyDrive are accessible

6. Right-click the mapped drive and select Disconnect

Finally, we need to create a shortcut to map the drive when desired:

7. Right-click the desktop and create a new shortcut

8. Paste the command line you created in the text document into the wizard without the switches, e.g.

net use s: "\\[email protected]\DavWWWRoot\bc634a9b20da709c\^.Documents"

9. Give the shortcut a suitable name (bearing in mind you can’t use a colon (:) in the name of the shortcut), and save it

10. Finally, edit the shortcut properties to run it minimised, and select a suitable icon using the Change Icon button

I selected an icon from SHELL32.dll – there’s a good number in there to choose from. Mine shows a couple of computers with a network connection alongside a globe, which I think sums up the function nicely!

11. If you would like a new Windows Explorer window to open displaying the contents of the SkyDrive folder after mapping the drive, edit the shortcut properties to prefix the target with "cmd /c " and append " & explorer s:", (without the quotes) as shown below:

cmd /c net use s: "\\[email protected]\DavWWWRoot\bc634a9b20da709c\^.Documents" & explorer s:

I find managing files on the SkyDrive this way works well, and you can go ahead and create subfolders at will using the normal Windows methods. However, if you need access to a different top-level folder you will need to set up an alternative shortcut (and/or drive letter) by following the steps above again.

If you change your Windows Live password in future, it will be necessary to repeat the steps above up to the point where you create the shortcut, to provide and save the new credentials. There isn’t a documented method of permanently removing the saved credentials should they no longer be required, as far as I’m aware - however, I will mention that they are stored under %APPDATA%\Microsoft\Credentials in hidden system files – delete them (and reboot) at your own risk!

I have seen it reported that accessing files on your SkyDrive via WebDAV can be very slow, but I haven’t experienced this myself. Of course you must remember that there is no way that it’s likely to be comparable to local storage or LAN speed-wise. Various people have reported that ensuring you do not have your Internet Explorer proxy settings configured for automatic detection can improve transfer speeds – I haven’t tested this myself. To check this, in Internet Explorer, go to Tools – Internet Options – Connections tab – LAN settings and ensure that the "Automatically detect settings" checkbox is unselected (assuming you don’t need to use this functionality of course).

Bear in mind that all the usual restrictions with regard to your SkyDrive still apply – you can only upload files of up to 50 MB in size each, and only certain types of files are permitted. However, with 25 GB of storage provided by Microsoft for free, this is a convenient way to store (and edit) your important Office documents online.

Finally, if you’d like to do this without the complication and you’re happy to install additional applications, there are a number of free applications available that may meet your needs. In the course of this work I tested a few of them, but none of them provided exactly what I wanted, so I stuck with the method described in this post.

Filed under: Windows 5 Comments