With one of my customers the project went very smooth. Installing and configuring all servers and roles, updating, configuring and tweaking all their requirements. Set up tests, approving and set a go-live date, moving all users and re-configure terminal servers by group policy, and so on. Everything smooth.
Until….we removed the old pool. De-activate all services, remove all software, and so on went just fine. The last step was to remove the pool, and it seemed to have finished succesfully. No errors, a 100% succesfull job. At least, it seemed that way.
After the first reboot (it could also have been a configuration change – as long as the frontend service restarted), the front-end service didn’t start anymore.
An error was logged in the Office Communications Server event log;
Server could not retrieve its initial configuration for a class from the WMI Provider.
Class: MSFT_SIPTrustedServiceSetting
Cause: This can occur if the connection to Active Directory or SQL back-end database is down or if permissions to the service account are altered. Retrieval can also fail if an invalid entry is entered in the class using the UI or WMI or if corruption occurs in local WMI repository.
Resolution:
Make sure the account the service is running under has proper privileges and that connection to Active Directory or SQL back-end database is functional. Verify an identical entry does not exist as a direct federation partner or an IM service provider.
Hmm. This error sent me in the direction of a not-correctly configured database server or database settings, as I just moved the configuration databases from one server to another.
After a long search in that direction, I referenced the technet forums where another person came with the solution. Credits go to Ben-Shun Zhu for this one.
In the end, this had nothing to do with a database server, but with the WMI property “MSFT_SIPTrustedServiceSetting”, as the error stated as well.
by opening ADSI edit, in the configuration container of OCS (ADSI Edit\CN=Configuration,DC=domain,DC=com\CN=Services\CN=RTC Service\CN=Pools), this setting is found.
There, modify any objects within the RTC Service “Trusted Services” Container; remove the contents of property “RoutingPoolDN” and set value to “”, where there is any reference to a sepcific pool.
After this change, the front-end service started successfully again.
This leads me to the conclusion that the front-end service checks several configuration settings in the active directory prior to start the service. One of these is this Trusted Services. When someone build some application code against the OCS pool, it creates and entry in this configuration container. And when the pool is removed, this entry will, of course, not dissapear out of the blue. However, where the front-end service checks the availability of these items and their properties, in this particular case it failed, and therefore didn’t start.
When you have more than one pool, this property might not be set to “”, but the desired other pool.
Bottom line: Just make sure that no entry exists in this configuration container from ADDS referring to the “to be removed” OCS Pool, prior removing the pool. It can save you a lot of time, and pain 😉