Deploy a resource forest topology
Important
Skype for Business Online operated by 21Vianet in China will be retired on October 1, 2023. If you haven't upgraded your Skype for Business Online users yet, they will be automatically scheduled for an assisted upgrade. If you want to upgrade your organization to Teams yourself, we strongly recommend that you begin planning your upgrade path today. Remember that a successful upgrade aligns technical and user readiness, so be sure to leverage our upgrade guidance as you navigate your journey to Teams.
Skype for Business Online, excluding the service operated by 21Vianet in China, was retired on July 31, 2021.
The following sections describe how to configure an environment that has multiple forests in a resource/user forest model to provide functionality in a hybrid scenario.
Topology requirements
Multiple user forests are supported. Keep the following in mind:
For supported versions of Lync Server and Skype for Business Server in a hybrid configuration, see Plan hybrid connectivity.
Exchange Server can be deployed in one or more forests, which may or may not include the forest containing Skype for Business Server. Make sure you have applied the latest Cumulative Update.
For details on coexistence with Exchange Server, including support criteria and limitations in various combinations of on-premises and online, see Feature support in Plan to integrate Skype for Business and Exchange.
User homing considerations
Skype for Business users homed on premises can have Exchange homed on premises or online. Teams users should use Exchange Online for an optimal experience; however, this isn't required. Exchange on premises isn't required to implement Skype for Business in either case.
Configure forest trusts
In a resource forest topology, the resource forests hosting Skype for Business Server must trust each account forest that contains users' accounts that access it.
If you have multiple user forests, to enable cross-forest authentication, it's important that Name Suffix Routing is enabled for each of these forest trusts. For instructions, see Managing Forest Trusts.
If you have Exchange Server deployed in an another forest and Exchange provides functionality for Skype for Business users, the forest hosting Exchange must trust the forest hosting Skype for Business Server. For example, if Exchange were deployed in the account forest, a two-way trust between the account and the Skype for Business forests is required.
Synchronize accounts into the forest hosting Skype for Business
Assume Skype for Business Server is deployed in one forest (a resource forest), but provides functionality to users in one or more other forests (account forests). In this case, users in the other forests must be represented as disabled user objects in the forest where Skype for Business Server is deployed.
You need to use an identity management product, such as Microsoft Identity Manager, to provision and synchronize the users from the account forests into the forest where Skype for Business Server is deployed. Users must be synchronized into the forest hosting Skype for Business Server as disabled user objects. Users can't be synchronized as Active Directory contact objects, because Microsoft Entra Connect won't properly synchronize contacts into Microsoft Entra ID for use with Skype.
Regardless of any multi-forest configuration, the forest hosting Skype for Business Server can also provide functionality for any enabled users that exist in the same forest.
To get proper identity synchronization, the following attributes need to be synchronized:
| User forests | Resource forests |
|---|---|
| chosen account link attribute |
chosen account link attribute |
| mail |
mail |
| ProxyAddresses |
ProxyAddresses |
| ObjectSID |
msRTCSIP-OriginatorSID |
The chosen account link attribute will be used as the Source Anchor. If you have a different and immutable attribute that you would prefer to use, you may do so; just be sure to edit the AD FS claims rule and select the attribute during the Microsoft Entra Connect configuration.
Don't sync the UPNs between the forests. You need to use a unique UPN for each user forest, as you can't use the same UPN across multiple forests. As a result, there are two possibilities: to synchronize the UPN or to not synchronize.
If the unique UPN from each user forest wasn't synchronized to the associated disabled object in the resource forest, single sign-on (SSO) would be broken for at least the initial sign-in attempt (assuming the user selected the option to save password). In the Skype for Business client, we assume that the SIP/UPN values are the same. Because the SIP address in this scenario is user@company.com, but the UPN of the enabled object in the user forest is in fact user@contoso.company.com, the initial sign-in attempt would fail and the user would be prompted to enter credentials. Upon entering their correct UPN, the authentication request would be completed against the domain controllers in the user forest, and sign-in would be successful.
If the unique UPN from each user forest was synchronized to the associated disabled object in the resource forest, AD FS authentication would fail. The matching rule would find the UPN on the object in the resource forest, which was disabled and couldn't be used for authentication.
Create a Microsoft 365 organization
You'll need to provision a Microsoft 365 organization to use with your deployment. For more information, please see Subscriptions, licenses, accounts, and tenants for Microsoft's cloud offerings.
Configure Active Directory Federation Services
Once you have a tenant, you'll need to configure Active Directory Federation Services (AD FS) in each of the user forests. This assumes you have a unique SIP and SMTP address and User Principal Name (UPN) for each forest. AD FS is optional and is used here to get single sign-on (SSO). DirSync with Password Sync is also supported and can also be used in place of AD FS.
Only deployments with matching SIP/SMTP and UPNs were tested. Not having matching SIP/SMTP/UPNs may result in reduced functionality, such as problems with Exchange integration and SSO.
Unless you use a unique SIP/SMTP/UPN for users from each forest, you can still run into SSO problems, regardless of where AD FS is deployed:
One-way or two-way trusts between resource/user forests with AD FS farm deployed in each user forest, all users share common SIP/SMTP domain but unique UPN for each user forest.
Two-way trusts between resource/user forests with AD FS farm deployed only in resource forest, all users share common SIP/SMTP domain but unique UPN for each user forest.
By placing an AD FS farm in each user forest and using a unique SIP/SMTP/UPN for each forest, we resolve both issues. Only the accounts in that specific user forest would be searched and matched during authentication attempts. This helps provide a more seamless authentication process.
This deployment is a standard deployment of the Windows Server 2012 R2 AD FS and should be working before continuing. For instructions, see How to Install AD FS 2012 R2 for Microsoft 365.
Once deployed, you need to edit the claims rule to match the Source Anchor selected earlier. In the AD FS MMC, under Relying Party Trusts, right-click Microsoft 365 Identity Platform or Microsoft Office 365 Identity Platform, and then select Edit Claim Rules. Edit the first rule, and change ObjectSID to employeeNumber.
Configure Microsoft Entra Connect
In resource forest topologies, it is required that user attributes from both the resource forest and any account forests(s) are synchronized into Microsoft Entra ID. Microsoft recommends that Microsoft Entra Connect synchronize and merge user identities from all forests that have enabled user accounts and the forest that contains Skype for Business. For details see, Configure Microsoft Entra Connect for Skype for Business and Teams.
Note that Microsoft Entra Connect doesn't provide synchronization on premises between the account and resource forests. That must be configured by using Microsoft Identity Manager or a similar product, as described earlier.
When finished and Microsoft Entra Connect is merging, if you look at an object in the metaverse, you should see something similar to the following:
The green highlighted attributes were merged from Microsoft 365, the yellow are from the user forest, and the blue are from the resource forest.
In this example, Microsoft Entra Connect has identified the sourceAnchor and the cloudSourceAnchor from the user and the resource forest objects from Microsoft 365, in this case 1101--the employeeNumber selected earlier. Microsoft Entra Connect was them able to merge this object into what you see above.
For more information, see Integrate your on-premises directories with Microsoft Entra ID.
Microsoft Entra Connect should be installed using the defaults, except for the following situations:
Single sign-in - with AD FS already deployed and working: Select Do not configure.
Connect your directories: Add all of the domains.
Identify users in on-premises directories: Select User identities exist across multiple directories, and select the ObjectSID and msExchangeMasterAccountSID attributes.
Identify users in Microsoft Entra ID: Source Anchor: Select the attribute you've chosen after reading Selecting a good sourceAnchor attribute, User Principal Name - userPrincipalName.
Optional features: Select whether you have Exchange hybrid deployed.
Note
If you have only Exchange Online, there could be an issue with OAuth failures during autodiscover because of CNAME redirection. To correct this, you will need to set the Exchange Autodiscover URL by running the following cmdlet from the Skype for Business Server Management Shell:
Set-CsOAuthConfiguration -ExchangeAutoDiscoverURL https://autodiscover-s.outlook.com/autodiscover/autodiscover.svcAD FS Farm: Select Use an existing Windows Server 2012 R2 AD FS farm and enter the name of the AD FS server.
Finish the wizard and perform the necessary validations.
Configure hybrid connectivity for Skype for Business Server
Follow the best practices for configuring Skype for Business hybrid. For more information, see Plan hybrid connectivity and Configure hybrid connectivity.
Configure hybrid connectivity for Exchange Server
If necessary, follow the best practices for configuring Exchange hybrid. For more information, see Exchange Server Hybrid Deployments.