We are in the process of implementing an EMR, Electronic Medical Records, system one of our clients.  The 15 year old Alpha Micro OS, AMOS32, is being replaced by a SQL based system.  This particular client has 50 some odd computers spread across 6 sites.  All of the workstations are members of the domain and very few users have local admin rights.  The problem is that the EMR vendor has not been forthcoming about some of the procedures that are required in order to get the client software installed.

We installed the client on all 50 odd computers (and discovering that we needed .net 3.5 SP1) but we were not able to test the software as we did not have any credentials to log into the application with.  We followed the provided instructions and at that point that was all that we could do.

Two weeks later, when the client obtained test passwords we found that most of the software would not log into.  There were various errors so a call was placed to the vendor.  We then learn that specific permissions are needed on two folders that the software installer created.  The permissions that are "required" are full control for "everyone" and "Domain Users" to c:\ecw and to the software's program files directory.  We also learned that the vendor needed admin rights on the workstations in order to resolve any problems.  Part of our standard configurations is to create a "Workstation Admins" group and assign "Workstation Admins" to the local computer administrator group.  This makes it easy to give users local admin rights when necessary.  As part of the software install, we created a user for the software vendor that has admin rights on their servers.  The software vendor's user name was also added to the "Workstation Admins" group.  This gave admin access to the local machines so that they could solve problems.

Two weeks ago, the vendor complains that they do not have admin rights on the workstations.  We comfirned the the vendor was in the "Workstation Admins" group and that the "Workstation Admins" domain group was in the proper group on all of the computers.

A week ago, the vendor was still having problems, so I decided to visit one of the sites and see what was really going on.  The client had previously told me that the new software problems were not my problem to resolve.  I discovered two things:  1) is that the software has to be lauched for the first time by the administrator!!.  Once the administrator starts the software and a user logs in, the users can then log into the workstation with limited rights and launch the software with no errors.  At that point I ran the software after logging in with admin rights.  Then the client discovers that two functions don't work.  hmm.... Logged the user out, logged in as administrator, ran the sofware, ran the two functions, logged out, logged in as the user, the user ran the software and used the two previously erroring functions with no errors.  Now we now that we have to touch every computer and the process that is required.  When we asked the vendor, the answer way "Yes, you have run the software as administrator before users can login."  So now we have touched each computer 3 times.

This morning I get a call that two users are having problems running a previously untested function (insurance).  Having already been down this path, we tried logging in as the administrator, running the failing function.  The user logged in and the failing insurance function was now working.  Another thing that we would have liked to have known earlier.

At this point, the client tells me that we have not given the vendor the proper permissions that they need to resolve problems.  We got the project manager on the phone and he confirms that we need to run the software as admin.  He also says that support is telling him that support still does not have admin rights:  he again states that they need the administrator password.  We have the discussion and he finally understands that the username/password that we created so that they could connect to the servers was the same username and password that they should be using on the workstations.  It seems that support is used to logging in as "administrator" and apparantly most/many? medical practices willing give the domain administrator user/password to support!  The project manager said that he would put a popup for support telling them to use the "server remote access" username/password for workstation support.

Guess what phone call we get three hours later?  A support tech asking for the "administrator" password!  He finally understood what username/password that is was supposed to be using.

hc