A client was trying to setup a lab of HP T610 thin clients to stream Windows 7 from Citrix Provisioning Services 6.1. The T610 they used to create the image worked flawlessly, they captured the image, and could then stream it back fine in private or standard mode. The issue appeared when they went to stream it to more than one T610 – while the original machine worked fine, on every other T610 they tried it would blue-screen on startup with the dreaded 0x0000007B error.
“It’s probably something really simple” I said – famous last words – and set about checking for differences between the T610s in the BIOS settings, firmware versions and so on, deleting and recreating machines in the PVS console, recreating the AD accounts and more. I was already familiar with the “ghosted network card” issue (CTX133188) but this was not the issue. A couple of hours later and no “simple” fixes in sight – I eventually stumbled across this thread and on page 4 one of the posters references MS hotfix KB2550978. I booted the VHD in Hyper-V, removed the PVS Target Device software, installed this hotfix and reinstalled the PVS Target device – problem solved!
The issue is the T610 clients support a feature called “PCI Express Serial Number Capability” so from PVS’s point of view, the network card in every individual T610 is seen as a new NIC and needs the driver installed before it can boot successfully. But as it’s trying to boot across the network, this causes the 0x0000007B error. Not many clients I have come across stream to physical desktops, so this probably won’t impact too many people, but I hope this info helps someone out!
I had a previously stable XenDesktop farm start having issues today, with the client saying they could not connect to any of the Windows 7 desktops in their farm. A quick investigation revealed most of the desktop VMs had been placed in maintenance mode by the Desktop Delivery Controller. It will do this automatically if the VMs do not register after several reboots, see CTX126704 for the registry entries that control this behaviour.
After much investigation looking at the PXE and TFTP services on the Provisioning Servers, checking DHCP scopes weren’t full, confirming switch ACLs and VLANs were correct and more, I found the setting on the DHCP server for Conflict Detection had been recently enabled. It was set to 2 attempts, but it seems this setting caused enough of a delay that the VMs would time out trying to PXE boot. Once the setting was reverted to zero everything was back to normal.
Note that this client’s XenDesktop setup was XenServer 6.0.2, and the XenDesktop VMs were in the same VLAN as the Provisioning Servers so the client VMs could just broadcast to receive the PXE settings. This is one of the preferred options for enabling TFTP high availablility as per Citrix Blog post by Nick Rintalan last year here (option 4 in his post).
I haven’t yet checked to see if this issue manifests itself in all environments, but now that I’ve seen it I recall having similar issues at another site where we couldn’t get PXE boot behaving reliably and we ended up handing out the TFTP server via DHCP options 66 & 67. Hopefully this helps if you are troubleshooting a similar issue, and I’d be keen to hear from anyone that has the same issue and whether my fix above worked for you.