Installing SQL Server in a High-Security Domain, Part II

In this article, I pointed out some of the most common permissions failures when installing SQL Server in an environment where security has been hardened, such as the removal of the Debug Programs permission. In my experience, "hardened" usually means some default permissions have been removed from various accounts.

Recently some colleagues had failures while attempting to install SQL Server 2008 R2 on a VMware virtual Windows cluster, even though they had ensured their installation account had the 3 privileges I covered in the previous article. One of the difficulties with these types of failures is that you don't get an error saying something clear like "Sorry, you don't have the Debug Privileges permission," so it can be a little troublesome to figure out exactly which permissions are missing, if any. In this case, my colleagues were able to successfully install SQL Server after adding the "Act as part of the operating system" and "Logon as a service" permissions to the installation account. I'm going to repeat myself to emphasize they added these permissions to the installation account (the account they were logged in as while running the installer). That difference allowed their install to succeed, but if you use this remedy, remember to remove those permissions from the installation account after you finish the install.

Did they need both of those are just one of them? We don't know, they didn't uninstall and reinstall with just one of them to narrow it down. If you gain any insight on what security settings cause this problem, and whether or not only one of these permissions is needed to succeed, please let me know.