In a previous post, I discussed the benefits of restarting your virtual desktops on a consistent schedule. You can find that post HERE. When first looking to implement a reboot solution, we first did some basic Windows scripts. Some built into the task scheduler, and some run from a computer remotely using built in Windows commands. We found that these solutions were not working. We narrowed it down, if the virtual desktop was sitting at the desktop, or idle if you will, it would work fine. However, if people had disconnected from their virtual desktop (which many only do), Windows on the virtual desktop was considered ‘locked’. This was causing the scripts to not run on these machines.
Found a Citrix blog about using Windows Powershell that interacts with the Desktop Delivery Controller. Using this method allows control of the virtual desktops directly from the DDC, so it controls the connection state, rather than the operating system on the virtual desktop. Following that link will show you how else to automate your Xendesktop environment, with extra sample scripts and tips to handle other tasks.
Anyone who uses XenDesktop with Provisioning services, will know that keeping all your virtual desktops up to date can be a bit of a challenge. Unless users log off/restart, they may not get your latest vdisk image right away, and depending on the user, it may be months before they see the new vdisk image.
For us, this presented a few challenges in keeping our users up to date. We use pooled desktops with desktop restart on user log off.
- Users would not log off, and we would have some users end up being a couple vdisk versions behind. This was not a positive user experience, as we were getting calls into our helpdesk about issues that had already been resolved.
- Having multiple vdisk versions can consume a lot of disk space on the Provisioning Services side of things. This is also compounded if you have to have multiple versions of vdisks with different software configurations. So this was causing us to keep up to 6 unneeded vdisk images. Due to disk space procurement processes, disk space isn’t as readily available as it may be for others, so running low on disk space, limits the ability for us to move forward with new vdisks.
- Various levels of user experience. Users who generally logged off every day were getting a fresh desktop each day, and thus their sessions ran smoother, than those that did not log off.
- We wanted to keep our environment flexible for not only the users, but also for the IT department as well. This means that we wanted a way to be able to seamlessly be able to cut over services to new servers, or make changes with as minimal impact as possible.
With this in mind, we decided to go to automated forced restarts in the early morning hours of every Sunday. These restarts would be able to ensure the virtual desktops were checking for new vdisks once a week, freed up precious disk space on the infrastructure side, and also gave the IT department a small maintenance window, to be able to cut over services without noticeable impact to the end users.
With having this maintenance window, we’ve been able to perform the vast majority of the maintenance/upgrades, that would have traditionally caused us to schedule an outage. If you have enough redundancy built in, you can maybe get away with doing the upgrades/maintenance on the servers or services offline, during normal work hours, cutting down the need for going to the office on the weekend.
There are many benefits from having automated virtual desktop restarts, and depending on your environment, the amount of benefits you’ll get will vary. In a future blog, I’ll discuss how we handled restarting our virtual desktops. The answer may surprise you.
A little while back, I was troubleshooting an issue with content redirection on XenApp 6, where double clicking on a file was supposed to open a XenApp 6 hosted application with the document opened within it. The application would launch, but the document would not open. Upon further troubleshooting, I noticed that it was only happening when there was a drive letter was in the path, of the document that was trying to be opened. If opening a file from a UNC path, the content redirection would work. I had two XenApp 6 servers in identical configuration for load balancing & redundancy, both had the same applications.
For the longest time, I figured that there was something wrong with my Citrix policies for content redirection. As time went on, and my patience wore thin, I stumbled upon a forum post in the Citrix Support Forums, that eluded to a small application called Adobe Drive that was playing havoc with other’s XenApp farm. Adobe Drive is a “plugin” that comes with a few of the Adobe products, such as
- Adobe Photoshop CS4 Extended
- Adobe Premiere Pro CS4
- Adobe Director 11.5
- and a few more…
Adobe Drive allows users to connect to Adobe Version Cue CS4 servers, the server-based file management system. With Adobe Drive, the connected servers will appear just like a mounted hard drive or mapped network drive, providing users with a few different ways of interacting with their Version Cue files.
I knew that I had Adobe Photoshop CS4 Extended installed, and presented as a hosted application, so I decided to investigate, and sure enough, Adobe Drive had been installed. Adobe Drive is a mandatory plugin that gets installed with Adobe Photoshop CS4, so installing without it, was not an option.
Upon reading further in the Citrix support forum, many people tried a few tricks such as removing Adobe Photoshop CS4 Extended, trying a variety of registry tweaks. Ultimately, the general consensus was that rebuilding the XenApp Servers was the solution. Even Citrix had came to that same conclusion. I knew it was somthing unique on those two servers, as I had built a third XenApp server for another set of apps, and that server did not have this issue.
I proceeded to make a copy of one of the problem servers (yay for virtual machines), and rebuilt the two XenApp 6 servers that were running Photoshop CS4 Extended on them, and after getting everything back up and running, the problem was fixed. We still had our XenApp 5 farm around, so we installed it on a Windows 2008 server, and it has been running fine since. I would also say that we encountered this problem, roughly 1 year prior to this post. So there may be some official solutions available for this now.
If you’re currently running Provisioning Services 5.6 and want to move to Service Pack 1, then there is a number of steps to make this upgrade happen. With most service packs, a simple installer will upgrade the software on your server, and life is good. However, with Provisioning Services, there are 3 components of PVS that need to be upgraded to make everything work together.
- Provisioning Services database
- Provisioning Server(s)
The PVS database is done when the first server of the farm is upgraded, and then the following servers are done. The trickiest part will be upgrading the target device software on the vdisks. Typically, you’ll have a number of devices running on provisioning services in standard mode, but in order to install the new version of PVS Target device, it would essentially break the streaming to that device. So just as if you were to upgrade to the next complete version of PVS, you may need to re-create the vdisks. This may be done by “copying” the vdisk to the end point device, then installing the PVS 5.6 SP1 target device software, then create the image again.
So, simply installing this service pack, would definitely require some planning, and most likely a schedule maintenance window. One thing to determine, is if the upgrade to Service Pack 1 is really necessary, or not.