Dynamics GP Integration Manager Errors: RPC Server, ActiveX

Almost every Integration Manager failure in Dynamics GP traces back to one of four things: a second Dynamics.exe process already holding the connection, a broken COM registration for Dynamics.exe, an eConnect service account that is not in the DYNGRP role, or a source data file that is still open in Excel. The error text tells you which one it is, and each has a documented fix that takes minutes rather than a support case.

Last updated August 2026.

Integration Manager is still how a large number of US Dynamics GP sites load purchase orders, vendors and invoices, and it fails in a small, repeatable set of ways. What makes it frustrating is that the message you see on screen is usually the outer wrapper, not the cause. The line that starts The destination could not be initialized is the wrapper. The part after the colon is the actual problem. This reference maps each message to its verified cause and fix, using Microsoft support documentation rather than forum guesswork.

The Integration Manager error map

Start here. Find the text you actually see, then jump to that section.

Error text	Real cause	First thing to try
RPC server is unavailable	Integration Manager is already connected to Dynamics GP	Exit Integration Manager, reopen it, run again
ActiveX component can't create object	Dynamics GP was not written to the registry correctly	Re-register Dynamics.exe with the /REGSERVER switch
Automation Error Library not registered	Same broken COM registration	Re-register Dynamics.exe, then IM.exe and IMRun.exe
The object invoked has been disconnected from its clients	Same broken COM registration, seen on opening IM	Re-register as the user hitting the error
The stored procedure name doesn't exist	eConnect COM+ account lacks rights on the GP databases	Add that account to DYNGRP on DYNAMICS and every company database
ADO field is nothing	The source data file is still open	Close the spreadsheet or text file, then run the integration

Why does Integration Manager say the RPC server is unavailable?

Because Integration Manager is trying to open a connection to Dynamics GP that it already has. Microsoft documents this as KB 943948, and the cause is stated plainly: Integration Manager tries to connect to Dynamics GP, however Integration Manager is already connected. It is a stale connection problem, not a network or firewall problem, which is why the RPC wording sends so many people down the wrong path.

The documented fix is three steps: exit Integration Manager, start it again, run the integration. When that is not enough, the connection is being held by an orphaned process rather than by the application window you just closed.

Step	Action	Why it matters
1	Exit Integration Manager and exit Dynamics GP	Closing the window does not always end the process
2	Open Task Manager and look at the Processes tab	This is where the orphan shows up
3	End any Dynamics.exe process still listed	That process is what still holds the connection
4	Start Dynamics GP, then start Integration Manager	Order matters, GP has to be up first
5	Run the integration again	A clean connection is established

Two situations make this recur rather than resolve. On Terminal Server or Citrix, more than one active session for the same user gives you a second Dynamics.exe you cannot see from the session you are working in, so check for extra sessions rather than extra windows. Separately, if the error only appears on large batches and never on small ones, it is worth splitting the file, because a size related failure looks identical on screen.

How do I fix cannot create ActiveX component in Integration Manager?

Re-register Dynamics.exe as the user who is getting the error. Microsoft KB 915463 attributes this whole family of automation errors to a single cause: the installation of Dynamics GP was not written to the registry correctly. The fix is to put the registration back, not to reinstall.

The specific key Integration Manager looks for is this one, and it should hold the full path to Dynamics.exe:

HKEY_CLASSES_ROOT\CLSID\{6D016639-BA35-11CF-827E-00001B27AB13}\LocalServer32

You can check it by opening regedit, choosing Find on the Edit menu, searching for 6D016639-BA35-11CF-827E-00001B27AB13 with only the Keys box ticked. If the subkey is there, the LocalServer32 folder shows the Dynamics.exe path. If it is missing, re-registering creates it.

To re-register, sign in as the user receiving the error, then run the executable with the /REGSERVER switch:

"C:\Program Files (x86)\Microsoft Dynamics\GP\Dynamics.exe" /REGSERVER

Note the switch is /REGSERVER. It is frequently reproduced on community blogs as /regsrver, which silently does nothing useful. Most executables show no confirmation when they register, so no message box is not a failure signal. Check the registry key again afterwards to confirm the path was written.

If the automation errors survive that, Microsoft says to re-register two more files the same way, and to do it signed in as the user who will actually run the integration:

"<path>\IM.exe" /REGSERVER
"<path>\IMRun.exe" /REGSERVER

The signed in as detail is the part people skip. COM registration of this kind is per user, so re-registering while signed in as an administrator and then handing the machine back to the clerk who runs the integration reproduces the error immediately.

What does the destination could not be initialized mean?

It means Integration Manager could not start up the destination adapter, so nothing was written to Dynamics GP at all. It is a wrapper message, and on its own it tells you almost nothing. The useful information is the clause after the colon, which is one of the specific causes above.

The practical consequence is good news: a destination that could not be initialized has not posted a partial batch. Nothing reached the company database, so there is nothing to unwind before you retry. That is very different from a failure partway through a running integration, which is covered further down.

Why does Integration Manager say the stored procedure does not exist?

Because the account that eConnect runs under does not have rights to the Dynamics GP databases. The message looks like a missing object, but the procedure is almost always there. Microsoft KB 951775 gives the real cause as a permissions problem on the eConnect COM+ component identity.

The error text appears in this shape, where the placeholder is whichever eConnect procedure the integration needed:

DOC 1 ERROR: eConnect error - The stored procedure procedure_name doesn't exist.

The requirement is specific. The account configured on the eConnect COM+ component must be a member of the DYNGRP role in the DYNAMICS database and in every company database it will touch. DYNGRP is what carries Execute permission on the eConnect stored procedures, so without it the procedures are effectively invisible to that login.

To find out which account is actually configured, rather than which one you think is configured:

Step	Where
1	Start, then Run, type dcomcnfg and press OK
2	Component Services, then Computers, then My Computer, then COM+ Applications
3	Right click the eConnect for Microsoft Dynamics GP application, choose Properties
4	Open the Identity tab and read the account under This user

That account is the one that connects to SQL Server. Once you have the name, confirm its role membership from SQL Server directly rather than trusting the GP security windows:

USE DYNAMICS;
EXEC sp_helprolemember 'DYNGRP';

-- repeat against each company database
USE TWO;
EXEC sp_helprolemember 'DYNGRP';

A very common version of this is an integration that works against the test company and fails against live, which is nearly always DYNGRP present in one database and missing in the other. Checking every company database, not just the one you tested in, is what closes it out for good.

What causes the ADO field is nothing error?

A source data file that is still open. If the spreadsheet or text file feeding the integration is open in Excel or a text editor while the integration runs, the source adapter cannot read the field it expects and reports that the ADO field is nothing. Close the file and run it again.

This one is worth knowing precisely because it looks like a data problem and gets treated as one. People start rebuilding the mapping or retyping the file when the actual fix is closing the window it is open in. It is also the reason scheduled integrations sometimes fail only when a particular person is at their desk with the source file open for review.

How do I stop a purchase order integration failing halfway through?

Validate the reference data before the run, not during it. A destination that fails to initialize is harmless because nothing posted. A run that fails on document 40 of 200 is the expensive case, because the first 39 purchase orders are already in the company file and the rerun will duplicate them unless you trim the source.

Purchase order integrations break mid run for a narrow set of reasons, and all of them are checkable in advance:

Check	What breaks without it
Vendor ID exists in the company database	The document errors out on the header before any lines post
Item number exists and is assigned to the site	The line fails even though the header was accepted
Unit of measure exists in the item U of M schedule	Quantities post against the wrong conversion
Currency ID set up for the vendor	Multicurrency documents stop at the header
Next PO number in Purchasing Setup has headroom	The run stops when the number sequence runs out
Source file closed on every workstation	Produces the ADO field is nothing error mid batch

Two operational habits make the difference in practice. Run the batch in slices rather than as one 500 document file, so a failure costs you one slice. And route the exception rows to a named owner instead of leaving them in a log nobody reads, because unattended integrations fail quietly and the cost shows up weeks later at month end. Teams running scheduled loads across several systems usually end up with some way to route those exceptions to whoever owns the fix rather than to a shared inbox.

It is also worth confirming where the documents actually landed. Purchase orders posted by an integration write to the same tables as ones keyed by hand, so a query against the Dynamics GP purchase order tables is the fastest way to see exactly how many documents made it in before a failure.

Can I import purchase orders into Dynamics GP without Integration Manager?

Yes. eConnect is the underlying layer Integration Manager itself calls, and it can be driven directly from .NET or from SQL, which is the usual route once a load needs to run on a schedule. Third party tools such as SmartConnect are also widely used on US GP sites, and they use the same eConnect procedures underneath, which means the DYNGRP permission requirement described above applies to those too.

Whatever drives the load, the data still has to arrive in columns first. If your purchase orders come in as supplier PDFs, that capture step sits in front of every one of these routes, and the purchase order to Dynamics GP converter covers turning those documents into the fields an integration expects. The same problem shows up on every other platform: the QuickBooks purchase order import route and the general ERP import workflow both start from the same extracted file.

What should I check before running a purchase order integration?

Run this list once and most of the errors on this page never appear. It takes about two minutes and it is considerably cheaper than unwinding a half posted batch.

Before you run	Why
Only one Dynamics.exe process is running	Prevents the RPC server is unavailable error
Only one Terminal Server or Citrix session is active	Same cause, harder to spot
Source file is closed everywhere	Prevents ADO field is nothing
eConnect COM+ identity is in DYNGRP on every company database	Prevents the stored procedure does not exist
Dynamics.exe is registered for the signed in user	Prevents the ActiveX automation errors
Company file is backed up	The only reliable way to reverse a bad batch
Test slice of two or three documents runs clean	Catches mapping errors before volume

Integration Manager has a reputation for being unreliable, and that reputation is mostly undeserved. The failures are repetitive and documented. The environment around it, the registry state, the COM+ identity, the number of open sessions and the number of open files, is what actually determines whether a run completes, and all four of those are things you can settle before you press Run.