In a recent deployment OCS 2007 R2 Enterprise Edition was deployed to a physical server running Windows Server 2008 that began to exhibit problems immediately after the first reboot. Basically the server failed to respond to network traffic and was unreachable via RDP or other previously listening services after restarting.
Upon connecting to the console locally the server had apparently dropped off the network, as indicated by the system tray Network icon displaying as disabled.
After checking the physical connections and verifying there was no IP address conflict a number of hardware-related tests were run. Eventually we found that if the OCS services were disabled then the server would boot normally with networking enabled. Checking the logs showed that all OCS services appeared to hang on startup for 10-15 minutes, after which they would all start and both OCS and Windows itself functioned normally. The server appeared back on the network and all looked fine, until the next reboot. If each OCS service was disabled then the server would boot-up normally and respond to network traffic immediately. The latest round of OCS hotfixes were applied to the server but there was no change in behavior.
A contact in the OCS Senior Support team then sent me the following details as the issue has been seen before in other Server 2008 OCS Front-End deployments, but has not yet been reproduced under testing. It’s so far unknown if the there is a conflict between Server 2008 and the specific hardware used in this scenario, or if that is entirely unrelated.
Resolution
The workaround instructions we received from the Microsoft Product Support team was to configure a dependency on the WMI Performance Adapter service.
- Set the Startup Type of the WMI Performance Adapter service (wmiApSrv.exe) to Automatic
- Configure the OCS Front-End service (RtcSrv.exe) to be dependant on the WMI Performance Adapter service
The ‘sc config’ command can be used to modify the DependOnService value. Note that by default the Front-End service is already dependant on the Windows Management Instrumentation (WinMgmt) and CNG Key isolation (KeyIso) services. Because this command overwrites the current value both the existing and new entries must be supplied. To verify the current configuration is the same as this example, check the Dependencies tab on the Front-End server before making any changes.
Then issue the following command to configure the new dependency. Add any additional dependant services to the command below to retain any other services that might already be customized.
c:>sc config rtcsrv depend= WinMgmt/KeyIso/WmiApsrv
[SC] ChangeServiceConfig SUCCESSTo double-check the new service dependency the registry value can be viewed here:
HKEY_LOCAL_MACHINESYSTEMControlControlSetServicesRtcSrvDependOnService
- Restart the server and validate that all OCS services start correctly, and in a timing manner with no adverse impacts to the host’s Network connection
If this does not resolve the original issue (as was the case with this specific deployment) then it’s further recommended to set a delayed startup on all OCS services except for the Front-End service.
- Leave the Startup Type of all Office Communications Server Front-End service set to Automatic
- Configure the Startup Type of all other Office Communications Server services to Automatic (Delayed Start)
This last step resolved the startup issues on the Front-End server by allowing Windows to complete bootup and register with the network before starting up additional OCS services. this is considered more of a workaround as the root-cause was not yet identified.
