I am currently working on a project for which the Apache web server is preferred, but Windows is mandatory. I have not used WAMP for some years, but I believe these days that it works well and is stable. We have four web servers, each in two load-balanced pairs. Apache is being run as a Windows Service.
A colleague has found some information that says it is safer to run Apache under a custom account rather than the "Local System Account". So, a local account has been created on each box and the credentials entered into the "Log On" tab in the Service Properties dialogue box.
From time to time when the Apache configuration changes, I need to restart each service. To do that I select the Apache2.4 entry in the Services window and click on the restart button. However, for all boxes, it is touch-and-go as to whether it will be successful. When it fails, I get a Windows error that says:
Windows could not start the Apache2.4 service on Local Computer.
Error 1069: The service did not start due to a logon failure.
So, I dutifully add the service password in again, whenever this happens, and then it always starts up. One guess I have is that the dialogue is forgetting the password it has been given. It does not ever forget the username.
I have examined the permissions given to this local user in Local Security Policy -> Local Policies -> User Rights Assignment -> Log on as a service Properties, and found that the user is in there normally, but if it becomes missing, then an Apache restart will fail.
When researching this, I found this identical scenario (although the service in that case is PostgreSQL). However, the accepted answer of using the Local System Account is not an answer to the question posed, in my view. The question ought to be: why does the user lose the right to log on as a service?
It is not required to restart Apache HTTP Server in order to reload the configuration, you can just run
This way, only child Apache HTTP Server processes will be restarted and your server won't miss a request.
If those windows servers are members of a domain then it's possible that some group policy is overwriting this "logon as a service" local policy.
Having discussed this with a colleague, we are pretty sure that Group Policy is modifying things, as bcs78 says. We're also informed we have no chance of getting the Policy changed.
We have:
I've lost track of exactly which servers the issue has happened on, but it is quite possible it is just the AD servers (2) and (3). Since these are LAN servers and behind a firewall, we've taken the decision to switch these back to run Apache as "Local system account".
We are hoping that the front facing web servers in (1) won't be affected by this Policy, so we can keep the configuration we prefer there.