How to install Dentrix 24.1 onto a remote workstation

For years now, whenever we swapped out a desktop and needed Dentrix reinstalled, our staff would call Dentrix Support to have them do the installation manually. This is because, sometime 5-10 years ago, when you double-clicked on “setup.exe” it just wouldn’t work. It often complained about missing components, .NET runtime versions, or similar. I think Crystal Reports was a frequent culprit. This was a far cry from when we bought the practice >15 years ago, when I could install Dentrix without much issue by putting in the CD(!) into the tray and running setup.

Today, I needed to get Dentrix set up on a remote computer to test some things. But I had no interest in calling Support to make this happen. I was determined, determined I say, to get this done myself.

Instructions

Note that these instructions were written for Dentrix 24 with Windows 10 Pro (10.0.19045 build 19405). I’m certain that they will break in the future. All of the steps below need to take place on the workstation.

  1. Navigate to \\[server]\DTXCommon\Installs\
  2. Copy the 24.1.1.17965 folder (or whatever is the latest one you see) to the workstation. I also copied the sibling files over to the Workstation as well, for good measure; not sure if that’s required or not. So, if this is what my server contained in \\[server]\DTXCommon\Installs\ :
    How Dentrix Server's Installs folder looks
    then this is what my workstation contained in my working folder:
    How the workstation's Installs folder looks, with only a subset of the Dentrix folder copied
    WARNING: even with the reduced number of files copied, this still required 3.2GB on disk.
  3. Try to run 24.1.1.17965\setup.exe . It will probably fail with an error about Crystal Reports.
  4. So, try to run Crystal Reports installation first. Find it in 24.1.1.17965\ISSetupPrerequisites\{CrystalReports-13-0-32bit-Prereq}\CRRuntime_32bit_13_0.msi . But, for me, this failed with Error 1904. Module C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\crtslv.dll failed to register. HRESULT -2147010895. Contact your support personnel. If it works for you and you don’t get this error, great; you can probably go back to step 3 and run the setup.exe for Dentrix again.
  5. After digging around the Internet, I found this answer on StackOverflow, which gave me the hint I needed. We have to reinstall the Microsoft Visual C++ 2015 Redistributable package. I found that on Microsoft’s website. Note: be sure to download the 32-bit version, because that’s what Crystal Reports relies on here apparently.
  6. When you try to install the Visual C++ 2015 Redistributable package, that may fail with an error if you already have one installed. I had to go to Settings > Control Panel > Add/Remove Programs, and uninstall Microsoft Visual C++ 2017 Redistributable (x64) 14.12.25810 first. After I did that, I rebooted, then worked backwards from here:
    • Installed Microsoft Visual C++ 2015 Redistributable Package (32-bit version), per line 5 above
    • Installed Crystal Reports via the CRRuntime_32bit_13_0.msi file, per line 4 above
    • Installed Dentrix via the setup.exe, per line 3 above

Other notes

Using Dentrix Workstation over a TailScale VPN is significantly slower than using Remote Desktop to the server or another workstation. There must be a ton of synchronous round trip calls made within Dentrix, with the (not invalid, at the time it was created!) assumption that your server and your workstations will all be connected to a high-speed intranet network.

Dentrix services not starting on boot (2023 edition)

Last week, we experienced catastrophic failures with Dentrix. Every attempt to launch Office Manager, Appointment Book, Family File and Ledger, on the server and all workstations, crashed within seconds of launch.

Our system:

  • Dentrix 23.2.3.6311
  • Windows Server 2019 Essentials
  • 15+ workstations

We were without Dentrix for 6 hours while Dentrix Support uninstalled then reinstalled (!) Dentrix. That resolved it at the time, but it was not clear as to why it worked (and Support had no idea either).

A week later, Windows Update (KB5026362) downloaded on a Thursday, but did not yet install.

We restarted the server on the following Saturday and let the Windows Update complete. On Sunday, we attempted to launch Dentrix. Appointment Book and Office Manager would spin for a few seconds, then crash and shut down, on the server and on all workstations. Mild panic ensued. Interestingly, Document Center, Office Journal, and Timeclock still worked.

We attempted these things, none of which worked:

  • We re-enabled LLMNR
  • We uninstalled KB5026362

Lots of Google searching and deep thinking, we looked at Server Manager, and noticed that not all services were being launched at start (there was a red 5 next to it, indicating that 5 services did not launch). One of those was DtxUpdaterSrv. It listed status of “Stopped” but startup type of “Automatic”. Which means, it attempted to start but couldn’t. On a whim, I started the service manually, and immediately the broken applications started working

Digging deeper, I saw that these services, along with DentrixACEServer, all had attempted to start on system boot. None of them completed; every one of them had an Event log that showed “A timeout was reached (30000 milliseconds) while waiting for the … Service service to connect”.

With some searching, I came across this ServerFault post on how to change the default timeout from 30 seconds to 60 seconds. I applied the change and rebooted. The Dentrix services came up on the reboot, so things may be better! Only time will tell of course.

Turn off Multicast Name Resolution (LLMNR) to speed up Dentrix

UPDATE 4/15/2021: IMPORTANT! The latest Windows security update, KB5001330, is causing issues with Dentrix accessing the common folder on some computers. Dentrix released a notice yesterday stating that they found a workaround: turn Multicast Name Resolution (LLMNR) back on. While this might be fine for a temporary workaround, it’s a terrible long term solution because LLMNR is a known attack vector.

On Dentrix’s Facebook page, one participant indicated that another potential workaround is to set the Hosts file on each workstation to point the server to the server’s IP address. This should bypass all external name resolution, and bypass this issue altogether. We briefly tried this method (to solve a different problem) a few months ago, with terrible results, but it might be worth trying again.

The third potential workaround is to uninstall the Windows update and force your workstations to hold off on applying the update. And then, hope and pray that Dentrix will release a patch to address this problem the right way.


UPDATE 4/2019: we upgraded to G7, and everything is still speedy. This solution still holds, for us anyway.


UPDATE 4/22/2018: I had rebuilt two of our client machines (a front desk and an operatory computer), and the staff was complaining of Dentrix being extremely slow on these two. I remembered this post, followed the directions, and boom things are fast again.

P.S. Dear Dentrix Support, stop telling your clients to go upgrade all of their machines when they experience this issue. Please try this first.


ORIGINAL POST 6/20/2015:
The Dentrix G6 installation went relatively smoothly for the Belmont office of Forever Dental. After a few days, support came in and installed eCentral so we can file electronic claims. That’s when the problems started. Specific Dentrix modules (notably, Treatment Planner and Chart) were running extremely slowly. Treatment Planner would take upwards of five minutes to open a patient chart. This made no sense: it’s a small (but growing!) second practice, and there is no reason Treatment Planner should require so much time.

Our setup is relatively simple:

  • Windows 7 running G6 Server
  • 5 Windows 7 workstations running G6 Clinical or G6 Frontoffice workstation
  • All 6 machines connected to a router and obtaining IP addresses with DHCP. Nothing fancy like static IPs, hosts files, etc.
  • LogMeIn Hamachi set up on all machines, so that we can Remote Desktop into those machines

After 2.5 hours with Dentrix, they stumbled upon a solution: disable link-local multicast name resolution (LLMNR). My theory is that Hamachi adds so many subnets as the network grows, and unless you have static IP addresses mapped to names in the hosts file, LLMNR requires each request to a name to timeout before finally identifying the proper name-to-IP-address mapping.

Yes, it worked, but even as I wrote the above, it felt wrong. So if someone out there knows what is really going on, please leave a comment!

Upgrading from Dentrix 11 to Dentrix G4

Ah, the fun never stops with Dentrix.
As a part of the massive buildout of Forever Dental, we decided to upgrade from our aging Dentrix 11 to Dentrix G4 in order to better facilitate more than doubling the number of workstations that access the server.

A beautiful Saturday afternoon rolls around (one we’ve committed indoors to this upgrade).  We met the system requirements, walked through the Ten Installation Tips, and are ready to go.  We put the DVD in, cross our fingers, and press “Install Now”.

After clicking ‘Next’ a few times, we are greeted with this.

It reads “Database Conflict. The version of the database does not match the version of the DENTRIX program files”.

Since we had scheduled this upgrade on a Saturday afternoon, Dentrix Support was closed.

We were likely the first callers when Dentrix Support opened Monday morning.  After walking through the situation, our tech support rep told us that the issue is due to a couple of missing *.idx or *.dat files in the Dentrix/data directory.  We walked through every file that was supposed to be there (approximately 30), and, behold, it turns out that 3 were missing (LCM_Log.dat, LCM_Case.dat, LCM_Def.dat).  We would have to use Dentrix 11’s Selective Setup to install _only_ those three files.  The good news was that these files related to Lab Case Manager, which was never used in the practice.  The bad news was that this might destroy the entire database.  After completing the Selective Setup, we were to run Rebuild to rebuild the entire database, the continue with the upgrade.

We started the entire process again at 6PM, after the last patients left and after we backed up the system.  Selective Setup completed, Rebuild completed, and the data appeared sound.  We then ran G4 installation, and after a tense 20 minutes, it completed successfully.

Or so we thought.  Immediately after completion, I launched Appointment Book on the server.  Crash.  I launched Office Manager.  Success.  I clicked on Appointment Book from Office Manager.  Crash.  I wish I took a screenshot of that error that we got, because it was a scary looking one.

At this point the time read 6:58PM (Central time).  Dentrix Support closes at 7PM.  We called them immediately and thankfully they were open.  We spoke to another tech, and learned that Windows Server 2008 R2 does not by default install .NET Framework 3.5.1, and we had to do this manually.

I ran Server Manager and clicked on Features, then Add Feature.

I clicked on the + next to .NET Framework 3.5.1 and clicked the checkbox next to .NET Framework 3.5.1.  I specifically did NOT check WCF Activation (as indicated by the Dentrix Support tech).

I clicked Next and finished up the installation.
After completing this, Appointment Book opened successfully.

UPDATE:
Several days after the upgrade, everything seems to be running smoothly.

 

Backing up Dentrix Image 4.5’s database

This is a followup to the earlier post, Migrating Dentrix Image 4.5’s database to another computer. Please see that post to understand how I got here in the first place.

Now that we have successfully migrated, we want to begin the process of performing nightly backups of this data. As expected, Dentrix does not provide consistent, reliable documentation of how to do this, particularly for older platforms such as this. My goal here is to illustrate what I have done and solicit comments from others out there to understand their approach.
First, our setup.
  • Main Dentrix 11 and all DXImage files are running on Windows 2008 Server
  • DXImage database is running on Windows XP
  • We have a 2-disk RAID NAS in our network
  • We also subscribe to an offsite backup service, CrashPlan
We currently back up Dentrix Image’s database in two ways.
  1. With Dentrix’s internal backup. If you dig deep on the server where your image database is housed, you will see a folder called ViperDataBackup. In our case, this is in \Dentrix\DXImage\MSDE\MSSQL$VIPER\Backup\ViperData . This folder grows with two new files each day:
    ViperData_db_[date].BAK
    ViperData_tlog_[date].TRN
    These files seem to represent nightly backups. We use Cobian Backup on the server to copy all files from this directory to the NAS each night. The main issue, as illustrated below, is that I have no idea how to restore from these files currently.
  2. With our own scripts. DXImage database is running on Microsoft SQL Server Embedded, in a database called VIPER. We created a script that essentially backs up the VIPER database each night to a file, then copies that file to the NAS. The two main lines of this script are:
    osql -S SERVER2\VIPER -E -i SqlFullBackup.sql
    copy /Y /Z /V *.* X:\backup\
    where SqlFullBackup.sql is as follows:
    BACKUP LOG MASTER WITH TRUNCATE_ONLY
    BACKUP LOG MODEL WITH TRUNCATE_ONLY
    BACKUP LOG MSDB WITH TRUNCATE_ONLY
    BACKUP LOG VIPER WITH TRUNCATE_ONLY
    BACKUP DATABASE MASTER TO DISK =’C:\backup\MASTER-nightly-backup.bak’
    BACKUP DATABASE MODEL TO DISK =’C:\backup\MODEL-nightly-backup.bak’
    BACKUP DATABASE MSDB TO DISK =’C:\backup\MSDB-nightly-backup.bak’
    BACKUP DATABASE VIPER TO DISK =’C:\backup\VIPER-nightly-backup.bak’
    We then backup the entire contents of this c:\backup directory to the NAS.
We have not had the opportunity to test the restore procedure for this backup method. However, I feel fairly confident that, by backing up in two methods, we will be covered should disaster strike our poor little DXImage database. I particularly trust the second method, as it does not rely on having to contact Dentrix Image Support at all.