Before I re-energised my blog I’d been thinking about what to post about. One of the things I’ve noticed is that prescriptive guidance for specific errors is sorely lacking presently. My plan was to blog about every error and solution I came across in development and deployment, as well as anything fully resolved on the forum. Of course I forgot to note down several so this has taken a bit of a backseat however one of my colleagues hit a nice layer-8 issue today that will be the first of many that I hope to cover.
The user-friendly error was the standard “Service not available” error. This doesn’t tell us much, so the first thing we must do is get the real error. Thomas Vuylsteke has published the step-by-step instructions on the TechNet wiki: How to Configure Detailed Error Pages for the FIM Portal. Follow the instructions in that article to configure detailed error pages for the FIM Portal. When done, regenerate the error (i.e. load the portal as the user who failed again) and see the real error.
In my colleague’s case he’d installed FIM and could not logon to the portal as the account that installed the FIM Service. He also couldn’t logon via NTLM. Once he’d enabled detailed error pages the solution was pretty obvious. Here is the full error:
The remote name could not be resolved: 'http'
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Net.WebException: The remote name could not be resolved: 'http'
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
[WebException: The remote name could not be resolved: 'http']
System.Net.HttpWebRequest.GetRequestStream(TransportContext& context) +1003
[EndpointNotFoundException: There was no endpoint listening at http://http/ResourceManagementService/MEX that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.]
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) +10257978
System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) +539
System.ServiceModel.Description.IMetadataExchange.Get(Message request) +0
Microsoft.ResourceManagement.WebServices.MetadataClient.Get(String dialect, String identifier) +236
Microsoft.ResourceManagement.WebServices.ResourceManager..ctor(String typeName, LocaleAwareClientHelper localePreferences, ContextualSecurityToken securityToken) +35
Microsoft.IdentityManagement.WebUI.Controls.ConfigurationModelBase.RetrieveResources(String type, String filter, List`1 attributes) +168
[ServerDownException: Error connecting to server]
Microsoft.IdentityManagement.WebUI.Controls.ConfigurationModelBase.RetrieveResources(String type, String filter, List`1 attributes) +1171
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3394
In the case of the above the solution is straight-forward enough. On the “Configure FIM Service and Portal: Configure connection to the FIM Service” wizard page of the FIM Service & Portal setup the FIM Service Server address had been specified as a URL, e.g. http://idweb.contoso.com. A simple mistake. The correct format is the unqualified or qualified hostname, e.g. idweb or idweb.contoso.com.
Further validation can be made by inspecting the configuration file. Open the following file (assuming a default installation):
C:\Program Files\Microsoft Forefront Identity Manager\2010\Service\Microsoft.ResourceManagement.Service.exe.config
Within the <configuration> </configuration> section you’ll find two elements: resourceManagementClient and resourceManagementService:
Note the resourceManagementServiceBaseAddress and externalHostName properties. In our case these were http://idweb whereas they should have been idweb.
How to fix? The correct way is to rerun setup and choose a Change installation type. When prompted enter the correct name without an HTTP or HTTPS prefix, i.e. enter simply the hostname.