To thin client, or not to thin client?
If you’re looking to get into the virtual desktop scene, and wondering how to manage endpoint devices, you may look at thin clients. And why not? Thin clients have a small footprint, and relatively cheap, and generally have less moving parts. However, like anything, they do have their cons as well as their pros.
In our environment, we started out with thin clients/virtual desktops as replacements for desktop PCs, and for the most part it works relatively well. However, when we introduce multimedia into the picture, that is where we came across some challenges. This case is especially true if you do any kind of multimedia offloading, or flash redirection. We found that playing natively without the virtual desktop involved, the thin clients would stutter, and freeze during playback. Not only just on multimedia, but Adobe Flash heavy websites were taking a toll as well. This was leading to a poor user experience for those on thin clients. When we use the same virtual desktops paired with a PC (or an endpoint with more power in CPU and video card), we found the results to be quite different. We were able to get HD content working as Citrix has advertised.
So if you end up using a desktop PC as a pseudo thin client, you can still leverage the benefits of virtualization, you can keep the end points clean with just the basic plugins for connecting to a virtual desktop, and if you have standardized hardware, and a PC fails, you can just do a PC swap, and the users won’t have much downtime.
The biggest lesson we learned from this, is that there may not be a single definitive answer for an endpoint in any environment. Depending on your users, and your environment, you may have a need have a couple different types of endpoints that you support, or maybe even introduce a Bring Your Own Computer concept. If your users are looking for desktop replacements, where maybe some video is needed every now and then, or they will have a wide range of uses, it may be better to have something a little bit on the higher end of things, rather than capping the performance with a device that just isn’t up to the task. If you have users in a data entry position, something like a shipping & receiving, a thin client would probably be an ideal candidate, because the computer would be just used for data entry.
Moral of the story: Know your users, know your environment, know how your users use their desktops.
Virtual machines do not boot
Came across an interesting problem the other day, where 5 virtual servers running on XenServer were turned off. Upon trying to power them up, they failed to start, didn’t even pass POST. Looking at the XenServer logs, the error “the operation cannot be performed because the specified VDI could not be found on the storage substrate”. Immediately, I thought our SAN was having problems, but on closer inspection, I realized that they were fine.
Entering that error into Google. showed that others had seen this problem before, and they had found that it had to do with connected CIFS share(s) in their desktop pool. We had our ISO library on another file server connected via CIFS share. The first thing to try, is to see if you can detach & forget the share from within XenCenter, but most had said that it did not work, or was not an option. The same was for me, the option was not there to gracefully remove it. Lastly, it was suggested that restarting the physical host solved the problem for most. Given that it was a Sunday morning when the problem started up, this was the most optimal time for us to restart the servers for our environment.
After restarting one server from our resource pool, I was able to remove the CIFS share, and virtual servers began to boot again.
We got away pretty lucky, with next to no impact.
Disappearing published applications
Users will get upset pretty quick when their applications start to randomly disappear, then come back, and then not work again. We recently had this happen, but it was one of our support applications that this was happening to, so the issue was contained to the help desk. If the application was showing up, sometimes it could not be launched, and an error would come up, saying the user did not have access to the app any more. Well, when nothing has changed, and double checking the permissions on it, I can tell you, that was not the case.
Looking at the event log of the Web Interface servers, there were errors of “An error occurred while enumerating a user’s resources”. Citrix support article CTX114769 has information on the process for identifying applications that may cause this issue.
It turns out, that application entries in the XenApp database may become corrupt, and that is what happened with our application. Just to be clear, the install of the application was fine, it was the entry in the XenApp farm that was corrupt, so the presentation of the application. I guessed that it was being caused by our suspect applicaiton, so I just recreated the application presentation, and it has been working fine ever since. With more applications, and a larger farm, opening a ticket with Citrix and have them parse the logs will help identify which applications are causing the problems.
When not allowing is different than denying – Windows printing
The following may be common knowledge to system administrators who routinely work on printer permissions on a print server, but for myself, its generally not part of my job, so I don’t worry about it.
We recently deployed provisioning services to a computer lab for student use. When deploying our printing solution, we needed to prevent the students from being able to manage documents directly on the print server, and instead provided an alternative way to manage their documents. If they had access to manage documents, they could manage other student’s documents, which would cause problems due to the fact that the students pay money for their printing.
We were able to set up a stand alone station to manage print jobs, that would queue up all a student’s jobs, and wait for them to release them. This provided two benefits: 1) The student could print all of their jobs together, instead of having multiple jobs mixed in with others, and 2) Allow them greater control in making sure they were sure about what they were printing, and also showing a total cost of the selected jobs. Using this kiosk and some print management software, we were able to use a single domain account that would have the proper permissions to manage the documents, and it acted as a middleman between the students and the printers.
When setting the permissions for the students to NOT be able to manage the documents, you must explicitly set the Deny permission for it to actually deny access to manage documents. Simply unchecking Allow, will still allow them to manage the documents. According to Microsoft documentation, Deny access has higher priority over Allow, or none.
Hosted IE & that pesky IE ESC
We recently found the need to publish Internet Explorer 8 through XenApp 6, due to a web application requiring a specific configuration. However, anytime you use Internet Explorer on a Windows Server, the Enhanced Internet Security is on by default. Normally leaving this setting on is a good thing for security reasons, but when you have a server specifically designed for internet browsing, this may become more of an annoyance for users, and maybe even admins.
To Disable Enhanced Internet Security, open the Server Manager, and under Security Information, you’ll find a button to Configure IE ESC. You’ll be able to disable this setting for users and/or admins.
Now comes the part that isn’t so clear on how this works. By disabling IE ESC, you may notice that some users may still get the IE ESC pop up when trying to browse some websites. If IE ESC is disabled, why is the ESC popup still showing? Upon reviewing many registry tweaks online, and much trial and error, we determined that if a user had a profile on the XenApp server PRIOR to the setting being disabled, it stuck with the user’s profile as still being enabled. With ESC disabled, we deleted the user’s profile on the XenApp server, and when that user logged back in, IE ESC was working as intended.
Long story short, changing IE ESC does not appear to affect existing user accounts. New user accounts will pick up the current setting.