1

I have a script to create various services on our dev servers (all Windows 2008 64bit), using sc.exe.

The script includes setting the user account to run the service as, but I can never get the password set correctly. It sets the account name up fine, but whenever I attempt to start the service I get a logon failure. If I manually change the password in the service snap in, it works fine... what gives??

I've tried with and without quotes around the password, no success.

Example of the command I use: sc create PackageProcessing5 binPath= "c:\Program Files (x86)....exe" obj= na\sys-WSPackager password= "password"

Like I said, the service creates successfully, and when I check the snap-in, the user account is correct too. Just the password somehow gets overlooked. I've noticed that if I put an incorrect password in the command line it doesn't complain so I guess it's not validating it at all during creation?

Any ideas here?

2
  • Can you post a test script that demonstrates the problem?
    – SamB
    Nov 29, 2010 at 4:42
  • Never mind, it was trivially easy to reproduce :-(
    – SamB
    Nov 29, 2010 at 16:14

3 Answers 3

1

I think the problem isn't actually related to the password at all: probably you neglected to give the account the SeServiceLogonRight bit (Typically "Log on as a service" in GUIs). I found the name in this Windows XP Resource Kit help page on TechNet See knowledge base article kb259733 (Windows 2000) or kb327545 (Windows Server 2003) for how to do this from the GUI, but I'm assuming you really want to do this from the command line, for which you should look at ntrights.

This is based on my actually attempting to create the same simple service first with my own user account and with an existing service account that I had created earlier. With my own account, I got what I presume to be the same error as you've been getting from "sc start":

The service did not start due to a logon failure.

With the service account, I got this error instead:

The service did not respond to the start or control request in a timely fashion.

I assume this latter error is because the program I tried to start was not prepared to act as an NT service. (If it helps, the sc command that worked did not use quotes around the password.)

FYI, both commands were of the form:

sc create xemacs-beta-repo binPath= "C:\Program Files\TortoiseHg\hg.exe serve -d -R C:\code\xemacs-beta -E C:\code\xemacs-beta.hg-serve.log" obj= Sam10\foo password= bar

where Sam10 is the name of my (Windows XP Pro SP3) system.

I really can't say why re-entering the password in the GUI would fix anything, other than to suggest that it might add SeServiceLogonRight to the account in question -- have you been using fresh accounts each time you tried this, or have you also tried with accounts that you have manually made to work?

1

Add "sc config password= <password>" to your script to set the password of the runas account after "sc create".

I encountered the same problem and fixed it by using "sc config".

1

It needs to be broken into a few commands, try using the Powershell script below.

Basically, it adds a domain account to SeServiceLogonRight then creates and starts a service with a domain account.

  • Note: Powershell needs to be running as admin.

    Powershell Example below is to create a windows Service (In this case TeamCity Agent) and run it as a domain account:

    $accountToAdd = "mydomain\account"
    $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 ""Log on 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
        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 ""Log on as a service""" -ForegroundColor DarkCyan
    }
    Write-Host "Done." -ForegroundColor DarkCyan
    #Create Service and set Credentials
    cmd /c sc create TCAgent5 binPath= "C:\BuildAgent5\launcher\bin\TeamCityAgentService-windows-x86-32.exe -s C:\BuildAgent5\launcher\conf\wrapper.conf" DisplayName= "Team City Agent5" auto obj= account@mydomain Password= mypassword
    

You must log in to answer this question.