What we have seen in the previous section applies (for a large part) also to companies that have moved Lync (and Exchange) to the cloud but still require a resource forest configuration. Microsoft has published a document, Deploying Lync in a Multi-Forest Architecture (Partner Hosted Lync with Exchange Hybrid), at http://www.microsoft.com/en-us/download/details.aspx?id=44276, which outlines how to realize different multi-forest hybrid scenarios.
The main issue in a hybrid resource forest is related to companies requiring Enterprise Voice for Lync which is not available on Office 365. In a scenario like the previously mentioned one, our resource forest will be split between two different hosting providers (on-premises and cloud). The two hosts have no trust relationship, and this makes the deployment more complex. Exchange deployment can be online or hybrid (with an on-premises component), and depending on the decision we take about our Exchange services, our resource forest scenario will change. We will see some of the steps related to the resource forest deployment including only Exchange Online services. The Lync resource forest will contain disabled accounts.
Exchange Online will use active accounts related to our domain accounts that are enabled to mail services. That's a DirSync-based configuration, like the one we have seen in Chapter 2, Lync 2013 Authentication, with an identity management solution such as Forefront Identity Manager, which we will see in the following sections. The following schema is a high-level overview of our scenario (our user forest will have a public name of ForestB.com):
- Internal DNS: While the DNS records for the resource forest and for Exchange Online are the ones we use in a standard deployment, Lync records on our user forest will use DNS records that point to the resource forest (with a split brain configuration). For Exchange, there are two required records that point to Office 365:
CNAME
autodiscover.outlook.comCNAME
msoid.ForestB.com - Public DNS: Public records for the ForestB.com Lync deployment will be the usual ones that point to the resource forest. For Exchange, we have the following records to configure (which point to Office 365):
CNAME
autodiscover.outlook.comCNAME
msoid.ForestB.comA
mail.ForestB.comMX
ForestB.mail.eo.outlook.comTXT
ForestB.com - For the purpose of securing access to the internal resources, Lync is usually based on certificates from an internal CA. We have to import the certificate of the issuing CA (and eventually the whole chain) in our user forest. The Microsoft document that we mentioned in the introduction of this paragraph offers a solution based on certutil. Another solution that only uses the Group Policy Management is outlined in the TechNet post Manage Trusted Root Certificates at http://technet.microsoft.com/en-us/library/cc754841.aspx.
- Export the CA certificate from the resource forest (in our scenario, the CA is
alice.wonderland.lab) and copy it to a domain controller in the user forest. - Launch Group Policy Management, edit the Default Domain Policy option, and select Computer Configuration, Windows Settings, and Security Settings.
- Click on Public Key Policies.
- Right-click on the Trusted Root Certification Authorities store and import the CA certificates, as shown in the following screenshot:
- Export the CA certificate from the resource forest (in our scenario, the CA is
- Configure Federation for SSO and Directory Synchronization for Exchange Online (see Chapter 2, Lync 2013 Authentication and then see the Authenticating with online services using DirSync recipe).
- Lync and Exchange Online Identity management require a synchronization service. We will talk about FIM for the synchronization of the Lync resource forest with the user forest in the following sections. For Exchange Online, we are able to use the Forefront Identity Manager Connector for Windows Azure Active Directory or the Azure Active Directory Synchronization Services (AAD Sync). We will look at the configuration and use of AAD Sync later in this chapter.
- Configure the Lync resource forest like a standard Lync deployment. Additional configuration requirements are the DNS records in the user forest and (if deployed) integration with Exchange Online UM.
- For the deployment of Exchange Online, for the most part, we will follow standard procedures. It is important, however, to map the disabled accounts in the Lync resource forest to Exchange Online users. Attribute mapping for on-premises to the cloud could be complex, but if we are using AAD Sync, all the configuration is automatic because AAD Sync setup will detect our existing deployment of Lync and Exchange, and create dedicated rules and connectors (refer to the sections about AAD Sync in this chapter).