SharePoint installs can always be fun and interesting when you are trying to set it up in a least-privileged environment.  For the most part, you need all sorts of permissions, most of which are poorly documented (I really need to find a script I can just run that will enable ALL the exact permissions a SharePoint farm and service account should have).  Most resolutions for issues I’ve encountered when trying to install SharePoint end up with “Make the install account local admin.”

Every once in a while though I manage to track down the exact issue and what needs to be done in order to fix it.

When I was doing a scripted install the other day, I ran across this little gem:

“The process does not possess the ‘SeSecurityPrivilege’ privilege which is required for this operation”

In this case I was able to track it down to a Local Security policy that had to do with restricting the account’s ability to manage the auditing and security log.  This is often caused by specific permissions that have been enabled or disabled through a Group Policy Object (GPO) that has been deployed to the network.

The solution is to update the LSA and give the installation account the rights needed for “Manage auditing and security log

Manage auditing and security log

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment


Determines which users can specify object access auditing options for individual resources such as files, Active Directory objects, and registry keys.

A user with this right can use the security tab in the security permission set editor’s Properties dialog box to specify auditing options for the selected object.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

By default, only administrators have the privilege to manage auditing and the security log.

Once that was enabled the install went through.