Mergers, acquisitions, and other optimization activity can lead to a scenario where you want to merge multiple on-premises Skype for Business organizations into a single O365 Tenant, be that for Skype for Business Online or Teams.

Usually, the organization starts this process by synchronizing the on-prem AD contents from all organizations with Azure AD. This is followed by Exchange hybrid configuration. Both AD/AAD and Exchange support simultaneous hybrid configurations with multiple on-prem organizations.

Skype for Business, however, only permits one on-prem organization to be in a hybrid configuration at a time. The first organization is configured for hybrid, and the first SfBO or Teams users appear. Shortly after that, a report will come in to helpdesk about the online users not being able to reach the non-hybrid on-prem SfB organizations. Investigation shows that the on-prem users in the hybrid organizations can, however, reach these other organizations.

What’s going on can be a maddening process to unravel. For once, it’s not DNS or the network! When the AD/AAD sync is configured, the domain for the non-hybrid on-prem SfB organization is configured in the tenant (AD, Exchange, or a number of other reasons). This causes O365 to think that it now owns this domain for all O365 services, including SIP. The traffic to the user never leaves the hybrid organization via the federation processes, and results in a user not found scenario.

The solution is a simple one: Run the Disabled-CsOnlineSipDomain cmdlet against the non-hybrid on-prem SfB domain, from SfB online powershell. This tells O365 to ignore that domain for SIP purposes (but leave AD, Exchange, and others alone). Now the traffic will leave the organization and reach the intended user via federation. Problem solved!

When you have devices on an internal network that access the Internet via NAT, your firewall with perform what’s called “Port Address Translation”, or PAT.

When a device sends IP packets, it has both a source and destination port. The destination port is whatever service you’re access (like 443 for HTTPS), and the OS is typically in charge of selecting a source port, though an application (like Teams) may specific source ports to use.

Since you’ll have a number of systems behind your firewall, there’s the possibility that some of them will select the same source port to use in a conversation. This is especially true with an application like Teams that allows a source port range to be selected to facilitate QoS. PAT translates these source ports (whether or not they’re conflicting) to an unused port on the firewalls outside IP.

Problems can arise, however, if there is sufficient traffic on your LAN to use up all of the ports on the outside of your firewall. This can be because of a specific application using numerous ports, numerous applications running on a system, the overall number of systems on the LAN, or usually some combination of all three. This is called port exhaustion, as the supply of available ports is exhausted. Any modern enterprise or business class firewall will let you monitor the number of ports being used, and the good ones will generate an alarm. If you’re encountering port exhaustion, the most practical solution is to add IP addresses to the pool of IP addresses that the firewall can use.

If this isn’t possible, a much less favourable solution is to adjust timeout values on the firewall. Be aware that this can lead to poor application performance as connections need to be re-established for the application to run, rather than being left open.

Finally, you can use this article for guidance on planning the number of users/applications/devices per IP address. Note that these are only guidance, and different applications will use ports differently. Monitoring is key!