Deploying Lync Server in a Resource Forest Topology

I’ve been ask several times in the past about the options for having Lync Server 2010 or 2013 deployed in a forest then having another forest use the Lync infrastructure.  While there has been plenty of blog posts written about it, I think one of the most overlook behaviors of deploying Lync Server in a Resource Forest Topology is the way in which a user logs on.  I for one had to learn the lesson the hard way but luckily in a lab environment when I was testing the actual deployment prior to actually speaking to clients about it and what I learned is that if you have a Resource Forest Topology, the user actually needs to use a login that belongs to the domain where Lync is deployed in as the Sign-in address and a login that belongs to their own domain as the User name.  This can obviously be confusing and sometimes not acceptable for some organizations but is probably the only choice if you aren’t going to purchase Microsoft Forefront Identity Manager 2010 which costs around $15000 for the server license and around $500 for a user CAL and have a separate Exchange organization deployed in the forest with Lync deployed and another Exchange organization deployed in the forest that will be using Lync in the other forest.

Since I recently had a deployment a few months ago for a client that uses a Resource Forest Topology as well as Exchange Linked Mailboxes for corresponding accounts in the resource forest as demonstrated here:

Lync server 2013 simple central forest user provision through Linked mailboxes
http://blogs.technet.com/b/saleesh_nv/archive/2013/04/05/lync-server-2013-simple-resource-forest-user-provision-through-linked-mailboxes.aspx

… I took the opportunity to screenshot the steps so to not let it go to waste, I will put it in the blog post.

The following are a few useful articles and tools about the 2 different ways of deploying Lync to be shared between forests:

Deploy Lync Server 2010 in a Resource Forest Topology (Part 1)
http://actionxp.wordpress.com/2011/09/04/deploy-lync-server-2010-in-a-resource-forest-topology-part-1-2-2-2/

Part 1: Deploying Lync Server 2010 in a Central Forest Topology
http://technet.microsoft.com/en-us/library/gg670889(v=ocs.14).aspx

Part 2: Deploying Lync Server 2010 in a Resource Forest Topology
http://technet.microsoft.com/en-us/library/gg670911(v=ocs.14).aspx

Install the Lync Server Sync Tool
http://technet.microsoft.com/en-us/library/gg670886(v=ocs.14).aspx

Microsoft Lync Server 2013 Resource Kit Tools
http://www.microsoft.com/en-us/download/details.aspx?id=36821

Step #1 – Begin by creating a 2 way forest trust between the domains

I won’t go into the details of building a 2 way forest trust but you’ll need to:

1. Configure both forests’ DNS to be able to resolve the other domain (I prefer to use DNS zone forwarders)
2. Configure a 2 way forest trust between the domain

Step #2 – Use the Exchange Management Console to create a Linked Mailbox

Begin by opening the Exchange Management Console in the domain with Lync deployed:

 

 

Fill in the following fields with:

Trusted forest or domain:  Select the domain of the forest that will be using the resource forest’s Lync infrastructure

User name: Type in an administrator account to the domain that will be using the resource forest’s Lync infrastructure

Linked domain controller: Select a domain controller in the domain that will be using the resource forest’s Lync infrastructure

Linked master account: Select the user account in the domain that will be using the resource forest’s Lync infrastructure

 

Note the new linked mailbox account as shown in Exchange:

Note the disabled account created in Active Directory Users and Computers:

Step #3 – Enable the disabled account for Lync

Use the Lync management console to enable the disabled Lync account in the resource forest:

Step #4 – Use the SIDMap.wsf to populate attributes in a Resource Forest

Download the Lync Server 2013 resource kit at:

Microsoft Lync Server 2013 Resource Kit Tools
http://www.microsoft.com/en-us/download/details.aspx?id=36821

Install the tools and navigate to:

C:Program FilesMicrosoft Lync Server 2013ResKitLcsSync

Locate the SIDMap.wsf script as shown here:

Opening the SIDMap.wsf script will contain the following contents:

Execute the script and you will see the following prompt indicating the mapping of the two accounts between the resource forest and the forest that will be using Lync:

For more information on the switches available for specifying item such as the OU to search for the disabled accounts, see the following:

Use the SID Mapping Tool to Populate Attributes in a Resource Forest
http://technet.microsoft.com/en-us/library/gg670903(v=ocs.14).aspx

Step #5 – Create a sip.resourceForestExternal.com DNS record and configure a GPO to trust the internal Root CA of the resource forest in the forest using the resource forest’s Lync infrastructure

Since the forest using the resource forest’s Lync infrastructure will be using the resource forest’s domain as the sign-in address, you will need to create a sip.resourceForestExternal.com DNS record in the other forest’s domain (this is assuming the sign-in address is a public domain that is not the same as the internal domain of the resource forest).  Sorry about the confusion but let’s say:

• The resource domain’s internal domain name is corp.domain.com
• The resource domain’s external domain name is domain.com

Then the user will be signing in as john.smith@domain.com and so you will need a sip.domain.com A record to point to the Lync Standard or Enterprise Pool’s internal IP.

If the resource forest where Lync is deployed uses a internal Microsoft Certificate Authority for the Lync infrastructure, you will need to create a GPO in the forest using the resource forest’s Lync infrastructure to trust the resource forest’s root CA.

Step #6 – Test Login

With the above steps completed, you should now be able to log into the resource forest’s Lync using an account in the other forest:

Note the following:

Sign-in address: <the sign-in address in the resource forest domain>

User name: <the domain account of the forest using the resource forest>

 

I apologize for not going into a lot of details but I hope this gives a good idea of what such a deployment would look like.