Another day, another piece of FIM/MIM experimentation. I had built a fresh MIM 2016 environment in Azure to test a few scenarios out. That all went quick and seamlessly thanks to some great templates and a few scripts. Until I came to create the management agent (the purpose of today’s experimentation).
It didn’t matter if I tried to Create a New Management Agent or Import the Management Agent. I just got “Exception from HRESULT 0x80230729”. The common element however was that the Management Agent I was creating was based off a 3rd party MA based on Microsoft’s Extensible Connectivity Management Agent (ECMA). Specifically I was using Soren Granfeldts PowerShell MA.
Now I’ve used this MA extensively and not had a problem previously.
So I retraced my steps, clean build, pre-requisites etc. All good. I then tried creating an MA from the out of the box connectors. That worked. I successfully created an Active Directory Management Agent.
In the Windows Application Log I found the following from when I was trying to create the PSMA. A little more to go on from that information.
The link in the error message provides some info https://msdn.microsoft.com/en-us/library/dd409252(VS.100).aspx but it is a generic .NET article. Having experience with MIIS/ILM/FIM/MIM I figured the SyncEngine WebServices Config file would be appropriate place for the information provided in the MSDN link to go.
The Fix
The miiserver.exe.config file located in the default installation directory C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin is what you need to edit.
Near the end of the misserver.exe.config file find the <runtime> section. Insert the line <loadFromRemoteSources enabled=”true”/> as shown below.
Restart the Forefront Identity Manger Server Service from the Services Control Panel and you’re back in action.
Management Agent created and back to the task at hand. Happy days.
Follow Darren on Twitter @darrenjrobinson
Came across this article while hunting for something else.
Worth noting this is a Windows security feature for downloaded files. If you right click on the dll, go to properties, there’s an “unblock” option that allows you to say the dll is local and trusted.
Just had this exact issue, and when testing your solution I copied from this blogpost, pasted to the config file and saved+restarted the service, no change!
Looking closer I noticed that the quotes were different; ” vs the normal “.
Replacing the quotation marks with the “correct” one and restarting and now it works. Just a heads up if anyone else happens to struggle with this one…
Thx Tobias. Looks like WordPress changed the quote types.