During this week I was installing a new SharePoint infrastructure for one of my customers. The installation procedure went as expected and we were able to configure the complete environment using the central administration. However, after a reboot of the web front-end machine, IIS 7 returned a 503-Service Unavailable HTTP status message. SharePoint was not functioning anymore…
That meant… troubleshooting. You might imagine what I was thinking at this moment. The SharePoint logs didn’t tell me anything. I only noticed that the application pools of the central admin were stopped after the first hit on the web application. In addition, the Windows logs returned a Windows Process Activation Service (WAS) error. I started looking in every possible layer of SharePoint and after two hours I finally found an interesting article an article that described a similar issue.
In short, it may be the case that a domain group policy overrides an essential permission of the application pool accounts called “Log on as a batch job”. Without this permission, the application pool account is not able to run the application pool.
I was checking the local group policies of the web front-end and I finally found the problem. The application pool account was indeed not listed under the “Log on as batch job” policy. In addition, the farm administration account and all other service accounts that are running the SharePoint services were not listed in the “Log on as a service” policy. These policies were overridden the first time after the server restart with more restrictive domain policies.
The solution of the problem was simple now. It was only necessary to add all application pool accounts to the “Log on as batch job” domain policy and the service accounts (such as the farm administrator) to the “Log on as service” domain policy. After these changes, it was only necessary to force the policy upgrade on the web front-end by using the “gpudate /force” command. We checked again the local group policies and finally these reflected the settings that we needed. After a reboot of the web front-end, SharePoint was finally working as expected.
Hope this helps,