The root cause for this error condition is security permissions for the SQL Server service accounts.During installation I chose to leverage the new for 2012, virtual accounts, which are the default configuration option mind you (although I don’t intend and wouldn’t recommend using these over correctly permissioned Domain Accounts).
My biggest concern here is that Microsoft has chosen for the default service accounts during installation to be based on these virtual accounts that later will render the SQL Server instance unusable until you find this post or Microsoft fixes the issue. If an SSRS report user comes to you indicating that they’ve attempted to created a subscription and, although it allowed the subscription to be created, the report subscription failed to be sent via email with the following Status: When troubleshooting, I found that the subscription owner account name did NOT match the Windows account name of the user contacting me.
In the end, the root cause was a domain name change for the affected user.
The login name on the SQL Server hosting the Report Server database still had the old domain name for the user and used that name in the subscription setup, which failed when the credentials were used to generate and send the emailed report.
The quick fix was to execute the following via our SQL Server CMS (Central Mgmt Server): Just a quick self-help note today……if you ever see the error message below with a SQL Agent Job calling an SSIS Package stored in SQL Server (MSDB database) and leveraging a Proxy built on a specific credential, ensure the credential under the proxy has membership in the db_ssisoperator role in MSDB.
Shortly after configuring a new SQL Server 2012 server as a pull subscriber to a publication on a SQL Server 2008 Publisher/Distributor, we began receiving the following error message from the replication agents/jobs: The root cause, after much searching and testing theories, was permissions on the subscriber COM directory.
The fix was to simply grant the account that the distribution agent was running on appropriate write/modify permissions on the COM folder in question ON THE SUBSCRIBER, NOT THE PUBLISHER/DISTRIBUTOR.
Why this was not something done automatically by the replication setup process is beyond me, but once we granted the write permission to the COM folder on the subscriber (likely not necessary, but we also restarted the SQL Agent Job responsible for the distrubution), it all worked. -Patrick Script level upgrade for database ‘master’ failed because upgrade step ‘u_tables.sql’ encountered error 25641, state 0, severity 16.
This is a serious error condition which might interfere with regular operation and the database will be taken offline.
If the error happened during upgrade of the ‘master’ database, it will prevent the entire SQL Server instance from starting.
Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
This causes the SQL Server installation not only to be incompletely upgraded (Data Quality Services, Full-Text and Semantic Extractions for Search, SQL Server Replication, Database Engine Services fail to be upgraded), but also renders the entire database engine instance unable to start as the master database cannot be upgraded. After a bit of digging around, it became apparent that a temporary choice I had made during the initial installation of SQL Server 2012 was the root cause, although in my professional opinion it’s a bug and I’ve submitted a Connect Issue with a provided workaround.