Dentrix, Eaglesoft and Open Dental: The Server Requirements Your MSP Must Know

Most managed IT providers meet dental practice management software after the contract is signed. That’s the wrong order. These aren’t ordinary line of business applications with a SQL back end and a VSS writer, and the assumptions that work fine in an accounting firm or a law office fail here in ways that stay invisible until somebody actually needs a restore. Nobody notices. Then somebody does.

What follows comes from current vendor documents rather than forum lore. Henry Schein One published the Dentrix System Requirements 2026 in April 2026. Patterson Dental’s Eaglesoft and CAESY hardware requirements carry revision 035, dated 27 March 2026. Both are current. Both are public. And they disagree with each other on the fundamentals, which is the actual story here.

What Are the Server Requirements for Dentrix, Eaglesoft and Open Dental?

Dental practice management server requirements are the vendor-published minimum specifications for the machine holding the patient database, covering operating system, memory, processor, storage and network. Each of the 3 major platforms publishes its own. They aren’t interchangeable. A build that satisfies one can be explicitly unsupported on another.

Here’s the whole comparison in one place, pulled from the current vendor documents.

Compiled from the Dentrix System Requirements 2026, the Patterson Eaglesoft and CAESY hardware requirements revision 035, and the Open Dental computer requirements page. Figures are vendor minimums, not our build recommendations.

Read the virtual machine row again. One vendor tests on hypervisors and says so in print. Another says the use of a virtual machine to run any Patterson Companies software is not supported, and offers no qualification at all. Run a dental portfolio, quietly standardize on a virtualized host because that’s how every other vertical works, and you now have an unsupported production system sitting in at least one practice. You find out during an outage. Never before one. That’s how it goes.

None of These Platforms Runs on Microsoft SQL Server

This is the single fact that breaks the most managed IT playbooks. Your standard toolkit assumes a Microsoft SQL Server instance, a VSS writer and a backup agent that knows how to quiesce it. Dental software gives you none of that. Not one piece.

Dentrix ports are the firewall and antivirus exclusions listed in the Dentrix backup recommendations. Open Dental port and engine per the Open Dental MariaDB page. Romexis database support per Planmeca system requirements.

That last row is the part people miss. A practice running Planmeca Romexis for imaging genuinely does have a Microsoft SQL Server instance on the network, which means the SQL-aware backup agent your provider installed is probably working perfectly. It’s protecting the radiographs. Meanwhile the patient record, the ledger, the treatment plans and the perio charting all sit in a different engine the agent doesn’t understand at all. Wrong database. Right agent.

Open Dental adds a wrinkle worth naming. It needs the myISAM storage engine rather than InnoDB, and Open Dental states plainly that MariaDB must be installed using the myISAM default engine. myISAM carries no transaction log and no crash-safe recovery, so a copy taken while the service runs isn’t a consistent copy at all. It’s a set of files caught mid-write. Nothing warns you. MySQL’s own manual is direct about it, noting that with myisamchk you must make sure that the server does not use the tables at the same time.

Where the Published Requirements Contradict Each Other

These aren’t edge cases. Each one is a design decision a competent provider makes once, applies to every client, and then discovers doesn’t survive contact with a dental office.

That WAN line deserves a moment. A 2 location practice wanting one shared schedule is the most ordinary request in dental IT, and the Eaglesoft documentation tells you to call a Patterson software technology specialist rather than build it yourself. We disagree with that position on the engineering. We follow it anyway. Being right about the architecture is worth very little when the vendor declines to support the practice at 7am on a Monday.

Why Your Dental Backup Is Probably Backing Up Nothing

Here’s where the money is. Every one of these platforms holds its database open, and every one of them defeats a naive file-level or image-level backup in a different way. The job still runs. It still reports success. Restoring is the part that fails.

Henry Schein One says it plainly in the Dentrix backup recommendations. Their database server locks its database even when Dentrix isn’t open on any computer on the network, because the DentrixACEServer service is always running. So a usable copy needs a scheduled export through the Dentrix Server Administration Utility, which writes into a folder called DBCopyForBackup. Your backup software points at that folder. Never at the live database.

Eaglesoft engine stop and start procedure per the Patterson support article on the database server engine. Open Dental method per the Open Dental manual backup instructions, which state that manual backups should only be done on myISAM databases.

That Dentrix failure mode is the nastiest of the 3, and it deserves spelling out. If the scheduled export gets disabled, or the utility quietly stops running after an upgrade, your backup software keeps copying the DBCopyForBackup folder every single night without complaint. Green dashboard. Successful job. Correct file size. Contents never change. A practice can sit on an 8 month old copy of its patient database for as long as nobody tries to restore it.

Retention makes the stakes worse in Texas than most people realize. Under Texas Administrative Code Title 22, Section 108.8, a dentist keeps a patient record for at least 5 years from the last treatment, and for a patient who was a minor at that visit the clock runs until they turn 21 or 5 years pass, whichever is longer. Do the arithmetic. A 4 year old seen today produces a record you’re still responsible for in 2043. No server you buy this year will still be running then, which is the whole argument for treating dental backup as a data lifecycle problem rather than a nightly job. Our data backup services page covers how that gets structured.

The Antivirus, Firewall and Port Conflicts Nobody Warns You About

Every managed IT provider ships a standard security stack. In dental, that standard stack is where the tickets come from, because 2 of the 3 vendors publish explicit exclusions and 1 of them names products by brand, which is unusual enough in vendor documentation that it tells you how often the conflict has come up.

• McAfee VirusScan is listed as not compatible with Eaglesoft. Patterson also does not recommend AVG Free, Webroot or Avast, and states that Windows Defender is supported.
• Patterson does not recommend third-party firewall software and points to Windows Defender Firewall instead.
• Dentrix needs 6600 UDP and 6602 through 6605 TCP excluded from the firewall and antivirus configuration, and the Dentrix program directory excluded from scanning.
• Open Dental needs port 3306 open between workstations and the server for MySQL or MariaDB.
• Windows 10 and Windows 11 cap file share connections at 20 simultaneous sessions, which Open Dental documents as a real ceiling on peer to peer setups.
• Dentrix asks you to disable power management on the network interface cards to avoid disconnect errors on machines left idle.

None of that is exotic. All of it gets missed. Usually the person building the server has never opened the vendor requirements document, and is working from a template that served 40 other clients perfectly well and will keep doing so everywhere except here. A dental office is where the template stops working.

There’s a scheduling trap sitting on top of all this. Patterson notes that on Windows Server 2019, 2022 and 2025, scheduled tasks fail to start and stop the Eaglesoft database. That’s precisely the mechanism the documented backup procedure depends on, so a modern operating system and the documented backup method end up in tension on the same page of the same document. Somebody has to test that the pair actually fires. Don’t assume.

Two Deadlines Already on the Clock

Both of these sit in the vendor and platform documentation right now. Both carry budget consequences for a practice running aging hardware.

Windows 10 install cutoff per the Dentrix System Requirements 2026. Server 2016 dates per the Microsoft lifecycle policy.

That second one is sneakier. Every vendor here still lists Windows Server 2016 as supported, so a practice reading the requirements document concludes it’s fine. Their software vendor is telling the truth. Microsoft is the one turning off the security updates, and after 12 January 2027 a HIPAA risk analysis that finds an unpatched server holding the patient database isn’t going to end well for anybody.

What to Ask Before Anyone Touches the Server

Give this list to whoever supports you now. Their answers tell you more than a proposal will.

1. Which database engine does our practice management software use, and is it Microsoft SQL Server? If the answer is yes for Dentrix, Eaglesoft or Open Dental, stop there.
2. Show me the vendor requirements document you built this server from, and its revision date.
3. Is our server virtualized, and does our software vendor support that in writing?
4. What exact mechanism produces a consistent copy of the database each night, and where does that copy land?
5. When did you last restore that copy and open the practice management software against it?
6. Which antivirus and firewall exclusions from the vendor documentation are actually in place on this server?
7. Is the imaging database in the backup job, or was it excluded because of size?

Question 5 is the one that matters. Everything else is documentation. A restore somebody has actually performed is evidence, and in our experience the gap between practices that have tested a restore and practices that assume theirs works is the widest gap in dental IT. Watch how your provider reacts to question 5. Defensiveness is an answer.

One fair caveat on all of this. Cloud platforms change the shape of the problem rather than removing it. A practice on Curve Dental, which asks for 10 Mbps down and 5 Mbps up for an office of 1 to 10 users and doesn’t recommend satellite or wireless service, has no database server to back up and no engine to quiesce. It has also turned its internet circuit into a single point of failure for the whole schedule. That’s a better problem. It’s still a problem. Buy the second circuit.

Server Questions Dental Practices Ask Us

Can I run Dentrix and Eaglesoft on the same virtual host?

Does Dentrix need Microsoft SQL Server installed?

How much RAM does a dental server actually need?

Is a spinning hard drive still acceptable in a dental server?

Our backup says it succeeds every night. Is that enough?

What happens to our server when Windows Server 2016 support ends?

Have a Dental IT Expert Check Your Server

Send us your practice management platform, your server operating system and a screenshot of last night’s backup job. We’ll tell you whether the build matches what your software vendor publishes, whether the backup captures a restorable copy, and what it would cost to close the gap. Often the answer is that your setup is fine and needs 2 changes. We’d rather say that than sell you a rebuild you don’t need.

For the wider picture, our IT support for dental practices in Houston page covers what a dental engagement includes, the per operatory cost breakdown shows what it costs from 3 chairs to 12, and our HIPAA compliant IT services page covers the compliance layer sitting on top. Still choosing a provider? We published a ranked comparison of Houston dental IT providers that names the dental-only firms worth a call.