KB ID 0000878
This problem started when a client attempted to add a ‘distribution point’ for System Center onto the server. This process failed, then Outlook Web Access stopped working. First line found that the World Wide Web service was not running, when they attempted to start it, this happened;
Windows could not start the World Wide Web Publishing Service service on Local Computer. Error 1068: The dependency service or group failed to start.
Fair enough, the dependency in question was the Windows Process Activation Service. When they attempted to start that, this happened;
Windows could not start the Windows Process Activation Service service on Local Computer. Error 183: Cannot create a file when that file already exists.
This was a nightmare of a problem to troubleshoot, and IIS architecture is not my subject of choice. I was pretty much convinced the error was in a config file or a setting had been changed but where?
I restored the IIS config files from the servers own backup, and from before the error started, still the services refused to start.
Time to spin up Process Monitor. If you’re unfamiliar with Process Monitor, it is to Windows what Wireshark is to network traffic. Here I’m using it to get a ‘snapshot’ of everything that’s going on when the error occurs.
1. Run Process Monitor > Start it capturing data > Attempt to start the Windows Process Activation Service > Wait for the error > Stop the capture.
2. You will have a LOT of data, so lets narrow it down. On the properties of the service, you can see to launch, it runs ‘svchost.exe -k iissvcs’. Add in the Command Line Column, then add a filter to show only results for that command.
3. Normally at this point you would go through the results column and look for errors, e.g. access denied, not found, etc, but they all looked OK. However it was apparent that it was parsing the WebDAV_schema.xml file as it should, but before it did that, it also was reading WebDAV_schema – Copy.xml.
The copy was ‘moved elsewhere’.
4. At this point, the good folk at Microsoft came back and said they had been thought the applicationHost.config file and the bindings ‘didn’t look right either’. So we took a backup.
5. The bindings for port 80 (http) and 443 (https) were set to the default.
At this point the services could be started without error, and the problem was resolved.
Which of the two changes fixed the problem? The honest answer is “I don’t know”, what I do know is there was nothing I could find on the internet that helped in any way. As I had a backup of the applicationHost.config file I could compare the two see see what Microsoft meant by the bindings ‘not looking right’.
Related Articles, References, Credits, or External Links
Kudos to Mark Russinovich and Bryce Cogswell for Process Monitor