The purpose or goal of this document is to provide additional assistance, or guidance to the actual Forefront Identity Manager 2010 installation guide. It is meant as a companion document to help in the preparation of your installation of the Microsoft
Forefront Identity Manager 2010 product.
This document is more of a guideline to help make the installation easier.
This is a suggested account, not a mandatory account. The reason it is suggested, is because the installing account needs to have some elevated privileges to get the product installed.
Based on your FIM Solution, you may want to create some other accounts. Here are some other possible accounts that you may consider creating prior to executing the installation of the Microsoft Forefront Identity Manager product.
*NOTE: Remember these are just suggested names for the accounts, and suggested that you create them prior to executing the installation.
The below accounts are very commonly used accounts for common solutions, such as Self-Service Password Reset (SSPR) and GalSync. If your FIM Solution is going to work with other data sources, you may consider creating those accounts now. For example,
if you are incorporating a SQL Server Management Agent you may want to create an account to work with SQL Server, or if you are working with SAP, yu may want to get the SAP Management Agent Account created at this time.
*NOTE: Be sure to apply to Descendent User Objects
Thank you--this is useful. And now I'm going to ask for more. :-)
Would you be able to address which service account should be used when installing the password reset portal please? I'm not sure I'm clear on how that account needs to be configured or if it's OK to just use an existing service account. Thank you!
Great article. I always recommend the installer account to avoid dependencies on a specific person, especially with SharePoint. That should really make it into the product docs.
One note about permissions,..Making someone a domain (or local) admin won't automatically give them SQL permission unless it was configured that way during SQL install. It was that way in SQL 2005, but changed in 2008 I believe.