It’s difficult to find some time to keep feeding my blog as planned…
On the last weeks I’ve been working day (and night and weekends) on a project for a customer: a migration from OCS (2007 R2) to Lync. I decided to post a little about this to share you some of the experience.
You might think for now: “I have read documentation about that”, “already seen how” or “already done it”.
Well… this migration is somehow less common and documented. It will be a side-by-side migration, i.e., OCS users will be transferred to a Lync pool at another domain, but will remain on their existing domain (both Active Directory and SIP) with authentication maintained by domain trusts.
The challenge: planning and testing
Just like any IT project this is the important phase and we don’t want to “try and see if works” on the production environment. By performing a detailed survey and design the scenario will clearly help you to see what the really challenges are. Here’s what I have:
This design was validated after another important factor: a Lab where to test and validate the configurations required. To achieve this let me summarize the 3 particular challenges:
1. No end-user impact
This is my personal requirement. The user should by aware of the change, but shouldn’t be concerned or requested to perform any reconfigurations at his desktop applications. There should be enough automated procedures or scripts that will ease service-desk support and that the user will simple log-in on the next day and find a new application interface fully configured.
2. Phased user migration
I personally don’t like a ‘rip-and-replace’ migration and on this project, the high number of users, their locations and the limited of resources will require a migration of OCS accounts in groups by days. This is good for one reason: it will give a feedback of unplanned problems and help you plan and correct for the next move wave . The challenge is: how to move some users of the same SIP domain to a different pool. The plan was simple: use a temporary sip domain on the Lync side.
Note: this is fine since there’s no important external federation with other domains, and we can break communications for the migration timeframe.
3. OCS and Lync interoperability
Since this is a phased user migration, it’s required that user migrated to Lync pool can communicate with user still on the OCS pool. The answer could be simple: enable external federation between domains (using Edge Servers). There are two requirements I didn’t like: Allow everyone federation permission, and allow presence visibility to every external domain (by default only external contact in the personal contact list are visible to each other).
The alternate solution is to perform an internal routing (using the pool servers): user presence is visible and communications are direct without the need of setting any user permissions.
The other advantage is that troubleshooting communication problems is easier.
The next challenges
This are the steps at the server side, but for the end-user migration another challenges are presented:
- When to perform software upgrade? ex: OCS users schedule live meeting invitations, but Lync clients schedule using URL web services;
- How to migrate user personal contact list and update those contacts as they are migrated?
- Can to adapt Outlook and Exchange to the user’s migration?
What I wanted to demonstrate on this post is that:
- This migration process is possible, although it requires a lot of testing and well documented procedures.
- It’s a possible scenario for OCS and Lync co-existence, especially if we have companies merges or even multinational ones that have separate IT administration, are connect with dedicated WAN links and want to control external access and communications using internet links.
Comments always welcomed