I'm using this script from Ingo Karstein to try and set the Logon as Service right for a userID

param($accountToAdd)
#written by Ingo Karstein, http://blog.karstein-consulting.com
#  v1.0, 01/03/2014

## <--- Configure here
$accountToAdd = "domain\test1"

if( [string]::IsNullOrEmpty($accountToAdd) ) {
	Write-Host "no account specified"
	exit
}

## ---> End of Config

$sidstr = $null
try {
	$ntprincipal = new-object System.Security.Principal.NTAccount "$accountToAdd"
	$sid = $ntprincipal.Translate([System.Security.Principal.SecurityIdentifier])
	$sidstr = $sid.Value.ToString()
} catch {
	$sidstr = $null
}

Write-Host "Account: $($accountToAdd)" -ForegroundColor DarkCyan

if( [string]::IsNullOrEmpty($sidstr) ) {
	Write-Host "Account not found!" -ForegroundColor Red
	exit -1
}

Write-Host "Account SID: $($sidstr)" -ForegroundColor DarkCyan

$tmp = [System.IO.Path]::GetTempFileName()

Write-Host "Export current Local Security Policy" -ForegroundColor DarkCyan
secedit.exe /export /cfg "$($tmp)" 

$c = Get-Content -Path $tmp 

$currentSetting = ""

foreach($s in $c) {
	if( $s -like "SeServiceLogonRight*") {
		$x = $s.split("=",[System.StringSplitOptions]::RemoveEmptyEntries)
		$currentSetting = $x[1].Trim()
	}
}

if( $currentSetting -notlike "*$($sidstr)*" ) {
	Write-Host "Modify Setting ""Logon as a Service""" -ForegroundColor DarkCyan
	
	if( [string]::IsNullOrEmpty($currentSetting) ) {
		$currentSetting = "*$($sidstr)"
	} else {
		$currentSetting = "*$($sidstr),$($currentSetting)"
	}
	
	Write-Host "$currentSetting"
	
	$outfile = @"
[Unicode]
Unicode=yes
[Version]
signature="`$CHICAGO`$"
Revision=1
[Privilege Rights]
SeServiceLogonRight = $($currentSetting)
"@

	$tmp2 = [System.IO.Path]::GetTempFileName()
	
	
	Write-Host "Import new settings to Local Security Policy" -ForegroundColor DarkCyan
	$outfile | Set-Content -Path $tmp2 -Encoding Unicode -Force

	#notepad.exe $tmp2
	Push-Location (Split-Path $tmp2)
	
	try {
		secedit.exe /configure /db "secedit.sdb" /cfg "$($tmp2)" /areas USER_RIGHTS 
		#write-host "secedit.exe /configure /db ""secedit.sdb"" /cfg ""$($tmp2)"" /areas USER_RIGHTS "
	} finally {	
		Pop-Location
	}
} else {
	Write-Host "NO ACTIONS REQUIRED! Account already in ""Logon as a Service""" -ForegroundColor DarkCyan
}

Write-Host "Done." -ForegroundColor DarkCyan

If I login to each server an execute this script the ID is added to the Logon as Service group, but I've been trying to execute this script from my local machine to add this ID to the group on a few servers but the ID is not being added and the logfiles indicate that the script is hitting this else statement 

else {
	Write-Host "NO ACTIONS REQUIRED! Account already in ""Logon as a Service""" -ForegroundColor DarkCyan
}

Anyone any idea why this is happening or can I force this script to execute rem

Hi pmcm,

out of curiosity: Why are you trying to do this using PowerShell? This is the kind of task group policies shine at.

1. Add a Policy setting that creates computer-local group named "Logon as Service Users"
2. Add a policy setting that assigns "Logon as Service" permission to the local group created in step one (watch the order, in which those steps are taken, for obvious reasons)
3. Now when you need to assign these permissions to a user on any given computer ABC for the first time, you create a ActiveDirectory-local security group (let's call it LogonAsService-ABC) and add it to the local group created in step one (Now this is where I'd use a powershell function. It's trivial to code).
4. Finally, whenever you want to grant these permissions to a user, you just add him to the specific group in active directory.

This approach has the nice bonus of keeping all real permission assignments in one place and thus makes those a lot more managable (Imagine your boss asking you 2 years down the road, what user has which permissions on all computers in the company. Trivial if it's all in the AD. Less so if you need to check each computer).

Cheers,

Normally we do this with Group Policy. Just add the user in GP and it will be set to all systems covered by the policy filter.

You cannot remotely manage this and it will create amny other issues.  SECEDIT will not work remotely by design.  Group Policy has extensions which allow it to do this.

You might be able to accomplish it using a scheduled task although I have never tried that with secedit.

But trying to kickstart a new way to do things in our workplace can be challenging.

Too true, too often, alas.

However, I have found group policy to be an excellent way around this, since with group policies inertia is on your side for a change. Also if you are using scripting for tasks - which judging by this post you apparently do - this means that once it's written down, most people don't try to change a thing unless it's absolutely broken. This means you ought to be able to simply do this on your own (you do have access to the gp, right?) and have it work. Afterwards ... who would change a running system that takes less effort to use without being a radical usage change?

After all, with the solution you are attempting in the original post, they'd still need to specify some informations (User and ComputerNames) and run the script. This would mean both paths have the same end user experience.

Cheers,
Fred

Even Group Policy cannot do this with a script.  You just need to add the users to the security policy and attach the GPO to the computer container(s) where you want to update the services.

I recommend that you create custom domain accounts to use as service accounts.  WS2012 can directly manage the passwords of these accounts.

https://technet.microsoft.com/en-us/library/hh831451.aspx?f=255&MSPPError=-2147217396

Even Group Policy cannot do this with a script.  You just need to add the users to the security policy and attach the GPO to the computer container(s) where you want to update the services.

I recommend that you create custom domain accounts to use as service accounts.  WS2012 can directly manage the passwords of these accounts.