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,

CG1

Receiver 4.2 desktop shortcuts

Yeah yeah, long time no blog.  I know.  Life gets in the way.  Work gets in the way.  I have a list of things I need to blog about, and I’ll get to a few of them here shortly.  For now, though, this one really needs to get out there, so I’m shortcutting said list, and getting it out there for you.  You’re welcome.  🙂

There seems to be very little information out there on this topic.  I Googled for hours.  I read the Citrix eDocs.  I read everything I could find.  Sure, lots of other people have blogged about it, but all they did was parrot Citrix’s announcement of the fact that the feature is back.  I highly doubt that even one of them has tried to implement the feature.  Or at least, if they did, they found out how big of a pain in the ass it is, and how the behavior of it is so strange that maybe they are best served by not telling the public about it.

As an anonymous blogger, I don’t have those same worries – making Citrix mad at me.

So, here I am to give you the “straight dope”, as it were.

 

First – the ADM template that is referenced to be used – I tried it.  I verified that it was applying properly by using GPRESULT /H.  It was working fine to apply the SSO settings.  GPRESULT showed all the shortcut settings I had configured.  Except there were no shortcuts.  It wasn’t doing what it was supposed to do.  The registry entries below were not configured.  NO idea what the deal is with that, but in the environment I was working in, it didn’t get the job done.  Now, maybe there was an environmental issue causing it?  I don’t know.  What I DO know is that I had to find a way to make it work, and so I’ll share that here with you just in case the ADM template doesn’t work for you, either.

HKLM\Software\Wow6432Node\Citrix\Dazzle

PutShortcutsInStartMenu  REG_SZ  true
PutShortcutsOnDesktop    REG_SZ  true
StartMenuDir  REG_SZ  <whatever the directory you want apps to go into in the start menu – leave blank to put them directly in start>
DesktopDir  REG_SZ  <whatever the directory you want apps to go into on the desktop – leave blank to put them directly on the desktop>

 

SO – What’s this weird behavior?  Well, for starters, it actually has to do with Storefront, not Receiver.  But since Storefront and Receiver function more or less as a pair, and the issue is manifest in Receiver, I’m still blaming that.  Mostly because I’m stubborn, as the issue DOES lie with Storefront.  For the record, this environment was using SF2.6.

The problem is that when Storefront remembers the application subscriptions, apparently a flag is set BY RECEIVER that tells Storefront whether or not it should create the desktop shortcuts.  Thus, if you have Receiver 4.0 or 4.1, and have a bunch of applications subscribed, THEN you upgrade to 4.2 – NOTHING HAPPENS.  No desktop shortcuts, no start menu folder like you specified – NOTHING.  How to fix this?  The official answer from Citrix (that doesn’t seem to be documented ANYWHERE that I can find) is “unsubscribe and resubscribe to all your applications”.  Well isn’t that just peachy.

Ok, fine.  So you’ve done that.

But then – you log into another workstation, and that one isn’t configured for desktop shortcuts.  Then you log back into one that is, and lo and behold – NO SHORTCUTS!

This is just ridiculous.  Why is the data about whether or not to publish an application shortcut stored in Storefront to begin with?  What are the implications for people who use XenDesktop, and access that environment using the HTML5 client?  What then?  I didn’t test this, but I’d imagine it will create a problem as well since naturally the HTML5 client relies on Storefront subscriptions, and is incapable of publishing a shortcut to the desktop on the client machine the browser is being run on.

IMO, the way this SHOULD work is Storefront just keeps track of the subscribed apps, and the Receiver handles creating and publishing shortcuts for any subscribed app.  That way moving amongst machines with different Receiver versions and/or configurations won’t create a problem.  I mean really, Citrix.  You bill yourself as a mobility company, and yet when the rubber meets the road, now you’re saying that “Sure, you can be mobile – as long as all your access devices have the exact same version of Receiver configured the exact same way.”

 

Doesn’t sound very mobile to me.

 

Good luck,

CG1

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,
CG1

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

Upgrading,

CG1

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.

 

Redirecting,
CG1

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)
oFS.CreateTextFile(sLogPath)
If oFS.DriveExists(sCacheDrive) Then
If oFS.FolderExists(sFolder) Then
If oFS.FileExists(sFolder & "\" & sFile) Then
Read_GUID
LogFile (sFile & " file found. Exiting script.")
Wscript.Quit
Else
Set oFile = oFS.CreateTextFile(sFolder & "\" & sFile)
LogFile (sFile & " file not found. Running Check_Trend procedure.")
Check_Trend
LogFile ("Check_Trend procedure complete - exiting script.")
Wscript.Quit
End if
Else
LogFile (sFolder & " not found. Creating folder and file.")
oFS.CreateFolder(sFolder)
oFS.CreateTextFile(sFolder & "\" & sFile)
LogFile ("Running Check_Trend Procedure after creating folder and file.")
Check_Trend
Wscript.Quit
End If
Else
LogFile(sCacheDrive &" drive could not be found. Quitting the script.")
Wscript.Quit
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)
oFile.Close
LogFile("Writing " & sRegGUID & " to the " & sFolder & "\Trend.txt file.")
Set oFile = oFS.OpenTextFile(sFolder & "\" & sFile, 2)
oFile.WriteLine sRegGUID
oFile.Close
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"
Loop
oFile.Close
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.  😉

Virus-free,
CG1

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
GO

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:

Failover_Partner=MYSECONDSQLSERVER

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.

 

Redundantly,
-CG1