Issue with an XMA that someone else wrote


  • Hello

    I'm struggling with moving the extensible MA by PoshCompany, between machines: I'm moving from the Development Environment to the pre-Live environment. I suspect that this is a more general question about an extensible management agent which has been developed by someone else, but it's driving me nutso.

    I've copied over the .dll, I've had the webservice set up correctly. I've double checked that both machines are running the same version of .Net (3.5.1). I've copied a .avp file hither and thither, but since it doesn't seem to matter where said file is (it's moved several times on the Development Machine).

    Every single time I try to run my initial import, I get an error 'stopped-extension-dll-load'. The Application Event Log gives me eventID 6166 qualifier 49152, with the further information of "The run step stopped because a configured extension for this management agent could not be loaded. Verify that the extension is loaded in the Extensions Directory. If the extension is present, confirm that the version of the .NET framework that can run the extension is installed on the server and that a supportedRuntimes entry in the configurations files specifies that version. The synchronization engine will not be able to load an extension that is built with a newer version of the .NET framework than the version of the .NET runtime it is hosting."  I've double checked the relevant .config file in the extensions folder - it doesn't have a supportedRuntimes entry. And, given that the .dll dates from July 2011, I doubt that the problem is that it's been built with a newer version of .NET than that which is currently installed!

    There are no errors in the Forefront Identity Manager eventlog when checking in eventviewer.

    I've worked my way through

    The runtime section of miis.config.exe looks like this in the source

    <assemblyIdentity name="Microsoft.MetadirectoryServicesEx" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="" newVersion="" />

    and this in the destination:

    <assemblyIdentity name="Microsoft.MetadirectoryServicesEx" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="" newVersion="" />
    <bindingRedirect oldVersion="" newVersion="" />

    Until I updated it to look like this:

    <assemblyIdentity name="Microsoft.MetadirectoryServicesEx" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="" newVersion="" />
    <bindingRedirect oldVersion="" newVersion="" />
    <bindingRedirect oldVersion="" newVersion="" />

    Which didn't help

    Then I changed it to being

    <assemblyIdentity name="Microsoft.MetadirectoryServicesEx" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="" newVersion="" />

    Also, no joy. So I went back to where I'd been in the first place for the destination, double checked mnsscrpt.exe.config and created dllhost.exe.configwo as per

    I'm running 4.0.3594.2 in the DEV environment, and 4.0.3606.2 in the pre-Live environment.

    All this leads me to believe that my next step is to recompile the .dll? It's probably a Good Thing that I do have access to the original code.

    Any further ideas appreciated...


    Tuesday, July 30, 2013 5:14 PM

All replies

  • Making sure you are running the same FIM version in both environments seems a good first step.

    Who are PoshCompany btw?

    Dave Nesbitt | Architect | Oxford Computer Group

    Wednesday, July 31, 2013 9:01 AM
  • You've copied this over a network?  Make sure that DLL files are not blocked - right click a file and check if you see "Unblock" option there.

    Also this might be a problem with class initialization in a code - maybe it tries to load some configuration file etc.? Have you checked application log for error entries?  

    Tomek Onyszko, memberOf Predica FIM Team (, IdAM knowledge provider @

    Wednesday, July 31, 2013 9:27 AM
  • Hi

    Well, we tried rebuilding the code on the destination server, but the shiny new .dll gave exactly the same error. The only error information in the event viewer is as per the original posting. Nothing in the FIM Application Log (I obviously need to reset a config file somewhere).

    .dlls aren't blocked, and I've copied everything over into the Extension folder from the \bin\deploy folder that had a .dll extension, just in case. I think it's unlikely that dlls themselves are the issue - the other MAs with extension code seem to be playing quite nicely.

    Going to see if I can break DEV next by installing the newer hotfix on there (I can snapshot it, so it's not the end of the world if it does break). I think it's going to be less stressful than trying to rollback the hotfix on the pre-LIVE box. I don't have the snapshot I took before putting that hotfix on, alas, as we didn't have enough space to keep it.

    All ideas still appreciated!

    Wednesday, July 31, 2013 10:14 AM
  • A couple of things...

    Which version of .NET are you compiling against?  I ran into a similar error with an incompatible version.

    Also, it may be that the XMA code is referencing an assembly that is available from the FIM Sync perspective, and thus failing to initialize the XMA assembly.  You can use the Assembly Binding Log Viewer (fuslogvw.exe) to determine whether you're failing to load required assemblies.  Suzanne Cook has a good article on using the log viewer for Debugging Assembly Loading Failures.

    Good luck!


    Marc Mac Donell, VP Identity and Access Solutions, Avaleris Inc.

    Wednesday, July 31, 2013 11:40 AM
  • With regard to binding redirects, I strongly prefer the "ranged" approach for oldVersion; e.g., oldVersion="" newVersion="".

    Another possibility is that the extension depends on some other DLL that you forgot to copy over or register in the GAC.

    You can also enable assembly binding logging (Fusion) a'la here.

    Steve Kradel, Zetetic LLC

    Wednesday, July 31, 2013 5:16 PM
  • Dear all: I think I've found the root of the problem. I applied hotfix 4.0.3606.2 to the DEV environment, and the dll promptly failed to load there. So I'm not missing a file/haven't forgotten to register something. Phew.

    Next stop will be trying the ranged version of the binding redirect.

    Thursday, August 01, 2013 8:55 AM
  • Look at the post below there is a know issue on 3606.2 and 4.0.3617.2 where it does not correctly update the Microsoft.MetadirectoryServicesEx.dll file. I typically patch the server to the latest version available, but in your case you may need to look at the 4.0.3617.2 <cite> </cite>hotfix as 3606.2 has some issues.

    Visit My Blog:

    • Edited by Jssting Wednesday, August 07, 2013 5:21 AM
    Wednesday, August 07, 2013 5:20 AM