Joe Richards, one of the technical reviewers for this book, has written a terrific command-line tool called ExchMbx, available from JoeWare.net (http://www.joeware.net/win/free/tools/exchmbx.htm). This tool allows you to mail-enable users, groups, and contacts, remove Exchange attributes from selected objects, and do a number of other interesting and useful things. Best of all, it can be used with the JoeWare adfind utility so that you never have to type another long user DN on a command line—feed adfind your search criteria, then pipe its results to exchmbx and you’re golden.

You need to create a user account and a mailbox.

While you can create a mailbox using ldifde, we’re not going to show you how to do it, because it doesn’t really work properly, as the msExchMailboxSecurityDescriptor attribute can’t be correctly set through ldifde. You can use the information included within this recipe to create the user object, but you then need to manually mailbox-enable the user object through ADUC (this was determined after a painful amount of testing the creation of a mailbox—once we determined that the mailbox looked right, but wasn’t working right, we did a little more research and found out that Microsoft definitely doesn’t recommend the creation of mailboxes through ldifde imports). However, the exchmbx tool fixes this problem by making it easy to mail-enable newly created mailboxes or contacts from the command line correctly, so feel free to use this method if it’s appropriate for your environment.

The creation of a mailbox via a script is really a two-step process, and it’s imperfect at best. Basically, what we’ve done is create a new user account in Active Directory, then used the script that is also used for Recipe 5.2 to mailbox-enable that user account. The discussion for Recipe 5.2 explains a lot of the process, so we’re going to point you to that.

MS KB 305144 (How to Use the UserAccountControl Flags to Manipulate User Account Properties), MS KB 324353 (Users Cannot Access Public Folders or Delegate Mailboxes on a Separate Server), RFC 2849 (The LDAP Data Interchange Format (LDIF)—Technical Specification), MS KB 293339 (How to create a mailbox-enabled user with CDOEXM in Visual C++), and MS KB 237677 (Using LDIFDE to Import and Export Directory Objects to Active Directory); exchmbx documentation at http://joeware.net

You have an existing account that isn’t mailbox-enabled; you need to create a mailbox for it.

Creating a mailbox for an account that already exists is relatively straightforward; actually, Microsoft only supports using ADSI or the CDOEXM CreateMailbox method to create the mailbox. That’s because mailbox creation actually has four distinct phases:

The reason you need to understand this process is timing. Until step 4, the user can’t log on to the mailbox because it hasn’t been created. For that reason, many organizations want to automate their mailbox provisioning by setting the security descriptor and other attributes manually; that way, instead of waiting for steps 3 and 4 to finish, users can log on and use their mailboxes immediately after creation. (Actually, these scripts normally send mail to the users as part of the setup process, so step 4 really does occur.) MS KB 304935 describes the somewhat involved process required to set mailbox rights on a newly created mailbox; it’s far simpler and safer to let the RUS and store do the work instead, so that’s the approach we present here.

Recipe 5.1 for creating a user and mailbox together, MS KB 313420 (How To Add a Mailbox to an Existing User Account in Exchange 2000 Server), MS KB 275636 (Creating Exchange Mailbox-Enabled and Mail-Enabled Objects in Active Directory), MS KB 327079 (How to programmatically create a mailbox for an existing user in the Active Directory by using CDOEXM), MS KB 304935 (How to set Exchange 2000 mailbox rights at the time of mailbox creation), and MSDN: IMailboxStore::CreateMailbox; exchmbx documentation at http://joeware.net

You want to remove the mailbox from an account while leaving the account intact.

In keeping with science-fiction author Spider Robinson’s famous dictum that it’s easier to build a tape eraser than a tape recorder, it turns out that removing a mailbox is simpler than creating one. The CDOEXM DeleteMailbox method does all the dirty work. In the previous script, you have to supply the user’s DN and the name of a DC, so that ADSI can be used to identify the mailbox; after that, deleting the mailbox itself is simple. When you delete the mailbox, two things happen: the mail-enabled attributes are removed from the user object (which will then be replicated to other DCs in the same domain, and then to GCs throughout the forest), and the mailbox table, and its associated data, will be marked for deletion in the information store. Don’t delete a mailbox unless you really want to get rid of it, because once the store deletes it, you’ll find it difficult to get it back; you can disconnect mailboxes or disable accounts if you want to prevent access while still preserving your opportunity to restore access later.

Recipes Recipe 5.1 and Recipe 5.2 for creating mailboxes and user objects, MS KB 297398 (HOWTO: Delete a Mailbox Using CDOEXM and Visual C++ ), and MSDN: IMailboxStore::DeleteMailbox.

You need to create a new group and mail-enable it so it can be used to send messages.

Creating a mail-enabled group from a script requires two separate sets of operations. First, you have to create the group. This is simple, since you can just use the ADSI Create method to create an object with the specified location and name (of course, you have to tell Create that you’re creating a group). This step also requires you to set the group scope, which you do by setting the groupType attribute. We’ve included the relevant group types as constants in the previous script.

After creating the group, you have to mail-enable it so that the correct proxy addresses are set. In a similar vein, if you create groups from the command line with dsadd, you’ll need to mail-enable them with the Exchange Tasks wizard or by using the MailEnable method as shown in the previous script.

One important note: the groupType attribute stores both the group scope and its type (that is, whether it’s a security or distribution group). To create a security group, just set the ADS_GROUP_TYPE_SECURITY_ENABLED to the group scope flag. For example, to create a security-enabled universal group in VBScript, you’d write:

objGroup.Put "groupType", ADS_GROUP_TYPE_UNIVERSAL_GROUP Or 
ADS_GROUP_TYPE_SECURITY_ENABLED

Recipe 5.1 and Recipe 5.2 for creating mailboxes and user objects, Chapter 7 of Active Directory Cookbook for more recipes for creating and removing group objects and manipulating their membership; MS KB 231273 (Group Type and Scope Usage in Windows); dsadd documentation at Microsoft’s Windows Server 2003 site

You want to apply mailbox size limits to users, groups, or organizational units, but Exchange only lets you set them on servers, mailbox databases, or the Exchange organization.

You can set mailbox storage limits in several different places, depending on how widely you want them to apply. By default, the storage limits you put on a mailbox (or public folder) database applies to the objects it contains; however, you can override those limits for individual mailboxes. As an optimization, only those limits that are actually set are stored. For example, let’s say you’ve configured a database to provide a default set of limits of 200 MB for warning, 300 MB for prohibit send, and 325 MB for prohibit send/receive. You then edit a handful of mailboxes to apply new limits, unchecking Use mailbox store defaults and filling in your own values for the warning limit. If you then try to query the value of mDBOverQuotaLimit and mDBOverHardQuotaLimit on the mailbox, you’ll find that these attributes don’t exist; instead, you’ll have to check the limits on the mailbox store to find out what the default limits are.

Recipe 4.5 for applying system policies to servers and Recipe 4.10 for setting default send/receive size limits on messages in transit

You have mailboxes on one server and need to move them to another.

The process of moving mailboxes is largely the same for Exchange 2000 and Exchange Server 2003. However, the Exchange Server 2003 version of the mailbox mover includes two welcome improvements:

Before you can move mailboxes across sites in a mixed 5.5/2000/2003 environment, there are some prerequisite steps you must fulfill:

The script for this recipe is distinguished largely by the long, ugly set of strings necessary to specify correctly which mailbox DB is to be used. It is necessary to specify the full path to the target MDB, but you don’t have to specify anything about the source mailbox other than the DN of the user.

MS KB 836489 (an update is required for mixed-mode site consolidation with Exchange Server 5.5)

You want to know who last logged onto a mailbox and when.

MSDN: Exchange_Mailbox class in the Exchange 2003 WMI section of the Exchange SDK

You want information about how many items are in a mailbox and how much space it occupies.

The code to find mailbox size is very similar to the code used to retrieve access and logon information. The mailbox size and item count are directly exposed via WMI in Exchange Server 2003, so they’re easy to get. Unfortunately, if you want to get the same information without WMI, you’re consigned to using MAPI: you’ll need to write a script that locates all the mailboxes (easy, given what you’ve learned in this chapter), then logs on to each one using MAPI to retrieve the mailbox size and item count properties. There are two big problems with this approach: one is that logging in updates the last logon time and user, and the other is that you have to run such a script with an account that has read access to all the mailboxes you’re scanning. For those reasons, we haven’t included the script here.

Recipe 5.7 for getting mailbox logon information and MSDN: Exchange_Mailbox class

Someone deleted one or more mailboxes and you want them back.

When you delete a mailbox, sometimes you need to get it back. Strategies for doing this vary according to what version of Exchange you’re using:

The Mailbox Recovery Center in Exchange Server 2003 works very much like the deleted item retention behavior for mail items. When you delete an Exchange Server 2003 mailbox, Exchange doesn’t actually remove the associated mailbox data from the store immediately. Instead, it replaces the mailbox attribute of the account with a special value known as a tombstone and leaves the mailbox data intact. The tombstone ages over time; when it reaches the end of the retention period (which defaults to 30 days), the store’s normal IS maintenance task will remove the associated data. Just as with the deleted item “dumpster,” you can recover mailboxes as long as you’re within the retention period for the associated store. All the recovery center does is remove the tombstone and reassociate the data in the EDB/STM files with the Active Directory account (to be sure, this is somewhat of an oversimplified explanation).

Recipe 5.2 for creating mailboxes, Recipe Recipe 11.10 for using the Mailbox Recovery Center, and Recipe 11.11 for using recovering storage groups

You have an Excel spreadsheet (or some other data source that can easily be turned into an Excel sheet) and you want to add many mailboxes at once based on its contents.

Many administrators never realize that Office applications like Excel, Word, PowerPoint, Visio, and Access are scriptable, too; in fact, the Visual Basic for Applications (VBA) script language shipped long before Microsoft decided to support broader scripting for administrators. You might be wondering why you’d want to use Excel as the front end for mass creation of mailboxes, but it actually makes a lot of sense to do so. First, Excel can easily digest CSV files, so if you’ve used csvde, the Exchange 5.5 Administrator application, or some other means of generating a CSV file, Excel makes it easy to clean up or reformat the contents of that file with minimal fuss. Second, Excel is scriptable and can easily connect to databases, so if you want to be able to tie account creation to some kind of existing business process that revolves around creating user records in a database, it’s a natural candidate. Third, Excel is a familiar tool to many otherwise nontechnical users—like your HR department. Providing a tie between Excel and Exchange means that you can more easily accept data from them without writing your own custom tools.

You can do something very similar with the exchmbx tool’s -cr switch, since you can pipe a text file into it. To use exchmbx , create a text file that contains the CNs of the mailboxes you want created. Optionally, you can specify the mailbox database where you want them created. Here’s a sample file, mailboxes.txt, that lists three users, one of which has a specific database given.

"CN=Paul Robichaux,ou=partners,dc=3sharp,dc=com"
"cn=Peter Kelly,ou=partners,dc=3sharp,dc=com" RED-EXCH01:SG1:MDB2
"cn=John Peltonen,ou=partners,dc=3sharp,dc=com"

Then use the -cr switch like this:

> Exchmbx -cr RED-EXCH01:SG1:MDB1 < mailboxes.txt

The two accounts that don’t have a mailbox database specified will end up in the database specified as an argument to exchmbx; the other will be created in its specified database.

Recipe 5.1 for creating an individual mailbox, Recipe 5.2 for mailbox-enabling an existing user, Chapter 6 of Active Directory Cookbook, and MSDN: Create User Accounts from Information in an Excel Spreadsheet (http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting04132004.asp)

You want to create a contact (or custom recipient, in Exchange 5.5 parlance) that can receive mail but that doesn’t have a mailbox.

Contacts differ from actual user objects in several ways, all of which are related to the set of attributes associated with the respective objects. Contacts aren’t security principals and don’t have any of the security principals’ attributes, so they cannot be used to assign privileges or to log on, nor do they have any of the SID-related attributes (SAMAccountName, objectSID, userAccountControl, and userPrincipalName) that user accounts have. They also don’t have mailboxes; instead, they use the proxy address field, familiar to us as the placeholder for the address of an account’s mailbox, to forward mail sent to the contact. The advantage of this approach: contacts can appear in address lists, so they look just like every other mail-enabled object.

When you create a contact via ADSI, the Dsadd utility, or CSV import, you only have to specify two attributes: the DN (specified by combining the contact object’s mailNickname attribute with its container path) and the primary email proxy address are required, but other attributes (including the display name, first name, last name, telephone number, and so on) are all optional. There are several important additional attributes (notably showInAddressBook, mAPIRecipient, and InternetEncoding) that will not be populated by the RUS when it next runs; you must stamp these values manually.

MS KB 275636 (Creating Exchange Mailbox-Enabled and Mail-Enabled Objects in Active Directory), MS KB 233209 (Windows 2000 Contacts and Users), and MS KB 327620 (How to use Csvde to import contacts and user objects into Active Directory)

You want to create separate address lists for subdivisions of your Exchange organization.

Address lists allow you to create flexible groupings of your users that are automatically updated. If you’re familiar with recipient containers in Exchange 5.5, you’ll recognize the underlying idea: define a rule that says which users should be grouped together, then let Exchange reassign users as necessary. Unlike 5.5 recipient containers (which didn’t allow you to move users between them), address lists are based on LDAP queries, so the lists are dynamically assembled, and the original objects’ attributes are mostly untouched. You can write arbitrarily complex LDAP filter expressions to define the contents of your address lists; ESM provides a fairly robust interface for creating canned queries, but you can plug in your own filter expression via the GUI or in a script. (Note that although LDAP queries are used to build the address lists, clients access them via the Name Services Provider Interface, or NSPI.)

Once the address list has been created, the RUS will update it whenever it runs (which means that you may experience short propagation delays). If you leave the RUS schedule set to its default of “always run,” then the RUS will be run whenever a recipient policy changes, which in turn means that your address lists will be updated when you change recipient policies. The RUS actually updates the showInAddressBook attribute to reflect each address list in which the object should be visible. You can verify the address list’s presence in two ways: within ESM (although it may not appear until you quit and relaunch the snap-in) or by creating a new message in Outlook and clicking the To button, then using the Show names from the combo box to pick the new address list.

When you create an address list via script, it is important that you create it in the correct container. The All Address Lists object is the immediate parent of all the address lists you define in the organization; in turn, that object lives in the Address Lists Container object, a child of the Exchange organization object. The value of the PurportedSearch attribute specifies your LDAP filter.

Recipe 5.17 for hiding items from address lists, MS KB 319213 (How to Use Address Lists to Organize Recipients in Exchange Server 2003), MS KB 822940 (How to Manage Address Lists When You Host Virtual Organizations), and MS KB 253828 (How the Recipient Update Service Populates Address Lists)

You want to create a mail-enabled distribution group that automatically updates its membership based on rules you specify.

Query-based distribution groups are probably better known by their original name: dynamic DLs. The idea behind QDGs is that you should be able to define some set of search criteria that can be used to populate a DL, and that when objects’ properties change such that they should be included in, or excluded from, the DL, the DL should automatically be updated somehow. When you create a QDG, you must specify an LDAP filter that selects the objects you want. The filter in the listing above is the one generated by the ESM GUI when you create a new QDG; notice that it excludes items named “System Mailbox” and any item that isn’t a user or that doesn’t have an Exchange home server defined. You can specify more complex LDAP filters to selectively limit QDG membership to particular OUs or subgroups of users. One thing to bear in mind when designing your QDG queries is that the query will be executed each time the QDG is expanded. Each message sent to the QDG will cause an expansion, depending on where the sender is and which server is responsible for the expansion process. For complex queries, or for large result sets, the performance impact on your GCs and Exchange servers can be significant. You can work around this to an extent by designating a specific expansion server for the QDG (or any other DG); this doesn’t reduce the load, but it does let you control where it goes.

Another very important aspect of QDGs is that each has a legacyExchangeDN attribute, just like a mailbox. Also just like mailboxes, the legacyExchangeDN value for each QDG must be unique in the forest. If you create multiple QDGs with the same name (say, one in each domain of a multidomain forest), you must be certain that the legacyExchangeDN values for each QDG are distinct.

MS KB 822897 (How to Troubleshoot Query-Based Distribution Groups) and MS KB 839949 (Troubleshooting mail transport and distribution groups in Exchange 2000 Server and in Exchange Server 2003)

You need to give one user complete access to another’s mailbox.

You can assign delegate access to individual mailbox folders using the Outlook user interface; this is commonly done to give executive assistants access to their principals’ calendars without giving them access to messages contained in the Inbox. However, Outlook’s tool for setting mail folder permissions are best suited for providing delegate access, including the ability to send on the other user’s behalf. There are other scenarios in which you might want to give one user full access to another’s mailbox. For example, if you have a user who’s out on extended medical leave, another user might require access to that user’s Inbox and saved mail; another sadly common example is when an employee is being investigated for wrongdoing and the legal or HR departments request mailbox access. The technique described above gives one account or group full access to the target mailbox, meaning that users who have access can log on to the mailbox and use it as the original user could—no “Sent on behalf of” tags or other telltale signs that delegate access is in use. If you instead use ESM to grant these permissions to a mailbox store, the grantee will have that same level of access for all mailboxes in that database. Note that when you assign full mailbox access rights using the ADUC snap-in, the delegate doesn’t automatically get Send As permissions (see Recipe 5.21 to grant these).

Recipe 5.21 to grant Send As permissions, Recipe 5.15 to get the list of existing delegates on a mailbox, MS KB 295558 for using MAPI in Visual Basic to assign delegate permissions to individual folders, and MS KB 821900 for using OWA 2003 to get delegate access

You need to know which users have delegate access to a particular mailbox.

The list of delegates is stored as a single AD attribute on the user account: publicDelegates. When you ask Outlook to display the delegate list, it does so by reading that attribute and expanding it, then reading the security descriptors on folders in the mailbox. It also allows you to explicitly assign permissions. However, reading publicDelegates directly from the user object doesn’t tell you anything about what specific rights the defined delegates have, merely that they exist as delegates. At a minimum, they’ll have the ability to send on behalf of the original user.

Recipe 5.14 to grant full access to a mailbox

Your GAL currently displays user names with the first name first; you need to switch things so that the last name is displayed first.

By default, AD creates new user and contact objects with a canonical name (CN) based on the first and last names you supply, with the first name coming first. Thus, a user named “Tim O’Reilly” will end up as cn=Tim O'Reilly. This is normal and natural. However, some organizations insist on having the GAL sorted by last name. If you fall into that category, you have a couple of choices.

First, you could follow the procedures described in MS KB 250455 to change the way those CNs are created for new accounts, but you must be careful not to run afoul of the character restrictions described in MS KB 276266. In particular, creating CNs like cn=O'Reilly, Tim is a big no-no because of the embedded comma; you can use a backslash to escape embedded commas, but who wants to see strings like cn=O'Reilly, Tim? It also wouldn’t help you with existing accounts, because the GAL is actually built using the displayName property. When the object is created, its CN is copied to the displayName property unless you specify a separate display name at creation time. Thus, a better approach is to adjust the displayName property itself, since this has no impact on normal LDAP behavior. The previous script enumerates each user object in the selected container, skipping machine accounts or accounts (like Administrator) that don’t have a first name or last name set, then resetting the display name for accounts that have a first and last name defined. You’d need to re-run the script later to catch and fix any objects added after the first time you ran it; better yet, you could schedule it as a task to run periodically.

MS KB 300427 (How to Change Active Directory Display Names), MS KB 277717 (How to Change the Display Names of Active Directory Users with Active Directory Services Interface Script), MS KB 250455 (How to Change Display Names of Active Directory Users), and MS KB 276266 (Group Changes for Users with LDAP-Restricted Characters May Not Work)

You have mailboxes or mail-enabled groups that you don’t want to appear in the GAL. Alternatively, you have some hidden objects that you want to unhide.

Some objects need to be hidden from address lists so that users won’t send mail directly to them. For example, you might have resource mailboxes or mailboxes for people or projects that your general user population either doesn’t need to know about or shouldn’t be sending messages to. Making a mailbox invisible requires changing a single Boolean property, msExchHideFromAddressLists. There’s a separate property named showInAddressBook that contains the lists of address lists that the item should appear in. The RUS maintains showInAddressBook by updating the values in the list each time you modify an address list definition.

You can also use msExchHideFromAddressLists in LDAP queries. For example, you can easily query for all hidden mailboxes by using:

(&(&(objectclass=user)(objectCategory=Person))(msExchHideFromAddressLists=TRUE))

as the query string. However, you can’t hide an object from some address lists but not others: if you set msExchHideFromAddressLists on an object, it will be hidden from all address lists.

MS KB 253828 (How the Recipient Update Service Populates Address Lists)

You need to change the default reply-to SMTP address for a mailbox.

This recipe shows how to add a new reply-to address to a mailbox and set it as default. To set the default reply-to address across a larger number of objects, it is wiser to create a new recipient policy that is based on an LDAP query that applies to that group. Keep in mind that by default the highest-priority recipient policy that applies to the object will stamp the mailbox with an SMTP address (assuming that the policy contains an SMTP address specifier!). If you wish to manually set the default SMTP address, you should clear this property; otherwise, if the recipient policy and the addresses you’ve just entered are of the same type, the manually entered addresses will be overwritten the next time the RUS runs. The GUI has a checkbox labeled Automatically update email addresses based on recipient policy, which you will clear so that the information is not overwritten. When adding a new recipient policy programmatically, automatic updating is disabled by adding a value to the msExchPoliciesExcluded property. Changing this property to the value {26491CFC-9E50-4857-861B-0CB8DF22B5D7} achieves the same result as deselecting the automatic update checkbox in the GUI; if you want to reset it programmatically, you simply reset it to a null value by deleting that string.

Recipe 5.19 for creating recipient policies, which is the preferred way to update many addresses in the organization at once, and MS KB 318072 (Update E-Mail Addresses Based on Recipient Policy)

You want to create a recipient policy for your organization to control generation of email addresses for Exchange recipients, Mailbox Manager settings, or set Exchange to accept mail for a new SMTP domain.

Recipient policies are a useful way to apply address policies to groups of mail-enabled resources. Based upon an LDAP query, they allow you to specify a subgroup of objects to which they will apply. By default, Exchange will create SMTP addresses for all mail-enabled objects of the form [email protected]. Many organizations host more than one domain, or wish to have different address templates used for different departments, and recipient policies offer a simple method to achieve this.

Creating an email address within recipient policies is quite simple. The basic technique for SMTP proxy address templates has remained the same since the days of Exchange 5.5; you combine static parts of your email address template with variables that, when extracted from AD, will construct unique addresses for your Exchange recipients. The examples given assume that you want to create SMTP addresses, but the same technique works for generating X.400, cc:Mail, GroupWise, or Lotus Notes addresses. By default, a new recipient policy will be populated with a template of [email protected], which would simply take the Exchange alias property and prepend it to @domain.com.

Some of the useful variables available for constructing addresses include the following:

You can place a number in front of any of these strings to allow you to specify the first n characters of that variable; that is, %4s would give you the first four characters of the user’s surname, or %8d would give you the first eight characters of the user’s display name. The following are examples of how these variables work, given a user named John Q. Public, with a display name of “John Public”, and Exchange alias of jqpublic.

Besides allowing you to set recipient email addresses and mailbox manager policies, recipient policies are used by Exchange for two other scenarios. All domains that you wish to receive inbound mail for must exist in a recipient policy. The Exchange routing engine checks SMTP domain addresses in all recipient policies to discern which domains are local to the Exchange organization. Exchange also uses the default SMTP domain of the default recipient policy to determine the domain name used in creating the Exchange virtual directory and the Outlook Web Access virtual directory. For this reason, it is usually preferable not to modify the default recipient policy, but to add new recipient policies that will take precedence for creating addresses. (If you’re specifying a custom policy, be sure that the values you are specifying in the policy exist. If they don’t, the RUS will generate a wide variety of ugly email addresses, and that will cause problems.)

Recipe 5.26 for configuring Mailbox Manager settings, MS KB 319201 (How to Use Recipient Policies to Control E-mail Addresses), MS KB 822447 (How to Modify an SMTP E-Mail Address by Using Recipient Policies), MS KB 285136 (How to Customize the SMTP E-mail Address Generators Through Recipient Policies), and MSDN: Creating a Query Filter (http://msdn.microsoft.com/library/en-us/ad/ad/creating_a_query_filter.asp)

You need to control which accounts can send email messages to a distribution group.

This recipe provides a measure of control over traffic sent to groups within your organization, whether it originates within the organization or comes from without. There are two common scenarios where this is desirable:

Both distribution and security groups are managed in the same fashion, although security groups must be mail-enabled before the relevant attributes are available. When creating sender inclusions or exclusions in forests with multiple domains, be sure to consider the group’s scope and ensure that the groups added remain within the same scope boundaries whenever possible.

Note that the sender addresses specified must be associated with objects within Active Directory. You cannot use this as a general per-recipient filtering mechanism for external senders unless you are willing to create Active Directory contact objects for each external address.

Also note that Exchange 2000 (and by default Exchange Server 2003) trusts the value of the sender as provided in the header of the message, so this restriction can be easily defeated by forgery. Exchange Server 2003 provides the option to enforce authentication; however the message enters the organization, be it by MAPI, OWA, or SMTP, Exchange will ensure that the sender matches the provided authentication credentials when this option is enabled, preventing header spoofing. Since contact objects cannot be authenticated, they cannot be used to include foreign addresses when authentication is desired.

MSDN CDOEXM documentation for RestrictedAddressList property

You have a user who needs to be able to send messages as another user.

We tried to create scripts for both this recipe and Recipe 5.22 but neither one was really scriptable, because there are actually two parts to the delegation of these rights—delegating access to the actual attribute and creating the necessary ACLs. This made scripting a solution impractical.

Send-as permissions provide the ability for one user to send mail that appears to be from another user. This kind of permission is often granted in cases where a user is unable to access their mailbox for a period of time (due to vacation or an extended leave of absence), but it must appear that they are available, so someone else responds to new messages in their place.

Recipe 5.22 for assigning “send on behalf of” permission, and MS KB 327000 (How to Grant “Send as” and “Send on behalf” permissions in Exchange 2000 Server)

You have a user who needs to be able to send a message on behalf of another user.

When “send on behalf of” permissions are granted to a user, the user can send email messages from the account it was granted permissions to. The message will show the recipient that the message was sent on behalf of the modified account. Often, an executive may request that this type of permission be given to a trusted assistant so that the assistant can respond to general inquiries. For that reason, Outlook allows you to set this permission directly from the Delegates tab.

Recipe 5.21 for assigning “send as” permission, and MS KB 327000 (How to Grant “Send as” and “Send on behalf” permissions in Exchange 2000 Server)

You have a mailbox and need to allow either an additional user or a group of users to access information within it. This mailbox could either be a normal user mailbox or a resource mailbox, used to book a resource such as a conference room, audio/video equipment, or a company car.

The link between an AD user object and the actual mailbox in the Exchange message store is contained in two places: the security descriptor property on the actual mailbox database and the msExchMailboxSecurityDescriptor property in AD. The msExchMailboxSecurityDescriptor property is added to the AD user object by the Exchange schema updates; it holds a partial copy of the security descriptor on the actual mailbox. Modifying the AD property directly will not change the descriptor on the mailbox; changes to the mailbox security descriptor are mirrored back to the msExchMailboxSecurityDescriptor property. Because of this, granting access to other users programmatically can only be done through CDOEXM.

MS KB 310866 describes the steps necessary to modify a mailbox security descriptor using CDOEXM; in order to use it, the server must be at least Exchange 2000 Service Pack 2 or later. In addition, the relevant information store must be started and the mailbox store mounted. CDOEXM provides the IExchangeMailbox interface, which in turn exposes the MailboxRights property. This property then allows you to manage the security descriptor using the standard IADsSecurityDescriptor ADSI interface.

This technique requires a thorough understanding of security descriptors, access control lists (ACLs), and access control entries (ACEs); manipulating the IADsSecurityDescriptor interface uses the same principles underlying the NTFS file system permissions. This is a topic of sufficient complexity that it is outside the scope of a recipe.

There are two caveats to remember:

Many experienced Exchange 5.5 administrators find the relationship between user accounts and mailboxes to be one of the biggest differences in Exchange 2000 and Exchange Server 2003, as it affects the way that resource accounts are handled.

Under Exchange 5.5, user accounts (the Windows NT domain SAM) and Exchange information (ExchangeDS) were two separate directories. Under this model, it was easy for the Exchange directory to store the proper associations to relate multiple mailboxes back to one Windows NT domain user account. The user to mailbox relationship was one to many; any need for a many-to-one relationship was taken care of through the appropriate mailbox ACLs.

With the advent of AD, this association changed. The attributes that keep track of the user/mailbox association are now part of the user object, turning it into a one-to-one relationship. Resource objects in the AD-aware Exchange world have their own corresponding account object, usually disabled; management permissions are then granted to the appropriate user accounts via the security descriptor. Since the actual mailbox database (and associated security descriptor) is not created until the message store must actually deliver a message or enumerate the contents of the database, the initial permissions are not granted until the mailbox is initialized. This complicates scripted provisioning of accounts that must be accessible by multiple users.

Recipes Recipe 5.1 and Recipe 5.2 for creating mailbox-enabled accounts, MS KB 275636 (Creating Exchange Mailbox-Enabled and Mail-Enabled Objects in Active Directory), MS KB 327079 (How to programmatically create a mailbox for an existing user in the Active Directory by using CDOEXM), MS KB 304935 (How to set Exchange 2000 mailbox rights at the time of mailbox creation), MS KB 310866 (How to Set Exchange 2000 Mailbox Rights on a Mailbox That Exists in the Information Store), and Chapter 23 (“Permissions and Auditing”) of Active Directory, Second Edition (O’Reilly)

You want to control the number of recipients to which a single message can be sent.

Limiting the number of recipients that can be included in one message can help prevent the spread of viruses by SMTP. We chose to set the recipient limit to 100 per message, but we’re not working in an organization where messages are sent to hundreds of recipients at once. While limiting the number of recipients a message can be sent to is a good thing, you should ensure you’re not preventing your users from doing business efficiently.

Recipe 4.10 for more on setting default send and receive limits; MS KB 821881 (How to Modify Global Settings in Exchange System Manager) and MS KB 319356 (How to prevent unsolicited commercial email in Exchange 2000 Server)

You want to control the offline address lists (OALs) on your server.

Before we start in on the details of how offline address lists work, let’s straighten out a terminology wrinkle. The Outlook team calls these objects “offline address books,” or OABs. The Exchange team sometimes calls the same things OALs, but sometimes they call them OABs. Don’t let this confuse you too much.

OALs are designed as a convenience for clients—specifically, clients that may not be connected to the server at a given time. The idea behind the OAL is that it should serve as a locally available replica of selected address lists that can be used for address resolution on a machine that cannot connect to an Exchange server at the time. If you think of the OAL as merely an offline version of the GAL (or of selected GALs, since you can choose which specific address lists are included in a particular OAL), you’ve got the idea, although the OAL doesn’t include all of the information found in the GAL (custom properties and group membership data isn’t included). Outlook uses its local copy of the OAL to handle both GAL browsing and name resolution when offline.

The OAL itself is a set of .OAB files that are stored in a system public folder, the name of which varies according to the version of Exchange you’re using (for Exchange Server 2003, it’s OAB Version 3a); that’s why, when you create a new OAL, you have to wait for store maintenance to run—a new instance of the system public folder has to be created. Each day, the Exchange system attendant kicks off a process known as OABGen; it creates an incremental file (changes.oab) that contains all the changes made in the preceding 24 hours. This daily incremental update is posted to the folder so that clients can download it; by default, the folder’s aging limit is set to 30 days, so clients can pull up to 30 days of deltas before they have to download a complete OAL. Speaking of complete OALs: after the daily differential object is created, OABGen refreshes the full copy of the OAL and stores it as well.

There are several circumstances in which Outlook will download a full OAL:

Recipe 5.12 for creating address lists, MS KB 841273 (Administering the Offline Address Book in Outlook 2003), and MS KB 811870 (XADM: Troubleshoot offline address book download issues)

You want to use the Mailbox Manager feature of Exchange Server to clean up certain items within your users’ mailboxes.

Mailbox Manager examines three MAPI properties of an object when determining whether to process an item according to the policies in place: PR_MESSAGE_DELIVERY_TIME, PR_CLIENT_SUBMIT_TIME, and PR_LAST_MODIFICATION_TIME. If all three of these properties do not meet the criteria defined within Mailbox Manager, then the object will not be removed from the mailbox. Since the PR_LAST_MODIFICATION_TIME property is reset each time a message is opened, items that you might have expected to be removed from the mailbox may still be in place. This is to ensure that objects that are currently in use within the mailbox remain active and usable.

For objects such as IPM.Appointment, IPM.Task, and IPM.Journal, additional MAPI properties are checked to ensure that active and recurring appointments, active tasks, and active journaling activities are retained. You may not want mailbox manager to take action on a specific message class. In order to leave all appointment items, for instance, you can select Exclude Specific Message Classes and click Customize. You would then type IPM.Appointment in the Exclude Message Classes area and click Add.

Mailbox Manager also checks for message sizes. By default, it will not remove items that are less than 1 MB. If the message size is less than 1 MB (or whatever size you modify your policy to use), it will not be deleted from the mailbox even if it is older than the age limit defined in your policy (which is 30 days in the default settings).

It is always best to initially run Mailbox Manager in report mode to determine what the results of the scan will be.

It’s possible to create a script to duplicate the functionality of Mailbox Manager, but it seems impractical to do so, given the inherent flexibility of Mailbox Manager itself.

MS KB 302804 (Message Age Limit Properties Used by Mailbox Manager) and MS KB 319188 (How to use recipient policies to control mailboxes in Exchange 2000 and Exchange 2003)

You want an application that easily allows you to modify user accounts attributes in bulk.

The ADModify tool, written by Marc Nivens and Dan Winter of the 24x7 Enterprise Messaging Support team at Microsoft Product Support Services, provides a powerful GUI utility for bulk modification of user accounts. It comes in two flavors, Win32 (Version 1.6) and .NET (Version 2.x) and is available for download from the Microsoft Download Center or from its project home at GotDotNet (http://workspaces.gotdotnet.com/ADModify).

ADModify 1.6 generally provides less functionality than ADModify.NET does, but it does provide the following features that have been removed from Version 2:

If you don’t need any of these features, are not yet running Windows Server 2003, or prefer not to deploy the .NET Framework 1.1 on your management workstation, use ADModify 1.6. It is used in much the same fashion as Version 2 and is documented in the included help file. Otherwise, look at both flavors and use the one that gives you the mix of functionality you need; on Windows Server 2003, this will generally be Version 2.

ADModify.NET provides the ability to export mailbox rights to XML and reimport them, as well as an XML log that provides undo capability. It also adds support for the remote control and Terminal Services fields in Windows Server 2003.

You need to change properties on user accounts.

Setting attributes of user objects is extremely straightforward using the ADUC MMC. However, in the interest of usability, Microsoft chose to expose the most common subset of attributes to the MMC interface. For example, it’s especially confusing that the Exchange Global Address List displays an “assistant” field, but the field does not exist in the GUI. The best way to change these unexposed attributes is through scripting. Our “assistant” example is kept in the msExchAssistantName field, and when updated through scripting, will appear in the Exchange Global Address List. Because some attributes are missing from ADUC, you may want to use either ADSIEdit or LDP to view attributes, even though these tools are somewhat more difficult to use.

You can also get the acctinfo.dll extension from the Windows Server 2003 Resource Kit; this DLL, when registered, will add a new Additional Account Info tab to the user properties dialog; this tab shows logon time, password date and policy, and lockout information for the selected account.

This type of script is also useful for stepping through a group of objects and updating a particular attribute, such as changing a division’s address or phone number.

Recipe 5.1 for creating mail-enabled user accounts, and Recipe 5.29 for retrieving properties on user accounts; the table at http://www.kouti.com/tables/userattributes.htm for mapping AD attributes to what you see in ADUC

You need to retrieve a list of properties on user accounts.

ldifde is a useful tool to quickly export a list of object attributes from a command line, but the output is not as clean as if you write a script. By scripting your solution, you can limit your output to the subset of information you’re looking for, or format the output in a more readable manner.

MS KB 237677 (Using LDIFDE to Import and Export Directory Objects to Active Directory) and MSDN: Active Directory Schema