Dental Software and Imaging Support in Charlotte: What Breaks, Which Layer Failed, and What to Send Before You Call

The imaging vendor says the software is fine. The IT company says the computer is fine. Charlotte practice owners hear both on the same morning, usually while a hygiene patient waits, and both can be telling the truth.

A typical version of that morning: 8:10 AM, a sensor that captured fine yesterday reads "not detected", and the only overnight change was a Windows update nobody scheduled. The front desk is on hold with the vendor while the IT company's line rolls to voicemail.

What follows is for the owner of a four-to-ten-operatory Charlotte office living through it: the layer behind each symptom, the checks worth ten minutes, the facts to hand your IT provider so the ticket is not bounced back, the order to restart the server closet after an outage, and the questions for any provider bidding on this work.

Which company owns a dental software or imaging problem in Charlotte, and what counts as support?

Two companies share the job: the practice management or imaging vendor owns its application; your IT provider owns the Windows workstation and drivers, the server and database, the network, backups and Microsoft 365, and should own the diagnosis and the vendor call when a sensor stops capturing. The full who-fixes-what matrix is in dental software support vs IT support; this page stays on which layer failed in a Charlotte practice.

Legend Networking explains how that vendor hand-off is handled, platform by platform, on its national dental software and imaging support page, and the city-level commercial detail sits on the Charlotte dental IT services page. From here on, the article sticks to the practical question: which layer failed, and who fixes it.

The table below is the split to keep in your head. Every product named on this page is named because you might run it; nothing here is a claim about any vendor.

What breaks, and who fixes it?

For each system a Charlotte practice is likely to run, the table names the symptom in your words, the layer that most often failed, the first thing to check before you call anyone, and the question that sorts a capable provider from one who will bounce the ticket back to the vendor.

Two patterns run through every row. When the trouble starts the morning after an update, look at drivers and the patch process before you suspect hardware. When it shows up in one operatory but not the next, the workstation or the cabling is the suspect, not the program. If your current provider meets both with "call the vendor", nobody owns the hand-off between driver and application.

What should be in hand before you phone your IT provider?

A ticket that arrives with the facts below is worked; one that arrives as "the sensor is broken" is triaged, and triage is where the morning goes. Before you dial, take five minutes and gather the following. Most of it is on the screen in front of you.

• • [ ] Which operatory and which workstation. The name on the computer's label or the sticker your provider put on it.
• • [ ] Just this computer, or every computer? Walk to a second room and try the same action.
• • [ ] The exact message, photographed. A phone photo of the error dialog beats a description.
• • [ ] What changed since it last worked. A Windows update prompt, a new sensor, a moved cable, a vendor upgrade, a power event overnight.
• • [ ] The product and version. Help > About in the practice management or imaging program.
• • [ ] The patient-safe timing. Whether a patient is in the chair now, and when the next imaging appointment is.
• • [ ] What you already tried. A reboot, a different USB port, a different room.
• • [ ] The vendor ticket number, if you opened one. So the two companies can talk to each other rather than through you.

Keep this list taped near the front desk. It is the single cheapest thing a practice can do to shorten a software ticket.

Why did the sensor stop working after an update?

Because an intraoral sensor is not one device but three things that must agree: the sensor hardware, a driver that Windows loads, and a capture interface the imaging program calls. An operating system update, a USB power setting or a driver mismatch between two workstations breaks the agreement, and the imaging program reports it as "not detected".

The failure modes repeat often enough to list.

The driver did not survive the update. Windows feature updates and some cumulative updates replace or disable third-party drivers. The morning after, the device is present in Windows but the imaging program's capture source is gone. The fix is a reinstall of the sensor driver and a check that the TWAIN or vendor source is selected again inside the imaging program. The prevention is a patch process in which imaging workstations are updated on a schedule and the sensor is tested before the first patient.

USB power management turned the port off. Windows can suspend a USB port to save power. A sensor plugged into that port works until the computer idles, then disappears. The check is the power-management setting on each USB root hub on the acquisition workstation; the prevention is a workstation build that disables it for imaging machines.

The hub is the problem. Sensors want a direct connection to a controller on the computer, not a shared hub under the monitor. A hub that also powers a camera and a keyboard will drop the sensor under load. Plug the sensor into the back panel of the workstation and leave it there.

Different driver versions in different rooms. A sensor that travels between operatories meets a different driver in each. It works where the driver matches and fails where it does not. The check is the driver version on every workstation; the prevention is identical builds, or one sensor per room.

The wrong TWAIN source during a full-mouth series. Imaging programs let the operator pick a capture source. If a workstation has more than one source registered (an old sensor, an intraoral camera, a scanner), the program may default to the wrong one halfway through a series. Clearing retired sources from each workstation removes the choice.

The cable. A sensor cable is the most-handled component in the operatory. Wear shows first as intermittent detection, then as no detection. A cable that is kinked at the sensor end is a replacement, not a troubleshooting job.

None of these is cured by the imaging vendor, and none is cured by buying a different sensor. They are workstation and process problems, which is why a provider who tests imaging after every update is worth more than a provider who answers the phone politely.

Which Windows version and server does your software need?

If a Charlotte office keeps one date on file, it is Microsoft's: "Windows 10 will reach end of support on October 14, 2025. The current version, 22H2, will be the final version of Windows 10". A Windows 10 machine still in use is exposed now and stranded by the next vendor release built for Windows 11.

Vendor requirement pages are the only honest source for what each application needs, and they should be read for your exact version rather than quoted from memory. Open Dental publishes its computer requirements openly. For workstations it names "Windows 11"; for servers, "Windows Server 2025," "Windows Server 2022," "Windows Server 2019," and "Windows Server 2016". It adds that "the server can run Linux or MacOS-X", and states that "All of your machines do not have to have the same operating system." On memory it says "4 - 8 GB is recommended." and that "The server or computer where MySQL/MariaDB is installed may need more memory, especially if using InnoDB." On storage it gives "Typical server installation needed: 1 - 2GB + database size + A to Z folder" — and because that A to Z folder holds the images and documents, an Open Dental server fills up long before its database is large. On connectivity: "you should be connected to a high speed internet connection. Consider this a requirement".

Dentrix and Eaglesoft publish their requirements through their own support channels, and this article quotes only requirement pages that are openly published, so no figures are given for either here. Ask your vendor representative for the current requirement sheet for the version you run, and give it to your IT provider. Anything else, including numbers quoted on other websites, is secondhand.

The practical questions, whichever platform you run:

1. 1. Which Windows version is on every workstation today, and when does each move? Imaging acquisition workstations first, because they are the ones a vendor update will strand.
2. 1. Which server operating system, and is it still in Microsoft support? A server past its support date is patched by nobody.
3. 1. Is the server sized for the database and the images together? Images outgrow the database year after year; add a cone beam, and a server sized only for the PMS runs out of room within a few years.
4. 1. Who installs vendor upgrades, and who tests imaging afterward? The upgrade is the vendor's; the test is the IT provider's.

The server, workstation and lifecycle side of this is the subject of Legend's dental office server and workstation setup page; the questions above are what to bring to that conversation.

Cloud, on-premise or hybrid: what changes for a Charlotte practice?

The cloud changes who looks after the server, not whether one exists. On-premise, it sits in your Charlotte suite and your IT provider owns its patching, storage and backups. Cloud practice management moves it to the vendor's data center. Hybrid runs the PMS in the cloud and keeps imaging local, the arrangement any office with 3D imaging should plan around.

The neutral version of the trade-off, stated without a recommendation:

Three points matter more than the rest for an owner deciding this in Charlotte.

Cone beam volumes are large, and the capture happens in the room. Whatever the practice management decision, the CBCT acquisition workstation, its software and the storage the volumes land on stay in your office. Capture software runs on a workstation in the room and writes to storage that workstation can reach, which is why most practices that move the PMS to the cloud keep an imaging server, and why "we moved to the cloud" rarely means the server closet is empty.

The export terms decide how hard it is to leave. With the database on your own server, a future vendor's migration team can read it directly and run as many refreshes as the cutover needs. Some cloud platforms provide a single export at the end of the contract. Before you sign, ask in writing how you get your complete data, including images, in a standard format, and how many times.

Your internet circuit becomes clinical infrastructure. On a cloud PMS, the circuit that was good enough for email now carries every chart. A second circuit, a firewall that fails over between them, and a plan for what the front desk does during an outage are design items, not extras. Circuit sizing and failover get their own treatment in the Charlotte dental office network support article.

Legend's cloud solutions for dental practices page covers the hosting side, and Legend's Open Dental IT support page is the reference for an office that runs the one major platform with openly published requirements. This article does not recommend a platform and does not compare them; a practice choosing software has a different question from a practice keeping its software running.

What happens to the imaging server when the power goes out in Charlotte?

Outages rarely damage a server; restarts in the wrong order do. Workstations boot before the server, imaging programs look for a database that is not listening yet, and a sensor on a machine that came up before its driver loaded stays "not detected" all morning. The fix is a written order taped inside the server closet door.

Powering down, if you have warning or the UPS is beeping:

1. 1. Close the practice management and imaging programs on every workstation, so open database connections end cleanly.
2. 1. Shut down workstations, acquisition PCs last, because they may be mid-write to the image store.
3. 1. Shut down the imaging server if it is separate from the PMS server.
4. 1. Shut down the PMS server last. It holds the database every other machine depends on.
5. 1. Leave the firewall, switches and internet modem on the UPS until it exhausts; they draw little and come back on their own.

Powering up, after the utility is stable:

1. 1. Firewall and modem first, then switches. Wait until the link lights settle.
2. 1. The PMS server. Wait for it to finish booting; the database service starts after the operating system, and a workstation that connects too early will error.
3. 1. The imaging server, if separate.
4. 1. Workstations, acquisition PCs last.
5. 1. Re-detect each sensor by opening the imaging program on its workstation and taking one test capture before the first patient. Do the same for the CBCT acquisition workstation.
6. 1. Check the overnight backup. If the outage spanned the backup window, the backup may have failed or be incomplete, and the next one needs to be confirmed rather than assumed.

Two questions decide how much of this you ever have to do. The first is UPS runtime: how many minutes does your server's battery give you, and is it enough for a clean shutdown, automatically, when nobody is in the building? Ask your provider for the number for your server, measured, not read from a box. The second is restore time: when was the last test restore of the database and the image folder, and how long did it take? A backup that has never been restored is a hope. What a tested backup actually looks like is laid out on two Legend pages: dental backup and disaster recovery services and, in more depth, the longer dental data backup and recovery guide.

For the regional picture (how outages tend to run around Charlotte, how big a UPS to buy, how a second circuit takes over) see the Charlotte dental IT guide. The point for this page is narrower: the imaging server is the machine most likely to come back wrong, and the order above is how it comes back right.

Is Microsoft 365 set up the way a dental office needs?

Microsoft 365 is part of the clinical stack in most Charlotte practices, because email carries referrals, lab correspondence, insurance documents and, too often, radiographs. It belongs under the same ownership as the server: one named administrator, multi-factor authentication on every account as part of the practice's technical safeguards, and a documented process for staff who join and leave.

The questions an owner should be able to answer, or get answered by a provider in one call:

• • Who holds global admin on the tenant, and is it a named person with MFA? If the answer is "the company that set it up three years ago", the tenant has no owner.
• • Is MFA enforced for every account, including shared mailboxes and the doctor's? Multi-factor authentication is an access-control safeguard; a single exception is where the phishing email lands.
• • What happens to a mailbox when someone leaves? The account is disabled the same day, mail is forwarded or archived, and the login is removed from every portal the person used. Ask to see the checklist.
• • Does anyone email radiographs as plain attachments? If so, the practice needs a secure transfer route for referrals and labs, and staff need to know it exists.
• • Is the tenant tied to the same provider that manages the server? Separate owners for identity and infrastructure is how a locked-out front desk and a locked-out server happen on the same morning.
• • Is 365 data backed up outside Microsoft's own retention? Deleted mailboxes and OneDrive files have retention windows; the practice should know what they are and whether anything is kept beyond them.

None of this is legal advice and none of it makes a practice "compliant"; it is the technical-safeguard layer that HIPAA's Security Rule describes, applied to the system most practices forget to include in their IT contract. Legend's cloud solutions and dental cybersecurity services pages cover the identity and email side of a practice's safeguards.

What can Legend show a Charlotte practice?

These are the facts Legend Networking publishes, each one checkable before a Charlotte owner signs anything:

• • 3,500+ practices supported
• • 22+ years in dental IT (since 2004)
• • 4.8 rating · 173 Google reviews
• • In-house engineers; no outsourced first-level triage
• • Ian Lynch — 22 years in dental IT; oversees the NOC, onsite dispatch and client technology roadmaps

On a software ticket, the operating model counts for more than any of those figures. Legend's published hours: Help desk Mon–Fri 7 AM–7 PM CT, Saturday 8 AM–2 PM CT; 24/7 critical/emergency line. Behind that sits 24/7 monitoring, which is a different service from a person answering. Charlotte runs on Eastern time, so the desk is staffed 8 AM–8 PM ET Monday to Friday and 9 AM–3 PM ET on Saturday, and the 8:10 AM sensor failure described at the top of this page lands inside those hours. Any provider you shortlist should be able to separate its monitoring from its staffed desk the same way.

Legend's headquarters is in Dallas, Texas. Its stated coverage model: Onsite dispatch by appointment across served dental markets; remote-first nationwide. What that means for a Charlotte address is a question to put to Legend directly, with the reply on paper, before any contract. Flat monthly plans run $399.99–$1,200 per practice per month, a typical single-location practice is $600–$900 per month all-in, backup protection is from $39.99 per month (storage-dependent), and hardware procurement, major cabling projects and software licensing are quoted separately. For a software and imaging ticket, that last line is the one to read twice: a replacement sensor or a new acquisition workstation is hardware procurement, quoted separately from the monthly plan.

Each platform Legend publishes a page for is linked in the table above. Those pages describe how each product fits into a practice network; the products are yours, and the pages are the reference. Pricing, contracts and the city-level conversation start at dental IT support in Charlotte; for the software and imaging layer across every platform, Legend's national reference is practice management software and imaging IT support.

What should you ask your IT provider?

Ask questions whose answers you can check. The list below assumes you have already had one provider whose answer to every imaging ticket was "call the vendor", and that you want your next sales conversation to get to the point.

• • [ ] When the sensor fails, who calls the imaging vendor, you or my front desk? The answer should be a person and a process, not "we can if needed".
• • [ ] Do you manage sensor drivers and TWAIN sources, and what do you test after Windows updates? Ask for the checklist and the day of the week imaging workstations are patched.
• • [ ] Who owns the imaging server, and is it monitored, backed up and included in the restore test? Then ask the free-space figure today.
• • [ ] When did you last restore our database and image folder, and how long did it take? A date and a duration, or the backup is untested.
• • [ ] What is our server's UPS runtime, measured? And does the server shut itself down cleanly when the building is empty?
• • [ ] Which of our workstations are on Windows 10, and when does each move? Imaging acquisition PCs first.
• • [ ] Who holds global admin on our Microsoft 365 tenant, and is MFA enforced on every account? A name, and a yes.
• • [ ] Is the imaging-to-PMS bridge on your workstation build checklist? If it is not, the next re-imaged computer will save radiographs that never attach.
• • [ ] What are your staffed help desk hours in Eastern time, and what is the path outside them? Separate the monitoring from the people.
• • [ ] Which costs sit inside the monthly fee, and which arrive as separate quotes? Sensors, workstations, cabling and licenses are usually separate; you want it in writing before the first invoice.

Write the answers down and file them. Three months in, they are what you measure the provider against; if you ever switch again, they are your starting record.