Automating Shared-Mailbox Management in Exchange 2003

Downloads
95696.zip

In many companies, it’s standard practice for employees to send email to customers using their personal corporate email address. But the downside to using a single-user address is that when an employee is out of office or leaves the company, external messages sent to the employee’s email address might not receive a timely response—or any response. The Microsoft Outlook Out of Office Assistant addresses this problem to some degree, but some companies don’t allow out-of-office responses to external senders.

Exchange’s shared mailboxes provide a means to avoid this problem. Most users are familiar with shared mailboxes such as [email protected] or [email protected], which external customers use to send messages to the company or a department instead of to a personal email address. At my company, we have around 900 shared mailboxes for various uses. To avoid bogging down our IT department with managing these shared mailboxes, I created a scripting-based solution to streamline administration of our Exchange Server 2003 shared mailboxes. I also provide a few suggestions for ways to enhance the solution, in the sidebar "Modifying the Shared-Mailboxes Solution." I tested the shared-mailboxes solution on Windows Server 2003 and Windows XP as well as Exchange 2003. My solution works with all versions of Outlook.

Pros and Cons of the Solution
Before you decide whether this scripting-based automated shared-mailbox solution suits your environment, consider its pros and cons. The solution’s main advantages include the following:

• Consistency: Values on Active Directory (AD) objects are always and automatically set in the same way each time they’re used. Thus, users don’t need to understand the details of account creation; and you don’t need to grant permissions on objects and folders individually in Outlook.
• Administration of the mailbox permissions is delegated to end users and is done via mail-enabled security groups found in the Outlook address list.
• All employees can find the user who’s responsible for the shared mailbox.
• All employees can see whether they have rights to use the shared mailbox.

The solution also has several downsides:

• Group membership requires users to log off and log on after a group is modified.
• An extra group object is needed for every shared mailbox that’s created.
• Someone needs to understand the script and maintain it. For example, changes to standard operating procedures could require changes to the script or configuration.
• The solution works only with Exchange 2003 and doesn’t support Exchange Server 2007. If you’re upgrading to Exchange 2007 in the near future, you shouldn’t use this solution because the scripts for it don’t work with Exchange 2007’s mailbox-creation facility and permissions.

Solution Prerequisites
My shared-mailbox solution consists of a number of batch-file and .vbs scripts, several Microsoft Windows utilities (Csvde, Dsacls, Dsquery, and Ldifde), the Microsoft GotDotNet ADModify tool, and the Blat freeware utility. The Windows utilities are used for retrieving and updating AD objects. ADModify is used for granting full mailbox permissions to the security group in the shared mailbox. Blat is used for sending a test email message to the newly created shared mailbox. This tool needs relay permissions to be able to connect to the chosen SMTP server (which you define along with other settings in the tool's configuration file—more about this later). If these permissions aren't set, no test email will be sent.

I’ve tested all these utilities. If a newer version of any of the utilities is available and you want to use it, be sure to test it before updating the shared-mailbox solution.

To use the shared-mailbox solution, you’ll need to perform a few preliminary tasks. First, check whether your Exchange organization already uses the AD extension attribute extensionAttribute1. (The extension attribute is used to separate the shared-mailbox objects from other AD objects; I explain the attribute’s usage and values a bit later.) You can do so by running the Dsquery command-line utility (dsquery.exe), as follows:

 dsquery * -filter 
 "( extensionAttribute1 =*)" 
 -attr cn extensionAttribute1 

(Some code in this article wraps to multiple lines for publication purposes.) If you already use this attribute in your domain, you have to find another unused extension attribute that you can use. Then change the extension attribute number from 1 to any value from 2 to 10 to find an unused extensionAttribute value that you can use for the script. When you’ve selected an extensionAttribute, use a text editor to replace all occurrences of the text extensionAttribute1 with extensionAttribute <selected number> in the SM.bat and SMowners.bat files.

You'll also need to create an organizational unit (OU) in AD where shared mailboxes and groups will be located. The location must be used in the SMutils.ini configuration file, which I discuss a little later.

Additionally, consider who should use the shared-mailbox tool. You’ll probably want to limit the use of this tool to IT administrators and exclude end users. If you're an Exchange administrator, you should probably have permission to create shared mailboxes. But if you use a separate username while performing administrative tasks that require Exchange Administrator rights, you can use the Runas command when using the shared-mailbox s cripts.

If you want certain end users to create shared mailboxes, you can follow these steps to enable this capability:

1. Create a security group containing those users.
2. On the shared-mailbox OU in AD, delegate these permissions to the security group : Create, delete and manage user accounts and Create, delete and manage groups. Delegate Exchange View Only Administrator to the security group on the Exchange organization.
3. Set the mailbox-store permission Change permissions for the group on the mailbox store where your shared mailboxes are to be placed.

Be sure that the shared-mailbox creators have installed Microsoft .NET Framework 1.1, which ADModify requires. You can download .NET Framework 1.1. Click here for more information about ADModify.

Additionally, when ADModify is used to set Exchange mailbox permissions as it’s used in my solution, The Microsoft Exchange System Management Tools (i.e., Exchange System Manager) need to be installed on the system that the shared-mailbox creator uses. (These tools and their requirements are on the Exchange 2003 CD-ROM.)

Installing the Shared-Mailbox Solution
Download the shared-mailbox solution (to do so, click the Download the Code button at the beginning of this article), then unzip all the files from SM.zip to a destination (e.g., the c:\ root folder). The script needs write permissions to run in the chosen directory. When you unzip the files, they'll be saved to \Admin under your destination directory—for example, c:\Admin if you unzip to c:\.

You can install the source files in a network share, but if you do so, only one creator may use the shared-mailbox solution at a time. That is, because the script creates temporary files in the \Admin folder, if you’re using a share it’s possible that multiple runs of the script could attempt to use files that are already in use.

SM.bat is the main script in the shared-mailbox solution. When SM.bat creates the first shared mailbox, it tries to copy the ADModify utilities to a new directory called c:\admodify. If the copy fails, SM.bat uses the \admin\admodify source directory. For help with ADModify, from the source directory run the command

 admodify\admodcmd /? 

To use the shared-mailbox solution, you’ll have to customize it for your environment. First, you’ll need to modify the PATH variable to include the destination of your shared-mailbox solution files. Also, you’ll need to change certain settings in the SMutils.ini file to enable the scripts to run in your environment. To do so, navigate to the Admin folder (e.g., c:\admin). Use a text editor to edit the SMutils.ini file and change the settings, which Table 1 lists. As you can see in the sample SMutils.ini file that Figure 1 shows, you use a semicolon to separate the attributes and values. Note that the default SMutils.ini file doesn’t include the domctrl and rootDN settings (see Table 1 for further description of these values). When the SM.bat script runs for the first time, it tries to retrieve these values from SMutilis.ini. If SM.bat doesn’t find these values, it prompts you to select a domain controller (DC) from a list.

The first time you run SM.bat, you also have to select the mailbox store for your shared mailbox. If you want to create a separate mailbox store for the shared mailbox, do so before you run SM.bat. You can change the default mailbox store at any time by running the SMfindHomemdb.bat script from your source directory.

After your first shared mailbox has been created via the shared mailbox solution, it’s a good idea to check that the mailbox and security group have correct email addresses stamped by Recipient Update Service (RUS). If RUS hasn’t stamped the address correctly, you’ll have to change one of your existing email policies or create a new one that includes these objects in the future. For example, you could include the following text in the policy’s LDAP search to include both shared mailboxes and the security groups:

 (extensionAttribute1=SM*) 

You can run the shared-mailbox solution from a shared directory; to do so, follow these steps:

1. Install the required software (described in the Solution Prerequisites section) on your server (I tested this on a Windows 2003 system).
2. Create the share.
3. Grant share permissions to relevant users (e.g., by using a security group).
4. Use a Universal Naming Convention (UNC) to name the share, or connect the share to a drive letter.
5. Install or move all files to the share.
6. Change the sourcedir value in the file SMutils.ini file to the name of the share (e.g., \\server\sharename\admin, \\server\admin, or x:\admin).
7. Change your PATH settings to include the share.
8. Start SM.bat as described in the next section.

Running SM.bat
You can start the shared-mailbox solution in several ways, by entering any of the following commands at a command prompt:

• SM.bat—starts SM.bat and displays the command’s Help screen when command is executed with no parameters. The script exits if your settings require Unicode mode.
• SMstart.bat—finds your SM.bat file (according to your PATH), tests for Unicode, goes to your source directory, and starts SM.bat without parameters (i.e., it displays the Help screen).
• call SM.bat—starts SM.bat from a batch file (bulk creations).
• cmd /u—starts a command prompt in Unicode mode. When you execute SM.bat, it now runs in Unicode mode. This is also necessary before executing batch files with bulk creations (see the Unicode setting's description and notes in Table 1 for further details).

How It Works
My script creates one shared mailbox and a distribution list (DL) with one member. The member is the person responsible for assigning other users access to the mailbox. The list is assigned full-user permissions on the new shared mailbox. The script generates a unique and complex password and assigns this to the domain account. Since other accounts are granted rights to access the mailbox indirectly, the users don’t need to know this password.

To create a shared mailbox, the SM.bat script needs three parameters: mail alias, display name, and username (i.e., the responsible user’s account). For example, the command

 SM.bat helpdesk "Company Helpdesk"
 DollyP 

tries to create a shared mailbox with these values set: alias = helpdesk, display name = Company Helpdesk, username = DollyP. It also tries to create a mail-enabled security group with these values: alias = helpdesk-owners, display name = Company Helpdesk (Owners), username = DollyP. The alias must have no spaces and can be only a combination of the characters a–z, A–Z, 0–9, hyphen (-), or underscore (_) because these characters are used to make the email address. The script could fail if you use invalid characters. It’s a good idea to determine a naming convention for your shared mailboxes to avoid problems when setting aliases on user mailboxes.

Before it creates the shared mailbox, the script looks for another Exchange object with the same email address as the new shared mailbox will have (based on the settings in SMutils.ini ). The script exits if the email address already exists. The script also tries to find the responsible user in AD. If it doesn’t find the user, the script exits.

If the script can continue, it performs these tasks:

1. Reads constants from SMutils.ini.
2. Creates a user object with a mailbox.
3. Sets a complex password on the user object.
4. Enables the user object.
5. Sends a test email message to the mailbox.
6. Creates a Universal Security Group (USG).
7. Sets the responsible user on the security group and gives the user permissions to modify the list.
8. Places the responsible user in the group.
9. Grants full mailbox and object permissions to the security group on the shared mailbox.

When the script is done, it has created both the mailbox and the security group. The script also sets the attributes in AD that Table 2 shows.

Easier-to-Manage Shared Mailboxes
The described solution is “as is,” but feel free to modify it as you wish. Of course, you use these scripts and utilities at your own risk. You should test the entire solution well in an isolated environment before using it in production. I’ve used a lot of my free time to make this solution as generally usable as possible. I hope you’ll find this automated shared-mailbox–management capability a valuable addition to your Exchange administrator tool set.