Since we're working on using App-V for application virtualization, and use McKesson's Medisoft for our medical billing, it of course made sense that we'd try to virtualize Medisoft and distribute it as a virtual application to our end-users. For those in the medical field who use McKesson's Medisoft billing application, you probably know that it has it's quirks. One big one is that it needs to write to a config file in the install directory... meaning that if the app's users don't have admin rights or power user rights, specific ACLs need to be set on Medisoft's "Bin" directory to allow Medisoft to work under non-admin user accounts. If you don't have read/write permissions, you get an error about access to the LasCon.cfg file. At FSW we have a security group called Medisoft, comprising groups and users who need to use Medisoft. That group then gets the appropriate rights to the Bin folder, LastCon.cfg, and the other relevant folders and files.
This quirk also messes up App-V sequencing, as you'll get a "could not write to Q:\Medisoft\Bin\LastCon.cfg" error when you first try to use your freshly-virtualized app after sequencing. Sequencing, of course, will succeed, meaning that you will only experience the problem when you test (you do test before deploying, right?). This happens no matter what ACLs you have set in the sequencing steps - it's because there's zero rights to the Q: drive (I say Q: because it's the default App-V drive... insert your custom drive where appropriate if you use one), so even if you make the entire Medisoft folder accessible to Everyone during sequencing, you're out of luck. Since it's installed to Q:, and there's no access to Q: the ACLs don't matter - it takes on the Q: drive's inaccessibility.
This is easy enough to work around, however... Luckily it's a simple modification to the normal sequencing process. Simply sequence the application and let it install to it's normal (that is, \%programfiles%\Medisoft) location. App-V will still see the installation and capture it correctly. You'll also capture a bunch of other useless bits (IE, various folder shortcuts, etc.), which you can remove.
As a general rule, I also open up Medisoft, OfficeHours,and Medisoft Reports before clicking "I am fnished installing" as well, in order to capture the registry entries pointing to my medidata directory. Even though this can be captured later, I prefer having it up front. It makes little difference either way. That said - it's a good idea to open up the Claims Updater and Revenue Management Updater - they will almost certainnly require updating and it's crucial that they be updated properly. Just remember to open them separately - if another product is open, the updater will ask you to close and retry.
2 comments:
Thanks for this post. While we do not use McKesson Medisoft, we do use many other McKesson products, which we have virtualized. Do you have any other tips/recipies for McKesson products? We have made App-V package for HMM 10.1, HCM/HCC 10.1 and 10.3 (sometimes called CAF), HEMM (used to be called PMM)and Practice Partner.
Thanks!
Thanks for the comment. Sadly, my answer is that no, we haven't done anything with McKesson products beyond Medisoft and OfficeHours, largely because those are the only ones we're using. We were looking at their EHR package, but elected to go with another vendor.
Post a Comment