…is not a good idea. In a production deployment a second server should be built using the desired server name, and then all OCS users moved over to it. Or a temporary staging server can be stood up in order to rebuild the original server. Either way, simply renaming an Office Communications Standard Server 2007 can be painful.
Shortly after deploying a standard server in my lab I noticed during server configuration that I had fat-fingered the server's hostname and was not to happy about that. I decided to see what would happen if I just renamed the server without any preparation in OCS. After renaming my virtual guest from JDSSOCS01 to JDSOCS01 I was welcomed with a standard Windows startup message alerting me to a service failure.
A quick scan of the Application event log uncovers event ID 12291 explaining that "the Communications service is registered for a different machine." Microsoft Knowledgebase Article ID 830535 covers this error, but in reference to LCS 2003, and states that changing the FQDN of a Live Communications Server is not supported. So it doesn't appear to be supported in OCS 2007 either.
The article's resolution suggests exporting the RTC SQL database to a file, removing the OCS services, and re-installing the product. Because I had already renamed the server I was unable to deactivate the pool/server using the previous name and was presented with a couple warnings during the uninstall that some configuration information will be left in the Active Directory domain; I took note of this for later troubleshooting. I also completely removed the SQL 2005 Express components in order to wipe the OCS install from the server.
During reinstallation of the OCS Standard Server the setup wizard reported a failure and viewing the install log showed that the server could not be activated for a pool due to a conflict. At this point I decided to just delete the VM and rebuild the server from a fresh image as deploying a clean lab environment was my overall goal. Before creating a new server with the desired server name of JDSOCS01 I went to delete the existing computer object in Active Directory, but oddly enough I was warned that deletion of that object would result in all child objects also being removed from AD. I checked out the existing computer object using ADSIedit and apparently the OCS installation inserts additional objects under the server:
I deleted the computer object and imaged a new virtual guest using the correct server name. This time the OCS Standard Server installation completed successfully, but I received another error after validating the front-end server configuration:
Failure: [0xC3FC200D] One or more errors were detected
Diagnose Server
Check Configuration
Checking all trusted servers
Internal Server JDSSOCS01.lab.schertz.local
DNS Resolution failure: No such host is known
Suggested Resolution: Make sure there are no typos in the Server name. Make sure that the Server name is published in the DNS (A or SRV record) or hosts file entry is configured correctly.
This is the part where I spent some time digging through AD looking for where the old server name was hiding. After running some LDAP queries using the string *pool* I discovered where OCS stores it's configuration data in AD:
CN=RTC Service,CN=Microsoft,CN=System.DC=domain,DC=com
I located and deleted the Pool object for the old server:
CN=JDSSOCS01,CN=Pools,CN=RTC Service,CN=Microsoft,CN=System,DC=schertz,DC=local
But that didn't resolve the validation errors after rebooting the OCS server. I dug deeper and found both the old and new server FQDNs referenced in multiple objects under Global Settings, MCU Factories, Trusted MCUs, and Trusted WebComponentsServers. Using the command ldifde -f output.txt -d "dc=schertz,dc=local" is was able to search the text export file for all the objects with attributes referring to "jdssocs01":
CN=Global Settings,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local
DN: CN={DB1226B0-B04E-494F-BF44-6C365A2A4CF1}
objectCategory: CN=ms-RTC-SIP-TrustedServer
msRTCSIP-TrustedServerFQDN: JDSSOCS01.schertz.local
CN=MCU Factories,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local
DN: CN={0AAB2557-E5AA-4229-8F43-600554BAE453}
objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/
DN: CN={55753891-89EA-4F18-B020-5FA5928BE97F}
objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/
DN: CN={56B7C1C4-1961-461A-B40F-3ABB3C62BE31}
objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/
DN: CN={E1F6A173-E15D-427A-8E2A-87DD1CAAD947}
objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/
CN=Trusted MCUs,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local
DN: CN={459B434F-3099-4049-8A2E-56D0524AFAD4}
objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local
DN: CN={51D7A033-A074-4285-9589-FB78AAB6A460}
objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local
DN: CN={9DE8BC35-D15A-4F8F-8BCD-A819014420F0}
objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local
DN: CN={C5677C4C-7BE6-484D-9CD4-878F1F8427BE}
objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local
msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local
CN=Trusted WebComponentsServers,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local
DN: CN={93A1A739-3B44-4F0B-935A-170EAAA63026}
objectCategory: CN=ms-RTC-SIP-TrustedWebComponentsServer
msRTCSIP-TrustedWebComponentsServerFQDN: JDSSOCS01.schertz.local
I deleted all objects above and then removed the invalid ServicePrincipalName entries from the RTCService and RTCComponentService user accounts.
I forced AD replication between both domain controllers and rebooted the OCS server, and the validation check no longer reports any failures.