I was testing a configuration migration in a customer environment and, when importing the FIM MA, I hit the good old error:

Failed to connect to the specified database or Forefront Identity Management Service. Please check the specified database location, service host address, and account information.

There’s several reasons why you can hit this error.  I’m going to blog about them all, but I’m going to dedicate a post to each.  In this post, the reason was communications.  Specifically the FIM Synchronization Service couldn’t connect to the FIM Service web service.

Here’s the error (from verbose tracing):

mscorlib: System.ServiceModel.EndpointNotFoundException: Could not connect to http://idweb:5725/ResourceManagementService/MEX.  TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.99.104:5725.  –> System.Net.WebException: Unable to connect to the remote server –> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.99.104:5725 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) at …

I immediately checked the firewall and yes the rules for the FIM Service: Forefront Identity Manager Service (STS) and Forefront Identity Manager Service (Webservice) were present and enabled.

I verified I could access the FIM Service from the system, i.e. I browsed to the portal.  I also tested name resolution for the hostname of the FIM server and the virtual hostname (the URL).

I then looked into the IE settings for the FIM Synchronization Service, i.e. I reset the IE zone settings to default; added the virtual hostname to INTRANET zone; and ensured a proxy wasn’t configured and that automatically detect a proxy server was off.  I retried this with the FIM MA account too.

Nothing worked.  I looked at the NIC properties on the FIM Synchronization Service server for the second time and it hit me.  The network was public.  I jumped back onto the FIM Service server and the network connection here too was public.  I bounced the Network Location Awareness Service (NLASVC) and then the box was on a domain network.  Back to the FIM Synchronization Service box, bounce NLASVC and this too is now on a domain network.  Retry the connection and bingo, we’re through and the FIM MA goes off and creates.

The reason?  The two firewall rules created by the FIM Service installation are only configured for the Domain profile.  Disabling the firewall’s not an option and neither is, in my opinion, changing the scope of the rules.

Why hadn’t NLA sorted out the networks?  I don’t know that yet but I’ll try and dig into my suspicions and will post back on that if I ever get to the bottom of it.

Summary

One of the reasons for not being able to create a FIM MA (manually or via configuration import) or not being able to update the schema on an existing FIM MA is connectivity.  By default, the FIM Synchronization Service process needs to be able to access the Resource Management Service which is listening on TCP 5725.  In order to access this port both the FIM Service node(s) and the FIM Synchronization Service node need to be connected to a domain network.  If authentication and name resolution are working (GPUPDATE is a good way of quickly validating this) and the network isn’t picking up the fact that either server is on a domain network then consider either disabling and enabling the NIC or restarting the Network Location Awareness (NLA) service.