Download this script

Background

I was recently asked to provide an automated process for enabling and managing LCS 2005 attributes for users in our Active Directory.  Since it took a while to gather all the information and a small amount of scripting to the complete the solution, I thought it would be worth sharing my findings here.

The script discussed in this article is available for download in the attached ZIP file (if you are subscribed to the Activedir.Org site).  The process described here can be implemented with no prior knowledge of scripting being required.

How to manually enable LCS users

I’m certainly no LCS expert.  In fact, I have no idea about LCS.  My task here was completely focused on the Active Directory side since this is where various LCS attributes are stored, on the AD user object.  So I had to start with the basics and use the manual process of enabling a user.  If you already know how to do this then you will certainly be bored by this section and will want to jump to the next.

Assuming at this point you have completed all the necessary pre-reqisites for an LCS install, such as the schema updates, domain prep’s etc. and you have an LCS Server up and running then you want to start enabling your users.  To manage LCS users you need to have fulfilled three pre-requisites:

• Active Directory Users and Computers MMC (Adminpak.msi installed)
• LCS Administrative Tools (installed from the LCS Install CD)
• You must be a member of the Users/RTCDomainUserAdmins group (or equivalent delegation)

If you have all this, open up ADUC and look at the Properties of a User Object.  There you will see an additional tab called ‘Live Communications Server’.  Here you can enable/disable and manage LCS attributes such as SIP Address, SIP Server and enable the User for Federation and so on.

fig 1. RTC Attributes as viewed on a User Object in ADUC

fig 2. RTC Advanced Attributes as viewed on a User Object in ADUC.  Through the attached script these attributes can be set globally on users across a domain, OU etc. automatically.

RTC Attributes on a User Object in ADSIEdit : just to give an idea of the attributes you can query on using LDAP filters.

There is an option of bulk-enabling all users in an OU using the manual process.  This is probably a good way to start enabling all your existing users, provided you are happy to enable everyone within a container (OU, Domain etc.), unconditionally.  Since my task was to automate a solution, the manual bulk enable method wasn't really an option especially since it provided no functionality to filter which users we wanted to enable.  

Not wanting to go into much more detail than this (simply because I dont have the LCS knowledge!), I’ll just mention one more thing to be aware of.  The AD data is somehow synchronised with an LCS SQL DB.  When a user is enabled in Active Directory a process called called User Replicator controls this synchorisation process.  I suppose you could liken it slightly to Exchange's RUS. 

The LCS Address Book Service, also running on the LCS Server, will check existing LCS users for any changes since the last sync (say if a user has been renamed for example).  This is all done via the DirSync control that tracks changes on objects in the directory.  So this final piece of the puzzle explains how the users AD configuration makes it from AD in to the LCS environment. 

For best results, we should make sure that any automated process we have to enable LCS users runs prior to any AD to LCS sync process, since users will only be fully enabled until the sync from AD to LCS has completed.  In some environments this may only happen once per day. 

This is about as far as my LCS knowledge extends, so I’ll stop right here with LCS talk!

For more information on configuring the Address Book and User Replicator services, see

http://www.microsoft.com/technet/prodtechnol/office/livecomm/library/reference/lcsref_12.mspx

Creating a script to automate this process

After searching around for a while I located and downloaded the LCS 2005 Resource Kit from the Microsoft Site (don’t install the LCS 2003 ResKit like I did at first ;-)).  The LCS 2005 Reskit can be download from here:

http://www.microsoft.com/downloads/details.aspx?familyid=A368DED8-EA7C-4C65-9844-39CAFA07A454&displaylang=en

After installing this I found exactly what I needed in matter of seconds, great!  A WMI script called LCSEnableConfigureUsers.wsf.  Perfect! 

As it turned out the script worked quite well straight out of the box.  It provided pretty much the same functionality from the script as the manual process provided with the advantage allowing us to schedule the task to run every night (using the Windows Task Scheduler).  It will enable all users in an OU, all users in a group, or both.  Still, there were a few shortcomings to be worked out before putting it to work in our environment.   A few changes to this script were required.

What needed to be changed?

Missing LDAP Filters

One of the first shortcomings was having no way of making use of LDAP Search/Filters to scope which users should be LCS enabled/disabled.   For example, enabling only users within an OU having a specific 'Company' attribute setting would be a nice feature.  The ResKit script only provided the option to enumerate ALL users in an OU or Group without any way to filter on custom criteria.

Additionally, further benefits would be gained by implementing LDAP Search and Filters since they make it possible for us to only query the AD for users that have not already been LCS enabled.  This is more efficient for larger environments, where the script would be potentially querying 1000’s of users each runtime.  This leads us nicely onto the next point…

Enabling already enabled users

The current ResKit script re-stamped all users at each run time whether they were LCS enabled or not. This is pretty inefficient.  Okay, it makes sense in some cases where for example you would like to change a global setting and re-apply it to all users (for example if you were wanting to set an new LCS Server) however doing this every time the script runs seems overkill. 

I wanted to keep this functionality so it could be used to rollout new settings to all users, however, for everyday use this would be disabled and the script would only enable users that were not yet enabled and ignore the existing LCS users.

One Setting Fits All

I wanted a way to use the LDAP filters to apply different settings to different sets of users.  Say there were two different departments in my company, one needed Public IM Connectivity but the other didn’t.  The only way of maintaining this type of environment would be to create two separate instances of the ResKit script.  Okay this was acceptable but I wanted everything to be managed from a single location and a single script and set of config files. 

No way to maintain a central list of users that should be disabled

There was also no way in the Reskit script to maintain a list of users that should not be LCS enabled.  I wanted something in our environment where we could maintain a list of users that would be LCS disabled, regardless of whether they fell into the LDAP query result.  This would be in the form of an AD Group.  If the user was added to this group, they would never be LCS enabled, and if they were LCS enabled prior to being added to this group. they would be LCS disabled. 

The aim here was to make it simple for a help desk to manage a list of who is blocked from using LCS.  By providing just a group, there would be no need to delegate any special LCS permissions to the Helpdesk, they can just modify the membership of this group to manage LCS and the rest is automated.

Configuring and running the script
 

There seems little point to get into the VBScript code since you shouldn’t need to change anything, unless of course you are planning to use it as example code and implement something similar within your own solutions.  The script uses WMI to manage the LCS user attributes. 

As mentioned previously, this script will work in most environments without any script changes.  Quick disclaimer though: all environments are different and if you do implement this in your own environment and it breaks something then we take no responsibility for it.

There are various configuration options and requirements that must be met in order to implement the script in your environment.

Requirements (same as for the manual process)

• Active Directory Users and Computers MMC (Adminpak.msi installed)
• LCS Administrative Tools (can be installed from the LCS Install CD)
• The logged in user must have RTCDomainUserAdmins (or equivalent delegation)

Script Installation

Download the ZIP file attached to this article and expand it to a directory on your HDD, for example c:\LCSUserEnable.

Quick Start

See the Examples directory in the ZIP file for some quick starts.  You will need to customise the configuration files to your environment but this doesn’t take much effort to figure out. 

Once you downloaded and extracted the script on your workstation, there should be the following files:

• LCSConfigureUsers.wsf   – the script file
• Users.txt                        – the file that defines the scopes of users
• GlobalConfig.txt              – the file that defines the LCS properties (and how) to be applied to users
• Enable.bat                      – a batch file that calls the script with default parameters
• \Examples                      – a set of examples

I would always recommend testing the script in your test environments first.  You can potentially enable all domain users if you aren’t careful.

Once you tested the script and are happy with the results (hopefully), you can change this line inside the file LCSConfigureUsers.wsf (edit this in notepad or VB source editor of your choice).

' actually write changes to the directory objects
Const bWriteChanges = false 

How to Configure the USERS.TXT

Open the users.txt to find the default settings.  You will find something like this;

The format of this file follows this convention:

DISABLEGROUP:<distinguishedNameOfGroup>

DN: <distinguishedName Of OU To Use As SearchRoot>##<LDAPFilter>

GROUP: <distinguishedNameOfGroup>

DISABLEGROUP:  you can specify the distinguishedName of a group where you will place users that will never be LCS Enabled (and if they are LCS enabled they will be disabled).  If you don’t want this function then you can remove the line, or simply prefix it with a semi-colon (;). 

Please note that if you do use the DISABLEGROUP feature then it must appear only once in the users.txt file and must be at the very beginning! 

You now have two options to enable LCS users, either by LDAP Search : (DN:) or by Group (GROUP:)

Ldap Search

DN: here you can specify the Default Search Root to begin any Searches.  This should be in the format OU=MyUsers,DC=MYDOMAIN,DC=COM following your own domain naming structure.

Still on the DN: line (after the ## delimiter) you can specify the LDAP Search Filter you want to use for searching users.  Anything matching the filter within the search scope will be LCS enabled.  For example (cn=*) will enable all users found under the Search Root you specified, (cn=a*) will enable all users where CN begins with ‘a’.  (department=MyDept) would only enable users within a specific department called MyDept and so on.

More information on LDAP filter specifications can be found on the MSDN web site.

The script automatically appends its own LDAP Filter to ensure you only enable valid users so you can omit any (ObjectClass=User), (ObjectCategory=Person) and UserAccountControl flag search filters from your filters.

If you are in a test environment and want to get started you can use the default filter of (CN=*) to get you started.

Note that you can specify multiple DN: tags in the users.txt file depending on your requirements.  Some examples can be found in the Examples directory in the ZIP file.

By Group

GROUP: here you can specify the OU of a group where you will place users who will be LCS Enabled (if they aren’t already members of the DISABLEGROUP that is).  This should be in the format CN=MYGROUP,OU=GROUPPS,DC=MYDOMAIN,DC=COM following your own domain/ou  naming structures.

Note that you can specify multiple GROUP: and DN: tags in the users.txt file depending on your requirements.  As an example, you could have

Here you will see we can specify different DN: and GROUP: tags to enable us to scope which users we will LCS enable. 

You can also specify which settings you would like to enable on each group of users.  This is done by appending a ConfigFile to the end of each definition in the users.txt and can be found in the examples directory of the ZIP file. 

Configuring GLOBALCONFIG.TXT

Open the GLOBALCONFIG.TXT  to find the default setting, something like this;

 
You can pretty much keep with the defaults here.  Most of the attributes are fairly self explanitory.  They are documented in more detail in the ZIP file.  You would certainly need to enter the HomeServerDN wth the LCS Pool Name in distinguishedName format (as in the example provided).

Scheduled Task

If you choose to go live with the script, it's possible to use Windows Task Scheduler to schedule the script to run each night or whenever you like.  It would be most efficient to run it slightly before the User Replicator and Address Book Service in order to populate the address book within the scheduled run.

Advanced Configuration 

As mentioned earlier you can apply different settings to different sets of users if required.  See the /Examples directory within the attached ZIP file for an example of this. 

I hope you find this useful and it saves you some time when working with LCS users.