We help IT Professionals succeed at work.

SQL Server (SQLEXPRESS) won't start

We've recently took an image of a Windows Server 2008 server and restored it to different computer with identical hardware.  Now the service for SQL Server Express 2008 won't start.  Why?
Watch Question

Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooter

Few places I'd check for hints:
  Windows System Event Log, Windows Application Event Log, and the Log\Errorlog files under the MSSQL install directory.

A few possible causes:
  The account under which SQL is running doesn't have permissions to the critical databases: Master, mssqlsystemresource, and Tempdb.
  The location of those critical files aren't EXACTLY the same, and SQL can't find them.
  One or more of those critical databases are corrupt.
  The account under which SQL is running doesn't have permission to run the application at all.

But I'd hate to be guessing.  Look over the three logs, and see if they give a clue.


The application log reports ...
"initerrlog: Could not open error log file 'D:\SQLServerData\MSSQL10_50.SQLEXPRESS\MSSQL\Log\ERRORLOG'. Operating system error = 5(Access is denied.)."
SQL Server is installed on the c: partition of the source computer, as is the operating system.  Only the SQL Server Data and other data is on the d: partition.
I took an image of the c: partition and restored it to the target computer.  However, I only copied the "'D:\SQLServerData" folder to the D: partition of the target computer.  I had to stop the SQL Server Service to do this.  The service logs in as "Network Service".  Why wouldn't the target computer be able to access the error log?
Professional Troublemaker^h^h^h^h^hshooter
I just confirmed on a standard installation of Windows 2008 here, and NETWORK SERVICE doesn't have any special permissions to a folder created under the root of a volume.  Looks like SYSTEM would, and the Administrators group would.  Members of the Users group would only have read access.

When you copy from one volume to another, the directory would acquire the security permissions of the destination volume.  (So, in this case, moving the directory from C: to D:, it wouldn't keep the same permissions... it would acquire the permissions of the root of D:\.)

As a suggestion, look at the permissions assigned to the directory on the C: drive, and recreate those permissions on the directory on the D: drive, and try restarting SQL again.  There may be additional issues, so there may be multiple iterations of going back to the logs and figuring out why it won't start.


I actually copied the directory from D: of the source computer to D: of the destination computer.  It works when I give "NETWORK SERVICE" "Full control" permissions.  Why would "NETWORK SERVICE" have access on the source computer without being listed in the list in the permissions for the folder?  The only users listed for the data folder on the source computer are Creator Owner (no permissions), system (full control), Administrators (full control), and Users (read permissions).
Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooter

Check the 'Log' directory on the source, and confirm that the installation program didn't grant NETWORK SERVICE permissions above read.

Using a normal copy to copy files from one computer to another does not preserve NTFS permissions.
Many backup programs will preserve those permissions... so when you perform a restore, the permissions are correct.


The errorlog file itself on the source has permissions for NETWORK SERVICE even though the folder doesn't.  Thanks for the help.