I am often coming across migration projects where QCS exists prior to the QMM implementation. These conditions always add extra complexity and need very careful approach. There is no single document that would explain how to handle it for every possible scenario. The general rule of thumb is not to overlap the scopes of the two products or ideally decommission QCS and take over all its tasks with QMM which may not always be possible, for example if QCS syncs into some 3rd forest and collaboration needs to be preserved before and after migration. Here are some important tips that I came up with.
1. Carefully separate QMM and QCS scopes. Analyze what each tool will do where scopes absolutely have to overlap. This is often the case where QMM migrates while QCS continues to publish same objects to the 3rd external forest – check #5 below.
2. During transition depending if QCS stubs are Contacts or Mail-Enabled Users you either consume them via “Merge Objects with the corresponding Contacts” QMM Sync setting or match into them via Email Address configured on the domain pair.
3. To address issues for the migrated users getting NDRs when replying to the migrated messages, LegacyExchangeDNs from Source Forest QCS stubs need to be added to the Target Forest original objects as X500 addresses. Coherence Reply-Ability Tool is the best way of performing this task – the tool was successfully used in the very large 100,000+ objects enterprises. Another nice thing it does – copies QCS stub object’s GUID into QMM matching attribute which then allows to preserve DL membership during migration.
4. Watch for LEDN change when merge-To QCS stubs are turning into mailboxes by QMM. QMM will still preserve original LEDN of Mail-enabled user adding it as X500 but there will be an effect on Legacy FB becoming abandoned during LEDN flip. Here again we have Coherence SwapLEDN tool to fix such unpleasant condition.
5. QCS copies Target Address, so if QMM switches users populating targetAddress with @target.local while QCS for example continues syncing to the external Forest it will lead to NDRs. Solution is to configure @target.local Exchange Connector in that remote QCS partner (external forest).
6. When Un-Subscribing, moving objects out of collection or deleting the publication, it strips Exchange attributes from the QCS stubs taking them out from the GAL causing outage – be careful. For the proper transition:
- Stop and Disable all QCS services on the subscriber’s side. Then uninstall QCS. Any re-configurations from within the QCS itself can lead to the described above effects
- OR if QCS cannot be taken out of the picture perform these steps: Disable publication, move stubs out from the QCS OU, clean QCS matching attribute and ACS: Proxy Address from stubs, then merge via QMM, Re-enable publication and only then Un-Subscribe. This will not lead to the stubs removal from the GAL and they will gradually transition from being Mail-Users to QMM mailbox-enabled objects.
