Fix QuickBooks Database Server Manager After a Windows Update

After a Windows update, QuickBooks multi-user mode fails with H202 errors that look like data corruption; we tell the two apart and restore access.

After a Windows feature update, workstations often lose access to the company file. QuickBooks reports H202 or a -6000 series code, everyone suspects corruption, and someone reaches for the Rebuild tool. Our engineers treat these incidents as hosting faults first. The file itself is usually intact, and a service restart plus a rescan brings multi-user mode back.

Why does a Windows feature update break multi-user mode?

Multi-user access rests on two Windows services. The database service is named QuickBooksDB plus a two-digit number tied to your version, and QBCFMonitorService helps workstations find the host. A feature update can stop either service, reset its startup type, or switch the network profile to Public. Any one of those changes cuts workstations off from the host. The error then surfaces on the workstation, which is why the file gets blamed.

Restart the hosting services

1. Sign in to the machine that holds the company file as a Windows administrator.
2. Open the Services console from the Run box or the Start menu.
3. Find the QuickBooksDB service for your version. It must be Running, and its startup type must be Automatic. Start it if it is stopped. Restart it even if it shows Running, because a service can run and still be unresponsive after an update.
4. Repeat the checks for QBCFMonitorService.
5. If either service is missing from the list, the update removed it. Reinstall the server components from your QuickBooks installer, then return to this list.

Rescan the folder with Database Server Manager

Stay on the same machine and open QuickBooks Database Server Manager.

1. Open the Scan Folders tab and add the folder that holds your company files, including any subfolder that contains them.
2. Start the scan and let it finish. The scan rewrites the small .nd network descriptor file that sits beside each company file.
3. Read the results and confirm the company file is listed with the right version.

If the file is listed but workstations still fail, delete the .nd file beside the company file and rescan. That file is safe to remove, and Database Server Manager rebuilds it during the scan. Never delete the .tlg file next to it, because that log can hold transactions not yet written to the company file.

Confirm hosting sits on the server and nowhere else

Open QuickBooks on the host and choose File, then Utilities. You should see an option to stop hosting multi-user access, which means hosting is on. If the menu offers to host instead, hosting is off; turn it on there. Check every workstation the opposite way, because only the machine holding the file should host. A workstation that hosts by mistake is a classic H202 trigger.

Also confirm the network is marked Private on the host. A Public profile, which updates sometimes restore, blocks the sharing that multi-user mode depends on.

Is it a hosting fault or real file damage?

The decisive test happens at the console of the host. Open the company file directly on that machine, in single-user mode. If it opens and behaves, the data is fine and the fault is in the hosting layer. Then run Verify from the File menu under Utilities. A clean verify settles the question: no rebuild is warranted.

Corruption announces itself differently. Verify fails, reports go out of balance, or errors appear after the file is open. Hosting faults fail before the file opens: H202, -6123, 0, or a message that the file is already in use. If H202 survives every step above, the host remains the suspect, and our QuickBooks error code repair service covers that layer.

Confirm multi-user mode from a workstation before any rebuild

Prove the fix from a workstation, not from the server.

1. Open the company file from a workstation through the same network path every machine uses.
2. Switch to multi-user mode from the File menu.
3. Open the file on a second workstation at the same time. Two simultaneous sessions prove the host is serving the file again.

Hold off on Rebuild until all of that passes. Rebuild rewrites the data file, runs long, and answers actual Verify failures, not connection errors. Run it only from a fresh backup, and only when Verify flags damage on a host that serves properly. If Verify still fails at that point, our QuickBooks Verify and Rebuild repair service takes over from there. Our engineers fix the host first and judge the data last, because that order settles these incidents without touching a healthy file.