A lot of requests have come up in the past both on the Microsoft TechNet forums and during previous engagements around how to mitigate the risks involved in extending the AD schema for Lync Server 2010.
There are rollback processes that come with Lync Server 2010 to remove the forest and domain level changes, but once you’ve done the schema level change, there’s no way of rolling back the changes using the Lync Server 2010 tools.
For a lot of IT teams, this will be acceptable as there is inherent faith in Microsoft’s ability to extend its own schema.
However, if your AD environment is heavily regulated by IT governance and your change control guidelines require a back out process for each change, there is a way to provide this. I’ll outline each step below.
Isolating the Schema Master from AD
To provide a back out plan for this change, the following risk mitigation prerequisite steps must be carried out prior to running the actual AD schema preparation step:
- Log on to the domain controller that holds the Schema Master FSMO role.
- Temporarily suspend AD replication capability from the domain controller using the following step
- From a Command Prompt, run:
repadmin /options +DISABLE_OUTBOUND_REPL
This process will suspend outbound AD replication from this domain controller, meaning changes we make won’t replicate to all of AD. Alternatively, you can disable the NIC of the machine, or disconnect it completely if it is a physical machine to achieve the same outcome.
Running Schema Preparation
To prepare schema for Lync, log onto the domain controller that holds the Schema Master FSMO role. You can then prepare the schema using either the Lync Server 2010 Deployment Wizard or the Lync Server 2010 Management Shell.
I’m not going to republish what is already documented, so here are the Microsoft TechNet library articles for performing the Schema Preparation step using both methods mentioned above:
To prepare schema of the forest, you must be using an account with Schema Admins group membership.
Verifying Schema Preparation Completed Successfully
From the previously linked TechNet article:
- Log on to a domain controller as a member of the Enterprise Admins group.
- Open ADSI Edit by running adsiedit.msc from the Run command.
- On the Action menu, click Connect to.
- In the Connection Settings dialog box under Select a well known Naming Context, select Schema, and then click OK.
- Under the schema container, search for CN=ms-RTC-SIP-SchemaVersion. If this object exists, and the value of the rangeUpper attribute is 1100 and the value of the rangeLower attribute is 14, then the schema was successfully updated. If this object does not exist or the values of the rangeUpper and rangeLower attributes are not as specified, then the schema was not modified.
Reintroducing the Schema Master to AD
Once you’ve verified that the AD schema preparation was successful, you can roll back the risk mitigation prerequisite by completing the following steps:
- Log on to the domain controller in the domain that holds the Schema Master FSMO role.
- From a Command Prompt, run:
repadmin /options -DISABLE_OUTBOUND_REPL.
If you chose the option to disable/disconnect the NIC, you can reconnect/re-enable this now.
From here, you can carry out the AD Forest and Domain preparation steps for Lync.
Rolling back if Schema Preparation failed
If the schema preparation step has failed for whatever reason, then replication links or network connectivity SHOULD NOT be restored. The following steps are recommended to be carried out:
- The domain controller holding the Schema Master FSMO role must be decommissioned from Active Directory and rebuilt.
- The Schema Master role should be seized from the original domain controller and homed on another domain controller in the domain.
If these steps are required, they will not affect normal operational functionality or Active Directory structural integrity e.g. account and service logon.
Proving the roll back worked
Use the following steps to prove that the back out was successful:
- On a domain controller within the domain, open ADSIEdit.msc.
- Navigate to the following container CN=Services,CN=Configuration,DC=contoso,DC=com.
- Verify that the CN=RTC Service container does not exist.
From here, you can troubleshoot why the Lync Schema Preparation failed. Once resolved, you should attempt schema preparation again.
Using this process, you can effectively satisfy change control requirements and make sure your Lync Server 2010 deployment isn’t delayed or hindered.
If you’ve got any questions around this, please feel free to post in the comments section.