OCS to Lync: a different migration scenario

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

Federation requires enabling user permissions and has more communications routing

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).


Routing enables direct and full user communications

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


10 thoughts on “OCS to Lync: a different migration scenario

  1. Octavio 06/03/2012 / 00:12

    Hi I think I am trying to solve this same situation. You seem to be the only article I’ve read that comes even close…

    My company is in N. America, has had an OCS 2007 R2 pool, and our domain is “NAdomain.local”. We have international branch sites which have had their own, totally separate domains. In the past, we granted those domains users access to our OCS 2007 R2 pool previously through our edge, via contact accounts created for them in our NAdomain AD. Now, we are all merging into one new super domain, “GLOBALdomain.corp”, with two-way trusts to existing domains. We built a Lync 2010 Enterprise pool (FE+AV, Director, Archiving — Edge to be added) on GLOBALdomain. As it stands now, testuser@GLOBALdomain.corp (an actual GLOBALdomain.corp account), can logon and use Lync just fine so the install is working properly. As all of the international users are moving directly into this new domain, they are ready to use Lync with brand new contact lists, signing on to the pool using @globaldomain.corp sip addresses. We are now ready to bring in my users from NAdomain, and this is where things get messy.

    The method chosen for authentication on GLOBALdomain for any existing NAdomain user is that each user has a linked disabled user created in GLOBALdomain, which is linked to their NAdomain user. Due to infrastructure in other areas of our network, this is the only way we can proceed. The users will remain actually in the NAdomain.local domain for the next few years. I am about to run the 2010 schema prep on NAdomain. Once that’s completed here’s where things stand:

    -The NAdomain OCS 2007 R2 pool is not at all in my 2010 “topology builder” design if I load existing
    -Being on a different domain than where the new pool sits, the NAdomain pool is completely invisible to the Lync 2010 pool
    -During deployment of the new pool, I did include sip addressing @NAdomain.local, which is what we use on the existing 2007 R2 pool on NAdomain.local

    I’m stuck on how to cleanly migrate users with their contact lists from the R2 Pool. Do I need to make the OCS R2 pool known to the Lync pool? Is there a way to cleanly export from the OCS 2007 R2 pool on NAdomain, then import to the Lync 2010 pool on GLOBALdomain? Worse yet, do I need to build a 2010 Pool on NAdomain, just to have transfer the users to GLOBALdomain pool?

    I’m very familiar with how to do things on same domain, but alas, I have to work with this situation as is. Any help is appreciated, and I know what you’re thinking as you read this… Yikes.

    P.S. Just wanted to add that the solution that I think will work is… Once I have the NAdomain schema upgraded, I can add the OCS 2007 nadomain.com pool as a legacy site in topology builder. I can then hopefully re-home the nadomain based users (OCS-wise) to the 2010 Front End. Once a user is re-homed, they should hopefully be able to Logon using the same credentials they did for OCS 2007 R2, and maintain their contact lists from OCS 2007 R2. I would love for someone who’s faced this before to give me a defacto, yes that will work. My fingers are crossed…

    • LuisR 06/03/2012 / 21:52

      It is also good to know that someone else is experiencing the same challenge.
      I can see you also are moving to a kind of “resource forest” topology, and is a smart approach.

      Is the NA a child domain of GLOBAL? if not, upgrading the NA schema will not make OCS2007 pool visible to GLOBAL.
      If in fact OCS2007R2 and Lync2010 are on separate active directory domains there is two scenarios:

      Bing bang – completely move all sip accounts in one weekend. Important tasks:
      – Create the OCS SIP domains on Lync;
      – link each NA user domain with an account at GLOBAL;
      – Update all desktop clients to the latest MOC Cumulative update (it will allow access to Lync server and you can later upgrade them to the Lync client)
      – Enable users in Lync with the exact SIP address;
      – Export the user database from OCS to Lync (using DBIMPEXP tool); <<< This is the tool you are looking for <<<
      – clear all MSRTC-*** user fields from NA domain, except MSRTC-PrimaryUserAddress (this will keep client to get the logged on user sip address);
      – Change de DNS SRV pointers to lync.
      – If you want to change the migrated users to a new SIP domain you can do with Lync, but to easy client configuration you should update the MSRTC-PrimaryUserAddress and ProxyAddresses at the NA domain and write a logon script to clear the MOC last user logon;
      This approach is good since you can configure Lync as you plan, and the change is just a DNS pointers update task (or even reverting back)

      The fased migration (as I did with 3 OCS sip domains):
      – Configure a federation between Lync and OCS;
      – You have to use 'temporary sip domains' while you move the users;
      – most of the steps are similar to the previous scenario…;
      – … but you have to use some scripting to directly interact with the SQL databases user contact list to update the user changes 😉
      – At the end include the previous sip OCS domains and assigned back to the migrated users;
      This approach allows more controlled migration, demands less human resources, but has more tweaks and there's still a presence issue while users are on diferent domains.

      I would suggest the first approach.
      To try the second, you should be very confortable with OCS/Lync configuration settings and test on a Lab environment.

      Good luck

      • Octavio 07/03/2012 / 12:23

        Hi Luis,

        Thanks for your tips. I just wanted to clarify my end goal, then maybe with just a little more help from you I can move forward…

        The Globaldomain and NAdomain are not in the same forest. They just have the two-way trust, and full local connectivity between domains. The main SIP domain that I had planned to use was @GLOBALdomain.corp, since eventually everyone’s email address eventually will use this same convention. I did however include the SIP domain used in our OCS 2007 R2 pool, @NAdomain.local, in every step of deploying Lync 2010 thus far (as alternate SIP domain).

        Here’s an example of how a user logs on to our OCS 2007 R2:
        user john.doe currently is an NAdomain account user
        he logs on to ocs 2007 r2 client, hard-coded via registry to connect to the ocs 2007 r2 pool/edge, he enters john.doe@NAdomain.local in the first field, nadomain\john.doe in the second field, and his password in the third field (note: he doesn’t have to type this info every time, it’s just for my example)

        Now we create a disabled john.doe linked user in Globaldomain for authentication purposes. The account is linked back to John’s actual NAdomain account. In Lync front end on Globaldomain, I gave this globaldomain linked account the OCS access (as I can’t – at the moment – see and thus give access directly to the NAdomain account). The SIP username I used was @globaldomain.corp From here, I would suspect the logon to work as follows:

        john.doe logs onto Lync 2010 pool in Lync 2010 client. he enters john.doe@globaldomain.corp in the first field, nadomain\john.doe in the second field, and his password in the third field

        This unfortunately did not work. This was from a computer in the NAdomain, and I had just connected successfully to the pool using a normal (non-linked) new Globaldomain.corp test account. This proved to me that the problem was only when trying to log on as a linked user. This was not a password issue either. I tried to do the same thing using @NAdomain.local SIP username in the 2010 pool profile, as to match the users’ 2007 R2 profile. Again this did not work, so for sanity, I immediately tried to logon with the GlobalDomain (direct) account test user again, and everything worked fine.
        In conclusion, I am ok with the users on NAdomain continuing to use NAdomain as their SIP domain. I’m just looking for as seamless a transition as possible. To achieve this, I need them to be able to logon using the linked user model (this is my top priority), and secondly, if possible, to migrate or export/import their contact lists (all contacts would also be on NAdomain.com, thus hopefully still be valid). In this scenario, when we push the Lync client out to our users, it will simply logon to Lync 2010 using our DNS and give the user the impression of an actual migration, even though technically they are working on a copy. This would be just as acceptable to me.

        Additionally wanted to note that your comments have raised one more important question for me. Do you envision me having an issue in temporarily using the NAdomain’s 2007 R2 edge server for the 2010 pool?

        When the plan was to migrate between the pools, like you would in a same domain upgrade, it included allowing edge access to the 2010 pool, which is supported. This would be followed by testing/phased migration of users to the 2010 pool. In the interim, I would be bringing up our 2010 edge (which will use the same external public certificates/DNS/PIC) then cut-over to it. This is the same plan of attack as when we moved from OCS 2007 to 2007 R2. Is this plan invalid due to separate domain forests? Again, any advice or even bad news will help me move forward. Hopefully it’s just the former.

  2. Octavio 07/03/2012 / 12:44

    p.s. with the idea of keeping the sip domain “the same” in the lync 2010 pool as part of this pseudo-migration…

    Would it make sense to first add GLOBALdomain.corp as a sip address in my OCS 2007 R2 pool, then after-hours change the profile of each user in AD to use this as their sip domain, then have users logon to ocs 2007 r2 with the new address the next day.

    Would this facilitate allow the SIP address in the Lync 2010 pool to be GLOBALdomain.corp? Even if it does, I can envision it breaking contact lists as I don’t believe these are dynamically updated, but maybe they are.

    Obviously if I was john.doe@NAdomain yesterday in your contact list and today I am john.doe@GLOBALdomain, your list may not being aware of the change would display me as unavailable.

  3. octavio 07/03/2012 / 19:28

    UPDATE – I’ve gotten the linked user to be able to log-on, and I have a really good understanding of the two methods in your blog.

    I’m still interested in knowing if the 2007R2 (NAdomain) pool edge server can act as edge to the 2010 (GLOBALdomain) Front End/Director pools

    Secondly, would you be able to provide steps or easy to understand documentation on how to setup internal federation from OCS 2007 R2 side and from Lync side, specifically where they are in different domains with different CA’s.

    My thinking now is that if get the 2007 edge supports the 2010 pool, and I can federate internally, then, I would use your phase-in approach as follows:

    -I can have users “migrated” to the 2010 pool (replicated using NAdomain.local as the sip domain in Lync 2010 which matches their 2007 profile, export/import contacts from the 2007 pool, then change sip domain to Globaldomain.corp in Lync 2010)
    -The “migrated users will be able to connect remotely using the existing edge
    -The migrated users will connect and see presence with users still homed on 2007 pool, and Vice-Versa

    This is leaving out client-based steps and many other items I’m aware of. I’m actually considering deploying an NAdomain based pool for now just to get the features we want quickly (Mobility, etc), but eventually we do need to move to the server hosted in the new domain, so I still need to figure things out with certainty.

    Thanks for your response in advance.

    • LuisR 07/03/2012 / 23:52

      Since you solved the linked user log-in you are half-way on your objective 🙂

      You can use the 2007 edge server for Lync for AV and content sharing, but I don’t think you will be able to get user authentication (the OCS edge config tab only has room for one next hop pool address)… You should use a Lync edge.
      If you have both Lync and OCS in production, you should keep sip domains separated, so you can ‘route’ communications between users. Internal federation can be setup by using static domain routing.
      There’s a lot of work behind this scenario and it’s not easy to explain all the tweaks. For example, Live meeting requires DNS configuration and the OCS edge to allow Lync users to participate on OCS web meetings.
      This migration took me about 2 months at a lab, testing configurations and preparing bulk migration scripts.

      Another approach is to setup two ‘dummy’ edge servers inside your network (one for OCS and other for Lync) exclusively for federation between the domains (only possible if you do not use federation with external partner domains)

  4. Mark 07/05/2014 / 16:38

    I think this description is better , I am migrating an ocs pool from a forest has multiple pools in multiple domains and I want to migrate lync only for my users to a new forest and work with resource forest model( the users stay in the old forest and lync implemented in the new forest and change the sip domain to a new one like sub.domain.com instead of domain.com so I migrate the users to the resource forest and changed the msrtc-primaryuser address of the users In the old forest to the new user address so the lync client updated with the new address and update contact list in the old forest users with new address of users but that make a problem with the presence and communication as other pools see that our users with the new address in the local forest as the find a local user in the forest with the required address that required to connect !! so any other solution or tweak to make this solution work

  5. Mark 07/05/2014 / 17:16

    sorry for sending for the third time but I am trying to make it more detailed ,


    I am facing a strange migration where I need to fulfill the following :

    the current environment :

    forest with multiple domains and lync and ocs pools

    the required is :

    1-create a new forest to work as resource forest for one domain of the old forest

    2- migrate users with another domain sip “sub.domain.com” instead of “domain.com”

    3- allow users to login automatically with the new address

    4- Change the contact list in the other domains to see the new address of users

    what had been done :

    1- Create disabled users in the new forest and add to them msrtcsip-originatorsid so users in the old domain can access

    2- create federation between the two sip domains to maintain the communication

    3- change the users msrtcsip-primaryuseraddress to new address so the lync login address populated with the new one and other users contact list populated with the new address

    the problem :

    the third step changed the login address and updated the contact list for the other domains users contact list but the presence not working and the other users can’t initiate the IM with new migrated users as it looks the other servers find the users in the old domain with same sip address in msrtcsip-primaryuseraddress

    • LuisR 08/05/2014 / 23:07

      I’m not exactly sure how is your setup, but you have to consider that no pool can contain the sip address(es) of the other pool.
      How are connecting both pools? Edge Servers?

  6. Pingback: URL

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s