I'm trying to update a cluster to SQL Server 2008 R2 SP3. I've installed SP3 on the passive node but when I failover the cluster it errors when running through it's upgrade scripts. The messages & error messages from the SQL Logs when it's back on it's happy node are as follows:
Msg – Exporting ##MS_AgentSigningCertificate## to N:\SQL\DATA\MPData7\MS_AgentSigningCertificate.cer
ErrMsg – Could not export certificate, trying again with random name. If this is a mkmastr build then this is an error.Exporting ##MS_AgentSigningCertificate## to N:\SQL\DATA\MPData7\MS_AgentSigningCertificate2DC9C8FF-1B52-4B40-8F59-6B7714201D43.cer
Error: 15240, Severity: 16, State: 1.
Cannot write into file 'N:\SQL\DATA\MPData7\MS_AgentSigningCertificate2DC9C8FF-1B52-4B40-8F59-6B7714201D43.cer'. Verify that you have write permissions, that the file path is valid, and that the file does not already exist.Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step 'sqlagent100_msdb_upgrade.sql' encountered error 15240, state 1, 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.
There are other error messages related to not being able to recover the master database but I'm not worried about them.
On reviewing the error messages I can see that the path the certificate is trying to be exported to is not the same as the default data path for the instance.
The default path for the instance is N:\SQL\Data\MPData5 which I can see from the server properties and the registry. The SQL Server service account has full read/write access to that path.
Best Answer
If (the path to the master database or system databases (including certificates) exist and the SQL Server domain account have the appropriate permissions) Then (Look into further troubleshooting by introducing the global trace flag 902. This skips script upgrade of the database after a SP or CU patch upgrade. See link: https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql .This will let you know if your patch on the passive was actually successful. If cluster still fails to come online, then its either a permission or an unusual install. Can you check the setup bootstrap logs on the passive node to confirm that the patching was indeed successful. Check the Detail_%datetime%.txt and the Summary_%datetime%.txt files to confirm this. Let us know what you find to continue troubleshooting.