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:
- Timeout of logon sessions
(auto lockout)
- Power management related
policies
- Requiring additional
authentication steps
- Denying access to local
drives
- Prompting users for slow
network connections
- Start a certain program at
logon
- Create another domain user
account on all domain-joined machines.
- 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.