LedgerCrossingLedgerCrossing Buy LedgerCrossing — $299

Can You Run the QuickBooks Web Connector as a Windows Service? (No — Here's What To Do Instead)

If you host QuickBooks Desktop on a server and you're trying to make the Web Connector sync without someone staying logged in, you've probably noticed that nobody gives you a straight answer. The question sits unanswered on Intuit's own developer forum. So here it is:

No. The QuickBooks Web Connector cannot run as a Windows service, and no configuration, wrapper, or scheduled task changes that. Below is why, what people try anyway (and how each attempt fails), and the setup that actually works on a server.

Why it's architecturally impossible

Two hard constraints, and you'd need to break both:

1. The Web Connector is an interactive desktop app. It's a .NET WinForms program that lives in the system tray, draws windows, and shows dialogs. Windows services run in an isolated, non-interactive session (session 0) with no desktop. A tray app launched there has nowhere to put its UI and no user context to run in — it either fails to start or hangs invisibly the first time it tries to show anything.

2. QuickBooks Desktop itself is an interactive desktop app. This is the constraint that kills every workaround, because even if you somehow ran the connector headlessly, it connects to QuickBooks through the SDK's COM interface — which needs the QuickBooks application available in a real user session, with the company file open or auto-open configured. There is no headless QuickBooks Desktop. Whatever talks to it needs a logged-in Windows session; that's a property of QuickBooks, and nothing bolted onto the connector can remove it.

What people try, and how each one fails

Task Scheduler with "Run whether user is logged on or not." The task launches, but that option runs the program in a non-interactive session — the same dead end as a service. QBWC starts, can't reach a desktop or a running QuickBooks, and produces nothing but connection errors (typically QBWC1013). With "Run only when user is logged on," it works — but then you're back to requiring a logged-in user, which was the whole problem.

Service wrappers (AlwaysUp, FireDaemon, NSSM). These wrap ordinary programs as services, and they're fine tools for the right job. This isn't the right job. The wrapper can keep QBWebConnector.exe alive as a process, but it can't conjure the interactive QuickBooks session the COM connection needs, and the first modal dialog QuickBooks throws — an update prompt, a company-file message — blocks the whole pipeline invisibly, in a session no one can see. You've traded a connector that fails visibly for one that fails silently. Also unsupported by Intuit, for whatever that's still worth.

A disconnected RDP session. Log in over RDP, start everything, then disconnect (not log off). This one actually half-works, because a disconnected session stays interactive. But it's fragile: Windows Updates reboot the box and nothing comes back up; group policies log off idle sessions; someone logs in to check on things and steals the session. It's the setup most MSPs are running today, and it's why "remote in and restart the Web Connector" is a recurring calendar item.

What actually works on a server

Since the logged-in-session requirement comes from QuickBooks itself, the reliable pattern is to stop fighting the session and make everything inside it unattended-proof:

  1. Dedicate a machine or VM to QuickBooks integrations — not a box people also work on.
  2. Configure automatic logon for a dedicated Windows account (via netplwiz or Sysinternals Autologon, which stores the credential encrypted), then lock the console automatically at logon with a scheduled task. Auto-logon plus immediate lock gives you a live interactive session with no unattended unlocked desktop.
  3. Set QuickBooks to open the company file in that session, and authorize your integrations to connect automatically even when QuickBooks can't prompt (Edit → Preferences → Integrated Applications).
  4. Make sure everything auto-starts — QuickBooks, and whatever connector you use — so a Windows Update reboot heals itself instead of paging you.

Do all four and the setup survives reboots without a human. Which leaves one weak link: the Web Connector is the component in that chain that still dies on its own. It crashes, corrupts its log, misses its polling schedule, and hangs on dialogs — that's its own long story — and it turns an otherwise self-healing setup back into a babysitting job.

LedgerCrossing takes the Web Connector's place in exactly this setup — when the integration is one you control. It's a lightweight system-tray app that runs in that auto-logon session and exposes a local HTTP/qbXML pass-through to QuickBooks Desktop: your integration POSTs qbXML to a local endpoint and gets the response back immediately. No SOAP server, no polling schedule to miss, no QWCLOG to corrupt. (Works with anything that can make a web request; vendor-run apps that sync via the Web Connector can't be repointed at it.)

To be straight about the constraint this page is about: LedgerCrossing runs in the logged-in session too, because — as covered above — anything that talks to QuickBooks Desktop must. The difference is that it's built for unattended operation: it auto-starts with the session, reconnects on its own, doesn't fall over daily, and writes logs you can actually read when something on the QuickBooks side needs attention. Auto-logon server + LedgerCrossing is the "set it up once, stop remoting in every morning" configuration.

Buy LedgerCrossing — $299 →

QuickBooks is a registered trademark of Intuit Inc. LedgerCrossing is an independent product for QuickBooks Desktop and is not affiliated with or endorsed by Intuit.