Video Screencast Help
Backup Exec

Backup Exec Install Blog (A Common SQL 2008 R2 Upgrade Failure)

Created: 18 Jun 2014 • 2 comments
Nick Elmer's picture
+1 1 Vote
Login to vote

Today's blog is designed to help some of our customers with an issue they may experience during the upgrade to Microsoft SQL Server 2008 R2 Express with Backup Exec 2014. We are seeing a number of failures that return the following error in the install log: "Failed to install SQL Express BKUPEXEC instance with error -2067922409". If you review the summary.txt for the SQL Server 2008 R2 Express install failure, it will have an error like this "One or more selected features for upgrade have failed the SID check."

What does this mean? Well, the SQL 2005 Express installs (which were done by previous Backup Exec installs) created a few NT security groups for managing access to the Microsoft SQL server services. You can see these groups by going into "Computer Management" MMC snap-in and expanding the "Local Users and Groups" item, and clicking on the groups item. Within that item you should see items like "SQLServer2005MSSQLUser$BEMACHINE$BKUPEXEC",  and "SQLServer2005SQLBrowserUser$BEMACHINE " where "BEMACHINE" is the name of the computer that Backup Exec is installed on, and BKUPEXEC is the name of the named SQL instance that Backup Exec is using. These security groups have unique SIDs (Security ID's) which is how Windows knows them behind the scenes. If the groups are deleted and re-created, they will obtain a new SID generated at creation time by Windows. A SID looks something like this "S-1-5-21-2866118670-3898470722-3192775716-1004"

Microsoft SQL Server 2008 R2 Express upgrades started by Backup Exec 2014 may receive the failures mentioned above if the machine was renamed, promoted to a domain controller, or demoted from a domain controller. Any activity that changes the name of the machine, or changes the local security groups (which promoting and demoting does), will cause the upgrade to fail. This is because SQL 2008 needs to confirm that the group still exists. If the machine name has changed, then SQL can no longer locate the group to validate its permissions and therefore it halts the upgrade with the specified error. This requires user intervention to address.

The technote above shows how to obtain the unique SID for the SQL Server NT Security Group. That SID needs to be updated in the registry so that SQL can locate and validate the group during the SQL upgrade. Once the SID is obtained for the existing or newly created group, it will need to be placed into the SQLGroup registry value for the SQL Instance being upgraded. For all of my test cases, the only registry value out of sync causing the failure was the "SQLGroup" value. Once I obtained the appropriate SID for the SQLServer2005MSSQLUser$MYPC$BKUPEXEC and placed it in the SQL Group registry value for our instance, the upgrade continued successfully.

I hope this helps some of you understand why this is happening and how to correct it.
Nick

Comments 2 CommentsJump to latest comment

cmbezln's picture

Same thing happened to me.  deleted and readded the group and downloaded pstools to use psgetsid.exe for the aforementioned group and updated the registry values.  Of course now I have to restart our file server, so its not going to happen until tonight and I'm going to miss out on a day of backups.  Always an issue with BE.

0
Login to vote
Nick Elmer's picture

Contrary to popular belief, we do spent a fair amount of time trying to minimize reboots. When it comes to third party components, our hands are tied. Sorry to hear about your delay and thank you for the feedback.

Nick

0
Login to vote