Vista - ADSI scripting "risks"

A colleague has developed a script to add a second SMTP address to all of
our mailboxes in first.last@xxxxxx format, in order to satisfy a new
regulatory requirement for our organization. She is a competent and cautious
scripter, and I have reviewed some of her code and found it well crafted.

Before implementation we got into a discussion with someone from the group
that looks after our AD infrastructure. He is even more cautious, and wants
us to modify the script to apply the changes to smaller chunks of accounts,
evaluate the results to see if it has caused any "problems" for AD. We have
about 20,000 accounts scattered over perhaps 80 OU's, and he is suggesting
doing no more than about 200 at a time.

We have no problem doing this, however, when we asked what kind of
"problems" we should be looking for, he had no idea. And no idea how to go
about looking for those unknown problems. His concern is that if the script
goes completely haywire, it might cause operational issues for our exchange
infrastructure.

The obvious risks associated with our script would seem to include such
things as creating duplicate addresses, creating addresses with special
characters, creating illegal addresses, and somehow disabling the current
username@xxxxxx addresses.

The question I want to ask here is this: are there any other potential
issues that could result from running a script that modifies all accounts in
this manner? For example, bulk changes would certainly result in additional
replication traffic (we have as many as 200 DC's in perhaps 80 AD sites all
connected by a fairly robust WAN infrastructure). Are there any best
practices or guidelines that would allow us to predict the impact of this?
If not, are there any techniques for measuring the impact during or after
implementation?

I have used LDIFDE to update various attributes on the approximately 350
accounts in my OU, and, after testing one or two first, I usually just let
it run and have never seen any problems.

Beyond possible replication issues and logical errors in the script, are
there any other factors that would suggest that breaking a bulk modification
down into chunks would be a prudent thing to do?

Any comments will be greatly appreciated.

/Al

It's always good to be a little paranoid. Bulk updates do have an element
of risk and you should exercise caution when making large updates to the
directory service.

You've already anticipated the increase in replication traffic - I'm not
sure exactly how you would go about predicting the impact of this on your
network though. Updating in smaller batches as suggested would minimize the
impact on replication - you might also consider performing the update during
a period of low network activity.

It's always a good idea to test bulk updates in a QA environment first. You
might also choose a smaller sample of users to update in your live
environment before applying the update to all users.

Testing is always a good idea, but sometimes problems come up that haven't
been anticipated. It's always prudent to have a recovery plan. Make sure
you are familiar with recovery techniques and have a recent backup of your
directory before performing the update.

Hope this helps,

David,
http://www.wisesoft.co.uk
(My personal website and a free resource for IT Professionals)


"Al Dunbar" <alandrub@xxxxxx> wrote in message
news:OzHGDvNQJHA.1164@xxxxxx