As I may have mentioned before, I’m a big fan of scripted automation. It’s a life saver if you have to admin or work on larger systems. Anyway, I’ve produced a script for enabling either single or multiple users for Remote Call Control functionality on Office Communicator - I thought I’d share it as there’s some interesting ideas in it (from a scripting perspective) and also because some of you may actually find it useful.

Firstly, you can download the script from here.

The main point of the script is to take a user and configure the appropriate Active Directory properties on the user object to enable remote call control functionality. If you’re not sure what I mean by RCC, then have a review of this article here.

Essentially the script will configure the telephony mode to RCC and set the Server URI and Line URI values appropriately.

Probably doesn’t seem that big a deal does it? Imagine though on initial deployment if you had to configure the above for a 10s, 100s or 1000s of users - be proper tedious wouldn’t it?

This script does away with such manual sillyness. There are of course a few pre-reqs.

1. 1.You have to have appropriate rights to the user objects - so Domain Admins or explicit permissions to the objects we’re modifying.
   

2. 2.The script takes a 4 digit extension from the ‘ipPhone’ field and uses that as the RCC line ID. If that’s not set, the script won’t work.
   

3. 3.You need to set the value for your CSTA routing domain appropriately (I.e. the target DNS name for your CSTA gateway.
   

Option 3 may take a little explaining. OCS routes CSTA information to a target server - this target server is typically a CSTA gateway such as Cisco’s Unified Presence Server (CUPS) or Mitel’s Live Business Gateway (LBG). Users are identified as being targeted at the appropriate server by the use of the ‘Server URI’ in the user property.

You will need to modify line 14 of the script appropriately so that the variable ‘CSTAServerDomain’ is set to the appropriate target of your CSTA gateway. For example in my script it is currently:

CSTAServerDomain="cups-server.deathstar.local"

OCS is configured then to send any CSTA information for the domain ‘cups-server.deathstar.local’ to the IP address configured within the OCS routing. You must set this variable appropriately.

What you can do is copy this from an existing working user.

In the above you can see that my ‘Server URI’ is ‘sip:Mark.C@cups-server.local’. From this we can deduce that my ‘CSTAServerDomain’ variable must be set to ‘cups-server.local’.

So, to be clear, this script will not give you RCC functionality if you don’t have an appropriate, and already working, RCC infrastructure. What it will help you do though is deploy the appropriate settings to the user properties.

So, how do we run it? Well the script essentially has three modes of operation:

1. 1.Command line with a user DSN
   

2. 2.Command line with a user SAMAccount
   

3. 3.Command line with a text feed containing multiple accounts
   

The easiest way to run the script is to drag and drop it on to the ‘Start\Run’ dialogue box and then to append the user account you wish to enable in either DSN or SAMAccount format. For example:

Start/Run:

ConfigRCC.vbs MarkC        (MarkC being my SAM Account name)

OR

ConfigRCC.vbs “CN=MarkC,OU=Test Users,DC=deathstar,DC=local”

In this instance the attribute is the DSN of my user account.

If you want you can feed it a text-file too:

ConfigRCC.vbs C:\ListofUsers.TXT

The ‘ListofUsers.TXT’ is a simple text file containing a list of the users by their SAMAccount or their DSN Accounts. For example it may contain:

MarkC

CN=PaulC,OU=Test Users,DC=deathstar,DC=local

CN=Loopy,OU=Test Users,DC=deathstar,DC=local

The script will go through each one in turn and enable them for RCC.

The script could do with some tidying up and maybe some better error checking, but it essentially works and it has some useful ideas in it.

So what’s particularly useful - I.e. what may you find useful enough to use elsewhere? Well, firstly there’s the ability to convert a SAMAccount name to an associated DSN. The code piece for this is actually covered in my article here.

The other thing that’s interesting is the way the telephony functionality is controlled by the user object attribute ‘msRTCSIP-optionFlags’. This attribute is so important I’ve done another article on it - here.

Anyways, as always I hope you find the above useful.