MCS provisioned hosts fail to apply GPO during initial boot

After a successful image update on a machine catalog the MCS provisioned hosts do not apply the GPO’s during the initial logon. The netlogon service on the hosts is unable to apply the computer policies because the host’s NICs are not ready yet. So the initial end user login does not have any GPO settings applied.

A similar issue has already been placed in a user forum: A valid workaround/ fix has been provided for VMWare hypervisors:


Citrix XenDesktop 7.6
Machine Catalog: Static, 1:1 user – host assignment, user data discarded

Hypervisor :
Microsoft Hyper-V on Server 2012 R2
Hosts are on a Cluster, Checkpoints/ vDiscs on a CSV



the image is being updated on the machine catalog. After the successfull staging of the new image on the endpoint (Wyse ThinClient) the following steps are performed:

  • Running, working (=GPO’s applied) session on a MCS provisioned virtual desktop
  • Reboot initialized through the ThinClient (power off)
  • the user disconnects from the session (because of the ThinClient reboot)
  • the disconnection let the hyper-v vm shut down (configured in delivery group setting)
  • the hyper-v vm starts again (another delivery group setting: host are always powered on if there’s an user assigned)
  • the host starts, shuts down and starts again (new image applied)
  • the ThinClient reconnects and authenticates against the AD (Autologon enabled on TC)
  • the logged on user tries to reconnect to the session (polling the hyper-v vm)
  • as soon as the session is ready on the hyper-v host the user on the ThinClient reconnects to the session and logs in
  • the computer GPO’s are not applied (see netlogon error’s below)
  • resulting the user GPO’s are not applied (we don’t configure dedicated GPO’s for users, instead we use the Loopback/ replace option in computer policy user settings)
  • the user session looks like this
  1. there shouldn’t be a Shut Down option (removed through GPO)
  2. the desktop background is set to a consistent blue
see the difference:
This is pretty bad, as some of these clients are located in the airport public area and could be accessed theoretically by anyone. Through GPO I do secure and lock down some of the most critical clients.
During the logon process there are several messages (Netlogon, Group Policy Service) stating that the settings can’t be applied because of missing connectivity to the DC.
Interesting is that during the startup process there’s a second NIC initialized (NIC#2)
In the desktop after the user login the first NIC is shown as a hidden/ not working device in the device manager (cmd.exe ran as admin -> set devmgr_show_nonpresent_devices=1 -> start devmgmt.msc)
I suggest that the second NIC is being added during the provisioning of the machines from Citrix!
On my reference machine where the reference checkpoint (=base image) comes from I don’t have any second NIC.
So during the startup of the hyper-v vm the OS has to install the NIC two times which causes the netlogon service/ gpo service to fail becaus the first intalled NIC doesn’t have connectivity and the second NIC (#2) will be the active one – but is in place too late for the GPO’s to be processed and applied. Why the 2nd NIC? I suggest that the synthetic NIC configured in every target is the root cause. If I would configure a legacy NIC, I wouldn’t have the installation of a second NIC – but I would be limited to 100Mbit so that’s not an option.
Similare cases
I’ve found a post in the WWW reporting a similare case. The hypervisor there was VMWare.
Workarounds (not working)
  • startup script which pings the domain until the domain is reachable and performs a GPUpdate /force (/target:computer), startup scripts which performs a 40s ping until the computer proceeds to the logon screen
  • Set dependencies on the netlogon service to another service
  • Local GPO’s delaying the netlogon service until the computer is connected/ running scripts synchronously/ verbose logging/
  • Reg keys:

     RegSetValue -Hive “HKLM” -Path “Software\Microsoft\Windows\CurrentVersion\Policies\System” -ValueName “VerboseStatus” -ValueType “DWord” -Value “1”

RegSetValue -Hive “HKLM” -Path “Software\Microsoft\Windows\CurrentVersion\Policies\System” -ValueName “RunStartupScriptSync” -ValueType “DWord” -Value “1”

RegSetValue -Hive “HKLM” -Path “Software\Microsoft\Windows\CurrentVersion\Policies\System” -ValueName “HideStartupScripts” -ValueType “DWord” -Value “0”

RegSetValue -Hive “HKLM” -Path “Software\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon” -ValueName “SyncForegroundPolicy” -ValueType “DWord” -Value “1”

RegSetValue -Hive “HKLM” -Path “Software\Policies\Microsoft\Windows\System” -ValueName “GroupPolicyRefreshTime” -ValueType “DWord” -Value “10”

RegSetValue -Hive “HKLM” -Path “Software\Policies\Microsoft\Windows\System” -ValueName “GroupPolicyRefreshTimeOffset” -ValueType “DWord” -Value “5”

RegSetValue -Hive “HKLM” -Path “SYSTEM\CurrentControlSet\Services\Netlogon\Parameters” -ValueName “ExpectedDialupDelay” -ValueType “DWord” -Value “600”

Next steps
I do have a case open at Citrix since yesterday (02.12.15). I will perform two tests
  • Install the latest VDA Agent (7.6.300.7020) in the reference image
  • set the REG Key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters DisableDHCPMediaSense DWORD 1 (
The big question for me is if during the MCS machine provisioning process are there (and why) any NIC’s added to the virtual computer.
I will open a case @ Microsoft as well in order to fasten the solution finding process a bit and because the issue might be MS related. They have already proviced a KB for VMWare hypervisors (
Solution (11.01.16)
After intense troubleshooting with the MS Hyper-V/ Domain and network engineers a suitable KB has been found which fixed the issue.
The KB describing the same issue but with VM Ware serving as hypervisor links to another KB which contains a hotfix:
We’ve identified the files which are updated from this specific KB. I received the info about two KB’s which exactely updates the same files:
After installing those updates, the Ghost NIC’s still exists but the Plug and Play initialization seems to be faster and more reliable so the GPO’s got applied after each initial logon.

3 thoughts on “MCS provisioned hosts fail to apply GPO during initial boot

  1. Hi,

    I have exactly the same issue here (XenApp 7.6, MCS provisionned hosts Windows 2008 R2 SP1). Which MS hotfixes do I have to install in the master image ? Because KB links are for 7/2008 R2 (non SP1)…

    Thanks !

    1. Hi Xavier
      The KB 2708857 and 2647409 should apply to 2008 R2 SP1

      To apply this hotfix, you must be running one of the following operating system:•Windows Server 2008 R2 Service Pack 1 (SP1)

      Just ensure that all files in each KB are updated to the KB’s version and date. For example the file pci.sys should be updated to fileversion 6.0.6002.22847 and date 05-May-2012. The files are stored in c:\windows\system32\drivers\.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s