Domain Joining Considerations

You can join the LRS appliance PC to the Active Directory domain or leave it in a Workgroup. Consider the following points before making this decision.

• Domain-joining the LRS appliance PC helps in importing your organization’s private root certificate chain automatically.
• Domain-joining the LRS appliance PC enables you to grant domain users and groups administrative rights. By doing so, you will not have to remember the local machine level administrator account password.
• When you join an LRS appliance PC to the domain, we highly recommend that you create a separate Organizational Unit (OU), so that you can provide Group Policy Object (GPO) exclusions to the OU where all the LRS machine objects reside. When you do this, create machine objects in the OU before joining the LRS appliance PC to the domain.
• Many organizations have the following GPOs, which affect LRS appliance PC functions.  Ensure that you override or block the inheritance of these GPOs in the LRS OU:

• Alternatively, you might decide to leave the appliance PC in the workgroup. As with the desktop Lync client, this requires you to manually import the root certificate chain on the LRS appliance PC. You’re not required to import the root certificate chain if your Lync deployment is using a public certificate (for example, Entrust, VeriSign, etc.).

If you plan to join LRS machines to the domain, to avoid joining LRS machine inadvertently to an unintended OU, which may not be free from GPOs, ensure you join by using the following cmdlet from the LRS machine. This will ensure that the LRS machine joins in the correct OU and does not receive GPOs that might block LRS functionality.

$username = "contso.local\LRS01"
$password = ConvertTo-SecureString "password123” -AsPlainText -Force
$myCred = New-Object System.Management.Automation.PSCredential $username, $password

Add-Computer -DomainName contoso.local -Credential $mycred –OUPath “OU=LyncRoomSystem,OU=Resources,DC=CONTOSO,DC=LOCAL”

 

Even if you create a separate OU and block inheritance, there are some policies which are could cause issues at a higher level. A Group Policy with No Override setting beats an OU with a Block Policy Inheritance setting. For more information, see the article “No Override as Compared to Block Policy Inheritance” in the Group Policy documentation at http://technet.microsoft.com/en-us/library/cc978255.aspx.

You may have multiple approaches to solving these problems. We advise you to consult with your Active Directory experts to ensure you are provided with an OU that is free of GPO settings, or at least an OU in which the previously described policies do not exist.