FIM 2010 R2 RC Can't Create FIM Management Agent Error: Failed To connect to the specified Database
Error Message: I'm sure the Server, Database, and FIM Service base Address are correct, the Authentication mode is Windows Integrated and all of that is correct. Database is on another Server in the same AD domain I did notice that the FIM Service running on Localhost:5725 does not support MEX (eg: http://localhost:5725/mex/) Does it have to support MEX to create the management agent? I've tried the following for the FIM Service base address: http://localhost:5725/ http://[NetBiosName]:5725/ http://[IP Address of Server]:5725/ All give me the same error in the screen shot below. The User that it's connecting to sql with (domain user with Integrated Windows Authentication) Has DBO rights on the FIMService Database. I've Tried the following for Server (assuming it wants the SQL Server address for this one per the docs on tech net) IP v4 Address of the SQL Box, Netbios Name of the SQL box. SQL is running as the default instance. Any ideas on how to trouble shoot this?
December 13th, 2011 12:08pm

Hi, Is your FIM Service on the same server as the FIM Sync? I have an installation where they are separate and mex is not enabled. The configuration is: Server: sqlservername.domain.com database: FIMService FIM Service base address: http://FIMServiceServerName:5725/ Using Windows auth with an account configured for the FIMMA as specified in the docs. I've got my firewalls turned off since this is a lab. Not sure if that helps or not, but those are some details of a working instance. Thanks, Sami
Free Windows Admin Tool Kit Click here and download it now
December 13th, 2011 1:39pm

Sami; Thank you for your reply!! FYI: FIM Service and FIM Sync Service are on the same VM. (Does this make a difference ?? Should they be separated?) Tried with FQDN for SQL, no dice, tried with FQDN for FIM Service base address no dice. Jonathan
December 13th, 2011 2:04pm

Hi Sami; I can get to http://localhost:5725 in Internet Explorer and get the Standard WCF Service page that warns of MEX binding turned off. Top bit of the page in IE: I can ping SQL and there are actually connections from the FIM VM to the SQL VM that are open and running. On the machine with the FIM Service & Sync Service it also has SharePoint installed on a Single Server Config with a local SQL DB for SharePoint. SharePoint did not install the SQL 2008 R2 Native Client (the FIMService and Sync Service Databases on the other SQL Server are 2008 R2) So I did install the SQL 2008 R2 Native client from the MSI download and restarted. (Thanks for the link to the thread), Didn't help. Went to the domain controler added the FIM MA account to logon locally, applied it, then ran GPUPDATE on the FIM Service server (Per the thread, thanks again), no dice Checked the permissions on the Framework64 folder on FIM Service host. (Per the thread, thanks again), no dice Not sure what to do next? Is there some sort of trace log when adding a management agent to see what the issue is?
Free Windows Admin Tool Kit Click here and download it now
December 13th, 2011 2:43pm

Hi Jonathan, Do you see anything in the Event Viewer? There's a "Forefront Identity Manager Management Agent" folder under "Applications and Services Logs" that might have something useful. Thanks, Sami
December 13th, 2011 2:49pm

Carol no i used different accounts. I'm going to attempt an un-install / re-install of the RC and use a single account....
Free Windows Admin Tool Kit Click here and download it now
December 13th, 2011 2:55pm

Sorry I cant get the images to post here, guess they were having issues with the copy and past for images. I deleted the VM and started from Scratch, and did what Carol suggested and used the same account for Sync Service as the FIM MA and it now works. Thanks Carol!
December 16th, 2011 5:10pm

which alternate account did you used for sync service instead of fimma
Free Windows Admin Tool Kit Click here and download it now
November 2nd, 2012 4:22am

I used two accounts for the RC, apparently for the RC they needed to be the same, for the R2 RTM We did use seperate accounts per the MSDN docs and everything worked fine, of course as always do it in a test enviroment first. This thread was related to the Release Canidate for R2, not the actual R2 RTM
November 3rd, 2012 9:58am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics