Hi,The portal and service are installed on separate serversAll SPNs are configured as per the install guideCan access the sharepoint default site and sharepoint central administration site remotelyThe error message on the web page is 'Service not available' which i take to mean that the FIM Service cannot be contacted?Help!!Rob

Have you checked that the service "Forefront Identity Manager Service" is start on the server ?

The FIM service is running and i've even re-started it to no avail

Maybe you try to access the site with a different account that the one used to install the FIM.At the creation, only the installer has his account init to connect in FIM Portal with the attribute Domain, AccountName and Resource SID, which is the one from your AD.This way, only the installer can access site.Check also the permission site at http://localhost/IdentityManagement/_layouts/user.aspx to view if the installer account has Full Control privilege.You can also had the NT Authority\Authenticated Users group as Contributor to authorize connection for all Authenticated users.

I am having this EXACT same issue as Rob. Driving me nuts. lol We have also installed all components across separate machines, with correct SPNs setup, but even the installer account has random issues accessing the Portal from other machines. Will try the suggestions made here when I return to work next week and update you all.

try http://ip_address/IdentityManagement ??

We're using HTTPs not HTTP and we cannot use IP addresses in the URL, not permitted. The problem is intermittent. The Installer account is the Sharepoint Site Administrator and should be able to access the site. The account can locally but not remotely. The account can access the default Sharepoint site and the Sharepoint Central Administration site from any location, so i believe it is an issue related to the identitymanagement site. My gut feeling at present is an issue with Sharepoint and how the certificate is bound to the site.ThanksAnymore guidance??BTW, we are currently using RC3

try to enable more debug info on the portal C:\inetpub\www\wss\virtualdirectory\80\web.config search for "stack", change the callstack=true search for "custom", change the custom error page = Off search for ILMError, comment out that tag... try access the portal now and u should get the full stacktrace and as for https, you should still be able to access by IP i thought? just that the brwoser will warn u about the cert's hostname doesn't match?

Take a look in the event log I believe my posted question is the exact same issue. You should see the web service give you an unwilling to perform error followed by a cannot find user objectSID error.

I have all 4 FIM components installed across seperate machines (FIMSync, FIMService, FIMPortal, FIMPasswordPortal)Like the O.P., the portal only works correctly when I access it from the machine it is installed on.When I access it from any other machines, whether that be by FQDN, hostname, or IP address, I receive a "service not available" error. Sometimes a large one preventing the portal from loading, other times just sub-sections of the portal fail to load.The SPNs are correctly setup.I have enabled all the debug info as mentioned by Tony and have since received two event log errors after trying to access the portal from another machine:Source: Microsoft.ResourceManagement.PortalHealthSource Event ID: 10"The Portal cannot connect to the middle tier using the web service interface. This failure prevents all portal scenarios from functioning correctly. The cause may be due to a missing or invalid server url, a downed server, or an invalid server firewall configuration. Ensure the portal configuration is present and points to the resource management service. "The description for Event ID 8214 from source Windows SharePoint Services 3 cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: A request was made for a URL, http://<FQDN>, which has not been configured in Alternate Access Mappings. Some links may point to the Alternate Access URL for the default zone, http://<hostname>.<domain_name>. Review the Alternate Access mappings for this Web application at http://<hostname>:4748/_admin/AlternateUrlCollections.aspx and consider adding http://<FQDN> as a Public Alternate Access URL if it will be used frequently. Help on this error: http://go.microsoft.com/fwlink/?LinkId=114854 the message resource is present but the message is not found in the string/message table" "I also received many instances of the following, when successfully accessing from the Portal machine itself, as well as another machine where it partly fails: (Note: I have replaced the actual FQDN and hostnames with <strings>)Source: Windows SharePoint Services 3 Event ID: 8214

you are looking at the Application log there is a FIM specific event log under Windows Applications and Services nodeThe FIM Password Reset Blog http://blogs.technet.com/aho/

I have checked that log on the machine running just the FIM Service, but it has zero events.Has anyone else installed all FIM components across seperate machines? All other logging is working fine, not sure why this is empty.

Looks like we've got a good thread going here !I want to eliminate SPNs from my enquiry and also to remove some ambiguity in the inistall guide, so this is my setupServerA - FIM Service ServerAliasA - Alias for FIM Service ServerServerB - FIM Portal ServerAliasB - Alias for FIM Portal ServerSPNs i have registered:FIMService/AliasA(hostname) domain\FimServiceServiceAccountFIMService/AliasA(FQDN) domain\FimServiceServiceAccounthttp/ServerB(hostname) ServerBhttp/ServerB(FQDN) ServerBhttp/AliasB(hostname) ServerBhttp/AliasB(FQDN) ServerBHope this makes sense. If i've missed some out can someone with IIS expertise please point me in the right directionThanksRobLogged onto Portal Server, site opens OK. Logged onto Service Server, site opens OK, logged onto Sync Service server, site didn't open!

hm.. is the Alias CName or A Record? last time i tried something with CName and it's a pain to setup SPN for that...

It's interesting that for rob_wood it works from both the FIM Portal machine and FIM Service machine. On our setup only using the actual FIM Portal machine itself allows successful Portal access and authentication.Having enabled a full stack trace and error messages for IIS, we are mostly convinced we may a Kerberos related issue, as each machine on the network can access the FIM Service and port, but then gets an authentication error. We believe we have performed Kerberos delegation correctly, but need to go back to the start and tick things off in case we've missed something key.Can anyone confirm the behaviour of the Portal? When the user accesses the Portal, does the portal then solely contact the FIM Service, or is it a combination of the Portal contacting the FIM Service, as well as the client (i.e. Browser) also directly contacting the FIM Service?

The brwoser is not talking to the FIMService at all. my past experience, if FIMService and FIMPortal are on the same box.. u might be able to get around the kerb issue by... C:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config search for 5725.. change the hostname to localhost or IP... not sure how that will work for separated topology... but essentially, that's the address that FIMPortal tries to access the FIMService

If you are using LocalSystem or NetworkService as your AppPool account then you are registering the HTTP SPN's to the computer account. In this configuration you also need to make sure you have configured the computer account for Kerberos delegation.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

I had a very similar issue, configuring SSL as the installation guide lays out, then installing the FIM Service and Portal, and it generates very similar errors in the application log and webpage (Service not found). I laid this out here: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/944212ea-3178-4b07-841a-27829144d1c9 I haven't yet reenabled SSL following install, however. Due to other circumstances, I need to rebuild the lab environment and will get to this testing again later. Just thought I'd add my voice to the mix.

I've made a late discovery that during the last week the Installation section has been updated (although Technet still lists FIM2010 as RC1).It now mentions the need for a SPN where a sharepointservices serivce account is needed. Previously the http SPN for FIM Portal was indeed listed as a needed step, but made NO mention of a service account for 'sharepointservices'. Eagerly awaiting to get to work to try this out, and hoping this is the missing link to fixing my issue.By the way, another thing I noticed is that the now older install steps previously listed the SPN setup command as: "setspn -a etc etc"Now they state to use "setspn -S etc etc". The technet notes here say to use "-a": http://technet.microsoft.com/en-us/library/cc773257.aspx I see no mention of -S, and currently cannot access my test lab to test it out.Can someone shed some light on this? Is the '-S' a typo?

on a 2k8 DC... -S seems to be a better choice than -A because u don't want to have duplicate SPNs C:\Users\Administrator>setspn /? Usage: setspn [modifiers switches data] computername Where 'computername' can be the name or domain\name Modifiers: -F = perform the duplicate checking on forestwide level -P = do not show progress (useful for redirecting output to file) Switches: -R = reset HOST ServicePrincipalName Usage: setspn -R computername -A = add arbitrary SPN Usage: setspn -A SPN computername -S = add arbitrary SPN after verifying no duplicates exist Usage: setspn -S SPN computername -D = delete arbitrary SPN Usage: setspn -D SPN computername -L = list registered SPNs Usage: setspn [-L] computername -Q = query for existence of SPN Usage: setspn -Q SPN -X = search for duplicate SPNs Usage: setspn -X

Hi All,Thanks for all the investigative work on trying to resolve this issue. Here's what i've been up to, and so far everything works.Rebuilt my 3 servers using eval RTM and new DBs. Followed the install guide as far as SPNs ar concerned apart from the suggestion of using an SPN for the apppoolidentity account for the default sharepoint app pool. A colleague of mine assures me that Sharepoint app pools should be running under Network Service. So far i can connect remotely using http, have yet to configure SSL or set an Alias (with SPN) for the Portal server. This is where i reckon my problems will start as i believe there's a binding issue with certs requested through IIS for sharepoint sites, so will be testing that today.Incidentally, why didn't identitymanagement get it's own sharepoint site that we could have managed through IIS??Use SPN -S when adding SPNs, it prevents duplicates, or alternatively, use the Attribute editor in ADUC as you can also see what SPNs have already been setMore later....Rob

Rob, it appears we've solved our problem here.Basically, the instructions prior to and just after RTM were wrong for non-single machine installs. Seems a few days after RTM they were upgraded to suggest that a service account was needed for Sharepoint, as you've pointed out.That, mixed in with delegating Kerberos for the Sharepoint service account, as well as the FIM Portal and FIM Service machines, plus disabling Kernel mode authentication in IIS, and adding the Sharepoint service account to the MSSQL group on FIM Portal server to grant access to the portal DB that WSS installs. Will post the entire list of what we've done, once we've verified it by setting up our secondary portal. I'm hoping we've not missed anything. :pQuite frankly I am in the strong belief that the Install steps on Technet site are not adequate (although they've been somewhat improved recently) for anyone installing FIM across many machines, especially when splitting the FIM Service from the FIM Portal.

Has anyone gotten this working? Specifically something like this: FIM Sync, FIM Service, FIM Portal (for admins) on one server FIM Service, FIM Portal (for users), FIM Password Portal on another server SQL (wherever.. I happen to have all DBs on a SQL cluster) DNS aliases for each portal Portals secured via SSL WSS run under NetworkService or domain service account (though it's not obvious to me how to configure the latter without the full MOSS) SPNs as specified in the latest install guide This is a stopping point for me now.. I'm thinking about going with no SSL until I can figure it out, just so I can keep moving.. the error is "Service not found" in the IdentityManagement site collection web page.

Have you all checked your site urls / alternate mappings (Alternate Access Mappings) in SharePoint? Failing to access site remotely could be related to this. Best of luck to you all...

I've checked my Alternate Access Mappings.. First question: Has anyone gotten SSL to work in this situation (even after the Service/Portal install), and if so, do you enter http://<dnsalias> for the portal install wizard? Second question: Are people using A records or CNAMEs for DNS aliases?

It turns out it was SPNs.. so using SPNs of FIMService and HTTP for my FIM Service account (but nothing for the computer account got it working.. with SSL. However, I think I'm caught up to where rob_wood and RATLSNAKE are.. I can access the site from an external machine, but only if I use the account I installed everything with. Even using a DA fails with Service not found. Rob, did you get this working with the NetworkService account for WSS + SSL + remote machine accessing the portal?

Hi Tim and All, Just to update you all. We've just had our servers rebuilt in a completely new integration environment by independant build engineers following our install guides. All single instance VMs as follows: Synchronization Service server FIM Service Server FIM Portal server with WSS All have been built in accordance with the latest install guide on the RTM Eval version with the exception that the AppPoolIdentity for the default Sharepoint site is still Network Service, so SPNs have been set accordingly. SSL has been enabled I can succesfully open the identitymanagement site from the portal server and other servers with https Tim, until you add other users to FIM you can only open the identitymanagement site with the sharepoint site collection administrator account, which is usually the installer account. We used the same privileged account to build all 3 servers. Hope this helps. Rob

not only the user needs to be in FIM, but Domain + Account + DisplayName + ObjectSid all need to be populated accordingly. Common mistake is missing Domain or ObjectSidThe FIM Password Reset Blog http://blogs.technet.com/aho/

Its all in the install guide :)

Thanks for the reminder about needing to load the users into the portal <smacks head>. Regarding the install guide: it's not necessarily clear in my situation, where there's a DNS alias (CNAME) for a server that contains both the FIM Service and FIM Portal. Here are the relevant sections in this situation: You also have to create SPNs if the network address used by users and clients is not the same as the server name (for example, by using CNAMES) .. Establish the Service Principal Names (SPN) for the FIM Service by running the following commands: setspn –S FIMService/servername domain\serviceaccount setspn –S HTTP/servername domain\serviceaccount The servername above is the address entered during FIM Service setup and used by the clients to contact the Web Service. For the FIM Portal server, follow the steps in the next procedure. If the address the clients use to contact the FIM Portal is not the same as the server address, you need to establish an SPN for HTTP. That is, if you use a CNAME in DNS , have a SharePoint farm or use a load balancer, this address must be registered or Internet Explorer cannot use the Kerberos protocol when contacting the portal. Run the following command: setspn –S HTTP/FIMPortalAddress domain\sharepointserviceaccount The previous FIMPortalAddress is the address used by clients to contact the FIM Portal server. The domain\sharepointserviceaccount is the account used by the SharePoint Application Pool as defined in IIS. However, it's not possible to set the SPNs as above, because it will be a duplicate (regardless of whether WSS is using a machine account / NetworkService, or a domain service account). Through trial and error, it seems to work if I do the first steps but not the second (i.e. only the FIM Service SPNs).

You don't need to disable Kernel mode authentication - just edit the following file: c:\windows\system32\inetsrv\config\applicationHost.config ...look for the <windowsAuthentication tag and change it to the following: <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true"> When using web farms in WSS/MOSS you'll want to do this along with switching to the domain service account for the application pool.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

Whenever Kerberos is involved you cannot use a CNAME - you must register the alias as an A record. Using a CNAME will force a fallback to NTLM, or in many cases, a complete failure in delegation: http://www.identitychaos.com/2008/03/problem-with-kerberos-delegation.htmlBrad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

Thanks for that info, Brad. Are you saying you need to modify the applicationHost.config file in all cases, or only when using a web farm (and thus a domain service acct for that app pool)? Regarding CNAMEs and Kerberos.. that's good to know as well.. I would think MS should update the Install Guide then to reflect this (instead of referring to the CNAME as I pasted in my previous post). I do have a question though, after consuming this info.. How do we resolve the (supposed) fact that both the FIM Service account and the app pool service account both need the HTTP SPN registration? Use the alias (A record) for the app pool, and server name (A record) for the FIM Service account?

You essentially need to edit the file if you wish to use a domain service account AND retain the use of kernel mode authentication. There are serious performance enhancements when using kernel mode so it's worth retaining in high use environments. My understanding is that anytime you move to a web farm you need to use a domain account; however, IIS7/W2k8 changed the rules a bit so if I understand correctly, it may be more of a WSS/MOSS limitation at the moment. My rule of thumb, based on our MOSS teams' internal documentation, is to: Always use a domain service account for the app pool Edit the applicationHost.config file to retain kernel mode authentication Use A records instead of CNAMEs to maintain Kerberos viability Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

In my current configuration I do not have an HTTP SPN registered for the FIM web service but I do have circumstances where I'm seeing fallback to NTLM that I have not been able to explain. It's possible that you've keyed into something here that I abandoned earlier in my testing that I perhaps need to test again. In my original designs I was using two host headers, one for frontend website (hosted by the app pool account) and another for the web services themselves thinking that I'd want to load balance them separelty; however, I abandoned that later since the web server is contacting the web service using localhost in my current configuration. Perhaps I need to investigate this further but I'd prefer to have a little more input from the PG regarding which SPN's are being consumed here. If the web server is requesting the FIMService SPN then it's not using an HTTP one anyway... Here is my current configuration (FQDN's eliminated for brevity, but should have both short and long): Host Header: fim svc-sql MSSQLSvc/fimdb MSSQLSvc/fimdb:1433 svc-wss-fim (my app pool account) HTTP/fim HTTP/fimws01 (web node 1) HTTP/fimws02 (web node 2) svc-fimws (my web service acct) FIMService/fim FIMService/fimws01 FIMService/fimws02 None of my other accounts or computers have any SPN's registered. I think I'm actually going to switch my references from "localhost" to the local server names to see if that alleviates my other NTLM issues. You will also need to check the web.config files on each web server and look at how WSS is configured to talk to the web service. It should not be trying to talk back through your load balancer and instead be pointed at itself.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

My mistake was seting the Kerberos delegation only on the computer running the web services. Turns out that once I set it on the server running the portal also, all is good! Hope this simple fix works for others as well... Terry

My questions were answered in the Deployment webcast.. thanks Brjann Brekkan for putting that together! The Install Guide will apparently be updated soon to describe the SPN requirements better, from what I hear.

<windowsAuthentication is in there a few times. Do I change it for all of them?

Hi Rob I have the same kind of problem but I'm not really an SPN guy, so ca u help me out. I have three server FIM RTM deploy FIM Service (Server A, 10.10.10.1) FIM Sync Service (Server B, 10.10.10.2) FIM Portal and Reset Password components. (Server C, 10.10.10.3) Could you give some guidance about this?? I will appreciate all the help that u can give. cheers