Scenario: Running Deployment Scripts that are publishing WSPs into a multi-server farm (2 front-ends, 1 App Server)
Microsoft SharePoint Foundation Web Application Service running in their environment (where the Foundation Web Application is running) is making the deployment go fine, where as the same in our environment is not running, so the script is failing.
Generally, if you run this service in a server, that makes that server as WFE (Web Front End) so, people prefer to have this stopped in App Servers. But there is a dependency on this with the “Microsoft SharePoint Foundation Workflow Timer Service” and since this is running as well in the App Server, the script is trying to deploy the solution in the App Server as well and since the Web Application Service is not running, the script is unable to deploy and throws errors.
Now you have 2 options:
1. To stop the “Microsoft SharePoint Foundation Workflow Timer Service” and re-run the script and try how it works
2. Second, to turn on the Web Application Service on the App Server as well. Though it is not required or generally people don’t do it as a best practice, by leaving it on, it is not taking up any resources or it is not going to make the environment slow. The reason is – users always are hitting the WFEs only and thus the Foundation Web Application Service in the WFEs only invoke the IIS Web Sites, Load up the App Pools and start consuming memory
3. Since direct requests are not going to come to the App Server, the Foundation Web Application Service running in the App Server will never have any job to do: so the memory over here will not be used