Inter-Org Distribution List Migration

I had this post on at my previous blog and also at MSD2D, but I think it makes sense in putting it here also. You can download the code here.

Almost 40% of the current Microsoft Exchange customers are still using Exchange 5.5. Probably most of them have plans to migrate to the latest version, Exchange 2003 SP1, in the near future. There is lots of literature available about the right procedures for such a task, so if we’re not talking about something very complex, the migration process should be painless.

One of the difficulties you should be aware of (and now I’m speaking particularly for those who are about to migrate) is the migration of the old Exchange 5.5 Distribution Lists (DLs) to the new Universal Distribution Groups (UDGs) in Active Directory, when in an inter-organization scenario.

Migrating DLs in the same organization doesn’ http:

The only way I know to migrate DLs in this scenario (without using third party tools) is by exporting the DLs, and then using the LDIFDE or CSVDE command-line utilities to convert them to UDGs.

I had recently the opportunity to work on a client who needed this DL migration process, so a couple of colleagues of mine, Paulo Lopes and Paulo R. Lopes (they’re not related, before you ask), with a little contribution from myself, came up with the method I’ll describe next.

You can run the following command to perform a DL export from an Exchange 5.5 server (E55SERVER) in a Windows NT 4.0 Domain (NT4DOMAIN), using an NT4 account (NT4ACCOUNT) as the credentials:

ldifde -m -f DL_E55_NT4DOMAIN_OUT.txt -s E55SERVER -u -r “(objectClass=groupOfNames)” -l objectClass,rdn,cn,mail,otherMailbox,Extension-Attribute-1,Extension-Attribute-2,Extension-Attribute-3,Extension-Attribute-4,Extension-Attribute-5,Extension-Attribute-6,Extension-Attribute-7,Extension-Attribute-8,Extension-Attribute-9,Extension-Attribute-10,Extension-Attribute-11,Extension-Attribute-12,Extension-Attribute-13,Extension-Attribute-14,Extension-Attribute-15,textEncodedORaddress,uid,member -b NT4ACCOUNT NT4DOMAIN *

Then you must run a CSVDE export, in order to get the right Display Name:

csvde -f MB_E55_NT4DOMAIN.txt -s E55SERVER -u -r “(objectClass=*)” -l
objectClass,Admin-Display-Name,rdn,cn -b NTACCOUNT NT4DOMAIN *

The last step to import the DLs to Active Directory is to run LDIFDE again, using a global catalog server (GCSERVER):
ldifde -i -f DL_E55_NT4DOMAIN_IN.txt -s GCSERVER -j .\

The main problem with this method is that you’ll have to do some tweaking on those LDFIDE and CSVDE files in order to import them properly to the Active Directory. This can become a long, long time-consuming task (I know, I’ve been there). So I decided to create a script in order to automate this process.

Here is a brief description of what the script does:
1. Extracts Distribution Lists to a file using LDIFDE; 2. Extracts Exchange 5.5 Directory to a file using CSVDE (this is only necessary to match a user’s display name to his account name); 3. Modifies the first extracted file so that it can be imported using LDIFDE. Here is where the script does all its magic; 4. Imports DLs to Active directory as UDGs.

You still have to use ADC to synchronize the GAL. In fact, you must first import Exchange 5.5 users if you want the migrated DLs to be populated. So I strongly advise you to read the following KB article:

XGEN: How to Configure a Two-Way Recipient Connection Agreement for Exchange Server 5.5 User

Don’t forget that before you can run the script, you’ll have to modify the following variables:

strDN: the Distinguished Name of the destination OU
E55Server: the Exchange 5.5 server
GCServer: the Global Catalog server
NTUser: the NT User Account to connect to the source domain
NTDomain: the NT source domain

I don’t wish to bother you with one of those big disclaimers about responsibility or copyright, so I’ll just say that I’m offering you this script with the best of intentions, but you should always test before doing anything that can compromise your production environment. Besides that, feel free to distribute it to all your friends and to modify it, although I would appreciate that you drop me an email in case of new improvements.

Any feedback is always welcome.

You should also know that there are some issues with this tool:

Issues so far with the Inter-Org DL Migration Script

So far, these are the known issues with the script:

#1- Hidden DLs won’t migrate
Solution 1: unhide all objects before running the script
Solution 2 (not tested yet): try an LDAP filter on the LDIFDE command. Modify the command after the -r switch:
[…] -r “(&(objectClass=groupOfNames)(msExchHideFromAddressLists=TRUE))” […]
You can find more information about LDIFDE in the following KB article:
Using LDIFDE to Import and Export Directory Objects to Active Directory
Then you can use the same filter with CSVDE.
Of course you’ll have to run the commands outside the script.

#2- You get an empty file when you run the CSVDE command
Solution 1: modify the LDAP properties on Exchange 5.5, so that you can search more than the default number of items
Solution 2: run the CSVDE command directly on the Exchange 5.5 server (only supported on Windows 2000 Server).

#3- You cannot run the CSVDE command
Solution 1: check the permissions. Are you using an NT account with the propper permissions?
Solution 2: integrate WINS. Try replicating the WINS information from the NT domain to your current WINS server. You might prefer using an lmhosts file.
Solution 3: run the CSVDE command directly on the Exchange 5.5 server (only supported on Windows 2000 Server), then copy the file to server where you’re running the script.
Solution 4 (not tested yet): try to do a directory export using Exchange Admin. Make sure you have the following fields:
Take a look at Q155414 and Q261112 articles for an explanation on how to select field headers.

Any feedback about these issues is welcome. You can reach me by posting a comment here, or by the email address provided inside the script.

Disk geometry

Disk subsystem bottlenecks cause more performance problems than server-side CPU or RAM deficiencies, and a poorly designed disk subsystem can leave your organization vulnerable to hardware malfunctions.

This is so true! As memory chips become cheaper and consolidation dictates more users per server, the disk subsystem turns into the main cause of performance problems. The key to a system without problems is a proper planning and design. The document from which I extracted the beginning sentence, Optimizing Storage for Exchange Server 2003, is a good source of information.

One of the improvements you can make on your storage is to align the disks. Microsoft provides a tool, Diskpar, which allows to align the disk tracks with sector tracks. For partitions created by Windows 2000 and Windows Server 2003, the default starting sector for disks that have more than 63 sectors per track is the 64th sector, causing one out of every eight blocks of data written to your disk to span two disk tracks. Diskpar can increase disk performance as much as 20 percent, but you should always consult your hardware vendor before using this tool. Some disk configurations will have no benefit from the tool.
One fine example of information provided by the storage vendor is HP. Just take a look at this document: HP StorageWorks Enterprise Virtual Array 5000 and Microsoft® Exchange Server 2003: storage performance and configuration — white paper.

The Diskpar utility can be found in the Windows 2000 Server Resource Kit. With the release of Windows Server 2003 SP1, diskpart now includes this functionality. The new syntax for creating partitions with diskpart is:

create partition primary [size=N] [offset=N] [ID={Byte | GUID}] [align=N] [noerr]

Of course, you can still use diskpar:

Usage: diskpar [ -i | -s ] DriveNumber
  -i: query drive layout and partition information
  -s: set partition information (only used on raw drive please)

Ehlo World!

Forgive me the plagiarism, but I think “Ehlo World!” is a nice salutation that fits well in a blog dedicated to, according to, the number one corporate e-mail server.

Although I’m Portuguese, I won’t use my native language, I’ll post in English instead. I don’t dislike Portuguese, but I think this way I’ll reach a broader audience. Besides, I have a paralell blog 100% writen in Portuguese:

By the way, this blog will be the continuation of the blog I had at MSN Spaces, I’m thinking in bringing some of the posts to this site, meanwhile you can check them there.

So, let the games begin!