May 13, 2011 at 8:29 am
We implemented creating and using AD accounts to run SQL Services so fewer rights are granted but have one particular server where the changes won’t take. The only difference with this server is that it was renamed, and the SQL was renamed using sp_dropserver & sp_addserver after the server was renamed.
Environment and History: A VM machine running Windows Server Std SP2 64bit with SQL Server 2008 SP2 Std. 64bit.
Created 2 AD accounts to run the SQL Services
Added the 2 accounts to the following 3 groups: SQLServer2005SQLBrowserUser$ServerName, SQLServerMSSQLUser$ServerName$MSSQLSERVER, and SQLServerSQLAgentUser$ServerName$MSSQLSERVER
And granted full control to the Microsoft SQL Server directory under Program Files.
Right clicked on SQL Server Configuration Manager and Run as administrator to change SQL Server service logon from the Built-in default account of Local System to the new AD account, but receive the error: WMI Provider Error [call to WMI Provider returned error code: 0x800742a2]
And the application event log adds the following entry:
initerrlog: Could not open error log file ''. Operating system error = 3(The system cannot find the path specified.).
-But the path exists and the groups have full rights to it.
One other thing I noticed is that the groups SQLServerMSSQLUser$ServerName$MSSQLSERVER, and SQLServerSQLAgentUser$ServerName$MSSQLSERVER are still using the “old” server name and were not updated during the server rename, SQL drop/add execution. Should they have been?
We tried creating new groups with the “new” server name, added the two AD accounts in the same manner with full rights on the SQL install folder, but are having the same end result.
But also received this new error when setting the service back to Local System, if it has any bearing: No mapping between account names and security IDs was done. [0x80070534]
I searched the web for help but no resolutions for similar problems helped me here.
Any troubleshooting ideas would be greatly appreciated.
Thank you,
Lori
May 13, 2011 at 9:13 pm
The action will be carried out as you. Do you have permissions to the log folder? I know you're likely an administrator, but you probably want to check permissions. The error is being thrown by WMI because there is a permissions issue at the file system, hence the reason I say to start there.
K. Brian Kelley
@kbriankelley
May 16, 2011 at 9:18 am
Thanks, and yes - full permissions on the Log folder. Actually it's full permission on the folder Microsoft SQL Server a few levels up, but when checking the sub-folders the full permission rights are present.
Any other ideas?
Thank you,
Lori
May 16, 2011 at 11:29 am
Download procmon from SysInternals and see if there's a registry or file system hit that's causing the issue.
K. Brian Kelley
@kbriankelley
May 27, 2011 at 11:53 am
Thanks Brian,
I ran procmon and it gave a huge amount of output. I sifted through it for a few hours but can't find anything conclusive. I tried reducing it to just the services.exe process name with registry and file system activity but I still have over 5k rows. Many of the results indicate buffer overflow, name not found, and file locked with only readers. Can you help reduce the result set filter further?
I also tested the domain service account and the sql server starts up fine when I have it a member of the local admin group, so it definitely appears to be a rights issue.
Thanks in advance!
Lori
May 31, 2011 at 8:55 am
You should be able to drop the registry monitoring because the error being returned is it can't write to the log file. You should be able to filter further so that the you're only looking for hits against the logs folder.
K. Brian Kelley
@kbriankelley
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply