![]() ![]() Here’s the one million euro question! from my personal opinion the answer is: “Yes it can, but…” 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.This migration process is possible, although it requires a lot of testing and well documented procedures.What I wanted to demonstrate on this post is that: Can to adapt Outlook and Exchange to the user’s migration?.How to migrate user personal contact list and update those contacts as they are migrated?.When to perform software upgrade? ex: OCS users schedule live meeting invitations, but Lync clients schedule using URL web services.This are the steps at the server side, but for the end-user migration another challenges are presented: The other advantage is that troubleshooting communication problems is easier. 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. Routing enables direct and full user communications 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 answer could be simple: enable external federation between domains (using Edge Servers). 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. OCS and Lync interoperability Federation requires enabling user permissions and has more communications routing Note: this is fine since there’s no important external federation with other domains, and we can break communications for the migration timeframe. The plan was simple: use a temporary sip domain on the Lync side. The challenge is: how to move some users of the same SIP domain to a different pool. 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. 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. ![]() 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. The user should by aware of the change, but shouldn’t be concerned or requested to perform any reconfigurations at his desktop applications. To achieve this let me summarize the 3 particular challenges: 1. This design was validated after another important factor: a Lab where to test and validate the configurations required. By performing a detailed survey and design the scenario will clearly help you to see what the really challenges are. 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. 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. Well… this migration is somehow less common and documented. You might think for now: “I have read documentation about that”, “already seen how” or “already done it”. I decided to post a little about this to share you some of the experience. 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. It’s difficult to find some time to keep feeding my blog as planned… ![]()
0 Comments
Leave a Reply. |