Lync in the resource forest – msRTCSIP-OriginatorSid

In another article, I describe how an Exchange Resource Forest scenario works and how an Exchange First Migration can be used. Today I want to add another detail:

How does Microsoft Lync work in the Rebr/source Forest?
 

Microsoft Lync in a Resource Forest configuration

In an Exchange Resource Forest, users log onto an Account domain. Exchange mailboxes are provided in another trusted forest. For this to work user accounts in the Resource domain are deactivated and mailboxes are converted into so-called “linked mailboxes”

So, what happens when Microsoft Lync should be used in this Resource Forest? Logon with the user account from the Resource Domain is not possible as it is deactivated. Microsoft developed a similar solution to the one used for operating “linked mailboxes”. Remembering: the objectSID of the user account from the Account Domain is entered into the attribute “msExchMasterAccountSid” of the deactivated account in the Resource Domain. That is how Microsoft Exchange knows that another user account is authorized to use the account. The procedure for Lync is quite similar: here, the attribute is called “msRTCSIP-OriginatorSid” and the objectSID of the user account from the Account Domain is entered as well. Lync then automatically knows that the user is authorized to logon.

There are different ways to configure the msRTCSIP-OriginatorSid:

1. Lync Resourcekit Tool “sidmap.wsf”
2. Copy manually with ADSIEDIT
3. PowerShell Script
    

Solution via PowerShell Script

Usually I work in Active Directory Migration and Exchange migration projects and rarely with individual user accounts. That’s why I want to present the solution via PowerShell script which enables mass processing.

Firstly, the script searches for deactivated user accounts with a “linked mailbox“ and Lync configuration but without msRTCSIP-OriginatorSid“.

I recommend using the Quest PowerShell cmdlets for Active Directory because the cmdLet “getQADUSer“ with the parameters “-Enabled:false” easily filters out deactivated user accounts.

The filter looks like this:

The objectSID is read for every found user object. In this special case it has to happen via ADSI interface because the Account Domain is still operated in Windows Server 2003 mode and the Microsoft Active Directory cmdLet is not supported. (See article “PowerShell: Create connection to other domains)

Because the thus read objectSID cannot be written 1:1 into the attribute “msRTCSIP-OriginatorSid” it has to be converted into the type “System.Security.Principal.SecurityIdentifier“.

In this format the objectSID can be written into the attribute “msRTCSIP-OriginatorSid“. Because the attribute name contains a hyphen, it is easier to deposit the name as text in a variable ($Prop) previously.

Now the attribute “msRTCSIP-OriginatorSid” is filled with the objectSID of the user account from the Account Domain and logon to Microsoft Lync works properly.