I have another piece of VBScript that some of you OCS Administrators or implementors may find useful. So I thought I’d share. God knows I’ve had enough help from the community out there in the past, it’s only fair I put stuff back

This script will enable you to feed it a text file containing a list of usernames and it will then go off and enable for the OCS for you. In addition, it will also configure federation, internet/remote access, PIC access and archiving according to your specifications.

Note that there is a dependency on the user having an Email address set - typically you want your SIP address to be the same as your email address. If that’s not suitable it wouldn’t be too hard to modify the script to formulate the SIP address from first name/last name etc. If you have specific requirements drop me a line and I’ll see if I can help you out.

Why would you use a script rather than the built in Admin tools? After all you can right-click and bulk enable OUs for OCS can’t you - and configure them? Well the main reason I’d use a script is that sometimes users for implementations are disjointed - they’re scattered all over different departments and OUs. It makes locating them and configuring them somewhat tedious.

Also, another affect I find of scripting is that it actually helps you understand what you’re doing with those fancy GUIs. Something that really comes in useful when you’re up against it. Not only do you know how to enable users, you even know what AD properties do what - what’s not to love about that if you’re a geek. Anyway, moving on.

The text feed file is a simple text file that contains a list of users - one per line. The user can be identified by either it’s SAM Account name or it’s DSN, either is acceptable to the script. Here’s an example feed file.

LLoo is Loopy Loo (remember Andy Pandy?) by the way. I don’t know about you but I really run out of inspiration for test users sometimes. As you can probably guess from the above list!

Anyway, you can see that the source list can be a mixture of DSN & SAMAccount. There’s a function in the script that will turn a SAMAccountName into a DSN - I wrote about it in a previous article if you want to go have a look see. I find it easier to add in both as you don’t know what kind of list you’re often going to receive from sites.

You can download the script from here. Now, before you run it you have to modify it to your environment. Which bits need modifying? Well download it and open it up in a script editor, preferably one with line numbering. As I’m on OSX I tend to use TextWrangler - on Windows Crimson Editor.

Download and open it up, and I’ll run through the bits you must modify, and the bits you can.

PrimaryHomeServer

The script needs to know where to home the users you’re going to enable. Look at my example line from my demo system - it’s line 35 in the script (or just search for primaryhomeserver):

primaryhomeserver="CN=LC Services,CN=Microsoft,CN=ocspool,CN=Pools,CN=RTC Service,CN=Services,CN=Configuration,DC=deathstar,DC=local"

The above will have wrapped for readability but it all needs to be on the same line. Now you can probably guess what yours ‘should’ be however I would strongly suggest that you copy this from an existing user.

You can find it from an existing working user by looking up the property:

msRTCSIP-PrimaryHomeServer

..using ADSIEDIT. Pretty easy really.

OptionFlags

I’ve talked about msRTCSIP-optionflags before in this article. We need to set the relevant values for the users you want to enable.

Lines 86 through 88 are relevant in the script. Let’s have a look at those bits here:

==========

PublicIM=1'0 PublicIM Disable - 1 Public IM Enabled

AnonymousMeetings=64'0 Anon. Participants Disabled - 64 Anon. Particpants Enabled

EnhancedPresence=256'0 Enhanced Presence Disabled - 256 - Enhanced Presence Enabled

==========

They’re pretty self explanatory. Remember they’re not binary 1 for on, 0 for off - each bit is a cumulative value.

Typically on OCS 2007 by the way you’d want enhanced presence enabled. There’s a detailed description of what Enhanced Presence is here. The only time you wouldn’t is if your clients are still using pre-Communicator 2007 (I.e. LCS) clients. Remember once it’s set the user can’t go back to a previous client!

External Access & Archiving

There are a few items of functionality that are not covered by the ‘msRTCSIP-optionflags’ property. Instead they’re explicit AD properties on their own. You need to set these accordingly too.

The lines relevant from the script are 92 thru 94.

==========

federationenabled=TRUE'Set to FALSE if federation is to be disabled

archivingenabled=1'Set to 0 if archiving is to be disabled

internetaccessenabled=TRUE'Set to FALSE if internet access is to be disabled

==========

Word of warning - note the mixed descriptors here. Federation/Internet (I.e. remote access) are boolean TRUE/FALSE whereas ArchivingEnabled is numerical (1 for on, 0 for off). Incidentally on the archiving bit if you have your system to archive globally (I.e. not user set) then this setting will be ignored.

So set the above values to what you want.

Running the Script

Assuming you’ve modified the script to your environment, you’re now ready to create a feed-file and run the script. Of course I don’t have to mention to test it on some test users first - don’t just bang in 500 users in your first run!

How do we run the script? The simplest way is to drag and drop the VBS script to your ‘Start/Run’ box and then tag the path to your feed-file on the end. For example:

You can drag & drop the feed-file too from explorer. Depending on how many users you’ve put in the feed file it can take a while to run. I’ve tested it on my 4k seat test bed and it takes about 2 minutes to do around 4k users - not too shabby.

When it’s finished you’ll get this pop-up:

In addition, when you click ‘OK’ you’ll have two log files pop up in Notepad. The first, called ‘OCSErrorList.TXT’ is a list of users that the script failed to enable. I’ve left it in a raw format - it’ll just list whatever you put in the source file. In my source example above you’ll see that I had a dummy non-existent user called ‘Monkey’. The error file was returned like this:

It will essentially  list any users in the source file that it couldn’t successfully enable.

The second log file will be called ‘OCSBulkEnable.LOG’ and is in far more depth. Download the one from my dummy run here and we’ll have a look at the bits of it.

First part:

This part essentially tells you who is running the script, in what domain, which workstation, and the paths to the log & error files. Note that by default they go into your temp directory.

It also lists the feed-file that you’ve sent to it, and confirms that the script can find it.

Take a look at the next bit:

This bit is essentially confirming the options that you entered for federation/archiving and all that good stuff.

We then move on to the user-enablement. I won’t run through all the users but let’s have a look at one.

You can see the line fed in from the source text, then you can see it locate the DSN and then move on to process the SIP addresses. Any errors on the user would also be highlighted here. Let’s have a look at that pesky ‘Monkey’.

Well you can see from the above the script was unable to locate the DSN for the username provided.

Useful Script Functions

As I’ve hinted at above, I often think looking at scripts people have done is more than just getting a script that does something for you. It can teach you something about what you’re doing - how it works and why.

There’s some functions in the script worth looking at, mainly:

GetDSN. This returns the user’s DSN from a SAMAccount name.

ConfigOCSUser. This configures a user DSN object for OCS. Interesting to see the appropriate AD attributes don’t you think?

Summary

I hope you find this sort of stuff useful. It’s a very handy script to have if you’re doing larger implementations.

You can extend this to include RCC configuration by combining in the script from this article here. I’m also in the process of finishing an article on bulk-enabling users for Enterprise Voice (or UC Enabled) as well - all of which can be combined into one single master enablement script or kept discrete.

Personally I prefer one enabler and then for voice I use different scripts. No reason you can’t combine the two.

Anyways, hope this helped somebody!