Fixing Slow Multi-User QuickBooks After Windows Enables SMB Signing

Multi-user QuickBooks Desktop turns sluggish after Windows updates, and the cause hides in file sharing. We show how to confirm it and get speed back.

A Windows feature update can leave multi-user QuickBooks Desktop feeling broken. Lists crawl, saves stall, and opening the company file takes minutes. Nothing inside QuickBooks changed. Our engineers keep tracing this pattern to one Windows file-sharing default. Here is how to confirm it on your own network, restore the speed you had, and weigh the security trade honestly.

SMB signing is now on by default

Windows 11 24H2 and Windows Server 2025 began requiring SMB signing by default, where earlier versions negotiated it only when a domain asked for it. Signing attaches a cryptographic checksum to every packet, which stops a machine on the wire from altering traffic in flight. That protection has a computational price.

QuickBooks multi-user traffic is the worst case for this. The database layer sends thousands of small reads and writes between each workstation and the host. Every packet pays the checksum cost. A single large file copy pays the tax a few times; a database pays it constantly.

The symptom looks like a QuickBooks fault: slow opens, laggy saves, random stalls. QuickBooks is usually innocent. The slowdown tends to arrive the week the host or the workstations take a feature update.

How do you confirm SMB signing is the cause?

Start with timing. Open Update History on the host and on two workstations, and compare those install dates against the day the lag began. A match points at Windows.

Next, isolate the layers. Open the company file on the host itself, in single-user mode. If it runs at full speed locally but drags from workstations, the network path is the suspect.

Then check the setting directly. On the host, run an elevated PowerShell prompt and read the server side:

Get-SmbServerConfiguration | Select-Object EnableSecuritySignature, RequireSecuritySignature

On a workstation, read the client side:

Get-SmbClientConfiguration | Select-Object EnableSecuritySignature, RequireSecuritySignature

RequireSecuritySignature set to True means signing is enforced on that machine. True on either end forces signing for the whole conversation.

For a definitive answer, flip it off temporarily on the host and one workstation, restart both, and retest. If speed returns, you have your cause. Revert if you later decide the trade is wrong for you.

Rule out the usual suspects before you commit

Other faults mimic this lag. Confirm the QuickBooks Database Manager service runs on the host. Check that antivirus excludes the company file folder and the QuickBooks processes. Prefer wired links over Wi-Fi for workstations. An oversized file drags all by itself; our QuickBooks file optimization service covers that diagnosis and repair. Outright connection refusals carrying H202 codes are a different fault, covered by our QuickBooks error code repair service.

Restoring the speed, step by step

Record the current values first. Screenshot both Get- outputs before changing anything, so you can revert exactly.

On the host, in an elevated PowerShell prompt:

Set-SmbServerConfiguration -RequireSecuritySignature $false -Confirm:$false

On every workstation that opens the file:

Set-SmbClientConfiguration -RequireSecuritySignature $false -Confirm:$false

Restart the Server service on the host and the Workstation service on each client, or simply reboot both ends. Re-run the two Get- commands and expect False on RequireSecuritySignature. Then time a company file open from a workstation and compare it to your baseline.

One caveat matters on domain-joined machines. A group policy named Microsoft network client: Digitally sign communications (always) will re-enable signing at the next refresh and quietly undo your change. Run gpresult to check what applies, and if a policy forces signing, make the change there instead of locally.

What do you give up when you disable SMB signing?

Signing is integrity protection. It stops an attacker positioned on your network from tampering with traffic or relaying credentials between machines. Turning it off removes that guard for any conversation that stops signing. Encryption is a separate mechanism and is unaffected.

The honest framing depends on your LAN. On a switched, wired network behind a firewall, where every device belongs to the office, the practical exposure is small. On shared Wi-Fi, guest networks, or a flat segment carrying untrusted devices, keep signing and absorb the cost.

There are middle paths. Apply the change only to the accounting machines, and leave enforcement on file servers that hold other data. Give the bookkeeping group its own VLAN or switch. If policy or risk requires signing everywhere, a faster host CPU softens the blow, because the checksum work is CPU-bound.

Keeping the fix in place on a frozen install

A discontinued Desktop release will never receive a patch that absorbs this change. That is acceptable here, because the setting lives entirely in Windows and stays under your control.

Windows has changed SMB defaults before, and a future feature update may reset them again. Keep the screenshots, and re-run both Get- commands after every feature update on the host and the workstations. Deferring feature updates for a few weeks, while still taking monthly cumulative updates, keeps you off the bleeding edge without freezing security fixes.