August 5, 2016 at 5:44 pm
I am trying to install SP1 for SQL 2014 and getting the following error:
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
I tried searching for this error and didn't find anything useful. Most results were for SQL 2012 and didn't apply.
Any information would be greatly appreciated.
August 6, 2016 at 1:33 am
August 8, 2016 at 4:35 pm
johnwalker10 (8/6/2016)
not sure but can this help https://social.msdn.microsoft.com/Forums/sqlserver/en-US/c9babbfd-0289-451f-af35-9f3937c3d13e/error-upgrading-sql-2012-sp1-to-sp2?forum=sqlsetupandupgrade
Thanks for the reply.
I looked at that thread you referenced. The part that seemed relevant:
"Database engine system data directory in the registry is not valid"
We had this error occur when trying to install SQL 2012 SP2 on a server on which we had previously moved the system databases using the procedure on MSDN (link modified to allow posting): http- msdn.microsoft.com/en-us/library/ms345408(v=sql.110).aspx)
The SP2 install for database engine components failed - then a repair using the SQL 2012 SP1 media also failed.
Resolved by editing the registry value for HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL11.<MyInstance>\Setup\SQLDataRoot - to update it to the current location of the system databases. (This value was still set to the original folder from the install).
I checked the SQLDataRoot key: It is already pointing to the correct data path.
Though not being anywhere close to being an SQL expert, I noticed the highest version listed in the registry is 'MSSQL12.{instance name}. Is this the correct version for SQL 2014? Shouldn't the number end in 14 and not 12?
August 8, 2016 at 10:35 pm
12 is the correct build number for 2014.
You chose a startup account for your SQL Server 2014 setup, before receiving that setup error. If you logon to the machine as that startup account, run cmd.exe, and execute DIR <your observed SQLDataRoot value>, what response does the startup account receive?
August 9, 2016 at 9:17 am
SoHelpMeCodd (8/8/2016)
12 is the correct build number for 2014.You chose a startup account for your SQL Server 2014 setup, before receiving that setup error. If you logon to the machine as that startup account, run cmd.exe, and execute DIR <your observed SQLDataRoot value>, what response does the startup account receive?
I took this server over, didn't install SQL originally. How would I find that info after the fact?
August 9, 2016 at 8:01 pm
In SQL Server Configuration Manager under SQL Server Services right click SQL Server click Properties. Under Log on as: you will see the startup account. This should be the only place you change SQL Server's startup account. Never change SQL Server's startup account using services.msc. Unlike services.msc, SSCM grants rights and permissions, such as permissions to access SQLDataRoot. Check the folder's permissions for the identified account, and verify it has full control. If you can logon as the account (which is not possible when using a built-in account), you should see why setup raises the error.
There are security implications with using the built-in LocalSystem account as the startup account, because it elevates privileges to far more than what the SQL Server startup account needs. For example, if users have been riskily granted the ability to run xp_cmdshell, they will gain LocalSystem privileges. However, to test setup and/or avoid the issue, if the current account has a known password (or is a built--in account) you could consider temporarily changing the startup account (in SSCM, not services.msc) to the built-in LocalSystem account or your own account, and try setup again. Immediately after setup completes (oragain fails), I recommend reverting the startup account (in SSMC) to what it was, and carefully considering https://msdn.microsoft.com/en-us/library/ms143504(v=sql.110).aspx before making a permanent change (via SSCM).
August 10, 2016 at 11:55 am
SoHelpMeCodd (8/9/2016)
In SQL Server Configuration Manager under SQL Server Services right click SQL Server click Properties. Under Log on as: you will see the startup account. This should be the only place you change SQL Server's startup account. Never change SQL Server's startup account using services.msc. Unlike services.msc, SSCM grants rights and permissions, such as permissions to access SQLDataRoot. Check the folder's permissions for the identified account, and verify it has full control. If you can logon as the account (which is not possible when using a built-in account), you should see why setup raises the error.There are security implications with using the built-in LocalSystem account as the startup account, because it elevates privileges to far more than what the SQL Server startup account needs. For example, if users have been riskily granted the ability to run xp_cmdshell, they will gain LocalSystem privileges. However, to test setup and/or avoid the issue, if the current account has a known password (or is a built--in account) you could consider temporarily changing the startup account (in SSCM, not services.msc) to the built-in LocalSystem account or your own account, and try setup again. Immediately after setup completes (oragain fails), I recommend reverting the startup account (in SSMC) to what it was, and carefully considering https://msdn.microsoft.com/en-us/library/ms143504(v=sql.110).aspx before making a permanent change (via SSCM).
It's set to the built in account 'local system'.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply