Skip to main content

Converting Citrix PVS Image from XenServer to vSphere

Having repeated this nightmarish migration several times now, here's the steps I've found to be most efficient:
  1. Import your XenServer-optimized PVS image (as a VHD) in to XenCenter as a new VM.
  2. Snapshot and boot the VM (just in case you mess up the next step you won't need to import again).
  3. Uninstall the Citrix PVS and Citrix Guest Tools / Xen Tools bits. 
  4. Delete xen*.sys from c:\windows\system32 and c:\windows\system32\drivers
  5. Reboot and make sure everything still comes back up. It should revert to a generic Realtek network driver.
  6. Run VMware Converter on the VM. Alternatively you can export the VM from XenCenter as an OVA and then import it to vSphere.
  7. Be sure you are using a VMXNet3 NIC on the vSphere VM, not an E1000.
  8. Boot the resulting vSphere VM and install VMware tools.
  9. Delete the ghost NIC that is left from the Realtek drivers (https://support.citrix.com/article/CTX221733), otherwise you will get the BNIstack error.
  10. Install PVS target device software and run the imaging wizard again. 
  11. Follow all your normal steps for capturing a new image
If you run in to an IRQL_NOT_EQUAL_OR_LESS BSOD, you may be like me and have some piece of software set to redirect writes to the vDisk cache disk which no longer exists. Make sure you fix that prior to attempting a migration.

The most commonly recommended solutions for BNIstack errors during your first boot after capturing the image:
  1. Make sure no ghost NICs are still present
  2. Try uninstalling any antivirus and disabling IPv6
  3. Install the hotfix for KB 2550978 (https://support.microsoft.com/en-us/help/2550978/0x0000007b-stop-error-after-you-replace-an-identical-iscsi-network-ada)
  4. Consider changing the default open retry limits/interval for BNIstack (https://discussions.citrix.com/topic/377414-bsod-with-bnistack-and-cvhdmpsys/)

Happy migrations!


Comments

Popular posts from this blog

Outlook Credential Prompt When Opening Exchange 2013 Public Folder

After completing an Exchange 2007 > 2013 migration recently, I was left with one issue that was preventing us from stamping the project as a roaring success and moving on:

Outlook 2013 users were sometimes receiving a single pop-up prompt for credentials whenever they opened the Public Folder (we have only one). One. Single. Prompt.

Google was frustratingly unhelpful because searching for "outlook prompts for username and password when opening public folders" or something similar just resulted in a lot of folks who were always getting a pop-up that wouldn't go away. It was usually caused by an authentication failure of some sort.

However, we were in a different boat - Users got the prompt once when they first launchedOutlook and opened their public folders, but after entering it they could continue - authentication worked. Next time they logged in to their PC, it would happen again. Not a show stopper, but it definitely generated its share of support calls.

Repairing Mailbox Corruption in Exchange 2010

I recently got through recovering an SBS 2011 server after Active Directory face-planted in the middle of a workday. When I say recover, I mean I repeated the entire migration, using a cleaned up secondary DC - it was a fun weekend (expect another post about that experience). Although I thought we were in the clear, I got a call from the client about 24 hours after we had verified everything was working. He indicated that his iPhone had suddenly stopped receiving mail in the inbox (calendar, contacts, sent items were still fine) and throws up an error after spinning in circles for a few minutes that it "cannot connect to mail server".

SCEP Policy Update Troubleshooting

Because I'm a glutton for punishment, I recently started rolling out System Center Configuration Manager 2012 R2 SP1 and System Center Endpoint Protection across our VDI environment. There are always some considerations to be made in a pooled desktop / gold image type environment when loading software that uniquely identifies devices, but lucky for me SCCM/SCEP handled this just fine without any tweaking. However, there were some nuances to how SCEP policies are applied that caused some serious hair-pulling before I spotted the issues.