Dental Software and Imaging Support in Denver: What Breaks in Dentrix, Open Dental, Eaglesoft and Your Sensors, and What to Check First

Three things went wrong in your Denver office this month and none of them looked related. Dentrix in operatory 3 opens a chart half as fast since the last update. On Tuesday the sensor stopped capturing halfway through a full-mouth series. After the power blinked in last week's storm, Eaglesoft "lost the server."

Everything below is meant to be read with the fault still on the screen. There is a table for each of the eight systems Denver practices run most, a second table that reads your symptom into a layer, the order in which to turn a server room back on after a Front Range outage, what the Colorado notice statute says in its own words, and the list of things to have in hand before you call anyone.

Why do Denver dental offices search "dental software problems" and reach a sales page?

Denver owners search "dental software problems denver" with a fault in front of them, and the results are mostly sales pages and vendor comparisons, because few pages are written for the fault itself; this page is. Legend's national practice-management software and imaging support page describes the service; this article stays on the fault.

The search phrase is a tell. "Problems," not "best" or "versus." The person typing it already owns a platform; they want to know whether the slow chart, the dead sensor or the lost server is their problem, their IT provider's problem or the vendor's, and in what order to try things. A comparison of Eaglesoft against Dentrix for a six-location group is not that answer, and neither is a page that lists logos.

The honest frame for the fault moment is the stack. Every practice-management and imaging system in a Denver office runs across the same six layers, and each layer has a different owner:

• • The acquisition workstation in the operatory: Windows, memory, disk, antivirus, the imaging client, the practice-management client.
• • USB, hubs and drivers between that workstation and the sensor, the pan or the CBCT console.
• • The network path from the workstation through the switch to the server, and out through the firewall for anything cloud-hosted.
• • The server where the practice-management database and, usually, the image archive live, including its operating system, its services and its storage.
• • The vendor's application: the database engine, the bridge between the practice-management system and the imaging software, licensing, and version compatibility between client and server.
• • Power: the UPS, the outlet the sensor's workstation is on, and the order in which everything came back up after an outage.

Your IT provider owns the first four and the sixth. The vendor owns the fifth, with your IT provider usually on the call because the vendor will ask about the other five. This article is about telling them apart. For the wider picture of running a practice's technology in the metro, our Denver dental IT guide covers plans, pricing, continuity and phones; the commercial detail sits on Legend's Denver dental IT page.

What breaks, why, and what to check first, by system

Each practice-management and imaging product fails in its own characteristic way, and most of those failures live in the workstation, the network, the server or the power layer rather than in the product. The table below gives the usual fault, the usual reason, the first thing to check, and the question that gets a useful answer from whoever you call.

The products named here are yours, the systems a Denver practice is likely to be running. Each row links to the page on this site that describes support for that product, so the product-specific depth lives there and not here. What the table does not do is tell you which product to buy; that is a different page for a different moment.

Notice the right-hand column: five of the eight questions are about storage and backups, not the application. That is where imaging support actually lives, and it is why the server and restore sections below are not optional reading. A vendor support contract covers the application; your IT plan covers everything the application sits on. Keep the two apart when you call and you reach a fix faster.

If you are choosing a platform for a new Denver office rather than keeping an existing one running, that decision belongs on a different page: dental startup IT for Denver practices handles platform selection and build timing, and the product pages above describe each system's support.

Is it the software, the server or the network?

Read the fault into a layer before you touch anything. One slow room points at that room's workstation, cable or port. Every room failing together points at the server, the switch or power. A sensor that is "not detected" points at USB and drivers. Only when those are ruled out does the vendor's application become the suspect.

The order matters because rebooting the wrong thing destroys evidence. A server rebooted before anyone looked at its services comes back with the same service failing and no log of why. A workstation reinstalled because the sensor was not detected still has the same sensor, hub and Windows update. Triage is cheap; a reinstall during clinic hours is not.

The sequence that works, in the order a competent engineer would ask the questions:

1. 1. One room or every room? One room is that room's workstation, drop, port or USB. Every room is the server, the switch, the firewall or power.
2. 1. Local only, cloud only, or both? If the on-premises practice-management system works but cloud imaging, e-claims and email are dead, the fault is the circuit or the firewall. If the reverse, it is the server or the switch.
3. 1. Did Windows update, did the vendor update, or did the power go out since it last worked? Each one has its own layer. An update to the operating system is the workstation layer; a vendor update that moved the server but not the clients is the application layer; a power event is the power layer and the server layer together.
4. 1. Does the device appear in the imaging software's own device list? If not, the fault is below the application: USB, driver, power to the hub. If yes and the capture fails, the application is in play.
5. 1. Does the failing workstation reach the server by name and by address? Name fails and address works: name resolution. Both fail: the drop, the port or the server itself.

Then the table.

A fault that will not settle into one row is itself a finding; it usually means two layers failed together, which is common after a power event. Network layout, cabling and switch questions are the subject of Legend's dental office network design page; server and workstation specification is on the workstation and server service page. This article points at them rather than repeating them.

What to gather before you phone your IT provider

The fastest tickets are the ones that arrive with evidence. Before you pick up the phone, gather as much of this as you can without taking a room out of service:

• • The exact message on screen, photographed, including any error code or path. "It says can't connect" and "it says cannot connect to server DENTAL-SRV" are different tickets.
• • Which rooms are affected and which are not. One line: "Ops 1, 2 and 4 fine; op 3 slow since Monday."
• • The most recent change: Windows or the vendor pushing an update, a sensor swapped in, a workstation relocated, a storm or an outage. The date if you have it.
• • Whether the device shows in the imaging software's own device list. Yes or no.
• • The name of the workstation (on a label or in the system settings) and the name of the server as the clients see it.
• • Whether the UPS alarmed and whether the server was shut down cleanly or simply went dark.
• • Any case number the vendor gave you, plus whatever they told you to look at, if that call has already happened.
• • The last known-good time: "worked at 4:30 PM Friday, failed at 7:10 AM Monday."
• • Who is in the chair. If a patient is waiting on the capture, say so first; it changes the order of work.

That list is also the first half of what the vendor will ask, so it serves both calls.

Local server, cloud or hybrid: what does imaging decide in a Denver practice?

For most Denver practices the imaging archive decides the architecture. A practice-management system can move to a vendor-hosted service; a CBCT archive usually stays on a local server because the volumes are large and the viewer needs them fast. The common result is hybrid: cloud practice management, local imaging, with the network and backups designed for both.

Start from your own data rather than from a sales deck. Open the imaging archive's folder properties and read the size; then read last month's size if anyone recorded it. A practice with intraoral sensors and a pan produces a modest archive that grows slowly. A practice with a CBCT produces an archive that grows in steps every time the unit is used, and the viewer in the consult room needs each volume quickly, not after a download. That difference, measured in your own gigabytes per month, is the architecture decision, and it is why "cloud or server" is the wrong question for a practice with a 3D unit; the practical question is which parts go where.

The one vendor requirements document opened for this article is Open Dental's. On operating systems it is relaxed: "All of your machines do not have to have the same operating system. If you are purchasing new equipment, we recommend the newest version of the Windows operating system." Its workstation line names Windows 11 and its server line names Windows Server 2025, 2022, 2019 and 2016; it recommends "4 - 8 GB" of memory with the note that "Optimum performance is 8 GB," says of the processor "The newer and faster, the better," states that "SSD or NVMe hard drives are recommended, but not required," and adds that "An uninterruptible power supply (i.e., a backup battery) is optional but recommended." Its storage line is the useful one for the architecture question: "Typical server installation needed: 1 - 2GB + database size + A to Z folder." Of those three terms, only the A to Z folder, where documents and images attach, grows quickly; the database stays small.

Dentrix and Eaglesoft publish their own requirements documents, and this article does not quote them because they were not opened for it. Ask your IT provider for the current version of each vendor's requirements document before any server is specified, and ask specifically what each vendor says about running across a wide-area connection and on a virtual machine, because the answers differ by vendor and they decide whether a given cloud or hosted design is supported at all.

Two vendor-hosted paths exist on the practice-management side for the practice-management products named above: Open Dental's own hosted service and Dentrix Ascend. They are named here as options the reader can ask about, not priced, because their price pages were not opened for this article and a figure quoted second-hand is not a figure.

The practical shapes, from your data outward:

• • All local. Practice-management database, image archive and documents on one server in the office. Simplest to troubleshoot, most exposed to a power event and to a server that is never replaced. The backup and restore test carry everything.
• • Hybrid. Practice management vendor-hosted; imaging and CBCT on a local server. The internet circuit becomes the thing the schedule depends on, so failover matters; the local server is smaller but still needs the UPS, the backup set and the restore test, because the volumes live on it.
• • All hosted. Everything with vendors or in a hosted environment. Rare for a practice with a CBCT, for the storage and viewer reasons above; where it works, the circuit and the firewall are the whole stack.

Whichever shape you land on, two Microsoft dates set the clock on the hardware under it. On the desktop side, Microsoft's lifecycle entry reads: "Windows 10 will reach end of support on October 14, 2025." Server editions run on longer extended-support clocks: January 13, 2027 for Windows Server 2016 (the lifecycle page writes it 1/13/2027) and January 10, 2029 for Windows Server 2019. A Denver practice whose server runs Server 2016 has a replacement or upgrade decision this cycle, and that is the moment the local-cloud-hybrid question gets answered for real. Legend's dental cloud solutions page describes the hosted side; the workstation and server service page describes the local side.

What do Front Range power events do to a dental server, and how do you come back up?

A power event hurts a dental server twice: once when it loses power, and again when everything comes back on in the wrong order. The UPS should carry the server to a clean shutdown; afterward, bring up power, then the switch and firewall, then the server, then the imaging server, then acquisition PCs, and only then test a sensor.

Two kinds of Denver event matter most to a server room. Snow is one: across March 13 and 14, 2021, a 27.1-inch total piled up for Denver, which NWS Boulder's storm summary ranks as "the fourth largest storm on record since 1882." The other is the planned shutoff. Xcel now warns of its Front Range public safety power shutoffs in stages, which Colorado Politics laid out in April 2026 (a news report, not Xcel's or the Public Utilities Commission's own document): a stage beginning more than 72 hours ahead, a stage from 72 down to 24 hours, and a last stage from 24 hours to zero, with the final notices landing inside the four hours before the lines go dead. Nobody needs the forecast to be right. What the office needs is one list to work through during that 72-to-24-hour stretch and a second for the morning after.

Before a known shutoff or a snow day (the warning-window list)

1. 1. Confirm the UPS is on the server, the switch, the firewall and the carrier's equipment, and that its automatic shutdown is configured and tested, not just installed.
2. 1. Run a backup now and confirm it completed, including the imaging archive and the CBCT volume folder, wherever those actually live.
3. 1. Export the next two days' schedules and the patient contact list from the practice-management system to something that does not depend on the office.
4. 1. Shut the server down cleanly before the shutoff if the office will be closed anyway. A planned shutdown is the one you want.
5. 1. Note which acquisition PCs hold images locally (CBCT consoles often do) and make sure those are on the backup set.

Coming back up (the morning-after order)

1. 1. Power and UPS. Confirm utility power is stable before the UPS is switched back to load; a UPS that drained fully needs time before it will carry anything.
2. 1. Switch and firewall. The network has to exist before the server tries to find its storage, its name and its time source.
3. 1. Server, and wait. Let the operating system finish, then confirm the services that matter: the practice-management database service, the imaging server service, the shares. Do not open a client yet.
4. 1. Imaging server or imaging workstation, if it is separate from the practice-management server, after the server's shares are reachable.
5. 1. Acquisition PCs, one at a time, confirming each one reaches the server by name.
6. 1. Sensors, pan and CBCT. Power the units, open the acquisition software, confirm the device appears in its device list, and capture one test image to a test patient.
7. 1. Front desk last. Open a chart, open a ledger, open an image. Then check the clock on the server; a server that lost time will produce odd failures all day.

After a Front Range event, "the server did not come back" is often a sequence problem rather than a hardware one: a switch that came up after the server, an imaging workstation that looked for a share before the server had published it, a sensor PC that booted while the hub was still unpowered. The order above is boring on purpose. Two pages cover the backup set and the restore test in depth: the dental backup and disaster recovery service page, and, for the steps on the practice's side, our dental data backup and recovery guide.

What does Colorado's breach-notification law mean for imaging and PMS data?

Section 6-1-716 of the Colorado Revised Statutes ("Notification of security breach") starts a 30-day notice clock when a business determines a breach happened, and draws its own line between encrypted and unencrypted data. For a dental practice, the operational consequence is that the imaging archive and the practice-management database need a tested restore and documented encryption, not a guess.

The statute's own language, as published at colorado.public.law, on the three points that matter to a server room:

• • On what counts, subsection (1)(h): "'Security breach' means the unauthorized acquisition of unencrypted computerized data that compromises the security, confidentiality, or integrity of personal information maintained by a covered entity."
• • On encrypted data, subsection (2)(a.4): "The breach of encrypted or otherwise secured personal information must be disclosed in accordance with this section if the confidential process, encryption key, or other means to decipher the secured information was also acquired in the security breach or was reasonably believed to have been acquired."
• • On timing, subsection (2)(a): "Notice must be made in the most expedient time possible and without unreasonable delay, but not later than thirty days after the date of determination that a security breach occurred," a sentence the statute continues with law-enforcement and scoping qualifiers. Under subsection (2)(f)(I), the state's attorney general must also be told within those thirty days "if the security breach is reasonably believed to have affected five hundred Colorado residents or more, unless the investigation determines that the misuse of information about a Colorado resident has not occurred and is not likely to occur."

That is the statute, not advice; how any of it applies to a specific event, and how it sits alongside federal HIPAA breach-notification rules, is a question for your attorney. What an owner can do before any event is the IT part: know where every copy of the practice-management database and the image archive is, including the CBCT console's local disk and any laptop that has ever held an export; know whether each copy is encrypted at rest and who holds the key; and keep the last successful restore test on file, because a restore test is also the only proof you have of what was in the archive on a given date. Legend's HIPAA compliance support page describes the safeguards side of that work; it describes safeguards and readiness, not a legal status.

Sensors, TWAIN drivers and the full-mouth series that stalls

An intraoral sensor that fails halfway through a full-mouth series is the most time-sensitive fault in the practice, because the patient is in the chair with a holder in their mouth. Nearly every such failure is in the USB-and-driver layer under the imaging software, not in the software itself, and most are preventable with workstation settings.

The chain is short and every link in it fails in a known way. The sensor plugs into a USB port, sometimes through a hub or an extender. Windows loads a driver for it. The imaging software (DEXIS, Carestream, Romexis, Vatech's console, or the practice-management system's own imaging module) reaches that driver either natively or through TWAIN, the generic acquisition interface that lets an application talk to a device it did not ship with. A full-mouth series puts that chain through a long run of captures in a few minutes, which is exactly when a marginal link gives up.

What to have your IT provider set and check on every workstation with a sensor:

• • USB power management. Windows can switch off a USB port to save power, and a sensor mid-series is the first casualty. Selective suspend and the per-hub "allow the computer to turn off this device" setting should be off on acquisition PCs.
• • Direct ports, not hubs. A hub shared with a keyboard, a camera and a card reader is a point of failure; the sensor should have its own port, and if an extender is needed for cable reach, it should be an active one rated for the job.
• • Driver pinning after updates. A Windows update can replace a sensor's driver with a generic one. Acquisition PCs should be on an update ring that is tested, and the driver version should be recorded so that "it changed" is a fact rather than a suspicion.
• • TWAIN source selection. When an application offers a list of acquisition sources, the wrong one selected after an update or a reinstall produces "no device" with a perfectly healthy sensor. Document which source each room uses.
• • One sensor per room where possible. Sensors that travel between operatories accumulate cable damage and get plugged into whichever port is free. If a sensor must travel, it should have the same port and the same driver in each room it visits.
• • Sleep and screen savers. An acquisition PC that sleeps between patients may wake without the sensor. Acquisition PCs should not sleep during clinic hours.
• • The patient opened first. For integrated systems, opening the patient in the practice-management system before capture is what sends the image to the right chart; capturing first and assigning later is how images reach the wrong record.

Pans and CBCT units add one layer: a dedicated acquisition workstation, often with a second network connection to the unit itself. That workstation is a single point of failure with its own update, backup and replacement schedule, and it should be on the server's backup set because the volumes it captures sometimes live nowhere else until pushed to the archive. The product pages for DEXIS, Carestream, Planmeca Romexis and Vatech describe support for each; orthodontic offices running Dolphin have their own page at Dolphin Imaging IT support.

How much does software and imaging support cost in Denver?

Under a flat-rate managed plan, software and imaging faults are normally covered by the monthly fee, not invoiced one incident at a time. Legend's published range is flat monthly plans $399.99–$1,200 per practice per month, with typical single-location practice $600–$900 per month all-in; software licensing is quoted separately, and each vendor's own support contract sits outside both.

Three invoices are worth telling apart, because owners conflate them when a fault lands:

1. 1. The IT plan. Three Legend numbers apply here. The plan itself: flat monthly plans $399.99–$1,200 per practice per month. For an office with one location, the published figure is typical single-location practice $600–$900 per month all-in. For backup, the published starting point is backup protection from $39.99 per month (storage-dependent). Legend also states that hardware procurement, major cabling projects and software licensing are quoted separately. The workstation, USB, network, server and power layers in this article are what an IT plan, as distinct from a vendor contract, is for.
2. 1. The vendor's support contract. Dentrix, Eaglesoft, Open Dental and each imaging vendor sell their own support and update agreements. Those cover the application layer: the database engine, the bridge, version upgrades, licensing. This article quotes no vendor contract price because none of the vendor price pages was opened for it; the figure is on the vendor's own page or your last renewal.
3. 1. Projects. A new server, a re-pull of operatory cabling to 1 Gb, a new acquisition workstation for a CBCT. Quoted on their own, by Legend's published wording, and the moment at which the local-cloud-hybrid decision above gets made.

Hours matter at the fault moment and they should be read in your zone. Legend states: Help desk Mon–Fri 7 AM–7 PM CT, Saturday 8 AM–2 PM CT; 24/7 critical/emergency line. Shifted to Denver's clock, the help desk runs weekdays from 6 AM to 6 PM Mountain and Saturdays from 7 AM to 1 PM Mountain. Legend's monitoring is stated separately: 24/7 monitoring. Legend also states: in-house engineers; no outsourced first-level triage.

Location is a fair question for a Denver owner and it deserves the plain fact. Legend Networking's headquarters is in Dallas, Texas. It has 22+ years in dental IT (since 2004), 3,500+ practices supported, and a 4.8 rating · 173 Google reviews. Its stated model is onsite dispatch by appointment across served dental markets; remote-first nationwide. Before signing, ask what that model means for your address specifically, and have the reply put in writing. The monitoring has a named person behind it: Ian Lynch — 22 years in dental IT; oversees the NOC, onsite dispatch and client technology roadmaps.

This page names no Colorado practice; a project record from Texas or Florida is not evidence about Denver, so this page does not borrow one.

What to ask your IT provider about your software stack

Ask these in writing, and keep the answers with your network documentation. They work on any provider, including the one you have now.

If the provider can answer all eleven from documentation, you are supported. If the answers are mostly "we'd have to check," the software has been getting rebooted, not supported.