Migration of Skype for Business Hybrid Environment to Skype for business Online


A Quick search on web didn’t show much information on what all needs to be done for moving the infrastructure from skype for business hybrid setup to skype for business online setup. I thought of writing this blog with detailed procedure, so that it would be easier for anyone who are looking for details when they are planning to move from Skype for business hybrid to Skype for business Online scenario.

Before looking into the migration steps or procedure, lets first look at the process flow of Skype for business User sign in when in Hybrid setup.

Onpremise user sign in process (User : Onprem@domain.com)

  1. User provides the sip address Onprem@domain.com and clicks sign in on Skype for Business Client.
  2. Skype for Business Client makes Lync Autodiscover Query “Lyncdiscover.domain.com” which will be pointing to Onpremise Servers (as it’s a hybrid setup) and reaches the Front end server (Hybrid Server).
  3. Once Request Reaches the Front End server, Server first authenticates the user and checks if user is homed onpremise or online, since user is homed onpremise, User signs in to the onpremise Front end server and server will provide required services.

Online user sign in process (User : Online@domain.com)

  1. User provides the sip address Online@domain.com and clicks sign in on Skype for Business Client.
  2. SFB Client makes Lync Autodiscover Query “Lyncdiscover.domain.com” which will be pointing to On premise Servers (as it’s a hybrid setup) and hits the Front End Server
  3. Once Request Reaches the Front End server first authenticates the user and checks if user is homed onpremise or online, since user is not homed onpremise, it will check Hosted SRV parameter and identifies that user is homed online.
  4. Onpremise server will redirect the user to connect to online Servers by providing the Hosting Provider FQDN “Sipfed.online.lync.com”.
  5. User will then connect to online servers (after multiple redirects to user’s home server), which will re-authenticate the user and provide required services.

Once we are all set for migration from onpremise to Online, expect outages during the course of performing these actions (highly advised to perform these during non-business hours) as there is dependency on DNS servers TTL and Client DNS Cache.

Below are the steps to move the services from Hybrid completely to Skype for business online:

Step 1:

Ensure that all the users are migrated from Skype for business onpremise to Online

https://technet.microsoft.com/en-us/library/jj204969.aspx

 

Step 2:

Ensure that none the Applications (Office Servers or any third party applications) are dependent on the skype for business onpremise servers or made changes to make use of Skype for business online.

 

Step 3:

Modify the DNS records (externally & internally) and point the records to hit the skype for business online Services

44

Optionally, we can delete below unused records, as all the users are homed Online:

ExternalDNS:

2

InternalDNS:

3

Step 4:

Disable shared address space on Skype for business online:

https://technet.microsoft.com/en-us/library/jj994080.aspx

   Set-CsTenantFederationConfiguration –SharedSipAddressSpace $false

 

Step 5:

Clears resource records from a cache on the DNS server.

https://technet.microsoft.com/en-us/library/jj649893.aspx

Clears the contents of the DNS client cache.

https://technet.microsoft.com/en-us/%5Clibrary/jj553809(v=wps.630).aspx

 

Step 6:

Test the current setup for at least 2 weeks to ensure that after all the above changes, there is no issues or dependency on the Skype for business Onpremise Servers before proceeding with decommissioning of onpremise servers.

Decommission the Skype for business onpremise deployment

https://technet.microsoft.com/en-us/library/gg195815(v=ocs.14).aspx

 

 

Pragathi Raj S

Premier Field Engineer – Microsoft

 

 

Comments (16)

  1. Francesco Macri says:

    Hi, On Step 3. Modifying the DNS (Externally and Internally)

    Do we create/add the following records to our Internal DNS if they didn’t exist? At this point in our migration we only have these records created in our Public DNS.

    lyncdiscover.domain.com
    _sipfederationtls._tcp.domain.com
    _sip._tls.domain.com

    1. Pragathi Raj says:

      Hi Francesco,

      About the DNS records, “lyncdiscover.domain.com” & “_sip._tls.domain.com”, these are records client uses for Automatic sign in.
      We would need those records on the DNS Servers that client uses, Typically when clients are on Corpnet, they would be connected to Internal DNS and during that time Internal DNS Servers should have these records.
      If all your clients are leveraging public DNS Only then Internal DNS records might not be needed.
      however, adding it in internal DNS is not going to cause problem (even if someone connects to internal it would work)

      Regarding the record “_sipfederationtls._tcp.domain.com” this one is mainly for federation and would be used by Federated partner Edge Servers for querying for federated communication and this would be required on Public DNS.
      Hope that helps!

      Raj

  2. Dmitry says:

    Good stuff, Pragathi.

    Could you confirm please if the Edge server is involved in any way in the sign-in process for a SfB Online user whilst in the Hybrid mode? In #5 you are saying “after multiple redirects to user’s home server” – what servers, FE or Edge?

    Thanks
    Dmitry

    1. Pragathi Raj says:

      Hello Dmitry,

      For Sfb Online user, as long as they are using Lync 2013 or Higher clients (that uses Lyncdiscover records) Edge Server doesn’t come into picture, since they would get the Redirect Response directly while interacting with the Web Services.
      If they are using Legacy client (Lync 2010/Lync for Mac 2011) then since they depend on Access Edge Service via DNS Records, Edge would come into play.

      Regarding the Query on “After Multiple Redirects to user’s home server”, here I am referring to Online Servers, I initially when web services redirects the user to Cloud, it redirects to generic URL “Webdir*.online.lync.com” which reaches a specific pool in online, and users might be homes on different pool, so online servers would redirect the user to home pool/Server.

      Hope the above information helps.

      Raj

  3. Rick Eveleigh says:

    If you have people still running the Lync 2010 client do not remove the internal _sipinternaltls._tcp.domain.com record, instead change it to point to sipdir.online.lync.com.

    1. Pragathi Raj says:

      Hi Rick,

      Since they would be connecting to Office365 as a External User “it will use _sip._tls.domain.com” & not “_sipinternaltls._tcp.domain.com” (even if this record doesn’t exist, it will continue with Host A record sip.domain.com which is pointing to Office 365)

      Also, one thing that always comes to my mind is that Lync 2010 Clients connecting to Office 365 would use sip.domain.com (it would have attempted SRV Records but since it doesn’t follow Strict DNS Naming (domain name of user’s sipuri & host offering service domain), SRV would fail and it would fallback to Sip.domain.com “https://technet.microsoft.com/en-us/library/gg425884(v=ocs.15).aspx”)

      Thanks,
      Raj

  4. Chris says:

    What about the AD Attribute when i disable the Users, do i need to save some attributes (like proxyaddress) and reapply them after I decmmission the Pool?

    1. Pragathi Raj says:

      Hi Chris,

      Sorry, I missed this question earlier!

      Once we move users from on premise to Cloud, Resource (Userdata) is moved and AD attributes are stamped, users are no longer homed on Onprem, so we wont be disabling anyone on On-premise, instead we just proceed with Lync Servers/Pool Decommission.

      Basically, User’s AD Object Resides in On-premise AD & Sync’d to Cloud and the Resource for SFB is on SFB online.

      Thanks,
      Raj

  5. Michael Hincapie says:

    Thank you very much for this – as i am about to do this type of migration – Quick question I know i will have to wait some time for step 2 to be propagated but was wondering what is the average time wait to being testing? after migration has done and clients connect to SfB Online?

    Can I test the same night i do the migration or I have to wait one day?

    My Plan is to Migrate the users all to the cloud on Thursday and Friday night once I know the users are able to connect i do the migration of the DNS. Let me know what you think and thanks in advance.

    1. Pragathi Raj says:

      Hi Michael,

      Step 2 in this article is “Ensure that none the Applications are dependent on the skype for business onpremise servers” I am not certain if you are asking about this (since this is something admin should do manually depending on integration currently done with onprem)!

      About your plan, after moving users over to Cloud, and once you see them connecting to Cloud, you will switch DNS records to point to SFB Online, this sounds like good plan (Also,I would suggest you shutdown the onprem servers for 2 weeks and make sure there is no dependency on on-premise servers, before proceeding with decommissioning of servers)

      Hope the above info helps!

      Thanks,
      Raj

  6. josh sones says:

    Came across this and thank you for your time. However, I am still confused and trying to make sense of what we have and if this applies. We have old ocs (non r2) deployment and have since invested in o365. Our users are synched and have licenses. We are exchange hybrid and have some mbx migrated with more to be done. With that out of the way, I would like to move people over to use skype for business online rather than the internal ocs server. I noticed on my account, that if I launch old ocs client it connects to on prem ocs server and can still operate and shows all my save contacts. when I reboot skype for business auto starts instead and connects to cloud servers and I do not have contacts, but it logins successfully. This is the behavior on my personal external laptop too. Neither side can talk to the other it seems so does not look hybrid. Do these steps apply to my scenario? Do all the steps apply? Do I have to run the move user commands? Do I simply changes the dns records and have every stop using old client and have new client only? I want to decommission the ocs server very soon, but not much information on how to move forward. thx for your insight.

    1. Pragathi Raj says:

      Hi Josh,

      OCS clients use SRV Record for Auto sign in, which might be pointing to your Onprem Servers, however SFB Client uses Lyncdiscover Records first, if this is pointing to Cloud, then its possible that you are signing in to cloud account since you have assigned licenses to it.

      In a Ideal scenario, when customers wants to move from onprem to online, we suggest to sync AD Accounts and then assign license and then Move Onprem user to cloud (Once hybrid is setup).

      Since your are thinking of moving users over to SFB Online, you should consider implementing Lync/SFB Servers in your Environment and move users to Lync/SFB Servers and then configure Hybrid which will open the doors to migrate your onprem SFB Account to SFB Online.

      Refer to : https://technet.microsoft.com/en-us/library/jj205403(v=ocs.15).aspx for more details on Topology requirement and other planning for Hybrid Setup.

      Hope the above information helps!

      Thanks,
      Raj

      1. Josh Sones says:

        Thank you for your reply. Currently, I can be logged at the same time to both seperately to SfBO against cloud and microsoft communicator pointed to on-prem OCS R1 server with my internal company creds. I do not wish to have any on-prem OCS server or infrastructure anymore nor hybrid. I do not care about users contact lists. I simply want to:

        decomission OCS R1 standard server
        tell people to stop using Communicator client and launch SfB client
        since they all are synced to 0365 and have SfB license, it should connect and they can login with creds domain creds
        Now everyone is using SfBO and they can repopulate their contact lists

        Can it be as simple as that?

  7. Marc says:

    Good blog post, which will be helpful to me.

  8. Satya says:

    Well wrote Praj..ji

  9. Tom says:

    Thanks so much for this!

Skip to main content