So as a quick fix for me to remember, while performing and on-premises upgrade to the latest cumulative update for SharePoint 2013, I kept getting a failure. The error was related to the “SUBSCRIPTION” database only.
The actual message being displayed was found a little further down.
So you would think I just needed to change the account I was using, but then I checked I was using an account that had all the right permissions. I tried this upgrade using the “Farm Account“, “Administrator” and the core “Setup” accounts, which all had the right permissions to SQL. My “Farm Service” is only set with “dbcreator“, “public” and “securityadmin” roles, whereas the setup account has “dbcreator“, “public” and “sysadmin“.
Surely one of these accounts should have worked but every time it failed. So I checked the “SUBSCRIPTION” database and my accounts were listed as expected.
The “dbo” one is actually my setup account, tied to a “Windows Account“. Looking further into the accounts within the “SUBSCRIPTION” database I noticed that the default schema I had associated to my setup account was “dbo” so at least it had one set.
Next I checked what schema it owned and to my surprise it did not own “dbo” for this database. If fact it didn’t own any of them. So I checked “db_owner” which is the one that the upgrade was complaining about. It kind of made sense really, it could not make changes to it as the account supposedly had no permission to it, which in reality it had more than enough permissions but did not own it.
Once I set this and re-ran the upgrade command it completed successfully.
So note to self really, make sure the permissions are set as needed and the database schemas are owned by the right accounts.
Attempting to set up SP 2013 on Windows Server 2012 R2, I ran into this error when attempting to configure the MMD service via Central Admin. The MMD database got created, but then the service provisioning failed with the subject error message in the Log files on the 15 hive. My “dbo” account was not tied to my SPAdmin account but to the SQL Server SA account. However, the SPAdmin account had not been added to the DB that got created (though SPFarm account was there). Your post suggested to me the idea of adding the SPAdmin account to the DB and granting it db_owner permissions as well as making it the owner of the dbo_owner schema.
I then went back to SP and completed the provisioning of the MMD service using powershell instead of CA, so that I could connect to the existing DB rather than let the CA provisioning wizard try to make a new DB (and fail).
Thank you. I wouldn’t have had that idea without your help.
You must log in to post a comment.