If you have a look at this thread, and others like it, you will see that one of the recommended fixes is to restart the server. It always seems such a cop-out type of fix to do this – sort of a last resort when nothing else works. However it was the only thing that worked and now I will do this as one of the first things to try when I next run into it.

The reason for this post is two-fold … as a reminder that this can come up to bite you when you least expect it, and to identify potentially a new source of the problem – sync server migration.

I was migrating a sync server config, using the server import method from DEV to UAT, and using the trick of hitting cancel whenever I was prompted for connection details. This way you get a second prompt asking if you want to reuse the existing details, which I almost always do (apart from the initial deployment). This I did, and after migrating some associated FIM Server config, I then kicked off a full re-baseline of the FIM sync service (FI/FS on each MA starting with the FIM MA), checking that the FIM MA FI/FS was working OK. I woke to find all the FI/FSs had worked fine, but the FIM MA export run profile was repeatedly restarting the FIM MA export after hitting the default 5000 error limit.

At first I couldn’t understand why the FIM MA import had worked but not the export … and then I recalled an explanation from Andreas (MS FIM product group) that sometimes the FIM MA bypasses the FIM Service endpoint and talks straight to the database. I figured this must have been one of these scenarios (I’m still on FIM R1 for this site). I then spotted something unexpected – although I had hit cancel instead of re-entering connection details for the FIM MA, the URL was now showing http://localhost:5725/ … which was the DEV configuration but not the UAT configuration (separate server for the FIM service and portal). I would have thought that this constitutes part of the connection details, but in this case it appears to be an exception – note to self to always check this again next time!

I then tried to update this to the correct URL and BANG – I started getting the dreaded exception in the thread title. I tried a few things and nothing worked, so as a last resort I restarted the FIM sync/sql server and voila – magic did happen, and export started working again. I would love to know why this is the case, but I’ll leave that for the FIM PG to work out. I’ll raise this with them soon but in the meantime always check this when you’re applying this approach to your sync server deployment.