So I have a history of getting interesting projects, whether they start out relatively simple or are complex from the start. Sometimes, the seemingly standard/not-out-of-the-ordinary deployments end up with the most obscure problems. So far, I've only seen this happen once and was able to recreate it the issue as long as the same Active Directory information was used.
Background on the scenario:
Install any OCS role that depends heavily on WMI (practically all of them - the only roles not affected were the Archiving, Monitoring, and Communicator Web Access roles) on a Server 2008 SP2 server with .NET 3.5 SP1 and the usual post-3.5 SP1 updates (KB
958481 +
958483 +
958484).
Upon reboot, the networking stack would not come online and the system would stall during logon at the "Applying Internet Explorer Policy" or "Preparing Desktop". After waiting for the failed services to finally stall out (varies per server role), you will notice that most or all of the OCS related services are stuck at 'Starting'. RDP will be unavailable. The network icon will show as if the cable is disconnected.
If you set all the OCS services to 'Manual' and reboot, everything will start up normally. If you log in and start up the services manually, everything works fine. Obviously, this isn't an ideal setup for a production server.
During a sleepless weekend of research, I bumped into a few others that had experienced the same issue, most notably
here. We ended up using the work around of placing all the OCS services dependent on wmiApSrv. In addition to that, we also changed the services startup from "Automatic" to "Automatic (delayed)".
Soon after, Ben Kohn (
@axilar) found an interesting Server 2008 specific KB article that seemed to explain the situation completely, namely KB
2004121.
For future installs that have this problem, if I run into it again, I'll be doing the following, which comes from the above mentioned KB article:
To resolve this issue we need to modify the behavior of HTTP.SYS to depend on another service being started first.
1. Open Registry Editor
2. Navigate to
HKLM\CurrentControlSet\Serivces\HTTP and create the following Multi-string value:
DependOnService
3. Double click the new
DependOnService value that you created
4. Enter
CRYPTSVC in the
Value Data field and click
OK
The only aspect that I am still fuzzy on - why doesn't this show up in more OCS installs under Server 2008? Is it configuration specific? Obviously the CRYPTSVC isn't getting triggered on demand properly which in turn is causing the HTTP services to fail to start, which in turn causes this cascading OCS service/networking failure.
I'm glad it is fixable and you can work around it but I'm still puzzled.