Whether troubleshooting a problem or performing regular maintenance it is sometimes necessary to reset the passwords on the service accounts used by OCS.
Best Practice
Microsoft’s recommendation is to configure each service account to never have their passwords expire, but some organizations may have policies limiting or completely banning that type of approach.
In most cases it is best practice to retroactively disable password expiration on each Active Directory User Account used by OCS, as the setup wizard does not automatically configure this when creating the accounts.
A Standard Edition deployment will only have created RTCService and RTCComponentService accounts (assuming the default names), while an Enterprise Edition deployment would also add the RTCGuestAccessUser. (This third account is technically a user access account and not a service account in the standard definition.) If a Communicator Web Access server is deployed, then an additional service may also exist in the domain, typically called CWAService.
For each of these accounts, configure the “Password never expires” setting on the Account tab using the Active Directory Users & Computers management tool.
The Hard Way
But if the service account passwords must adhere to a corporate policy, then it’s key to monitor the Office Communications Server log on the Front-End server for any Warning events with ID 122296 as these events will alert administrators to the number of remaining days before the password expires (0 in the example shown below).
If the expiration event occurs, the services themselves will still continue to run, and even start correctly. So rebooting the server won’t flush out the root cause easily as one would expect the services to fail on start with a error about ‘invalid credentials’. That would be too easy.
Instead what will appear in the log are errors (12295) relating to the the services failing to verify the validity of the service account password, with a specific error code for expiration (0x800708C2).
From an end-user standpoint Office Communicator will still function. IM Conversations and telephony will still work, Live Meeting still works, all the major stuff still looks fine. But users may report that they can no longer expand any distribution lists within their OC Contact List, and others may notice an alert explaining that Office Communicator cannot download the corporate address book. The root cause of those issues are that the IIS application pool also runs under the RTCComponentService identity, which is effectively broken.
Resolution
Now whether you’ve caught the issue before anything expired or stumbled across this article in a panic the resolution is basically the same: change the passwords, update the services, and restart. (Of course if they haven’t expired you can simply set the accounts to not expire and leave the existing password, but then you would have stopped reading this article after the first few paragraphs 😛 ).
Begin by setting a new, strong password on each service account:
-
RTCService
-
RTCComponentService
-
RTCGuestAccessUser (Enterprise Edition only)
Then stop each of the OCS Service accounts on any domain-joined servers (Front-End, Mediation, etc) and update the service account’s password from the Log On tab in the properties.
Restart each service and check the event log, it should look much nicer than the mess of warnings and errors previously seen.
But wait, there’s more…
I imagine that most administrators would easily get through these steps without even searching online for assistance. The event logs, when found, are pretty clear about the problem and resetting the services are pretty simple.
But Office Communicator still won’t work correctly, yet. All users (internal or external) may be re-prompted for credentials after signing-in, with a message indicating it’s for access to the corporate address book. Also distribution group expansion will still be broken, but now with a different error. Beforehand the client would show a description immediately below the group saying “Cannot perform this action, and the cause is unknown”, but now the description would say that the user wasn’t granted sufficient rights to use that feature. Better, but not all better.
The missing link is that credentials also need to be updated within IIS on the Web Components server, and Communicator Web Access, if deployed.
Web Components Server – Standard & Enterprise Editions
-
Open up the Internet information Services (IIS) Manager and expand the Application Pools.
-
View the Advanced Settings for the LSGroupExpAppPool entry. Highlight Identity under th
e Process Model heading and hit the ellipses button to the right to edit the current Application Pool identity.
-
Click Set and re-enter the same credentials using the new password.
-
Stop and Restart the Application Pool.
At this point sign a user back into Communicator and both distribution group expansion and Address Book download functions should be restored. But if this is an Enterprise Edition server then there are still a couple of additional places that need to be checked within the IIS Manager, as the credentials for the Guest User Access Account are set in a myriad of virtual folders.
Web Components Server – Enterprise Edition
-
Open up the Internet information Services (IIS) Manager and expand the Default Website.
-
Drill-down to each of the directories listed below and reset the password on the RTCGuestAccessUser account.
-
AbsExtFiles
-
AbsIntFiles
-
AutoUpdateExtFiles
-
AutoUpdateIntFiles
-
DeviceUpdateFiles_Ext
-
DeviceUpdateFiles_Int
-
EtcPlaceNullFileTree (if configured)
-
Communicator Web Access Server
-
Open up the Internet information Services (IIS) Manager and expand the Application Pools.
-
Perform the same steps in the previous section for each of the three CWA application pools displaying a domain account under the Identity.
One Last Step
The Operations documentation for R2 has a pair of pages that show example LCSCMD commands used to re-activate an Enterprise Pool using the new passwords for the Guest Access account and the IIS App Pool account. The problem that I’ve run into with the examples is that neither seems to work correctly. The command used to reactivate the IIS Application Pool will error out at the end with “Failure [0xC3C7922] Guest Access user or user password isn’t specified." And running the command to reset the Guest User access fails with “Error [0xC3EC7A36] Missing service account password.” as well.
Apparently the first command requires that the Guest Access user account credentials (regardless of whether it has changed or not) needs to also be supplied,and the second command doesn’t work without also supplying the service account password. So if both commands are put together then the pool re-activation should complete successfully.
LcsCmd /Web /Action:Activate /PoolName:pool1 /User:RTCComponentService /Password:Password123
/Guest:RTCGuestAccessUser /GuestPassword:Password456
