Recently, I had to perform an upgrade to FIM 2010 R2 SP1 from FIM 2010 (pre-R2) in a development environment. After a few issues performing the upgrade, I was installing the FIM 2010 R2 SP1 Service and Portal on SharePoint Foundation 2013 and I kept running into the error: Forefront Identity Manager Service and Portal Setup Wizard ended prematurely.
Background
Because I was upgrading directly from FIM 2010, I couldn’t use the R2 to R2 SP1 Update from KB2772429, which requires you to already be running FIM 2010 R2 build 4.1.2273.0 or later, so I had to perform an upgrade using the full installation media. My FIM Sync Service installation detected it was an upgrade and went through fine. Very pain free! However, when I installed the FIM Service and Portal, it didn’t seem to detect my existing installation. When I told it to proceed anyway, and told it to use my existing database, it didn’t install the SP1 Portal, it just uninstalled my existing Portal instead.
This was a bit weird, but since my Portal had already been uninstalled anyway, I decided I’d give it another try, but this time take it as an opportunity to upgrade to SharePoint Foundation 2013.
Installing FIM 2010 R2 SP1 on SharePoint Foundation 2013
I referred to the Microsoft documentation regarding Installing FIM 2010 R2 on SharePoint Foundation 2013 and found it to be pretty pitiful. In fact, there really doesn’t seem to be any benefit to using SPF2013 with FIM unless you’re running Windows Server 2012 (no SPF2010 support until SP2), and several reasons not to (I’ll get to that in a later post) but I was committed by this stage.
The main hurdle was that Classic Authentication has been deprecated in SPF 2013 and removed from the GUI options for creating a web application. Since FIM 2010 doesn’t support Claims-Based authentication, you have to create the web application using the SharePoint 2013 Management Shell. Of course, the “Standalone” installation method with SPF2013 pre-installs your application with Claims Based, so you first need to delete that web application, then create another one via the Management Shell… anyway, all things for a later post.
FIM R2 SP1: FIM Service and Portal Setup Wizard ended prematurely
In true FIM fashion, this error is about as undescriptive as they come. So, in order to delve a little deeper, I executed the installation exceutable with verbose logging switched on:
msiexec /i “Service and Portal.msi /L*v “c:\temp\file.log
This time, when the installer ran, I was able to glean a bit more information:
MSI (s) (54:1C) [14:26:22:593]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI2922.tmp, Entrypoint: AddServiceToPerformanceMonitors
SFXCA: Extracting custom action to temporary directory: C:\Windows\Installer\MSI2922.tmp-\
SFXCA: Binding to CLR version v2.0.50727
Calling custom action Microsoft.IdentityManagement.ServerCustomActions!Microsoft.IdentityManagement.ServerCustomActions.CustomActions.AddServiceToPerformanceMonitors
Adding FIMService account to 'Performance Monitor Users' group
Property name = 'ServiceAccount', value = 'ourDomain\FIMService'.
DomainName='ourDomain'
AccountName='FIMService'
Domain AD found
Exception thrown by custom action:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x800706BA): The RPC server is unavailable.
at System.DirectoryServices.DirectoryEntries.Find(String name, String schemaClassName)
at Microsoft.IdentityManagement.ServerCustomActions.CustomActions.ChangeUserMembershipInGroup(Session session, Boolean addUser)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture)
at Microsoft.Deployment.WindowsInstaller.CustomActionProxy.InvokeCustomAction(Int32 sessionHandle, String entryPoint, IntPtr remotingDelegatePtr)
CustomAction AddServiceToPerformanceMonitors returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 14:26:25: InstallExecute. Return value 3.
Note the three bolded bits: While trying to add the FIMService account to the Performance Monitors group, the ChangeUserMembershipInGroup method throws “The RCP Server is unavailable”. I put this information up on a post I started on Microsoft Technet and was also able to find another post by Robin Gaal over at Traxion who had been having a similar issue when upgrading to FIM 2010 R2, which I posted on to see if he could provide more detail.
Between the two posts, the three bits of advice that came back were:
- Ensure you’re using a domain user and a local admin
Well, the account I was using was a domain user, a domain admin, a local admin and domain admins were also in the local admins group. I was also running the installer as administrator. I ruled this one out pretty quickly, but was good to do a sanity check.
- Check for AD Security customisations
This one came from Glenn Zuckerman at Microsoft in reply to my Technet post, who had debugged a similar issue and found that it was caused by some AD changes made in order to lock down security in the organisation. The result of these changes was that “the ‘Authenticated Users’ group had been removed from the Pre-Windows 2000 Compatible group” – so, another permissions issue. I had a look at our AD, but couldn’t see anything obvious that would cause any issues with performing the necessary tasks – I mean, I was able to add the user manually to that group, using the same user account performing the installation.
- DNS Suffix Incorrectly Configured – SUCCESS!
Robin Gaal had previously reported in his post that this was the issue behind their installation issue and that he was able to resolve it, so I asked him for some more detail. It turns out, his situation was very similar to mine – he was installing the FIM Service and Portal into a Test/Acceptance environment, where the default server configuration was registering the server to the production domain. The solution was as easy as going into the advanced settings for the server’s network adapter, and changing the DNS settings:
Of course, when I tried this, the FIM Service and Portal installed perfectly first try, and I was even able to use and upgrade my existing database (which took almost no time at all to upgrade). Success!!
Overall, a very frustrating installation experience – I’d planned the upgrade to take two days, which I thought was pretty generous, and it ended up taking me about 7. The good news is, I learnt a lot about installing and configuring SharePoint Foundation 2013, as well as some new tricks for debugging FIM installations. Thanks to the folks on the Technet forums for their help, particularly Robin Gaal, Glenn Zuckerman and Varun Kohli.
