OK, I have two idependent FIM 2010 servers created. Both have the Portal and FIM Service installed and they each work fine. However, now that we have a load balancer installed and configured, we want to use that to load balance the Portals and the FIM Services. The Portals work fine this way but we cannot get the FIM Services to load balance. So, taking the load balancer out of the mix, we just tried to point one servers Portal to the other servers FIM Service. This too was unsuccessful. So, when we went to the Portal on the server who was pointing to the other server for its FIM Service, we received a "Service not available". After cranking up errors on the SharePoint portal, we would receive a more descriptive, "The request for security token could not be satisfied because authentication failed". I can provide the stack trace if necessary but the relevant portion seems to be: [SecurityNegotiationException: The token provider cannot get tokens for target 'http://server1.qa.foo.bar:5725/ResourceManagement/Enumeration'. Now, we have our SPN's created: fimservice/server1.qa.foo.bar, fimservice/server1, fimservice/server2.qa.foo.bar, fimservice/server2, fimservice/fimlb.qa.foo.bar, fimservice/fimlb The first four are for the servers and the last two for the load balancers. Our FIM service on each server runs under the account "qa\fimportalservice" and our SharePoint application pools also run under that same account. I have tried messing with applicationHost.config and setting the "useAppPoolCredentials" on the SharePoint - 80 site, but that only succeeds in entirely breaking the SharePoint site, even the root site. Basically, it prompts you for credentials three times and has you go to a blank site. Kerberos delegation is turned ON for all services for the "qa\fimportalservice". We are not requiring Kerberos only in the web config Now, we have this all working in a completley different, isolated environment where we do not require Kerberos in the web config and did not monkey with the applicationHost.config file. Works beautiful. Now, the only difference we can think of is that in the working environment, the NLB was configured prior to installing FIM. In the non-working environment, NLB came later and so we are editing the web.config and Microsoft.ResourceManagement.service.exe.config files as necessary. Note that in the case where we are simply trying to point one server to the FIM service on the other server, we only edit the web.config file in the one location where you specify the ResourceManagement URL. What am I missing here? It seems like a Kerberos auth issue but I'm not sure where to go from here.

So to be completely clear, you are using the same database for both FIM Service installations in the backend. I have a similar setup, and I've never registered SPN's on a per server base. I've only registered the "fimservice/fimlb.qa.foo.bar" and "fimservice/fimlb" SPN's. The most important part is that everywhere FIM askes you to provide the FIM Service address you stick to the fimlb.qa.foo.bar entry. I know that the FIM Service installer wizard asks for it. You could fix this by using the reconfigure option when rerunning the setup. The second place is the FIM MA config in the Synchronization Service Manager. Besides that, because we work with a hardware load balancer, I've added "127.0.0.1 fimlb.qa.foo.bar fimlb" in the hosts files of both FIM Portal/Service Servers. This way I can prevent the one portal server hopping to the other as I see no use to that. But you seem to want the Portal from one Portal/Service server talk to the Service on an other server. Are you using a hardware loadbalancer? Are you sure the servers provididing the service to be load balanced can actually access the load balanced service themselves? TCP/IP wise this is not trivial. it's definately possible with some NAT configuration on the Hardware loadbalancer. To summarize: Don't use http://servername:7525 in a load balanced setup Use http://fimlb... in a load balanced setup Wanna force access to a specific node? 1) configure the host file with "IPofNode fimlbFQDN fimlb" 2) change the DNS for fimlb to point to the IP of a node instead of the VIP http://setspn.blogspot.com

OK, solved it. After some major tweaking of the config files, the most important being to indicate in the web.config file to "require" Kerberos, I got an error that led me to the answer. And that answer is to add the following to the web.config for the SharePoint portal server: Changed this: <resourceManagementClient requireKerberos="true" resourceManagementServiceBaseAddress=”http://server1.qa.foo.bar:5725” timeoutInMilliseconds="60000" /> To: <resourceManagementClient requireKerberos="true" resourceManagementServiceBaseAddress="http://server1.qa.foo.bar:5725" timeoutInMilliseconds="60000" > <system.serviceModel> <client> <endpoint> <identity> <userPrincipalName value="fimportalservice@qa.foo.bar" /> </identity> </endpoint> </client> </system.serviceModel> </resourceManagementClient> This is the article that led me to the solution: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/38fb54fe-cdbd-4c6c-ae24-d8b12d40b62d I guessed as to where to put the client configuration information and apparently guessed right. This also worked with the load balancer once we replaced the URLs with the load balanced URLs in the web.config files as well as the Microsoft.ResourceManagement.service.exe.config files.

So, in answer to your other questions, yes, they both use the same DB. As for the forcing to a specific node, I think that this configuration works a little better and avoids host files. Basically, just monkey with the Alternate access mappings in SharePoint so that you have the following: Internal URL Zone Public URL http://server1 Default http://server1.qa.foo.bar http://server1.qa.foo.bar Default http://server1.qa.foo.bar http://portallb.qa.foo.bar Intranet http://portallb.qa.foo.bar http://xxx.xxx.xxx.xxx Intranet http://protallb.qa.foo.bar Basically, you setup an extra Intranet zone with the portal's load balanced address and you also add an internal URL of the IP address. If your load balancer configuration references the real servers by their fqdn, then use that instead and use the IP address as your public url in your default zone. So, you just switch those two. This configurations gives you your load balanced configuration as well as a way to specifically go to each node without the need of host files or any other kind of magic. You'll always have the option to use load balanced or not. In terms of the portal hopping between FIM Services, this is exactly what was desired for fault tolerance although the circumstances of when that failure state might occur are severely limited. The FIM Service would have to fail but the portal would still be accessible. It could happen. Always use persistence for both the portal load balancer and the FIM service load balancer so that once a session hits one of them, it stays with that same server throughout the session. Note, the only reason I was testing with having one server go to the other server directly was that I was trying to simplify the troubleshooting and remove the load balancer as a possible cause. The configuration here is that the load balancer only responds on port 80 and so does port mapping behind the scenes to port 5725. Why? Who knows, but I didn't want that extra magic in the way of my troubleshooting. Turned out that it didn't matter and that wasn't the cause of the problems.

Ok, I can see where you are going. And must admit that the AAM's in sharepoint are a bit dark to me. About: In terms of the portal hopping between FIM Services, this is exactly what was desired for fault tolerance although the circumstances of when that failure state might occur are severely limited. The FIM Service would have to fail but the portal would still be accessible. It could happen. In that scenario, I assume you would manually point the portal to the other FIM Service? Or is your load balancer doing a check whether the FIM Service is alive on a node or not?http://setspn.blogspot.com

Yeah, AAM's in SharePoint are a bit of a pain. I don't even have a good analogy for them. The public URLs are what you end up seeing in the browser's address bar, but the internal URLs are all "allowable" ways to reach that same public URL. That's why it matters what address your load balancer uses to reference the real servers, because you have to set it up as an allowable address for the right public address. It's also why you always have to have a public/internal pair that are the same. Yes, it is the public address, and yes, SharePoint, it is an allowable address too. While I guess I understand the coding reasons behind that, I guess it is the seeming stupidity of that configuration that frustrates me the most about AAM's in SharePoint and probably causes the most confusion. It's like explaining to a 30 year old that you need to put one foot in front of the other to walk. That's what putting that entry in there feels like to me. It's obvious. I just want to slap SharePoint in the forehead and say "Duh!" every time I do it. It's just not intuitive that you would have to spell things out to quite that level in an otherwise seemingly sophisticated program. Wow, sorry about that rant. Bottom line, the GUI in that part of SharePoint is terrible. They could have eliminated a lot of confusion by simply building that GUI better. That whole table format is terrible because it doesn't really "group" the items in a visual way that you intuitively understand their relationships. Yes, the load balancer is doing a check (basically a "ping" on port 5725 to see if the default web page displays). If it is not there, then it automatically takes it out of the pool so to speak. So, in the situation where a FIM service on one of the boxes fails or is manually stopped, the system will automatically route all FIM Service traffic from the Portals on both boxes to whichever FIM service is still alive.