OCS in a locked-down AD

I just ran into an odd error installing Office Communications Server 2007 in a pretty restricted AD. I wasn’t around for the initial install / schema extension, so I’m not able to verify what permissions were or weren’t applied to the installation account, but it seems like something kept the service accounts from being assigned the proper rights. Here’s the scenario:

Forest Extended for the OCS schema: OK

Domain Prepped for the OCS schema: OK

OCS installed on the Front End: OK

Front End Activation: OK

Front End Services: partial. Grr…

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

The services using the RTCService account fired up no problem. But the ones using the RTCComponentService account wouldn’t start. So of course we tried changing the password etc. and nothing was working. Just for grins, we changed the account that the AV and WebConferencing services were using to the RTCService account – and they started!! This was driving me crazy… I could have just left it like that, but I didn’t want to let it go. So I had a look in the Event log and found these errors:

Event Type: Warning
Event Source: OCS Data MCU
Event Category: (1018)
Event ID: 41063
Date: 7/16/2008
Time: 4:01:23 PM
User: N/A
Computer: OCSFESERVER
Description:
Could not connect to Active Directory to read configurations settings. Will retry in 30 seconds.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Error
Event Source: OCS Data MCU
Event Category: (1018)
Event ID: 41038
Date: 7/16/2008
Time: 4:01:23 PM
User: N/A
Computer: OCSFESERVER
Description:
Office Communications Server Web Conferencing Server could not be started

Message: Cannot find object or property.

at System.Security.Cryptography.X509Certificates.X509Certificate2Collection.FindByCert(SafeCertStoreHandle safeSourceStoreHandle, UInt32 dwFindType, IntPtr pvFindPara, Boolean validOnly, FindProcDelegate pfnCertCallback1, FindProcDelegate pfnCertCallback2, Object pvCallbackData1, Object pvCallbackData2, SafeCertStoreHandle safeTargetStoreHandle)
at System.Security.Cryptography.X509Certificates.X509Certificate2Collection.FindCertInStore(SafeCertStoreHandle safeSourceStoreHandle, X509FindType findType, Object findValue, Boolean validOnly)
at System.Security.Cryptography.X509Certificates.X509Certificate2Collection.Find(X509FindType findType, Object findValue, Boolean validOnly)
at Microsoft.Rtc.Server.DataMCU.Security.CertificateStoreWrapper.GetCertificate(String certificateSN, String certificateIssuer)
at Microsoft.Rtc.Server.DataMCU.Security.CertificateStoreWrapper.GetCertificate(Byte[] certSN, Byte[] certIssuer)
at Microsoft.Rtc.Server.DataMCU.Configuration.ServerConfiguration.OnCertificateUpdated()
at Microsoft.Rtc.Server.DataMCU.Configuration.WmiRoutingSetting.initializeRoutingSetting(ManagementBaseObject targetInstance, ServerConfiguration serverConfiguration)
at Microsoft.Rtc.Server.DataMCU.Configuration.WmiRoutingSetting.wmiConsumerSink(String className, WmiConsumerEventType eventType, ManagementBaseObject targetInstance, ManagementBaseObject previousInstance, IDictionary propertyChangeFlags, ServerConfiguration serverConfiguration)
at Microsoft.Rtc.Server.DataMCU.Configuration.ServerConfiguration.WmiConsumerSink(String className, WmiConsumerEventType eventType, ManagementBaseObject targetInstance, ManagementBaseObject previousInstance, IDictionary propertyChangeFlags)
at Microsoft.Rtc.Internal.Wmi.WmiConsumer.GetInitialSettings(WmiConsumerClassEntry entry)
at Microsoft.Rtc.Internal.Wmi.WmiConsumer.Start()
at Microsoft.Rtc.Server.DataMCU.Configuration.ServerConfiguration.StartWmiConsumer()
at Microsoft.Rtc.Server.DataMCU.Configuration.ServerConfiguration.Initialize()
at Microsoft.Rtc.Server.DataMCU.ServiceWorker.StartServer(String[] args)

Resolution:
Look in previous event logs for more information about this error

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

It really looked like a permissions issue at this point. I checked to make sure the accounts were in the right groups and everything came up clean. RTCService and RTCComponentService looked identical as far as I could tell, same groups, same OUs.

I even ran the commandline utility to check LCS permissions:

>> LCSCmd.exe /Domain /Action:CheckLcsOuPermissions /OU:"OU=Dept1Users,OU=UsersOU" /ObjectType:user

>> LCSCmd.exe /Domain /Action:CheckLcsOuPermissions /OU:"OU=Dept1Servers,OU=UsersOU" /ObjectType:computers

This ran ok and came back with a log file showing all "Success". I didn’t give it another thought. As a last ditch, I decided to run a variation of the above command to set the permissions:

>> LCSCmd.exe /Domain /Action:CreateLcsOuPermissions /OU:"OU=Dept1Users,OU=UsersOU" /ObjectType:user

>> LCSCmd.exe /Domain /Action:CreateLcsOuPermissions /OU:"OU=Dept1Servers,OU=UsersOU" /ObjectType:computers

And this seemed to do the trick. Shortly thereafter the services with the RTCComponentService account were all able to start no troubles. So my best guess is that the AD was somehow locked down and some inherited permissions didn’t make their way through to my service accounts.

I used the OCS_CommandLine.doc guide from the set of OCS docs out on the MS website pretty heavily. It’s got tons of good info about commands to run checking / setting permissions. It reads like a novel! No, no it doesn’t but man is it useful for getting into some nitty detail.