I recently had the opportunity to deploy Provisioning Services 6.1 to upgrade an existing client from 5.6. As there was no possibility of downtime, we decided to go with a parallel update; taking a copy of the existing vDisk and reverse-imaging it as per the Citrix documentation, and then installing the Target Device software and using XenConvert to create a new vDisk.
Everything went perfectly until it actually came time to boot the target device from the vDisk. The dreaded BSOD! The 7B BSOD; which means a bnistack error. Well, there are scads and scads of Citrix articles on how to fix that, right?! So I tried them all; hidden network devices, BNNS timeouts, BDM settings, even switching from a VMXNET3 adapter to E1000 – none of it worked. Tried with every possible version of the Target Device software; both with and without the Device Identity Manager as well. Sigh…..
I engaged Citrix support and spent about 7 hours working with 3 different engineers; all to no avail. Nothing in the PVS logs, nothing in the system logs. But what we DID keep seeing was that the PVS Target Device software would work immediately upon install and then NOT work after a reboot. Hmmmm. We also saw a bnistack error in the event logs when booting from Hard Disk which stated that the service couldn’t start.
Searching through the internal and external KB articles on this turned up all of the same stuff I had already tried, along with one slightly different piece of information; CTX126523 . This article referenced a BSOD error with Windows 7 target devices on MS HyperV booting from a BDM. I’ll spare you all of the gory details, but essentially an MS Virtual adapter is created by HyperV and was loading ahead of the bnistack driver; this was causing the failure.
After much searching through various network and protocol bind settings, we were able to determine that the “Microsoft Network Monitor 3” NDIS driver was loading ahead of the bnistack driver, and preventing it from starting. The fix was to set the start parameter for the NM3 driver to “0”, and voila! A functional connection to the vDisk. Once we ran the XenConvert again, the vDisk fired up properly and all is again right with the world.