none
Installing FIM 2010 R2 SP1 on SharePoint Foundation 2013 RRS feed

  • Question

  • Went to upgrade my development environment to FIM 2010 R2 SP1 the other day. The current configuration was FIM 2010 (pre-R2) running on WSS 3.0. As the SP1 patch is only good for existing R2 servers, I went to install from the full R2 SP1 media. FIM Sync Service upgraded fine, but when I went to install the Service and Portal component, it didn't detect the existing installation and was attempting a fresh install. I figured I'd give it a shot anyway, and let it use the existing pre-R2 database, but instead of installing the R2 SP1 Portal, it seemed to uninstall my pre-R2 Portal. Odd.

    Anyway, I decided to give it another try and this time upgrade WSS 3.0 to the now-supported SharePoint Foundation 2013. I followed the Installing FIM 2010 R2 on SharePoint Foundation 2013 guide and after a few teething problems (soon to be blogged about!), I managed to get the system in a state where I'm confident it's ready to install. I've also run back through the Before You Begin from Forefront Identity Manager 2010 R2 Deployment Guide just to be on the safe side.

    However... when I run the installation, the progress bar runs through and then I get presented with this:

    "Forefront Identity Manager Service and Portal Wizard ended prematurely"

    Doesn't really give me much info. Nothing in event viewer.

    I tried to run the installer with verbose logging, as described in this post but I get:

    "The patch package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer patch package..."

    Okay, just realised I'm running msiexec with /p instead of /i. I'll give that a shot.

    Meanwhile, anyone got any other installation debugging tips?

    Has anyone else installed FIM 2010 R2 SP1 to SharePoint Foundation 2013?

    - Ross Currie


    FIMSpecialist.com | MCTS: FIM 2010

    Thursday, February 14, 2013 6:24 AM

Answers

  • Thanks Glenn - I went down that path, but couldn't see anything that had changed from your standard AD configuration. I thought there might be some restrictive group policies that might be interfering, but couldn't find anything.

    If anyone saw this other forum thread, the issue appears to be with DNS suffixes configured on the network adapter.

    Long story short: The development server I was installing on was deployed using a standard production configuration, so all the DNS Suffixes configured on the network adapter were for the production environment. When I added the dev domain suffix, FIM installed fine.

    I've written a detailed account on my site of how I troubleshooted and ultimately resolved this issue for anyone that encounters this issue in the future, which includes a few tips for installing FIM 2010 R2 SP1 on SharePoint Foundation 2013.

    - Ross Currie


    FIMSpecialist.com | MCTS: FIM 2010

    • Marked as answer by Ross Currie Tuesday, February 19, 2013 4:18 AM
    Tuesday, February 19, 2013 4:18 AM

All replies

  • That's a bit better, got some debugging info from the installer. Searching for "return value 3" finds me this:

    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.

    I see Robin Gaal had a similar issue - looks like it may be a "dnssuffix related problem"... anyone know what that means?

    - Ross Currie


    FIMSpecialist.com | MCTS: FIM 2010

    Thursday, February 14, 2013 6:37 AM
  • So went back to SharePoint Foundation 2010 today and seem to be having the same issue.

    FIMSpecialist.com | MCTS: FIM 2010

    Friday, February 15, 2013 8:20 AM
  • Ross,

    I have debugged a somewhat similar issue. The stack trace didn't show the RPC error but the function calls were exactly the same. I have gone through the setup routine and at the exact point you are at, it is attempting to find the service account that was specified during setup in AD. This could be a problem with DNS, you would be expected to have the proper DNS access to the AD environment for which the service account you specified belongs to.

    In my case, the problem was caused by AD group issues; the 'Authenticated Users' group had been removed from the Pre-Windows 2000 Compatible group. Have there been any changes to the AD org in order to lock security down? If it is DNS problem, a network trace run from the machine on which you are installing the FIM service and portal should clearly show this.

    • Marked as answer by Ross Currie Monday, February 18, 2013 5:30 AM
    • Unmarked as answer by Ross Currie Monday, February 18, 2013 5:30 AM
    Monday, February 18, 2013 5:13 AM
  • Thanks Glenn - I went down that path, but couldn't see anything that had changed from your standard AD configuration. I thought there might be some restrictive group policies that might be interfering, but couldn't find anything.

    If anyone saw this other forum thread, the issue appears to be with DNS suffixes configured on the network adapter.

    Long story short: The development server I was installing on was deployed using a standard production configuration, so all the DNS Suffixes configured on the network adapter were for the production environment. When I added the dev domain suffix, FIM installed fine.

    I've written a detailed account on my site of how I troubleshooted and ultimately resolved this issue for anyone that encounters this issue in the future, which includes a few tips for installing FIM 2010 R2 SP1 on SharePoint Foundation 2013.

    - Ross Currie


    FIMSpecialist.com | MCTS: FIM 2010

    • Marked as answer by Ross Currie Tuesday, February 19, 2013 4:18 AM
    Tuesday, February 19, 2013 4:18 AM