Menu 

Centricity 9.5 over Citrix XenApp 6

Introduction

This post will walk through some of the issues we experienced during the upgrade of a client from Centricity 6 on local workstations to Centricity 9.5 over XenApp 6. This upgrade was performed after a two month testing period which ironed out many issues that may not be covered in this post. Please note that we are not official support for GE health products and this document only describes the fixes we used to solve several of our major issues. Your mileage may vary.

Hardware Configuration

Our client hosts both the database server and multiple client XenApp servers on a pair of workload-balanced high-availability XenServers.

Software Configuration

The database server is set up exactly as described in the GE documentation for a site our size, including not running SQL Server R2. To get the initial 4 XenApp servers communicating and working together as a farm we were required to install hotfix XA600W2K8R2X6406. Three of the XenApp servers are also used as web secure gateways for offsite access, the firewall automatically load balances connections to those servers. As you will find later there were several other hotfixes needed for stability, but they were not used in testing or initially.

Initial Centricity Upgrade

The actual database upgrade was relatively painless and the installation guidelines provided by GE were quite specific and outlined all the steps needed. The only fault lies with the actual upgrade software which was found in pre-testing to not check some of the prerequisites (like the c:temp folder being writable) and fails at the very end of the upgrade. One last minute change in plans was that we were required to make was to rename the new server with the same name and IP of the old server. This was to allow for DTS, firewall rules, and various other connectors to continue to work without requiring a change process that the local Centricity support group claimed would take at least 3-5 working days.

Installing the Centricity client and upgrading it to patch 4 was also painless on the XenApp servers and the documentation explained each step well. Initially we shared both Centricity 9.5 via Internet Explorer 8 and Adobe Acrobat X, but later ended up dropping Acrobat sharing.

Citrix Receiver Deployment

We used a group policy affecting the relevant departments to install the receiver on computers via a startup script. We then scheduled all computers to reboot that weekend by passing a ‘gpupdate /force /boot’ command at 2am. The script used for the install was found freely available on the Internet and I do not recall the source. The, slightly edited, script we used was:

REM *********************************************************************
REM Customize the following variables
REM *********************************************************************
set DesiredVersion=12.1.0
REM Set DeployDirectory to a location containing the Citrix online plug-in installer
set DeployDirectory=\citrixlocation
REM Set CommandlineOptions for the Citrix online plug-in installer
set CommandLineOptions=/silent /ADDLOCAL="ICA_Client,PN_Agent,SSON" ENABLE_SSON=Yes ENABLE_DYNAMIC_CLIENT_NAME=Yes SERVER_LOCATION="http://citrix"
REM *********************************************************************
REM System verification
REM *********************************************************************
set CustomConfig=None
REM Check for any custom configuration files in the Default User profile
IF EXIST "%SYSTEMDRIVE%Documents and SettingsDefault UserApplication DataICAClient" set CustomConfig=exists
IF EXIST "%SYSTEMDRIVE%UsersDefaultAppDataRoamingICAClient" set CustomConfig=exists
REM Check if the machine is 64bit
IF NOT "%ProgramFiles(x86)%"=="" SET WOW6432NODE=WOW6432NODE
REM This script does not verify if a legacy client is already installed
REM Check if the desired online plug-in version is already installed
reg query "HKEY_LOCAL_MACHINESOFTWARE%WOW6432NODE%CitrixPluginPackagesXenAppSuiteICA_Client" | findstr %DesiredVersion%
if %errorlevel%==1 (goto NotFound) else (goto Found)
REM If 1 is returned, the registry query found that the desired version is not installed
REM *********************************************************************
REM Deployment begins here
REM *********************************************************************
start /wait %DeployDirectory%CitrixOnlinePluginFull.exe DONOTSTARTCC=1 %CommandLineOptions%
if %CustomConfig%==exists goto End
REM Clean the Default User profile if custom configuration files did not exist
IF EXIST "%SYSTEMDRIVE%Documents and SettingsDefault UserApplication DataICAClient" (
RMDIR /S /Q "%SYSTEMDRIVE%Documents and SettingsDefault UserApplication DataICAClient"
)
IF EXIST "%SYSTEMDRIVE%UsersDefaultAppDataRoamingICAClient" (
RMDIR /S /Q "%SYSTEMDRIVE%UsersDefaultAppDataRoamingICAClient"
)
:Found
goto End
:End

Monday Morning

“No campaign plan survives first contact with the enemy” – Helmuth Karl Bernhard Graf von Moltke

The first day of the week quickly highlighted several items uncaught in planning and testing ranging from certain connectors that worked in testing no longer working to general instability. As the week progressed we steadily resolved a host of issues with support from the normal local Centricity support and greater help from another support group which resolved some top issues outlined below in a matter of minutes over the phone.

Login Names

One of the first items we found was that XenApp does not handle multiple sessions by users using the same login name gracefully, even when set up to do so. Several of the shared exam rooms all used the same basic login into Windows for ease of use by providers (Centricity still required a single sign-on for HIPAA and tracking, of course!). While we knew that this was done, we did not realize that if there were more than 2 sessions under a name Remote Desktop will bring up a screen asking you which session to take over instead of creating a new one. This led to chaos as sessions continually hopped between rooms. To fix this we integrated the computer name into each rooms login and locked the user down to only be allowed to log into that workstation or the XenApp servers (otherwise they could not run applications!).

Centricity Printers

Printers in Centricity over XenApp proved to be the most disruptive problem encountered. From being unable to save printer preferences to extreme slowness in printing, we spent the better part of our time fixing printer issues.

Printer Names

In normal installations of XenApp printers are auto-created and torn down as your sessions are used, these printers are named according to the computer and session. Unfortunately, Centricity printer use preferences are based upon the name of the printer and not the path. This means the preferences will be reset every time Centricity is opened unless you are lucky enough to get the exact same computer and session combination.

Our first attempt at a solution for this was to create local print servers on minor department servers which would have their printers assigned to sessions via XenApp group policy. Unfortunately, this did not work well due to the local servers being 32-bit and the requirements of 64-bit drivers for the XenApp servers. While this would not be a problem when the drivers are available, the client uses several legacy printers which, while supported by built-in drivers, do not have drivers available to download and add to the print server driver cache.

Our final solution was to make each XenApp server a print server for Centricity. This gave us local printers which to print to and bypassed the 32/64 bit issues. The only long-term problem we continued to have is a custom-built Rx form which will not print to certain drivers and is being looked into by our local Centricity support/distributor.

User Names

The second fix was to make Centricity use the workstation instead of the logged in user to save preferences. By default Centricity will use the logged in users name to store printer preferences so they follow you to different workstations, and resets this choice on every patch or update. However our client wants preferences stored on a per-workstation basis as there are better printers to use depending on location more than who you are. To fix this you must edit the ‘emr.ini’ configuration file located in every installed Centricity 9.5 Client folder and change the ‘UseClientName’ property to ‘TRUE’.

Printing Speed

Quickness and stability of printing was handled through the application of several patches and resetting the local printers to use the default windows spooler and monitor instead of custom ones which came with the drivers.

For XenApp we installed the XenApp 6 Print Optimization Pack which included 64-bit drivers (XenAppGpmx_x64.msi) and an early hotfix (XA600W2K8R2X64010). We also installed the more recent hotfix XA600W2K8R2X64056 to further optimize printing.

On Centricity we installed GE’s ‘CPS95 Orders Printing Patch’ to speed up the abysmally slow order printing (2-10 minutes).

Adobe Acrobat

We originally had Acrobat as a shared application, users found it too slow to open and use on top of the substantial Centricity workload so it was turned off and now only pdf’s launched by Centricity itself are served from the server, all other PDF’s have been reverted to being launched from the clients machine. This will be re-visited in the future as more XenApp applications and server are brought online.

Centricity Stability

With the printer 32/64-bit driver problems it was not realized until later that there were several basic Centricity stability issues like random disconnects and crashes. To combat these issues we installed a series of Citrix-recommended hotfixes and one recommended Windows hotfix:

  • Windows
    • KB2465772
  • Citrix XenApp
    • XA600W2K8R2X64060
    • XA600W2K8R2X64017
    • XA600W2K8R2X64026
    • XA600W2K8R2X64029

GoToMyPC

Some users on site make use of GoToMyPC to work from home or around the world. However, it appears the Citrix Receiver occasionally has issues releasing client sessions when GoToMyPC is active. As a workaround we taught the afflicted users to log off their sessions and keep trying to reconnect to sessions until they saw the error stating they had no hanging sessions. We also implemented and idle session rule to log off session that have not been used in two hours or have been disconnected for five minutes. These steps seem to have solved this problem and helped ensure morning connections do not try and resume a hung session.

TWAIN

Several workstations made use of various TWAIN and USB devices to take pictures, scan documents, and capture insurance cards. However, depending on the construction of the local TWAIN drivers it was rather hit and miss for those capture devices to work in Centricity (even with TWAIN and USB device redirection). To alleviate this these workstation were installed with a local version of the client which, while slower in execution, allows them to use the capture devices without incident.

A Week Later

In general everything is stable, but there are occasional issues here and there. For example, one of the Medicare reimbursement transmitters decided to stop working over the weekend and the local Centricity support team is being slow to respond, the custom Rx form is still acting strangely from time to time, and any prescriptions printed from a certain patients chart will cause Centricity to crash in that session. Basically the normal Centricity strangeness we have come to expect.

In Closing

I hope the fixes we found are helpful to others planning upgrades to Centricity or moving onto the XenApp platform. We would like to remind any readers again that we are not official support technicians of Centricity so what worked for us could very well not work for you. However, I hope we at least give you some items to discuss with your local Centricity support team prior to your upgrade.

Submit a Comment

Pin It on Pinterest

Share This