PVS 7.6 Cache Disks on 2012R2

So…  Stood up some 2012R2 XA7.6 servers the other day, using PVS7.6 and cache in RAM with overflow to disk.

Then I saw that I had files in the WriteCache directory on the PVS server.  WTF?

After some screwing around, I found the solution.

Apparently PVS can’t use a disk that is GPT, you must use MBR.  Once I switched that and reformatted the disks, viola!  Everything worked exactly as it should.

Happy provisioning,


PVS 7.6 issues with v10 VMs on vSphere 5.5

You know, there are only so many delays I’m willing to deal with in a day.

First, there’s the bug earlier that bit me during install.  Can’t have a space in the name of the OU.

Now, I find another one that gave me the redass.  HARD.

So you’ve got vSphere 5.5.  Excellent.  Citrix says it’s supported.  Everything looks fine.  The customer wants v10 VMs, which is a pain (mostly because VMware’s web interface is a kludgy, bug-ridden POS), but whatever.  NOTE:  Yes, I’m a VCP, too, so don’t think I’m just “hatin on the competition”.  It does need work!

So you build your base image, optimize it, and install the PVS Target device driver.

Reboot, and it hangs loading windows.  I actually removed the bootux disabled entry using bcdedit just so I could see what was going on.

What’s the problem?

With v10 VMs, VMware attaches the virtual CDROM using SATA, not IDE.  Apparently the PVS target device driver can’t deal with that, so the VM never finishes loading.  NOTE:  It ONLY does this when there’s a vDisk attached – if you remove the vDisk from the target device, Windows will boot every time, so it’s not like the driver just outright breaks something.  Even more infuriating.

The solution?  Switch the CDROM to IDE.  Then, don’t forget to remove the SATA adapter from the VM.  Then after you’ve done that, make sure you go into device mangler and remove all the dead stuff – the SATA adapter itself, as well as any ATA channels that are no longer present.  You should still see two ATA channels present after the removal.  Basically, you want to remove all the grayed out items.  How?

Open an administrative command prompt, and enter “set devmgr_show_nonpresent_devices=1”.

Then, “start devmgmt.msc”

Then click view, and then show hidden devices.  Then expand IDE/ATA adapters, and remove all that stuff.


Again, remove only the grayed out items.

While you’re in there, check the Network Adapters, and remove all the grayed out NICs, too (but you already did that, right)?  *IF* you found any grayed out NICs and removed them, you should uninstall and reinstall the target device driver to ensure it binds to the correct NIC.

Then go ahead and re-run the imaging wizard, and you should FINALLY be able to pull an image of your VM.

Me?  I’m pretty disappointed in Citrix.  vSphere 5.5 has been out for a while now, and PVS 7.6 was only just released a couple months ago.  One would think they could have accounted for this, or at least made prominent note of it somewhere telling people about the problem.

But alas, here I am having to blog and complain about it.  Maybe next time..


PVS 7.6 bug

So, I’m doing my first production build of PVS 7.6 servers for a customer.  This particular customer had an OU already defined for all of their security groups. Ok, no problem, I’ll put the security groups in there for farm administrators and such.

Yeah, no.

The OU had a space in it.  The installation took just fine, but then it would not let me into the farm.  I got the old “This domain/user does not have access to the farm”.  Gee, thanks.  So, I go check the dbo.AuthGroup table.  It had a single entry, and it was correct:  “Domain.com/security groups/group”.

I moved the group to an OU without a space in the name, deleted the database, and re-ran the config wizard to create a new farm, and whuddya know?  It all started working again.

Even though Citrix wasted an hour of my time with this, hopefully you won’t waste yours.



Apparently PVS has some issues with DST.  Time doesn’t get updated correctly on targets, duh.  How does this manifest?  Event logs out of order, GPOs not getting applied, etc etc.


How do we address this?  Well, in PVS-land, one of the most important GPOs you have is the one that says “Do not change machine account password”.  If that one doesn’t work, no one can log into any of the targets because domain trust is messed up, right?  Well…   Imagine if for some reason your GPOs failed to apply!  What then??


Full info here:  http://support.citrix.com/article/ctx123336


  • Change the image mode to private image and check that the Local Security Policy Domain member: Disable machine account password changes is enabled within the vDisk image. — this is important so that the machine account password policy remains in effect even if GPOs aren’t correctly applied.
  • Resynchronize the computer before you restart.

Then to fix the time problem:

  • Click Start Run. Enter cmd to open the command window.
  • Run the following commands:
w32tm /config /update
w32tm /resync
Then restart, log in, and I recommend a gpupdate /force.  Then, shut down, flip back to standard, deal with KMS as necessary (see previous post), and you should be good.

Provisioning Server firewall ports

So you want to leave Windows Firewall enabled on your PVS server, do you?  Meh.  Ok.  Fine, here’s the list.

UDP 67  (PXE)
UDP 4011 (PXE)
UDP 6890 – 6930 (Stream)
TCP 54321-54322 (Console)

So..  If you do not open UDP 67, even if your DHCP server is NOT running on your PVS server, your VMs won’t display an IP when they try to PXE boot.  Go ahead, ask me how I know..

If 67 is open but 4011 is not, the VM will throw an error telling you so during the PXE boot process.



So, you screwed up your KMS licensing on your provisioned VMs?

So you booted your KMS-licensed VM and got a message about how your VM is a rogue copy of windows, or pirated, or some such, and you’re freaking out, aren’t you?  You issue slmgr /dlv and it says there is no installed product key, right?

First off, let me congratulate on you your rite of passage.  Secondly (in case the previous sentence didn’t clue you in to the fact), let me assure you that you aren’t the first one to do this.  Now, you’ve landed on this article because you typed something into Google looking for an article on how to fix it, didn’t you?  Fine, I won’t keep you hanging any longer.  Do this:

Power off all VMs using the affected vDisk image.
Switch the vDisk to Private Mode.
Click OK.
Open the properties on the vDisk again.
Change the licensing mode to “None”.
Power on your VM.
slmgr /ipk <kms product key>
slmgr /skms <fqdn to your KMS server – OPTIONAL – use if you need to specify a KMS server>
slmgr /ato
slmgr /upk
slmgr /ipk <kms product key>
slmgr /rearm

If you have Office installed, don’t forget to do ospprearm.exe, and if it’s a XenApp box, make sure to prepare for imaging and provisioning.  Then, shut the VM down.

Switch the vDisk back to Standard Mode and set your cache location.
Click OK.
Open the properties on the vDisk again.
Switch the licensing mode to KMS.
Bookmark this page for when you do it again <optional, but faster than Googling again>.


Upgrading Provisioning Server

So you have a working PVS deployment, but it’s not the newest version.  How do you go about upgrading this?  It seems a daunting task.  I mean, if you blow it up, none of your provisioned XenApp or XenDesktop VMs will function anymore, right?  And that would be bad, right?  So what’s a guy to do??  It’s easy, really.  No, seriously, it is.

First thing, we are going to assume that you built to best practices, and you have MORE THAN ONE provisioning server.  Make sure all your targets are using only one of the two servers.  Then, uninstall PVS from the one that’s not being used.  Then install the new version.  Tell it to join an existing deployment, answer the couple of simple questions, and it’s good again.  All the images should still be on the box, so you’re good there also, AND, it’ll even remember the bootstrap info (you are using the PXE service instead of DHCP 66 & 67, right?  If not, SHAME ON YOU!).  Then, fail all the targets over to that one, and then repeat the process on the remaining server(s).

Now, some of you are sitting there saying “Yeah, I’ve done that.  I have v6.1 PVS servers, but all my target devices are still running the v5.6 target software.”  Common.  So how to address that issue?  Again, easy.  Pretty time consuming, but easy.

We are going to assume the worst-case scenario, which is that you do NOT have a *current* VM with all the applications and software installed that you can just uninstall v5.6 and install v6.1 and take a new image.  For whatever reason, either that source VM has been deleted, or it’s so far away from current that it’s not worth the trouble to make all the changes to get it to be like the current image.  What to do?

  • Make a COPY of the vDisk for the image you want to upgrade. 
  • Mount the image in PVS. 
  • Use the wizard in PVS to deploy a new target device. 
  • Assign it the vDisk that you just made a copy of. 
  • Set the vDisk to PRIVATE mode.
  • Boot the VM. 
  • AFTER the VM is booted, hot-add a virtual disk to that VM that is at least as large as your image size.  So, your VM thinks the image is 40GB (it might be only 20GB on disk, but you did take a dynamic image, right?), so you have to add a 40GB virtual disk. 
  • Launch disk mangler, create a partition, format it and assign it a drive letter.  MARK IT AS ACTIVE!! (PRO TIP to follow about how to handle if you forgot to do this)
  • Browse your way to C:\Program Files\Citrix\Provisioning Services and run BNimage.exe.  You get a single window that pops up, and it asks you for the path you want to push the image into. 
  • Point it at your new, empty drive, and let it run.  It’ll reboot a few times during the process.  You must log back into the VM each time in order for the process to continue.  Do NOT make any changes to the PVS target until it tells you it’s finished!! 
  • After it’s finished (and you see a message telling you so), go into PVS and change the target to Boot From Hard Disk, and remove the vDisk image from it (so now there are no vDisks assigned to the target). 
  • Power the VM down, go into the VM settings and remove your local cache disk (you are caching to local disk, right?  If not, you’d better be caching in RAM!  If you’re using “Cache to server”, go read some other blog, even I can’t help you.) 
  • After you’ve removed the local cache disk, power the VM back on.  You’ll get a message from the PXE service that there is no disk asigned.  Press any key, and it should boot from the local disk now.  Oh, you get a message about no operating system?  One of two things has happened (both of which you were supposed to do if you were following my instructions!):  Either you didn’t mark the partition as active, or you didn’t remove the cache disk.  Here’s the PRO TIP I promised:  Add the local cache disk back to the VM (if you deleted it already, which you should have – just copy one from another VM that’s not powered on and then “add an existing vDisk”), then add the original private mode vDisk back to the target in PVS.  Set it to boot from the vDisk.  After it comes up, go mark the partition as active, then power it down and remove everything as I outlined above.
  • The VM now boots like a regular VM – it loads the image from the local vDisk in the VM.  Uninstall the old PVS target software, reboot, install the new software, reboot.  PRO TIP:  Do your hypervisor tools need to be upgraded?  Now is the time to do it…
  • After you have the source VM exactly the way you want it again, just run XenConvert, create a new DYNAMIC vDisk, and push the image back up to PVS.

Time consuming?  You bet.  Rock solid?  Absolutely.  NO problems with this method.