I've installed PostgreSQL 9.1 x64 on a Windows 7 Enterprise x64 system using the usual install method. The computer has a Novell Client for Windows, and a ZENworks Adaptive Agent, which I suppose externally manages some of the users/policies for the system. I've installed postgres on several Windows computers, so I'm a bit surprised that this system is behaving differently.
When the computer reboots, the PostgreSQL Service does not startup. The full message from attempting to start the service is:
Windows could not start the postgresql-x64-9.1 - PostgreSQL Server 9.1 service on Local Computer. Error 1069: The service did not start due to a logon failure.
I can then go to the properties for that service, in the "Log On" tab, retype the password that was originally used with the installer.
When I click OK, a dialog appears:
The account .\postgres has been granted the Log On As A Service right.
which sounds great. I can then correctly start the PostgreSQL Service and continue on. The problem is when I reboot, I need to go to manage the service, retype the password and manually start the service again.
Viewing the "User Rights Assignment" in "Local Security Policy", I see that the "Log on as a service" is wiped after each reboot, leaving only the default "NT SERVICE\ALL SERVICES". This is what I see on a fresh reboot:
I can then manually add the COMPNAME\postgres
user to this dialog to start the service, but it disappears on the next reboot.
Is the problem that the "Log On As A Service" privileges is wiped by the Local Security Policy, or is there something up with the Novell Client/ZENworks Adaptive Agent? Are there any other strategies to make the "Log on as a service" privileges stick for the .\postgres user?
Another way, may be password of user 'Postgres" (user Windows) has been changed. So, go to the "Log On" tab for the postgres service, Log on as .\postgres (no change), then retype correct password.
The fix was simple. Go to the "Log On" tab for the postgres service and change the selection from "This account" to "Local System account" (second figure in my question). Works perfectly now.
Another way to fix this seems to be changing the startup type of the service from Automatic to Automatic (Delayed Start). I am not sure why this fixes the problem but maybe one of the other services is needed to 'Log on as a service'