Does Lync Server use the same Active Directory attributes and attribute values that Office Communications Server 2007 R2 used?
Well, yes … and no.
. Don't you just love it when you ask a yes/no question and you get back
yes and no as the answer?
We didn't think so.
This question arose because an attendee we spoke to at TechReady 12 had written a script for Office Communications Server 2007 R2 that enabled users by going in and modifying the appropriate Active Directory user account attributes. For example, part of the process involved setting the value of the msRTCSIP-UserEnabled attribute. He wanted to know if that script would still work with Lync Server 2010, something which would be true only if the Active Directory attributes used in OCS 2007 R2 are the same as the Active Directory attributes used in Lync Server.
And the answer is that a lot of these attributes
unchanged. However, there have been some new Active Directory classes that have been added and a few Active Directory classes that have been modified.
(For a quick overview of the changes, see the article
Schema Changes in Lync Server 2010
.) Depending on what your script does, it's
that a 2007 R2 script could be used for enabling Lync Server users. However, we don't recommend it: rewriting the script to use Lync Server PowerShell is a much better way to go. For example, you could actually assign policies in Lync Server by directly manipulating the value of the msRTCSIP-UserPolicies attribute. However, the msRTCSIP-UserPolicies attribute has values that look like this:
In case you're wondering, there's actually a method to that madness; for example,
means that the external access policy with the Anchor value 5 has been assigned to this account. If you were really gung-ho (a polite term for "really crazy") you could decipher all of that and assign an external access policy by adding some value like
to the msRTCSIP-UserPolicies attribute. Or, you could simply run a PowerShell command like this one:
We strongly recommend you stick with PowerShell. Not only is it easier and faster, but if something goes wrong you can get support from Microsoft to help you fix the problem. That's probably
going to be the case if you start directly modifying attribute values; that's because that's not the supported method for managing user accounts. After all, that's why we added PowerShell to Lync Server in the first place.