none
FIM Service and Portal Installation Ends Prematurely RRS feed

  • Question

  • Hello All,

        I'm in the process of setting up a new production FIM 2010 R2 server. I have already installed the FIM synchronization service and I was able to install this successfully. I have already installed SharePoint services (WSS 3.0) and configured it for FIM. But when I try to install the FIM Service and Portal. I keep getting and error that says " FIM Service and Portal Installation Ends Prematurely" with no other details. If anybody has any advice please let me know. 

        I have already installed everything on a stand alone box in a dev environment and it all works correctly however I am unable to now install in a production environment 

       

    Monday, March 24, 2014 2:58 PM

Answers

  • Cameron is right - you should consider FIMService account nearly as normal AD account for user*

    An installer account should be admin on the box, where you are installing FIMService and he should be sysadmin on SQL during installation of FIMService. An installer account should be other than FIMService account itself.

    *FIMService account:

    Lock down the Service Account

    The service account should not be used by any other services or users. The account must not be used to logon interactively and requires no access to any additional resources beyond those granted during setup. The service account is used to provide the security context for the MIIS service as it accesses resources on the MIIS server and the associated database. It also provides the security context for the execution of any rules extensions.

    Lock down the service account to ensure no malicious user is able to sign in using its credentials and gain access to MIIS data. Configure Group Policies to lock down the account and restrict access to this account. Since the MIIS service only needs the account to run as a service, restrict the account as follows:

    • Deny logon as a batch job.
    • Deny logon locally.
    • Deny logon through Terminal Services.
    • Deny access to this computer from the network.


    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Tuesday, March 25, 2014 7:51 AM
  • To piggyback off of what everyone has said, I would recommend reviewing your current prepared environment once more and the associated service accounts and security requirements per the Installation Guide: http://technet.microsoft.com/en-us/library/ff512685(v=ws.10).aspx

    Many times, failed installation attempts are security related.  You should not be logging on interactively with any of the related service accounts.  As mentioned before, configure and use an appropriate FIM installation account with administrative privileges to the local server, SharePoint (unless you wish to use a separate farm account), and SQL.  Use this account during any installations, configuration changes, or patching.

    Other causes for failed installations or upgrades can be caused by the environment, in which the installer verbose logging or event log would prove useful.


    Regards, Jose Garza | MS: Svr Virt, MCTS:FIM, MCSA:2003 | http://josetheadmin.blogspot.com

    Wednesday, March 26, 2014 6:42 PM

All replies

  • Firstly, make sure you don'y have any issue logged in event log.

    If not:

    Run installer from command line with logging:

    msiexec /i {Package} /L*v {outputfFile}

    Then, open an output file - you can verify what is stopping your installation.


    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Monday, March 24, 2014 6:52 PM
  • Firstly, make sure you don'y have any issue logged in event log.

    If not:

    Run installer from command line with logging:

    msiexec /i {Package} /L*v {outputfFile}

    Then, open an output file - you can verify what is stopping your installation.


    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Hi Dominik,

         Thank you I was able to dump the log but am unsure of what any of it means. If somebody can look over the log and point me in the right direction that would be greatly appreciated.

    Link to log 

    Monday, March 24, 2014 8:17 PM
  • The below looks like your error, what privileges does the account you use to run the installer have?

    Calling custom action Microsoft.IdentityManagement.ServerCustomActions!Microsoft.IdentityManagement.ServerCustomActions.CustomActions.AddServiceToPerformanceMonitors
    Adding FIMService account to 'Performance Monitor Users' group
    Property name = 'ServiceAccount', value = 'domain\FIMSERVICE'.
    DomainName='domain'
    AccountName='FIMSERVICE'
    Domain AD found
    Exception thrown by custom action:
    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.UnauthorizedAccessException: Access is denied.

       at System.DirectoryServices.Interop.UnsafeNativeMethods.IAdsContainer.GetObject(String className, String relativeName)
       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)

    Tuesday, March 25, 2014 12:09 AM
  • The below looks like your error, what privileges does the account you use to run the installer have?

    Calling custom action Microsoft.IdentityManagement.ServerCustomActions!Microsoft.IdentityManagement.ServerCustomActions.CustomActions.AddServiceToPerformanceMonitors
    Adding FIMService account to 'Performance Monitor Users' group
    Property name = 'ServiceAccount', value = 'domain\FIMSERVICE'.
    DomainName='domain'
    AccountName='FIMSERVICE'
    Domain AD found
    Exception thrown by custom action:
    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.UnauthorizedAccessException: Access is denied.

       at System.DirectoryServices.Interop.UnsafeNativeMethods.IAdsContainer.GetObject(String className, String relativeName)
       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)

    Hi Cameron,

        The FIMService account is a member of domain administrators. It is also a member of the following all the fim groups both on the domain and local groups. That account is also sysadmin on the remote sql server and is sharepoint admin. 

    Tuesday, March 25, 2014 12:46 AM
  • Are you are using the FIM Service account to run the installer? This isn't really recommended, and it's usually best to create a dedicated installer account or use a different administrator account to execute this. Remember that the account you use to run the installer by default becomes the administrator account in the portal. 

    Though i'm not sure if this is actually breaking the installer in your case. 

    Tuesday, March 25, 2014 1:06 AM
  • Cameron is right - you should consider FIMService account nearly as normal AD account for user*

    An installer account should be admin on the box, where you are installing FIMService and he should be sysadmin on SQL during installation of FIMService. An installer account should be other than FIMService account itself.

    *FIMService account:

    Lock down the Service Account

    The service account should not be used by any other services or users. The account must not be used to logon interactively and requires no access to any additional resources beyond those granted during setup. The service account is used to provide the security context for the MIIS service as it accesses resources on the MIIS server and the associated database. It also provides the security context for the execution of any rules extensions.

    Lock down the service account to ensure no malicious user is able to sign in using its credentials and gain access to MIIS data. Configure Group Policies to lock down the account and restrict access to this account. Since the MIIS service only needs the account to run as a service, restrict the account as follows:

    • Deny logon as a batch job.
    • Deny logon locally.
    • Deny logon through Terminal Services.
    • Deny access to this computer from the network.


    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Tuesday, March 25, 2014 7:51 AM
  • To piggyback off of what everyone has said, I would recommend reviewing your current prepared environment once more and the associated service accounts and security requirements per the Installation Guide: http://technet.microsoft.com/en-us/library/ff512685(v=ws.10).aspx

    Many times, failed installation attempts are security related.  You should not be logging on interactively with any of the related service accounts.  As mentioned before, configure and use an appropriate FIM installation account with administrative privileges to the local server, SharePoint (unless you wish to use a separate farm account), and SQL.  Use this account during any installations, configuration changes, or patching.

    Other causes for failed installations or upgrades can be caused by the environment, in which the installer verbose logging or event log would prove useful.


    Regards, Jose Garza | MS: Svr Virt, MCTS:FIM, MCSA:2003 | http://josetheadmin.blogspot.com

    Wednesday, March 26, 2014 6:42 PM
  • Cameron is right - you should consider FIMService account nearly as normal AD account for user*

    An installer account should be admin on the box, where you are installing FIMService and he should be sysadmin on SQL during installation of FIMService. An installer account should be other than FIMService account itself.

    *FIMService account:

    Lock down the Service Account

    The service account should not be used by any other services or users. The account must not be used to logon interactively and requires no access to any additional resources beyond those granted during setup. The service account is used to provide the security context for the MIIS service as it accesses resources on the MIIS server and the associated database. It also provides the security context for the execution of any rules extensions.

    Lock down the service account to ensure no malicious user is able to sign in using its credentials and gain access to MIIS data. Configure Group Policies to lock down the account and restrict access to this account. Since the MIIS service only needs the account to run as a service, restrict the account as follows:

    • Deny logon as a batch job.
    • Deny logon locally.
    • Deny logon through Terminal Services.
    • Deny access to this computer from the network.


    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Good topic for a Wiki article: http://social.technet.microsoft.com/wiki/contents/articles/23330.technet-guru-contributions-for-march.aspx

    Thanks Dominic and Jose!


    Ed Price, Power BI & SQL Server Customer Program Manager (Blog, Small Basic, Wiki Ninjas, Wiki)

    Answer an interesting question? Create a wiki article about it!

    Thursday, March 27, 2014 2:24 AM
    Moderator
  • Lock down the Service Account

    • Deny logon as a batch job.
    • Deny logon locally.
    • Deny logon through Terminal Services.
    • Deny access to this computer from the network.


    Good topic for a Wiki article: http://social.technet.microsoft.com/wiki/contents/articles/23330.technet-guru-contributions-for-march.aspx

    Although I appreciate Wiki, I don't think that copying information from TechNet sites to TechNet Wiki would be a good idea :)


    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Thursday, March 27, 2014 7:32 AM
  • Ha! I meant the whole thing.

    Ed Price, Azure Development Customer Program Manager (Blog, Small Basic, Wiki Ninjas, Wiki)

    Answer an interesting question? Create a wiki article about it!

    Monday, January 18, 2016 7:31 AM
    Moderator