Passing Live QuickBooks COM Objects Between PowerShell Sessions

When a legacy plug-in stops working on newer versions of Windows, the natural replacement is a script that talks to QuickBooks through its COM-based request processor. That swap works — until you need to keep a single session open across multiple calls.

The Problem

A third-party application previously communicated with QuickBooks through a plug-in that instantiated the QuickBooks request processor object, opened a connection, began a session, and then processed any number of requests before closing the connection. The session ticket issued by QuickBooks remained valid for the duration, so the application could fire off request after request without reconnecting.

The plug-in broke on recent Windows builds, so the user replaced it with PowerShell scripts launched from the command line. Each script instantiates the COM object, opens a connection, begins a session, sends a single request, ends the session, and closes the connection. PowerShell then exits, and the COM object is destroyed.

The bottleneck is architectural: every command-line invocation creates a fresh process, and when that process terminates, the live COM object dies with it. The session ticket cannot be serialized to disk and rehydrated later — it is tied to the in-memory object that no longer exists. The result is that the application can only send one request per launch, with a full connect-disconnect cycle each time.

What the Community Found

The accepted answer points to a technique that works for other COM automation targets: grabbing an already-running instance instead of creating a new one. The approach uses a runtime helper method designed to retrieve a live object registered in the running object table.

The pattern is straightforward. The script attempts to attach to an active instance of the QuickBooks request processor. If one is found, it reuses it. If not, it creates a new instance, opens the connection, and begins a session. In theory, subsequent script launches could call the same logic, find the running object, and skip the instantiation step.

The Catch

The community answer includes an important caveat: this only works if the application exposing the COM object has registered itself as an automation server. The QuickBooks request processor may not do this. If it does not appear in the running object table, there is nothing for the helper method to find, and every script launch is back to square one — a fresh object, a fresh connection, and a fresh session.

One suggestion is to manually register the relevant component using the Windows registration utility. Locating the right file means searching the QuickBooks installation directory for the component that exposes the request processor. Whether this actually causes the object to register itself in the running object table at runtime is not confirmed.

The Workable Alternative

A follow-up response offers a more reliable architecture: stop trying to share a live COM object across separate processes and instead use interprocess communication.

The idea is to split the workflow into two roles. A persistent script launches once, creates the COM object, opens the connection, begins a session, and then idles — waiting for incoming requests. Subsequent scripts do not touch QuickBooks directly. Instead, they send their requests to the waiting script over a named pipe, and that script forwards them to QuickBooks through the still-open connection.

This sidesteps the registration problem entirely. The COM object lives in a single long-running process, so there is no need to retrieve a shared instance from the operating system. The session ticket stays valid because the connection never drops. Named pipes are a well-established Windows mechanism, and PowerShell examples for setting up this kind of channel are available.

The Takeaway

For users building QuickBooks integrations on modern Windows, the lesson is that COM objects do not survive the death of their host process, and session tickets are not portable tokens. The cleanest path is not to fight that limitation but to design around it — keeping a single process alive and routing requests to it through an IPC channel. That preserves the multi-request session model the old plug-in provided, without depending on runtime behavior that QuickBooks may not support.