We were experiencing trouble installing SQL Server 2014 onto a Windows 2012 R2 VM. These are new production boxes so I was being very careful. The problem manifest itself in two ways:
- A clean installation using our service account got almost all the way through and then failed with the Unauthorized Operation message. It was painful to get out of the installer. I would just hang on a cancel and then eventually exit.
- Installing using Local System worked but then we couldn’t switch to use our service account. We received the same error. This error included an 0x80070005 error code.
I have a number of other SQL Server 2014 installations on Windows 2012 R2 so this surprised me. The detailed error log included this:
Slp: Sco: Attempting to open service handle for service MSSQLSERVER Slp: Prompting user if they want to retry this action due to the following failure: Slp: ---------------------------------------- Slp: The following is an exception stack listing the exceptions in outermost to innermost order Slp: Inner exceptions are being indented Slp: Slp: Exception type: Microsoft.SqlServer.Configuration.Sco.ScoException Slp: Message: Slp: Attempted to perform an unauthorized operation. Slp: HResult : 0x84bb0001 Slp: FacilityCode : 1211 (4bb) Slp: ErrorCode : 1 (0001) Slp: Data: Slp: DisableRetry = true Slp: Inner exception type: System.UnauthorizedAccessException Slp: Message: Slp: Attempted to perform an unauthorized operation. Slp: HResult : 0x80070005 Slp: Stack: Slp: at Microsoft.SqlServer.Configuration.Sco.Service.StartService(String[] startParams) Slp: ---------------------------------------- Slp: User has chosen to retry this action
A search through the Internet revealed a number of possibilities. I tried to run the installation as Administrator. I wasn’t very hopeful on that since the first thing the installer does is pop up the UAC prompt. Someone also suggested disabling the UAC functionality. I didn’t try that. We also copied the installation media of the mounted DVD into a regular directory. That didn’t help either.
We finally discovered that the team that preps the VMs was now removing both “ABC\Domain Users” and “Authenticated Users” from the local “Users” group. And that was the issue. Putting the service account back in that group fixed the issue.