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,


Client Drive Mapping irritations

So I have a customer using XD5.6 with Win7 VMs, and XA6.5.  Everything was patched current on both the Microsoft and Citrix side.  The Receiver client in the VDAs was Receiver 3.4 Enterprise, the physical client-side receiver version didn’t matter, everything was tried (even Macs!).

The issue?  The customer needed to be able to map in USB thumb drives from the physical client.  Then, within the XD session, there were network drives mapped in (home drive, etc).  The customer needed to pass in BOTH the physical USB thumb drive as well as the mapped network drives so that content redirection would work properly and seamlessly from all sources within the XD VM.

Citrix doesn’t seem to support this.  I read CTX after CTX, and forum post after forum post.  I could only find one other person trying to do this, and their question was asked in an active thread with several Citrix employees commenting on it, and as soon as they asked how to map in BOTH, there was nothing but crickets.  Since June.

Well shitty!  What now?  The lack of information out there on the topic certainly doesn’t help my customer, and I’ll be damned if I’m going to give them some half-assed answer.  That’s just not my style.  After hours of messing with the registry, and confirming that the registry key referenced in CTX127872 was an either/or proposition (meaning one way you get the drives from the physical client passed into the XA session, the other way you get the drives from the XD VM passed into the XA session), I realized something had to give.  More investigation eventually brought me to the revelation that “one way, it maps everything WITH a drive letter, and the other way, it maps everything WITHOUT a drive letter”.

Ok, super.  So how to get the physical drives assigned a letter?  AH!  Legacy drive mapping!  It says it’s a XenApp solution, but I figured what the hell, why not give it a shot on XD anyway?  Yeah, no love.  For once, the CTX was actually correct in the scope of products it pertained to.  Go figure.

So I manually mapped one of the devices with net use at the command-line.  Then I opened that mapped drive and double-clicked a Word doc.  Success!  It opened in Word!  Now…  How to get all the drives to automatically map every time a user logs in?

Disclaimer:  I’m NORMALLY a VBScript guy.  Like, HARDCORE.  But, I didn’t have the time to properly write and debug some code, and this worked.  Yeah, yeah, go ahead and give me crap about not being a PowerShell guy.   Call me old, I just haven’t yet FULLY gotten on that bandwagon.  Feel free to re-write this in PS and post it in the comments.  🙂

In any event, what I wrote was this:

@echo off
if exist \\client\c$ net use * \\client\c$
if exist \\client\d$ net use * \\client\d$
if exist \\client\e$ net use * \\client\e$
if exist \\client\f$ net use * \\client\f$
if exist \\client\g$ net use * \\client\g$
if exist \\client\h$ net use * \\client\h$

I deployed it using a login script via GPO.  Again, no love.  The login script processed before CDM had a chance to finish bringing in the drives, so only the fixed disk mapped, not the USB removable drive.  The solution?  Put it in the startup folder in the default profile.

Viola!  Client drives are now mapped from both the end point AND the VDI VM.  Sure, it might be a touch ugly, but if you can get your users to match up something as simple as E: and E$, they should be able to figure it out.

Happy mapping,

XenDesktop 5.6 HRP05

So..  You are building a new environment and want to get it all patched up prior to even getting any real work done.  Always a good idea, right?

WRONG!  Not so with XenDesktop, apparently.

Citrix, in their infinite wisdom, coded this such that you cannot upgrade the database unless you already have a desktop group created.  They even wrote a CTX about how the upgrade button doesn’t appear (granted it was written for HRP04 – but still, this issue continues to exist?!?!), and their “solution” is to stop the Configuration service and launch Studio and then re-add the controller, but tell it not to upgrade the database for you.  Then use the upgrade script it generates and run that against the database manually.  Ok, great – except that when you stop the configuration service, Studio won’t launch, so…   WTF are we supposed to do now?

I started by uninstalling all 7 of the upgrades from HRP05, and then reinstalling the same components from the install media I used to build the DDCs.  Then, create your desktop groups and user assignments – very important!  Then, on the other DDC (the one that’s already been upgraded) you’ll see an “upgrade” button on the dashboard to upgrade the database.  Click it, then reinstall the HRP05 stuff on the one you downgraded.

What a PITA.  Jeez.  Thanks, Citrix!!



Removable Drive passthru with XD and XA

So Citrix allows you to passthru local devices into XD and XA sessions.  Floppy drives (really?!), optical drives, fixed disks, and removable storage, what fun!  With the Presentation Server 10.x client on the physical device, and Receiver 3.4 Enterprise in the Win7 XD VM, the removable devices passthru as floppy drives.  So, plug in your $300 Kingston HyperX USB-3 drive, and Citrix thinks it’s a floppy.  Brilliant!  But, it works.  Now, you upgrade the client on your physical Win7 machine to Receiver 3.4, and connect to your virtual Win7 desktop that has Receiver 3.4 Enterprise on it.  The USB passthru into XD works, and content redirection tries real hard, but you get an error after the app launches saying it can’t find the file.  You do file -> open, and sure enough, none of the drives from the physical machine have been passed into the XA session.  I previously blogged about this, but this issue is different.  In that scenario, the client devices were a major-name-brand thin client, and that registry key seemed to address the issues.  Apparently I spoke too soon, for that solution does not work in all scenarios.

The solution in this case?  Receiver 4.  Upgraded the Receiver on the physical Win7 client, and bam!  Everything passed through exactly as you would expect it should.

Maddening?  iMacs running v11.7 and v11.8 of the receiver client didn’t have this issue, they just worked.  Really, Citrix?  Your software runs on Windows.  The servers, the virtual desktops, all of it.  Yet the clients you publish only work flawlessly out of the box on Macs?  For shame.



Trend OfficeScan AV in Provisioned VMs?

So, some mandate from above has come down and you absolutely MUST have AV in your provisioned VMs (whether they be XenApp or XenDesktop).  Forget that Citrix does everything they can to steer you away from this, and the VMs are read only, and….  Well, you get the idea.  Either way, the powers that be said that there must be AV, and they are willing to pay for Atlantis or SSD storage or whatever it takes to make sure you’ve got enough IOPS to feed it.

So you say to yourself “Ok, it’s not my money anyway.  As long as the performance is there and the end users get a solution that is acceptable to them, it makes no difference to me.”  And then, the hard part:  How do you make it work??  Trend registers each client machine against the OSCE server using the GUID of the installed Trend OSCE client, NOT the machine’s SID.  But, since all the machines are basically carbon copies of that one base image, what’s a guy to do?  So, you went home, you pulled out your hair, you drank some beers to get over the headache this all caused you, and now, you’ve wound up here.  Fear not, brave Citrix admin:  I’ll show you the way.

Now, anyone with some decent Googlefoo can certainly run across another blog from some guy with a surname I can’t pronounce and with a TLD of .eu.  That’s where some of this came from.  However, I found the information there to be less than completely helpful, and, moreover, it didn’t solve the issue completely (not to mention the code needed help – option explicit, unused declared variables, scoping issues, etc).  What to do?  Improve, of course.

Step 1.  Copy this code into a vbs script of your choosing (this is for x64 VMs – if you want it for x86 VMs just edit the registry read/write lines to take out wow6432node)

On Error Resume Next
Set oShell = WScript.CreateObject("WScript.Shell")
Set oFS = CreateObject("Scripting.FileSystemObject")
sCacheDrive = "d:\"
sFolder = sCacheDrive & "\Trend"
sFile = "Trend.txt"
sLogPath = sFolder & "\Trend_log.txt"
If oFS.FileExists(sLogPath) Then oFS.DeleteFile(sLogPath)
If oFS.DriveExists(sCacheDrive) Then
If oFS.FolderExists(sFolder) Then
If oFS.FileExists(sFolder & "\" & sFile) Then
LogFile (sFile & " file found. Exiting script.")
Set oFile = oFS.CreateTextFile(sFolder & "\" & sFile)
LogFile (sFile & " file not found. Running Check_Trend procedure.")
LogFile ("Check_Trend procedure complete - exiting script.")
End if
LogFile (sFolder & " not found. Creating folder and file.")
oFS.CreateTextFile(sFolder & "\" & sFile)
LogFile ("Running Check_Trend Procedure after creating folder and file.")
End If
LogFile(sCacheDrive &" drive could not be found. Quitting the script.")
End if

Sub Check_trend
sFile2 = "ImgSetup.exe"
sSource = "C:\Trend\Trend\"
sDestination = "C:\Trend\"
LogFile ("Adding Run command for imgsetup.exe.")
oShell.RegWrite "HKLM\SOFTWARE\Wow6432node\Microsoft\Windows\CurrentVersion\Run\Trend OfficeScan ImageSetup", chr(34) & sDestination & sFile2 & chr(34) & " -HideWindow", "REG_SZ"
If Not oFS.FileExists(sDestination & sFile2) Then
LogFile (sDestination & sFile2 & " not found.")
LogFile ("Copying " & sFile2 & " from " & sSource)
oFS.CopyFile sSource & sFile2, sDestination
End If
LogFile ("Running Trend Sysprep.")
oShell.Run chr(34) & sDestination & sFile2 & chr(34), 0 , True
sRegGUID = oShell.RegRead ("HKLM\SOFTWARE\Wow6432node\TrendMicro\PC-cillinNTCorp\CurrentVersion\GUID")
LogFile ("GUID =" & sRegGUID)
LogFile("Writing " & sRegGUID & " to the " & sFolder & "\Trend.txt file.")
Set oFile = oFS.OpenTextFile(sFolder & "\" & sFile, 2)
oFile.WriteLine sRegGUID
LogFile ("Starting the Trend Realtime scan service.")
oShell.Run "net start ntrtscan", 0, TRUE
LogFile ("Script Finished.")
End Sub

Sub Read_GUID
Set oFile = oFS.OpenTextFile(sFolder & "\" & sFile, 1)
LogFile ("Running Read_GUID procedure.")
Do While oFile.AtEndOfStream = False
sLine = oFile.Readline
LogFile ("Writing GUID " & sLine & " to the registry.")
oShell.RegWrite "HKLM\SOFTWARE\Wow6432node\TrendMicro\PC-cillinNTCorp\CurrentVersion\GUID", sLine, "REG_SZ"
LogFile ("Starting tmlisten.")
LogFile ("Starting ntrtscan.")
oShell.Run "net start tmlisten", 0, TRUE
oShell.Run "net start ntrtscan", 0, TRUE
LogFile ("Script Finished.")
End Sub

Sub LogFile(Message)
Set lFile = oFS.OpenTextFile(sLogPath, 8, True)
lFile.WriteLine Now & " - " & Message
End Sub

Modify line 4 in the VBS above to reflect your cache drive letter.  Sorry the formatting got wrecked, blame it on the WP editor.  PLEASE TEST this before just stuffing it into production!  I am not responsible for your copy/paste/fail maneuvers if you don’t at least have a basic handle on VBS and can’t identify a code fragment that belongs on the previous line (nor am I responsible for any other reason, use at your own peril, etc etc — but I digress)…

Step 2.  Copy this code into a cmd file and name it whatever you choose.

REG Delete "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\Trend OfficeScan ImageSetup" /f
REG Delete "HKLM\SOFTWARE\Wow6432Node\TrendMicro\PC-cillinNTCorp\CurrentVersion\GUID" /f
del c:\Trend\imgsetup.exe
del c:\Trend\TmEngDrv.dll
del c:\Trend\TmPfwApi.dll
del c:\Trend\TmProxy.dll

Step 3.  Go into your VM in private mode.  Create the folder C:\Trend, and then create the folder C:\Trend\Trend.  Then, from your OCSE server, copy the file imgsetup.exe into the C:\Trend\Trend folder.

Step 4.  Install the Trend OfficeScan client (This solution tested with 10.5, BTW).  After it’s installed, unload it.  Then set all three of the OSCE services to MANUAL startup.

The VBS script above?  Add it to either the local policy of the image or to a GPO as a startup script.  The CMD above?  Yup, you guessed it, shutdown script.

Then, seal up your VM and shut it down.  Viola!  No more phantom registrations and offline VMs and all sorts of other weirdness in your OCSE reporting console.  Also, I would highly recommend that you create an auto-add domain (by IP, because your provisioned VMs are in a dedicated network, RIGHT?), and apply the correct AV exceptions to that domain.  Don’t know how to do that?  Google got you here, it’ll get you there.  😉


SQL mirroring for Citrix

So, you’re building a XenDesktop environment and you want to mirror the database for it.  while you’re at it, why not mirror PVS and XenApp, too?  They both support it.  But how do you do it?  You’re a Citrix admin, not a database admin!

Start by installing SQL Standard (or Enterprise) on two different servers.  Do NOT put the databases on the system drive!  Otherwise, just a vanilla install is fine (make sure to install SQL management studio).

For XD – create an empty database on the first SQL Server and call it whatever you want (XenDesktop is nice, but whatever).  The collation needs to be LATIN1_GENERAL_CI_AS_KS , and the recovery model needs to be set to full.  Also, make sure you have configured the proper permissions for your XenDesktop service account to access the database.  Then – create a new query and enter the following:

BACKUP DATABASE [XenDesktop] TO  DISK = N'C:\temp\XenDesktop.bak' WITH NOFORMAT, NOINIT,  NAME = N'XenDesktop-Full Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10

Then right click in the query window and select execute.  Copy the file XenDesktop.bak to the second SQL server.  Right click Databases and select Restore Database.  Enter XenDesktop as the database name, then select From Device, and browse to the file.  Then, check the box in the display next to the file name.  Then click Options in the left pane, and then make sure to select “without recovery”.

Now, go back to the first SQL Server and right click the database and then in the left pane, click Mirroring.  Click Configure Security.  Make sure the box for Witness Server is unchecked (if you want a witness, you can read more about it on MSDN, but this is a Citrix blog, not a SQL blog, so we’re keeping it simple).  Then enter the information for both the SQL servers.  Then for the account, use your SQL service account for each server (your SQL Servers do use a service account, right?  If not, go change it now – because if you want to use local system or network service, you need to use certificates, and I HATE certificates!).  Since the SQL servers in my deployments are generally dedicated to Citrix databases, I like to use the same service account for both servers.  If you use a different one for each server, just make sure you enter the correct one for each server.  After the wizard completes, click start mirroring.  That’s it.

Repeat the process for XenApp and PVS, changing the database names and .bak file names appropriately.  PVS and XenApp don’t much care about the database collation type like XenDesktop does.  For XenApp, though, you need to download the Native SQL client for the version of SQL Server you are using (2008 R2 is still the easiest with all the additional restrictions imposed by 2012).  After it’s downloaded, stop the IMA service, install the new client, and then open MF20.dsn and modify it thusly:

The Driver line should read

DRIVER={SQL Server Native Client 10.0}

Then, under the line beginning SERVER=, add the following line:


Obviously, put the name of your SQL Server in there.

Then just start the IMA service back up.

Nothing special should need to be done with PVS, provided the databases are correct.



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>.