5

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.

  • 1
    Does this path N:\SQL\DATA\MPData7\ exist? If not create one and see if failover succeeds now. – SQLPRODDBA May 13 '16 at 5:42
  • In addition, confirm that the SQL Server service account has full control permissions over that location. – Nic Oct 18 '16 at 2:31
1

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.

  • I wouldn't hold my breathe waiting for continued feedback from troubleshooting; one way or another, the OP's problem is probably no longer active, after more than 2 years. – RDFozz Jan 5 '18 at 18:07
-1

Try to run Repair on Passive node once that come clean try to failover to passive node, once failover test complete successful then try to apply SP3. Also make sure you have SQL Server service account is LOCAL ADMIN on both NODE.

  • Local admin is a security hole, and not recommended (or required). – Nic Oct 18 '16 at 2:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.