Cross Forest Trusts for User Migration and Skype for Business

I’ve been involved in my fair share of acquisitions and mergers larger companies over the years. You know, the kinds that are large enough to need government approval? A lot of them are fairly simple. The bigger company buys the smaller company and starts migrating users into their domain with tools like Microsoft Identify Manager, Forefront Identity Manager or one of the many Identity management tools available.

Usually they take this opportunity to either rebrand or amalgamate the SMTP/SIP domains making your life quite simple as they are effectively “New users”

But what about when as part of the migration process they decide to create cross forest trusts and do it the “old school” way?

Well Skype4B supports Resource Forests and multiple forests with a Central Forest. But not merging two companies separate forests each with their own Skype4B topology together.

One notable exception is that you can create a trust between both domains and migrate everyone into a single Office365 tenant. But that’s not what we are talking about in this article.

It should be noted if your endgame or nirvana state is to get your users into Skype4B Online or more likely Teams. Then the simplest method is to sync both forests with the same tenant and move the users from on-prem to Office365.

The issue is that most businesses will setup a cross forest trust whilst doing these mergers for other parts of the migration as they support moving users cross forest (cough Exchange cough) and as part of the cross forest trust. Conditional DNS forwarding will typically be setup between the forests.

Aaaand then everything Skype4B looks like this because your split DNS config is in a weird place.
(I’ve been told Windows Server 2016 and up can do some cool Split-Brain DNS stuff.. But that’s outside the scope of this article)

Googled this? Looking for the TL;DR?

I go into more detail for phase 0 and 1 below, but here is the summary of steps for a whole migration.

Phase 0 – Break-fix

If you need to set things up Right now and Phase 1 below is unsuitable because of delays in CAB etc

  • Review your current DNS external records or use something like RUCT to discover them
  • Insert static DNS entries to emulate the external DNS in the opposing domains to keep things “As-is”

Phase 1 – Enable Skype in the Split Forest DNS

  • Add Manual Federation Routes to Topology
  • If your federation FQDN internally resolves to the Front-End Pool, add HOSTS entries on the Edge pool
  • Install Root Certificates for each domain on all client PC’s / Lync Servers
  • Add Firewall exclusions so the two networks can see each other

Phase 2 – Prep the Environment to accept your users

  • Build new infrastructure (if required)
  • Prepare your old gateways etc to move to the new pool
  • Install the new Certificates
  • Export/import user data (contacts)
  • Test environment

Phase 3 – Proper Cut over

  • Enable the migrating SIP Domain in the new Topology
  • Update DNS for the incumbent sip domain
  • Cut over PSTN gateways to winning topology.

For the sake of this article we are going to say that TailSpinToys is being bought by Fabrikam and take a quick look at the issues and how we should resolve them before enabling DNS conditional forwarding.

First off, DNS!

DNS Discovery Issues

Issue: Federation between the two companies may fail.

If your edge servers use your internal DNS for DNS lookups instead of the recommended public DNS method federation will fail.
(This waaaay more common than it should be)

The federation discovery DNS entry for Fabrikam would typically point to which before the DNS changes would point to the Fabrikam Edge Servers. But will now route directly to Fabrikam Front-Ends and vice versa due to the Split DNS config (or even potentially, nothing as the SRV record should be missing internally)

When the TailSpinToys Edge Pool attempts to do a DNS lookup it will either find nothing or it may attempt to communicate with the Fabrikam Front-Ends directly instead of using the Edge Pool and will fail

Workaround: Configure Manual Federation discovery on both topologies for the merging sip domains.
Proper Fix: Always use external DNS where possible on Edge Servers

Issue: Clients will no longer use Edge Pool for sign in.

This should be expected behavior, but as Fabrikam clients at TailSpinToys offices now discover the Front-End Pool via DNS instead of the Edge Pool, They must be able to communicate with it and vice versa

Workaround: Use Static DNS entries to point to edge sever instead
Proper Fix: Add Firewall Exclusions (noted below)

SSL Trust Issues

Issue: Cross Domain Meeting Join issues

Now that the two companies will start having cross business meetings a lot, you will start seeing users unable to join meetings from each others meetings as web services no longer pass via the Reverse Proxies. This means they are signed by the opposing companies untrusted root certificate and will be rejected by the client.

Workaround: Use Static DNS to point webservices via external reverse proxies
Fix: Install Trusted Root certs for both companies in your client SoE’s and in your phone provisioning servers

Issue: User Sign in due to SoE problems

Users TailSpinToys users who are not using the Fabrikam SoE but have Fabrikam SIP addresses will now fail to login due to TLS trust issues (root certificate missing)
This is caused as previously they used the Reverse Proxies and Edge Pools to connect which have publicly trusted SSL certificates.

Workaround: Use Static DNS to point to external Edge Servers instead
Proper Fix: Install Trusted Root certs for both companies on both SoE’s

Issue: Cross Domain Address Book / Pin Service / UCWA

Same as above, but for web services. These will now point directly to the Front-End Pools instead of getting SSL re-branded via the Reverse Proxies.
As such users will be unable to lookup other users using the address book due to a certificate error

Workaround: Use Static DNS to point to external Reverse Proxy instead
Proper Fix: Install Trusted Root certs for both companies on both SoE’s

Firewall Issues

As Fabrikam users can now discover their home Front-End pool via the TailSpinToys DNS, their Skype4B client will attempt to connect to their home infrastructure directly instead of using the Edge Pool. This means that TailSpinToys networks must be able to communicate with the both the Fabrikam Front-End Pools and any Internal Edge Pool Interfaces for MRAS and vice versa.

See your initial design documentation for the list of ports and addresses you will need to add for this new “Remote site”
Remember that all vlans must be able to communicate with 3478 on the Edge internal interfaces.

Don’t forget you will need firewall entries for
• Front-End Pools
• PSTN Gateways (Media bypass)
• Internal CA – (CRL)
• Edge Internal interfaces

Thats it for now, If you need help with phase 2-3 there are plenty of guides on using Export-CsUserData, I might even make one soon.
Hope this helped.

One thought on “Cross Forest Trusts for User Migration and Skype for Business

  1. Hamed

    Dear James,
    Thank you for your article, I want to implement the scenario that users in the account forest can login with their account into the resource forest where S4B on-premise has implemented . I need step-by-step configure and implement documentation. I have read following article but it wasn’t completely useful so, my scenario is not complete , Could you help me in this regards.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.