SQL Server 2022 CU Updates and Error Code 0x851A0043

I’ve been working in the Azure space for the last few years and less with full server installations. Azure leaves file locations out of my control, but I recently had a client upgrading an on-prem server to SQL 2022.It was a fresh installation on a new VM. I installed SQL, restored all the data, then I moved files to their optimal locations. This was a fresh installation of SQL Server and I wanted to move all of the data files, log files and tempdb files to their own drives. I also wanted to move the system databases. The documentation cautions that cumulative updates (CU) could fail if a specific registry key isn’t updated after moving the master files, so I wanted to test this before I spent too much time configuring the server.

An excerpt of that warning follows here.

In that hive, change the SQLDataRoot value to the new path of the new location of the master database files. Failure to update the registry can cause patching and upgrading to fail.

That sounds serious, so I updated the registry key with the new master data file path.

The Error

I got the following error when I ran the latest CU installation after moving master. Maybe this is why other systems I examined hadn’t relocated files for the master database, or maybe it isn’t a common practice, but it stopped the upgrade and left the system at the base version.

The error reads as follows. It gives a clue to the solution, but it isn’t the registry path defined in the documentation:

Error installing SQL Server Database Engine Services Instance Features

The User Data directory in the registry is not valid. Verify DefaultData key under the instance hive points to a valid directory.

Error code: 0x851A0043

The Fix

In my production system and my two test systems, the issue was always a missing registry key. It wasn’t a misconfigured key, the key needed to be added. Once the following key was added and configured to point to the directory for my master data files, the CU installation worked.

1. Open Registry Editor and navigate to the MSSQLServer subkey (directory) that corresponds to your version of SQL Server.

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQLServer

• 1. If you aren’t sure of the version number, check the @@version variable in SSMS.

SELECT @@VERSION

1. Check for the string value “DefaultData”. If it is present and the value corresponds to the location of your master files, you have a different problem.

1. Backup this subkey by using the Export function. There are a lot of things in here that impact the behavior and functionality of SQL Server. We are just adding a new key, which is safe, but it’s better to have a backup.
2. Add a new “String value”, DefaultData, as shown in the screenshot above. Populate the value with the path to your master file. You can see mine in the screenshot above.
   1. I used two different laptops to test and validate these steps, so everything is on the same physical drive. I just used different paths to test this issue. On a server, you should separate your data, log, tempdb, backups, and possibly other files and databases depending on the actual server load.

That’s it. It’s just a registry key that isn’t created during the installation or using the SQL Server Configuration Manager. Once that value is present and configured correctly, you should be able to install your CU.

Documented steps

The Microsoft documentation is very thorough, and the process is easier than in earlier versions of SQL Server. But if you run into this problem, you know where to start looking. Older documentation lists this key, which is how I found it (eventually). The real reason I found the key is that there was a DefaultLog value, but not a matching DefaultData value.

If you move the master database, remember to follow all the steps in the documentation, in addition to adding this key. Updating the locations in the SQL Server Configuration Manager sets another registry key used by SQL during the startup process. You won’t even get SQL to start if you move the files and don’t update those entries, so read each step carefully.

Be sure to verify your file locations after making system changes like this. If you copy your files instead of moving them, you’ll know right away if something is misconfigured. The following script will show all of the files on your system and their locations. This is useful for validation and troubleshooting.

USE master
GO
SELECT
	 DB.name				DatabaseName
	 ,MF.file_id
	 ,MF.type_desc
	 ,MF.name				FileLogicalName
	 ,MF.physical_name		FilePhysicalName
FROM sys.master_files MF
	INNER JOIN sys.databases DB
		ON MF.database_id = DB.database_id

The file locations should match your expectations before you start using the system.

Summary

Moving files for the system databases is a common task on a new SQL Server system. You could make the argument that the files don’t need to be moved, but I think it simplifies some troubleshooting tasks if you have I/O issues. I’ve also worked with administrators that use the system databases for auditing activities, which increases the I/O load and also warrants changing their location.

I wasn’t expecting the amount of troubleshooting I had to perform to move the files and still be able to apply patches to the system. Luckily, it’s a very easy fix once you know that it’s a missing registry key and hopefully will be simplified further in future versions of the CUs or at least in the official documentation.

References

https://learn.microsoft.com/en-us/sql/relational-databases/databases/move-system-databases?view=sql-server-ver16

The post SQL Server 2022 CU Updates and Error Code 0x851A0043 appeared first on Simple Talk.