OCS Global Settings Migration Tool (GSMT) - Part 2 (customer case)

As we talked about part 1 of using the GSMT we posted the following article link. Today we are explaining a practical customer case. This customer was using the GSMT in the wrong way and by the end the customer was having two exactly the same pools in their infrastructure while CWA R2 was crashing configuring next hop (pool configuration).

Situation:

“Customer was having LCS 2005 SP1 deployed with almost 3900 users in one pool. The customer also configured Access Proxy to make sure users can logon remotely with their Communicator 2005 client. Parallel on the LCS 2005 SP1 deployment the customer was starting a pilot for in the first place for 25 users on OCS 2007 R2. Strange enough the customer was thinking that the OCS Gobal Settings Migration Tool was a prerequisite for installing OCS 2007 R2. To make this more clear. The GSMT is not a requirement to install OCS 2007 R2 in the correct way.” 

Anyway the OCS GSMT was downloaded and they installed the *.vbs files on the server. After that they started with the first migration step. To make the migration steps more clear review the steps below:

Source: OCS Global Settings Migration Tool documentation

The supported scenarios are closely related to expected Active Directory schemas. Because the Global Settings Migration Tool heavily relies on Lightweight Directory Access Protocol (LDAP) queries and Office Communications Server Active Directory classes and attributes. While you can tweak the script to fit your deployment, the tool requires certain prerequisites.

From an Office Communications Server perspective, the tool supports global settings migration with the following products:

• Live Communications Server 2005 SP1 (with appropriate QFEs: KB911966 and KB921543)
• Office Communications Server 2007

From an Active Directory Domain Services (AD DS) perspective, the tool only supports Windows Server® 2003 or later. It doesn’t support Windows® 2000. The key here is the requirement of inetOrgPerson schema. So please make sure you installed the QFE’s on LCS 2005 SP1 before proceeding with the steps below.

Migration has six steps.

Phase 1 (customer)

1. Migrate the global settings tree structure.

2. Copy over the global settings attributes.

3. Run ForestPrep to create necessary ACEs on the new global settings tree structure.

Phase 2

• 4. Update the Office Communications Server distinguished name references to the global settings tree.
• 5. Update the Office Communications Server users/contact/inetOrgPerson’s msRTCSIP-PrimaryHomeServer distinguished name references.
• 6. Remove the global settings tree under the root domain System container.

Because the customer did run the SchemaPrep for OCS R2 2007 and the rangeUpper attribute value was updated to: 1008…

• 1006: corresponds to Live Communications Server 2005
• 1007: corresponds to Office Communications Server
• 1008: corresponds to Office Communications Server 2007 R2

they failed to run the GSMT on step 4. In step 4 we need to accomplish to update the Office Communications Server distinguished name references to the global settings tree. The following message was shown:

As you probably understand this was caused by the SchemaPrep they run before running the GSMT. In general the customer was stuck on this migration and needed to contact PSS. After some chalk and talk sessions we figured out that we need to undo the previous migration steps.

The failure we had on installing CWA R2 by configuring the hext hop was directly related on double pool names in the system and configuration container. The way to fix this is to delete global settings tree structure in the configuration container by opening ADSIedit.

Before you do that please make sure you made a Active Directory backup (and test the backup!).

Conclusion:

Please be careful with the OCS GSMT! 

Source: OCS Global Settings Migration Tool documentation

During the Office Communications Server development cycle, it was noticed that some Office Communications Server deployments that start out as centralized move towards being distributed. Theoretically, this is what was recommended, because the closer Office Communications Server and its component services (conferencing server, web components, and so on) are to the SIP-enabled user, the better the collaboration experience will be. In practice, two issues were found:

• Long service start time
• Long replication delay when managing Global Settings in the snap-in

Both issues are expected from product design’s perspective. However, they are not acceptable to typical customers, especially to those who have been using the product since Live Communications Server 2003. There are many short-term workarounds. The best long term approach remains to migrate the Office Communication Server global settings from the root domain System container to the Configuration container.