AD Properties Required to Enable a User for OCS

As a follow-on to my popular post “Provisioning OCS From the Command Line”, several readers noted that they were in the situation where the OCS user had not been created (e.g. provisioned in AD). The AD user object exists, but that object has not been enabled for OCS. Until the user object is enabled for OCS, the associated WMI classes to configure OCS features cannot be used in their automated provisioning process.

The four minimum AD attributes necessary to enable an OCS user for sign-in with Communicator 2007 R2 are: 

AD Attribute Name Type Meaning
msRTCSIP-UserEnabled Boolean True = OCS Enable; False = not OCS Enabled
msRTCSIP-OptionFlags (1) Integer Bitmask representing OCS features.
msRTCSIP-PrimaryUserAddress String The primary SIP address of the user.
msRTCSIP-PrimaryHomeServer String The Distinguished Name of the Home Server.

With these four AD attributes set correctly, a user can login with Communicator 2007 R2 and you can then provision the user using the WMI provider and the ensuing various tools which use it (i.e. PowerShell, Scripting, Resource Kit tools).

Note (1): The AD attribute “msRTCSIP-OptionFlags” does not have to be set to enable the user for OCS, however, the user not be able to sign-in with Office Communicator 2007 R2 unless it is set to a bitmask value that enables Enhanced Presence:

  • The user will receive an error when they attempt to sign-in: “You will not be able to sign in because your account is not configured to support enhanced presence features”.
  • In the OCS management console properties for the user, the Other settings | Configure … | Enabled enhanced presence will not be set.
  • Adding a value of 256 to the value of msRTCSIP-OptionFlags will enable the user for Enhanced Presence. See the “Provisioning OCS Users (and the AD msRTCSIP-OptionFlags Attribute)” blog post for more information on “msRTCSIP-OptionFlags” and it’s possible values.

Once Enhanced Presence is set, it cannot be unset (the option will be grayed-out in the administrative console).  This can have implications if you still have Office Communicator 2005 clients which do not Enhanced Presence. See the previous blog post “Enhanced Presence and Upgrading Office Communicator Clients” for more information.

The AD attribute “msRTCSIP-UserEnabled” corresponds to the “Enable user for Office Communications Server” setting on the Communications tab in AD Users and Computers.  Just enabling this value to TRUE, is not sufficient to provision the user in OCS:

  • unless the user has a SIP sign-in address set (i.e. msRTCSIP-PrimaryUserAddress) the “Enable user for Office Communications Server” will still be unchecked and the user will not be able to sign in.
  • with this set to TRUE and a SIP sign-in address set, the user also must have a valid pool name/home-server (i.e. which corresponds to the “msRTCSIP-PrimaryHomeServer” AD attribute).  If a valid pool name/home-server is not set, AD Users and Computers will generate an error when attempting to view the Communications tab properties, and the user will still not be able to sign-in.

To help out with adapting your current provisioning process to enable OCS users, here is a quick VBScript snippet I put together which will set the four AD OCS user properties discussed in this post:

‘ customize the next line for your environment – you can use ADSIEdit or other tools to get the common name of a specific user
 
Set objUser = GetObject(LDAP://CN=<user common name>,OU=<user ou>,DC=<example>,DC=<com>)
objUser.put “msRTCSIP-UserEnabled”, true
objUser.put “msRTCSIP-OptionFlags”, 512         ‘ set this value to a bitmask representing which OCS features you want to enable/disable
objUser.put “msRTCSIP-PrimaryUserAddress”,  ‘ set this to the primary URI (typically the same as the users email address)
objUser.put “msRTCSIP-PrimaryHomeServer”,  ‘ set this to the distinguished name of the OCS front-end
objUser.setinfo
 
‘ Example PrimaryHomeServer: (e.g. “CN=LC Services,CN=Microsoft,CN=<your pool name>,CN=RTC Service,CN=Services,CN=Configuration,DC=example,DC=com”
 
Share and Enjoy:
  • Twitter
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • LinkedIn
  • MySpace
  • Reddit
  • Technorati

9 comments to AD Attributes Required to Enable a User for OCS

  • For OCS the AD attribute msRTCSIP-FederationEnabled will reflect whether the user is enabled for federation.

    For Microsoft Lync, have a look at this blog entry: http://blog.insidelync.com/2011/05/configuring-user-federation-remote-access-and-public-im-in-lync/.

    Curtis

  • manohar

    HI

    Is there any value for find out the user who are communicate to other domain ( Federation)

    Regards
    Manohar.K

  • Hi Kelly, you can automate this relatively easily using PowerShell or VBScript and the WMI provider. This blog post has an example of using the WMI provider with VBScript to access some of the OCS user properties. Another blog post of mine (at Provisioning OCS From the Command Line) has a more complete script for accessing these properties.

    There are lots of examples of accessing and querying AD (i.e. to query an OU). The Microsoft Script Center has them all nicely cataloged: http://technet.microsoft.com/en-us/scriptcenter/bb410849.

    If you are more comfortable in PowerShell, this article is really good (it explains how to use the WMI Provider with PowerShell): Ten Steps to PowerShell Scripting with Office Communications Server 2007 R2.

  • Kelly

    I need to write a script that will query an OU and check each user for the msRTCSIP-UserEnabled=TRUE attribute, if it is set to TRUE then check the msRTCSIP-PrimaryHomeServer attribute. if it is set to then change it to “CN=LC Services,CN=Microsoft,CN=ocspool1,CN=Pools,CN=RTC Service,CN=Services,CN=Configuration,DC=domain,DC=local”

    We are in the middle of collapsing a bunch of child domains into our main child domain and everything works fine except that some user’s PrimaryHomeServer attribute gets changed to

    When I manually change it to point to our PrimaryHomeServer everything works as it should.

    The only problem is we are migrating 1000-2000 users per week. I need to find a way to automate this.

    Thanks.

    Kelly

  • I put together and posted a powershell script to do this in the blog post “Provisioning OCS From the Command Line”: http://blog.insideocs.com/2009/01/16/189/. Note, the function requires 3 parameters: the SIP URI, the distinguished name (DN) of the AD user object, and the DN of the OCS home server. I posted another script to help retrieve those programmatically.

  • John

    Could you put together a powershell command which includes these attributes within the command you have in your “Provisioning OCS From the Command Line” blog?

  • Hi David,
    By ‘provisioning’ I just mean creating the OCS user and configuring the associated OCS feature set. A user can be configured to use OCS by only setting the AD attributes directly.

    Think of the WMI classes as a high layer that sits on top of AD, and other data sources such as the OCS backend database. The OCS WMI classes are customized for OCS and are more easy to work with because they are designed for OCS administrative functions. Under the covers the WMI classes will set the necessary associated AD attributes (not just user, but server, pool, org level), any backend OCS database tables values, and another other data sources to make the corresponding WMI changes. Also, depending on what you are doing, the WMI classes are easiler to work with in a scripting language. For example, when you start to do server and pool configuration, just getting the correct AD location can be challenging, and the WMI classes are easier to work with.

    I mention the AD attributes in several posts because most larger provisioning processes are use the AD attributes directly (e.g. while configuring other user services like Exchange).

    If you are into C# and the AD attributes are accomplishing what you need, there is no issue with setting them directly (that I am aware of).

    Hope that helps,

  • david

    Hi,

    Can user AD attributes directly do everything that provisioning the user through WMI can? Ie., what is the difference between setting the AD attributes and using WMI to configure settings?

    Thanks, and thanks for the post, very helpful.

  • [...] that is, the underlying AD object has been enabled at least once for OCS. See the blog entry AD Properties Required to Enable a User for OCS  for what happens the first time an AD object has been enabled for [...]

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>