My experience with doctor’s offices is that like all other businesses, they want to do as much as possible with as little expense as possible. In the last couple of years I’ve had to work on systems in offices that were still running Windows 98 on work stations and Windows Server 2000. My attitude, of course, is as long as a system does what you need it to do why change it? I’m not one that likes to upgrade every piece of software just for the sake of upgrading software.
However, the problem that comes up is when those same systems can no longer do what is needed. Recent changes in the way health care providers do business is forcing people in the industry to purchase new systems. Doctors are running out to buy new “Electronic Medical Records” (EMR) software to meet new requirements. These new systems require significantly more processing power than an old server running a P4 chip with 2GB of memory is going to provide. The problem then is how to stay in the old system while installing, training, and deploying the new system? All those patient charts aren’t just going to move to the new system instantly.
The issue I keep encountering is twofold: 1) The new EMR vendor is requiring a “clean server and clean workstations” for their software. No other programs (including active directory domain services AD DS) can be on the server; and, 2) the old software simply won’t install or work on the newer workstations anyway. Many of the older programs will not install on a 64 Bit OS, and even if it will, the client probably hasn’t paid for support in quite some time so you’re not going to get the new install disk. (If they had been paying for support, they wouldn’t still be running their system on Windows 98 or 2000 system!)
I just ran into this exact situation. Office was running a DOS based medical manager software on 32 Bit Windows XP machines. The office did have Windows Server 2003 as it’s domain controller, but the software would run just fine on an XP machine. The new EMR software they just purchased required a 64 Bit Windows 2008 R2 & SQL 2008 server with a LOT of hard drive space just for the EMR and the workstations were strongly encouraged to be Windows 7 64 Bit OS.
I got called in to do the initial set up. The lease on the servers and workstations was up so all the old equipment and a server needed to be returned to the vendor and new equipment was purchased. What I was asked to do was move the old EMR server to another computer and put the old EMR client on the new workstations so they could be in both systems during the transition.
This was when I discovered the problem with old 32 bit programs and new 64 bit systems. While there are compatibility settings on all the new OS’s, they don’t always work they way we’d like them to work, and without support from the old vendor, I was pretty much out of luck.
The solution I implemented was to use VMware Server 2.0. If you limit the number of virtual machines per server to 3, the license is free. I registered the client with VMware and downloaded the server software.
It would be pretty impressive to tell you that I just set up a virtual machine for each of the workstations we needed to replace, however, nothing is ever that simple!
I downloaded and installed a backup program that would convert my workstation to a virtual machine. It seemed simple enough. I created a virtual image of the standard workstation. Then I loaded that image to the first VMware Server thinking I’d just boot it up and go.
I was wrong.
The virtual machine did boot up. I was feeling all satisfied with myself and congratulating myself with my brilliance when I saw this message:
Since the last time Windows XP was activated, major hardware changes have taken place. Windows XP needs to be activated again…”
At first I didn’t understand why I was getting this message. I didn’t understand that even though you should be able to run XP on a VMware system, that the VMware machine did indeed have different hardware specifications than the machine I made the backup from. So far I didn’t think I had anything more than a minor annoyance as I just would go ahead and reactivate Windows. I click on the prompt to activate Windows and go through the prompts. No luck. Cannot activate. I finally get the prompt to call the telephone number and activate my product. I’m thinking this shouldn’t be an issue since I’m moving the system from one machine to another. I have a valid key and it will still be installed on only one machine (albeit a virtual one). No problem until the message on the line said (and this is a paraphrase), “Microsoft has no record of that product number. You may be able to return your copy of Windows to the vendor you purchased it from…”
I was shocked! I went through the whole process 3 or 4 times, each time with the same result. I then went and copied the XP key off all the old machines in the office and one by one tried to use each key to the same result.
Long story short (if that’s even possible after 900 words just to get to this point…), the copy of Windows XP I was using was legal so long as it was on a DELL computer of a specific model with a specific bios lock. Apparently Dell has or had a proprietary version of Windows XP Pro OS. I have since found out that HP did the same thing for awhile. This was an entirely new concept to me because I have for years had to reinstall Windows XP on OEM workstations (Dell, HP, Lenovo, IBM, etc.) and have used a Windows XP PRO OEM install disk using keys from every machine with little to no issue.
What I ended up doing is building a new virtual machine from scratch, installing the OS and the old EMR software, and other programs, and then deploying THAT machine to each of the virtual servers.
This of course created a couple new problems. The first one I knew ahead of time. I’d have to change the windows key on each machine to keep the copies legal, and then of course change the name of each machine for the intranet domain. The second problem is the one that embarrasses me that I didn’t count on it ahead of time.
After adding my virtual desktop to the VMware Server and powering it up, a dialog box would pop up on the screen asking if I was copying or moving the machine. I didn’t really know how to answer that question, so on the first one I said that I was copying the machine. When the virtual machine powered up I got the dialog box asking me to activate windows. I change the key and no problem. Next machine. This time I said that I was moving the machine. When I powered up this machine, no activation dialog box. I went in, changed the domain name of the computer and went on to the next machine. Feeling all smug, I then proceeded to move another 8 machines.
Each machine appeared to be working just fine. It wasn’t until the office attempted to actually work that we discovered the problem. The problem was the computers were S L O W. I don’t think I typed that slow enough. They were S – - L – - O – — -W. They were dropping packets and timing out and causing all kinds of general havoc.
The problem in a nutshell: When you move a virtual machine, the MAC address of the computer stays the same. As far as VMware is concerned, the physical machine is identical, including the MAC of the NIC card. Even though I changed the name of the computer and changed the IP address and even the Windows key, the MAC address is the same. This is what I’m embarrassed about. I spent a lot of time looking at the DNS server for an answer. The IP addresses and the system names matched up correctly, but intranetwork switching (LAN before getting to a router) uses layer 2 addressing (using the MAC address) rather than layer 3 addressing (using IP addresses). I had 8 machines with the same MAC address.
Once I figured out this problem and then subsequently how to go in and edit each machine to change the MAC (I ended up doing manual MAC addressing, converting the IP address to hex for the part of the address I could create, sort of like private IP addressing) the network was rock solid and the client extremely happy.
They are now the first and only office in town with a complete deployment of virtual machines running their old EMR at the same time as the same physical machines are running their new software. I discounted the time I spent figuring out how to make the VMware work (I don’t believe in charging clients for me to learn something they are paying me to know!) and all is well.

