Hi
I have seen this issue when building a multi server farm on using SQL Server 2012 as the back end database. I am running as best practice (separate install and farm accounts). The install account has public, dbcreator and security admin roles in the database. As pointed out in this script the four databases in question are all owned by the farm account, whereas the other databases are owned by the install account. At the point the script attempts to add the user users (managed accounts) to the profile database it fails as the install account does not have the necessary permissions in these databases. It will also fail (as pointed out above) if you try and run the power shell manually as the install account (for the same reason). Now, many users will not see this error, particularly if they run the install (incorrectly?) under the farm account credentials - in this case all databases will be owned by the farm account and the script has the necessary permissions to add the other users. I believe script will also work correctly if you give the install account sysadmin permission in the SQL database for the install (and then remove it afterwards).
In this case the database server was prepared in advance by another team in readiness for the SharePoint install. While we do not believe there is any special policy or server role customisation in play I cant rule it out.
I'll leave it to better minds than me to work out which is the more sensible approach or to consider if there is actually something that needs updating in the script / approach here.
Cheers
Adrian
I have seen this issue when building a multi server farm on using SQL Server 2012 as the back end database. I am running as best practice (separate install and farm accounts). The install account has public, dbcreator and security admin roles in the database. As pointed out in this script the four databases in question are all owned by the farm account, whereas the other databases are owned by the install account. At the point the script attempts to add the user users (managed accounts) to the profile database it fails as the install account does not have the necessary permissions in these databases. It will also fail (as pointed out above) if you try and run the power shell manually as the install account (for the same reason). Now, many users will not see this error, particularly if they run the install (incorrectly?) under the farm account credentials - in this case all databases will be owned by the farm account and the script has the necessary permissions to add the other users. I believe script will also work correctly if you give the install account sysadmin permission in the SQL database for the install (and then remove it afterwards).
In this case the database server was prepared in advance by another team in readiness for the SharePoint install. While we do not believe there is any special policy or server role customisation in play I cant rule it out.
I'll leave it to better minds than me to work out which is the more sensible approach or to consider if there is actually something that needs updating in the script / approach here.
Cheers
Adrian