Thursday, February 14, 2013

My experience with running Dentrix on a Terminal Server

We have a customer at work that runs Dentrix.  They have 4 offices, and need to have all of the patient data in one place.  Unfortunately, the only way that Dentrix supports this is through the use of Dentrix Enterprise, which costs about $80,000.  The customer wasn’t willing to spend that much on it, so we were forced to look at unsupported solutions.

From talking to one of the developers at Henry Schein, Dentrix is a very disk and network intensive application, which tends to cause problems when you run it on virtual PCs that share physical storage.  I set it up in a lab environment and experienced similar issues, but this may be because we were also using other non-Dentrix applications on the same physical hardware, and the hardware needed to be upgraded.

With our virtual infrastructure not up to the task of running Dentrix, I decided to build a physical infrastructure for it instead.  I grabbed two old servers and installed terminal services on them, along with the Dentrix G4 Clinical Workstation edition.

I talked with the developer about doing this, and he said that there were several known issues with installing Dentrix on a terminal server.  Namely, “slowness, refresh issues, and not prompting for a password when it should.”  Additionally, there are “identity issues, because the database won't know if the computer has the information it needed, because that computer is connecting and requesting the same information multiple times.”  However, with no other options available, I had to try it.

Getting it installed was a little less straightforward than it was on a Windows 7 workstation.  In order to get it installed (on a Server 2008 R2 operating system), I had to install two role services first: the .NET Framework 3.5, and Windows Desktop Experience.  Dentrix would not work without them.
After Dentrix was installed, I wanted to make sure it would work without giving everyone Administrator privileges.  I gave Domain Users permission to the “C:\Program Files (x86)\Dentrix” folder, and also had to disable UAC, and this allowed Dentrix to work for non-Administrators.  I also had to give users full permission to the “C:\DtxTemp” folder to allow them to be able to print the predefined letters they had set up there, but the program will run without doing this.
One of the offices also uses XDR.  I was able to get XDR to work as a non-Administrator by giving Users full access to the "C:\XDRClient" folder.

After all of this was done, I copied the program icons over to the Public Desktop (as the program only installs icons to the User’s desktop, by default), and everything was working fine.

The main terminal server I am running Dentrix on has dual quad-core Xeon 3.20GHz processors and 8GB of RAM, although I would like to get it upgraded to 16GB.  The second one has fewer users on it, and has a dual-core AMD Opteron 2.0GHz processor and 16GB of RAM.  I have about 10 concurrent users on the primary terminal server, and 5 on the secondary.

So far, they like the performance a lot better than their old infrastructure, which had everyone on their own physical blade PC – an Athlon XP 1500+ with 2GB of RAM, which is far below Dentrix’s minimum requirement of a 2.4GHz Pentium 4.  The only other issue I have had is when printing the appointment book view.  The reporting options there are a per-computer setting, so if a user at one office changes the settings there, all of the offices are affected.

Well, that’s all for now.  So far, the customer is happy, and hopefully, it will stay that way.

Thursday, February 7, 2013

HP Laserjet 4050 on a 64-bit OS

I had an issue connecting an HP Laserjet 4050 parallel printer (connected with a USB adapter to a 64-bit Windows 7 laptop) to a terminal server running 32-bit Server 2003 R2.  It worked fine when the user was running Windows XP, but after upgrading to a new computer, it no longer showed up on the terminal server.

The problem is that Windows must have a driver on the terminal server with the exact same name as the driver on the local computer.  In this case, Windows automatically installed the "HP Laserjet 4050 PCL 5" driver, but the server only had drivers for the "HP Laserjet 4050 PCL5E" and "HP Laserjet 4050 PCL6" printers.

Windows 7 also comes with a PCL6 driver for this printer, so I went into the properties for this printer (Control Panel, Printers, right click the printer and go to Printer Properties, Advanced tab, New Driver).  I selected the PCL6 version of the driver.  However, when I clicked OK, it told me that a driver needed to be installed.  Strange, as I was just using the driver that came with Windows.

It turns out there is a bug in the Microsoft drivers for this printer.  Here is the fix for that (copied from here):

As was mentioned above:
On your Windows 2008 server, open the registry editor and change the HPTrayCount:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\(printerName)\PrinterDriverData]

Set HPTray to 12 (hex, it'll show 18 in decimal).

 Note if you have 50 printers, you may have to do it 50 times.  On my server some said 0, and others were still set to 12.  I'm not sure why some changed and some did not.  The ones the still had 12 were not displaying any problems.
Scott

After I got that working, she was able to see the printer on the terminal server, but not in Quickbooks.  It turns out that Quickbooks has another bug that won't allow you to see printers whose names contain too many characters.  I logged her out of the terminal server, renamed the printer to "Laserjet4050," logged her back into the terminal server, and she was able to print in Quickbooks!