By Jeff Dixon
November 18, 2010
When we first set out on our journey to setup XenDesktop not enough thought had been given to one of our primary applications, Meditech. Meditech is the most used and widely deployed application we have and prior to XenDesktop, Meditech had been running in XenApp for remote users for some time. Due to this I believe it was thought that it would work equally as well in XenDesktop and with the exception of one oversight that was correct. Printing was this oversight.
Let me explain a little further, how much of our printing works for Meditech. We have what we call the Capture printer. The capture printer is a software driven printer that goes back to a mapping of computer to printer names. There is a database that maps computer names to printers. There is also an application that takes the print job and expands upon it. When a certain request is sent to the Capture printer it will typically print several items of varying quantity and to various locations. For example, it may print two copies of a report to tray one, a set of labels to tray two, and a wrist band to another printer from this single print submission.
Have you seen the problem that has arisen? With XenDesktops the hostname may be different every time. Additionally, many of our users work in different areas at different times. So User A may sometimes be working in department 1 and sometimes in department 2. No matter where she is logging in she needs to be sure she is printing to the correct printer(s) for that location.
There were three main issues I had to overcome in order to get this to work.
1. When Meditech printed, it had to see the hostname of the current session. While Meditech worked great from XenApp, the application was running from the server and therefore thought it was printing from the server. This was obviously an issue and it had a simple fix. I installed Meditech onto the Image.
a. Residual Issue – We run another program, Emdeon Assistant. This program launches and integrates with Meditech. This program also ran fine inside XenApp however with Meditech running on the image and Assistant running in XenApp they no longer played nice together. End Result, I had to install Assistant onto the image as well.
2. At this point I was able to get Meditech to print through the capture printer correctly but the problem was the hostname would change every time a user logged in and the hostname needed to be mapped to a particular printer. Now I know this is not the only way to resolve this but in order to continue using pooled desktops this was the only resolution I found to this issue.
In order to overcome the problem, each group of desktops that printed to the same printer was setup in one desktop group. So every computer that printed to printer A was in desktop group A and all computers printing to printer B would log into desktop group B.
3. This brings me to the last issue, Citrix Appliance Lock. Users log into different computers that print to different printers which means different desktop groups. Citrix Appliance Lock will only log a user into the first desktop group they have access too by alphabetical order. There is no way to change this and no option to select another group by the user. Since I’m primarily using repurposed desktops for my clients, I want the underlying OS to be hidden from the user and I want the user to have a seamless logon to the XenDesktop session. The Appliance Lock did what I desired but had a serious limitation in choosing desktop groups. I was able to resolve this by changing the Windows logon shell to a batch file and launching the session from there. I’ve written in much detail about this in the previous post, so please refer to it for more detail on this.
I’ve been running several very heavy users with this setup, most of which who are not overly tech savvy and the feedback so far has been very positive. There are a few definite changes to get use to in using XenDesktop but it also has a number of advantages. While we have yet to widely deploy this to everyone due to time and numerous applications that must be addressed, it is looking promising.
No comments:
Post a Comment