Programmatically Enabling Users for OCS 2007

I’ve run across a couple situations where enabling users for OCS via the Management Console proved to be a bit cumbersome, typically when wanting to only select a certain subset of accounts among a list of thousands. So I set off to figure out how to easily perform the same action by manipulating the AD object attributes directly with scripts and freeware tools.

The first step was to observe exactly what changes were applied to an account when enabled via the console. I took a snapshot of the populated attributes on a normal user account and compared them to the updated values after enabling the user with Active Directory Users and Computers via the Communications tab. In order to successfully enable a user for Office Communications Server 2007 via the console the Sign-in name and Server or Pool settings are required at a minimum to save the changes.

The information supplied above was then used to set additional attributes as I observed these changes to the Active Directory user object:

proxyAddresses: sip:jeff@schertz.lab
msRTCSIP-Archiving: 0
msRTCSIP-OptionFlags: 256
msRTCSIP-PrimaryUserAddress: sip:jeff@schertz.lab
msRTCSIP-UserEnabled: TRUE
msRTCSIP-PrimaryHomeServer: CN=LC Services,CN=Microsoft,CN=OCS01,CN=Pools,CN=RTC
Service,CN=Microsoft,CN=System,DC=schertz,DC=lab

It appeared that these were the minimum required attributes on a user account for enabling OCS. I picked another account and manually stamped each of these with the appropriate information and then checked the Communications Server tab in ADUC and found that everything looked in order. A quick sign-on with that account verified that now worked with OCS.

The msRTCSIP-OptionFlag attribute starts at 0 for basic account and is immediately set to 256 to enable Enhanced Presence, which is required to sign into and use the Office Communicator 2007 client. Higher values could be selected based on the matrix I’ve discussed before in this blog article which can control further settings like RCC, EV, PIC, etc. I haven’t tested this in Live Communications Server, but I’d assume the same process would work, except that the msRTCSIP-OptionFlag value would be set to 0 as there is no Enhanced Presence in LCS. In the migrations I’ve performed I typically see LCS users set to either 0 or 1 (PIC enabled) and upgrading the user to OCS set them to 256 and 257 respectively.

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Normally I would use an LDIF import file to make all the above changes in one process, but LDIFDE does not support modifying multi-valued attributes and the proxyAddresses attribute sort of throws a curveball at that plan, as LDIFDE can only overwrite the entire value. This means exporting all current values first, modifying the data to include the new entry and then importing the changes over, which is not a good approach in most scenarios. A VBscript could be written to read in the values first, add the desired change(s), and then rewrite all the addresses in the same way. Also a complicated and potentially dangerous maneuver if left in the wrong hands.

Probably the simplest (and safest) way to deal with the multi-valued proxyAddresses attribute is to use the handy tool ADModify.NET. This is a powerful tool that makes short work of batch changes to objects in AD. IT also records all changes to an XML file, offering the option to later undo the changes made in Active Directory. (I’ve used this feature at least once in the past, to my relief!)

Solution

A simple LDIF import file can be used to set the required values for all of the msRTCSIP attributes, but I recommend to add the new proxyAddresses value before setting the OCS-specific attributes.

The Custom tab in ADModify.NET allows any attribute to be changed and even supports appending and removing individual values from multi-valued attributes. Here are some potential choices for the value field:

Attribute Name: proxyAddresses

Attribute Value: sip:%’mail’%
Attribute Value: sip:%’msRTCSIP-PrimaryUserAddress’%
Attribute Value: sip:%’mail’%

In this example I used the account’s current mail attribute value as it is common practice to set the SIP address to the same string as the user’s primary SMTP address. If a different format is needed then another approach would be to set the msRTCSIP-PrimaryUserAddress value first via LDIF and then immediately run ADModify.NET to add the additional SIP proxy address using %’msRTCSIP-PrimaryUserAddress’% as the value. (Note that the "sip:" prefix is already stored in that attribute where as the mail attribute is just the addresses itself.

So an LDIFDE import file used to enab
le a single account would look like this:

dn: CN=Jeff Schertz,OU=User Accounts,OU=SchertzLab,DC=schertz,DC=lab
changetype: modify
replace: msRTCSIP-ArchivingEnabled
msRTCSIP-ArchivingEnabled: 0
–
replace: msRTCSIP-PrimaryHomeServer
msRTCSIP-PrimaryHomeServer: CN=LC Services,CN=Microsoft,CN=JDSOCS01,CN=Pools,CN=RTC Service,CN=Microsoft,CN=System,DC=schertz,DC=lab
–
replace: msRTCSIP-PrimaryUserAddress
msRTCSIP-PrimaryUserAddress: sip:jeff@schertz.name
–
replace: msRTCSIP-UserEnabled
msRTCSIP-UserEnabled: TRUE
–
replace: msRTCSIP-OptionFlags
msRTCSIP-OptionFlags: 256
–

The latter portion of this previous blog entry covers converting a CSV file into an LDIF file required to modify the existing accounts, so that a CSV file with hundreds or thousand of accounts can be used with LDIFDE to enable many accounts at one time.