Running Dentrix without Local Admin or UAC Disabled

Yep, this looks safe enough for me to put everyone's Social Security Number, medical history, and dental history into.

I used to support more than a few Dentrix installations back in the day. It was not fun - this particular Electronic Health Record (EHR) package, which is all the rage in dental practices across the US, requires local administrator access (see page 8) for all users. It's also strongly encouraged to disable User Account Control so that users aren't constantly bombarded with UAC prompts whenever they try to use the software. Needless to say, this is a highly less-than-ideal way of running a piece of software that's ostensibly designed for HIPAA compliant medical practices, which is why I was thrilled to no end when I changed jobs and stopped supporting dental IT.

Last Friday, I received an email. In it was a request that sent a chill down my spine:

We're teaching a class on Dentrix and need it installed in a computer lab.

Images of fresh-faced students with local administrator access on computer lab PCs filled my mind. Now, this isn't the first time I've faced this - the usual solution is to set the PC to dual-boot, with the administrator image being off of the student lab domain. It's not a perfect solution, but it at least keeps the damage to a minimum and protects our student lab servers. However, this solution only works with technologically sophisticated instructors and users; the instructors that needed Dentrix are sophisticated about Electronic Health Record systems, but not so much about proper Windows booting protocol.

I needed a better way. With some trial and error, I think I found one.

The first reason Dentrix requires local administrator rights is because it places its data folders in its installation directory, which, by default, is C:\Program Files (x86)\Dentrix [1], and whatever user is running Dentrix must have sufficient access to write to these directories. So, the first step to the solution is to make it possible for standard users to write in the standard installation folder:

cd %programfiles(x86)%
icacls Dentrix /grant "Users:(OI)(CI)(F)" /t

I also, just on the safe side, granted write access to everything else installed with Dentrix:

icacls "GURU LE" /grant "Users:(OI)(CI)(F)" /t
icacls "Guru Limited Edition Server" /grant "Users:(OI)(CI)(F)" /t
icacls "Business Objects" /grant "Users:(OI)(CI)(F)" /t

Next, we need to move the installed desktop shortcuts to places accessible by everyone instead of just the profile that Dentrix was installed under:

move %userprofile%\Desktop\*.lnk C:\Users\Public\Desktop

move "%userprofile%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Dentrix Learning Edition" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\"

move "%userprofile%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\GURU Limited Edition" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Guru Limited Edition"

Oh, and fix the permissions on them, too:

cd "C:\Users\Public\Desktop\"
icacls *.lnk /reset
cd "c:\ProgramData\Microsoft\Windows\Start Menu\Programs\"
icacls * /reset

That made it possible to run Dentrix as a standard user with UAC disabled. Now it was time to get around UAC. To do that, I followed the spirit of Ghack's guide on doing just that - I installed the Microsoft Application Compatibility Toolkit, then created Application Fixes enabled RunAsInvoker for each of Dentrix's client-centered applications, while explicitly avoiding the database rebuild utilities like _Rebuild or _Rebuild2. Namely:

• Appt.exe - Appointment List
• Apptbook.exe - Appointment Book
• Chart.exe - Patient Chart
• Document.Center.exe - Document Center
• Document.Convert.Daemon.exe - Document Convert Daemon
• Document.UnfiledUtility.exe
• Dtx.ThreeDDataLoader.exe
• DtxLink.exe
• DtxLinkNet.exe
• DtxRx.exe - Prescription Module Wrapper
• DXPort.exe
• Dxprint.exe - Dentrix Print Module
• DXWeb.exe
• Famfile.exe - Family File
• Journal.exe - Patient Journal
• LabTrack.exe
• Ledger.exe - Ledger
• Mailer.exe - Mail Merge Utility
• Office.exe - Office Manager
• Patpict.exe - Patient Picture
• PayerId.exe
• Perio.exe - Perio Module
• PEXI.exe
• Presenter.exe - Dentrix Presenter
• query.exe - Query engine
• Questionnaire.exe - Questionnaire engine
• QuickLabels.exe - Quick Labels
• RA.exe
• SearchPayments.exe
• Snapshot.exe
• TimeClock.exe - Time Clock
• Totscr.exe
• Tpman.exe
• Trintf.exe
• TxPlanner.exe
• Wizard.exe

Then it was time to use it:

sdbinst "\\server\path\to\Dentrix\install\dentrix-fix.sdb"

Note that I largely aimed with a shotgun instead of a scalpel - I basically whitelisted almost every single executable in the Dentrix folder I could find that I knew wasn't a database utility and wasn't something that already ran without UAC whitelisting (e.g. AppLauncher). I also excluded eSync's executables since we don't use eSync in our lab. Also note that, since this was a classroom environment, I didn't have to deal with integrating this with Dexis, Dentrix Image, SUNI, or the other, similarly broken imaging solutions that are used in the dental field - that said, the same solution might work. I'll further note that, at least in my case, data integrity is not a high priority; since this is for a lab environment, it just needs to work well enough to get the point across, not remain stable through several Dentrix upgrades. That last point is important since the Microsoft Application Compatibility Toolkit calculates checksums for each executable you add to your database - if Dentrix upgrades a particular executable, you'll need to re-whitelist it for it to work.

The result? A Dentrix installation that let me, as a standard user, load up every Dentrix module I tried and make changes to patient records without a single UAC prompt.

If anybody is actually brave enough to try this in the field, let me know - I'm genuinely curious.

1. Note that, for the purposes of my lab, we're instructing using Dentrix G4. Dentrix G5 is theoretically 64-bit native, so it might install in C:\Program Files on 64-bit systems.