+3
Not a bug

Dynamics CRM Upgrade 5.2.0.1 to 5.3.2.0, is not in the list of known agents

Daniel Walters 4 years ago updated by Beau Harrison (Senior Product Software Engineer) 4 years ago 19

I'm doing an upgrade of Broker. The order of what I did

1. Uninstalled the CRM Agent out of Add/Remove Programs

2. Upgrade Broker from version 5.2.0.2 to 5.3.2.0

3. Installed CRM Dynamics agent v 5.3.2.0

4. Attempted to start the service and got the error.

Image 5462

Double checked CRM Dynamics is now in the add/remove programs list. Rebooted the server. Problem still persists. Prompt support would be appreciated as I'm onsite doing an upgrade.

Under review

Hi Daniel,

Can you check the connector installed correct? Check that the connector dlls have been added to the <installDir>/Services and <installDir>/Web/bin directories.

Yes the files are there in both directories. Screen shot coming.

There aren't any old dlls in the Patches directory, by any chance?

Can you provide your extensibility configuration?

Services\Patches is empty.

Testing locally I was able to start Broker with your configuration. Can you try the following:

1) Remove the agents, connectors and adapters from configuration and attempt to start Broker. I've attached empty copies of extensibility files you can use. If Broke starts, check what plugins are listed on the About page, an if you can create new CRM agents/connectors.

empty-extensibility.zip

2) Uninstall the CRM connector, and reinstall it. Try the above again and, if it works, replace the empty config with your original config.

Also, is Unify.IdentityBroker.LDAP.Engine.dll a patch left over from the v5.2 install? You should always remove old patches when you perform an upgrade.

Thanks for the empty config that made it smoother to test. The service started with the empty config but the Dynamics CRM agent didn't appear when attempting to create a new agent. So we uninstalled the CRM Agent and reinstalled, restarted the service and it still doesn't appear in the list of available agents when trying to create a new one.

It also doesn't appear in the Plug-in Version Details in about. The Microsoft Active Directory plug in which was also installed does appear here.

RE: The ldap.engine dll. How do I know if a .dll is a patch?

Have you tried redownloading the CRM connector installer or have you been using the same installer to reinstall? Might be worth trying that.

If that doesn't do anything, try changing the Broker log writer to "Diagnostic" and restart the service. You might want to delete/move the existing log file first. After the service has started, attach the log file here.

As for patches, ideally, what patches are installed should be documented by whoever installed them. I guess that doesn't always happen, though. Uninstalling Broker and all connectors will remove all their dlls, leaving only patches, which is one way to tell if your doing that.


The version of the .dll is 5.0.0.0 and the referenced assembly is version 8.0.0.0 is what it looks like to me

(screenshot on the desktop, just copied out of the Services Folder.)

Richard from Infrastructure has fixed it because he has the CRM SDK and he copied the two dlls: microsoft.crm.sdk.proxy.dll and microsoft.xrm.sdk.dll into the Services directory. These are version 8.2 dlls. The CRM now appears in the About menu and is selectable in new connectors. Are you happy with this fix? And when I go into higher environments I'll package these .dlls or do you want to supply a different way of doing it?

This is the working .dll 

The connector should be looking for  v5 versions of those dlls unless there's a binding redirect to v8 in the .exe.config files. If that's the case, then using v8 dlls was probably intentional. If that's the case, hopefully somebody documented the reason why.

There's no binding redirect for either of the CRM assemblies in the service exe config.

There is a binding redirect to version 8. I couldn't tell you why. Would that have been preserved during the upgrade? Does this mean someone has set it this way in the past? As opposed to the installer doing it.

Not a bug

Changes made exe.config files are persisted during an uninstall or upgrade. Those binding redirects were not made by the installer, they have been added manually for some reason.