sclaggett

Installing Medisoft 17 Clinical Client on Windows 7

My in-laws run a small internal medicine clinic and were in the process of migrating to an electronic medical records system, specifically Medisoft's practice management software. The Medisoft software is passable as far as medical software goes, but the third-party reseller that sold them the software and was responsible for installation and maintenance encountered significant difficulties trying to get everything up and running. It wasn't for lack of effort, as the poor guy spent many hours wresting with their computer systems, but certain technical issues proved to be insurmountable for someone with a limited understanding of how computers work under the hood. In the end, I took on the responsibility of getting everything working and making sure their patient data was properly backed up off-site. This page contains notes on gotchas that I encountered while installing Medisoft 17 Clinical Client on several Windows 7 devices.

Disable User Account Control

I started by mapping the P drive to the server as specified in the installation instructions. Windows Explorer showed that the network drive had been successfully mapped (DCVBBXR1 is the name of the server):

Figure 1

But I quickly hit a road block trying to install the software because the Next button was disabled at the Select Destination Directory screen, despite the fact that the default directory "p:\ppart" was a valid location in Windows Explorer:

Figure 2

Clicking Browse in an attempt to select the path showed that the P drive wasn’t an option:

Figure 3

So the P drive was clearly mounted and accessible through Windows Explorer, but the installer couldn’t see it. What was going on?

It turned out the root of the problem was that the User Account Control (UAC) was limiting what drives the installation wizard could see. A workaround for this was to temporarily disable the UAC. This was done by exiting the installation wizard, opening the Control Panel and selecting User Accounts:

Figure 4

Clicking on Change User Account settings:

Figure 5

Lowering the slider from the current value of Default to Never Notify:

Figure 6

I observed that the system only prompted for a reboot part of the time, but the computer always needed to be be rebooted regardless so the changes would take effect. Now when the installer was run again it was able to see the P drive and could proceed past the step that it was previously stuck on:

Figure 7

After installation, the UAC could be returned to Default and the system rebooted once more without impacting the ability of the application to access the P drive.

Edit the hosts file

Now Medisoft Clinical Client had been installed, but it appeared to hang when ran and finally displayed a vague error message:

Figure 8

The error message meant something went wrong when trying to connect to the server, but it didn’t give any details, nor did the application generate a log file. I examined the situation using a combination of Process Monitor and Wireshark, and the results revealed that the client was trying to open a socket connection to the incorrect server:

Figure 9

Figure 10

The application was trying to connect to an external server at 66.152.109.107 when it should have been connecting to the internal Medisoft server at 192.168.0.5.

First I found that opening the following file:

C:\Program Files (x86)\McKesson\Practice Partner\Servers.config

And changing all occurrences of the server name (DVCBBXR1) to the server IP (192.168.0.5) would fix the problem. That indicated that something was going awry in the resolution of the server name, but changing the file above was hacky and likely to get lost during an update or reinstall. A better solution was to open:

C:\Windows\System32\drivers\etc\hosts

And add the following line:

192.168.0.5 DCVBBXR1

Now the server name resolved to the proper IP address:

Figure 11

And the client attempted to connect to the proper server:

Figure 12

Figure 13

Configure the server firewall

Note that I said that the client was attempting to connect to the proper server, because the connection was still failing. The client application once again showed the same vague error message as before:

Figure 8

The issue turned out to be that the firewall on the server didn’t have the required ports open. On the server, the Windows Firewall program was opened under Administrative Tools:

Figure 14

Inbound Rules was selected in the left panel and then New Rule... in the right panel:

Figure 15

The following choices were made in the new rule wizard:

Finally, the client could connect to the server:

Figure 16

Check the MR path

The above solutions were all that was required for three client computers, but the following error message was encountered on the fourth:

Figure 17

The client configuration was a bit different on this machine for some reason. The following file was opened:

C:\Program Files (x86)\McKesson\Practice Partner\mrpath.fl

The file contained a single line that referred to a folder on the server by the server's name:

\\DCVBBXR1\ppart\

Changing it to use the mapped P drive fixed the issue:

p:\ppart\