I recently needed to create few thousand mail-enabled users in Active Directory for a project in which the original plan was to use a third-party mail migration product to later mailbox-enable and then migrate data in from another directory. But as plans changed I found that we were going to need to manually convert a good number of these objects into mailbox-enabled accounts. At the time I thought, "No problem, I’ll just filter out the specific users and select the Exchange Task to Create a New Mailbox. Well, I was surprised to notice that is not an option in the Exchange System Manager for Exchange 2003; I guess I’ve never needed to do that before. Some searching through TechNet articles and discussion forums led me to believe that it was not possible to do this, and the recommended solution was to execute the Exchange task to remove the email addresses and then run the task to create a new mailbox. I didn’t like that idea very much, as not only is that a pain to do for hundreds of users, I’d have to export and re-import the current attributes as some changes had been made since originally creating those user accounts. For example, I had added a middle initial to all the accounts via an LDIF import after they were already mail-enabled, so that would cause the RUS to stamp different X400 address if it was run again on newly enabled objects. Because I already had all the attributes the way we needed them, I figured there had to be a way to retain the existing account state and force a conversion into mailbox-enabled status.
There are already some of good articles out there outlining the differences between a mail-enabled and a mailbox-enabled object in AD, like this one from MSExchange.org, but I was looking for even more detail regarding the stamping of attributes and exactly what Exchange does to determine the difference, so I started working backwards in my lab and it turned out to actually be pretty simple. If we modify just the right attributes, then the RUS will do the rest of the work for us.
The Process
Although these steps are unnecessary for the solution, I’m going to start out with reviewing how to increase diagnostic logging so that we can watch Application events and follow along with the RUS while it locates and stamps the attributes we desire.
First, we need to find out which Exchange Server is currently running the RUS for the specific domain in which we will be working. Also make note of the associated domain controller so that we can look for the changes immediately and not have to wait on, or force any AD replication. In this lab there is only a single domain controller (LAB2DC) and a single Exchange 2003 server (LAB2EXCH).
Then on the Exchange server (LAB2EXCH) we want to turn up diagnostic logging for a couple categories:
| Service | Category | Logging Level |
| MSExchangeAL | Address List Synchronization | Maximum |
| MSExchangeSA | Proxy Generation | Maximum |
Create a new user account in Active Directory, but do not create an Exchange mailbox. After the wizard is completed select the new object and choose Exchange Tasks and select Establish an E-mail Address. Add a new SMTP address for a foreign domain for this user. After a few minutes have passed, open the Application Event Log on the same Exchange server and look for event ID 3006 to appear, which shows what proxy addresses were added to the object:
Event Type: Information
Event Source: MSExchangeSA
Event Category: Proxy Generation
Event ID: 3006Description:
Policy provider instance processing recipient.
Recipient DN: CN=Mucci, Tony,OU=Users,OU=Contoso Corp,DC=contoso,DC=com
Current recipient proxies:
Applicable policies:
CN=Default Policy,CN=Recipient Policies,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com
Chosen policy: CN=Default Policy,CN=Recipient Policies,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com
Proxies of chosen policy:
X400:c=US;a= ;p=Contoso;o=Exchange;
SMTP:@contoso.com
Proxies in change list:
Proxies to generate:
X400:c=US;a= ;p=Contoso;o=Exchange;
SMTP:@contoso.com
Conflicts during generation:
Proxies generated:
X400:c=US;a= ;p=Contoso;o=Exchange;s=Mucci;g=Tony;
SMTP:tony@nwtraders.com
Proxies written to recipient:
X400:c=US;a= ;p=Contoso;o=Exchange;s=Mucci;g=Tony;
SMTP:tony@nwtraders.com
The Address List Synchronization events which immediately follow that event detail the steps that the RUS is taking to identify the type of objects (Mail-Enabled or Mailbox-Enabled) so that it properly stamps the required missing attributes. Take a minute to read through each of those events.
In this case the object was determined to be Mail-Enabled as denoted by event 8130:
Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8130Description:
‘CN=Mail Enable Recipient,CN=System Policies,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com’ added to ‘CN=Mucci, Tony,OU=Users,OU=Contoso Corp,DC=contoso,DC=com’. DC=contoso,DC=com
As documented in Microsoft TechNet article 253838, if the Recipient Update Service determines that an object contains a populated mailNickName attribute, then the RUS checks additional attributes to determine if the object is mail-enabled or mailbox-enabled. The trigger is if any of these three attributes are populated (msExchHomeServerName, homeMDB, or homeMTA) then the object is treated as mailbox-enabled, but if they are all blank (but mailNickName is still populated) then it is mail-enabled, and the RUS will attempt to fill in all the other attributes associated with the chosen type.
The Solution
Following that logic, and some trial-and-error, I determined that I only needed to make two simple changes to a mail-enabled account in order to allow the Recipient Update Service to then see the modified object as mailbox-enabled: add a value to the homeMDB attribute, and then erase the value of the targetAddress attribute.
Since the homeMDB attribute is the most specific of the three requirements for a mailbox-enabled account, the RUS will automatically populate the other two with the correct values, as well as adding the msExchMailboxGUID and all of the other required attributes. Although it is technically possible to set a value for the targetAddress attribute on a mailbox-enabled account later (for contact-less forwarding), if that attribute is not null at the time the RUS checks it then the object is still treated as mail-enabled.
So let’s use ADSIedit to modify those two attributes. First locate an existing mailbox-enabled user account in the same mailbox store as we want this user to be stored in, and copy the homeMDB attribute value:
CN=Mailbox Store (LAB2EXCH),CN=First Storage Group,CN=InformationStore,CN=LAB2EXCH,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com
Paste the string into the homeMDB attribute on our new user account, and then clear the targetAddress attribute value. After a few minutes check the Application log again for the associated event ID 3006, and then find the next occurrence of ID 8130:
Event Type: Information
Event Source: MSExchangeAL
Event Category: Address List Synchronization
Event ID: 8130Description:
‘CN=Mailbox Enable User,CN=System Policies,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com’ added to ‘CN=Mucci, Tony,OU=Users,OU=Contoso Corp,DC=contoso,DC=com’. DC=contoso,DC=com
We can see that the RUS has now identified our user as mailbox-enabled and if we look at the account’s attributes we’ll find all of the other required attributes are populated:
Scripting Bulk Changes
Since we now know what to change, it’s simple to create an LDIF import file to make these changes to many accounts in bulk. This also lets us decide which mailbox store each account should be assigned to, so using a CSVDE export and Excel it would be pretty simple to create a working spreadsheet to list our object’s current DN and desired homeMDB values. Using my colleague Derek’s blog on how to convert CSV files to LDIF format we should end up with a single import file that would convert any number of mail-enabled users into mailbox-enabled.
The LDIFDE import file would look something like this:
dn: CN=Mucci, Tony,OU=Users,OU=Contoso Corp,DC=contoso,DC=com
changetype: modify
replace: homeMTA
homeMTA: CN=Mailbox Store (LAB2EXCH),CN=First Storage Group,CN=InformationStore,CN=LAB2EXCH,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com
–
delete: targetAddress
–
One final note is that since a mail-enabled object should have a foreign SMTP address while a mailbox-enabled object would typically require an Exchange-owned SMTP address, we’d probably want to stamp a new primary SMTP address depending on the specific scenario. This can easily be accomplished via another LDIF import to modify the proxyAddresses and mail attributes, or using a tool like ADModify.NET.
Does this work in Exchange 2007?
In a native Exchange 2007 organization the RUS has been eliminated, so I started to poke around in my 2007 lab to see how this process might differ, or if it is even at all possible. The biggest difference is how Exchange 2003 determines an objects ‘mail type’ by looking at a range of attributes and their values (or if they even have any), while Exchange 2007 actually has some new attributes which are used to define the objects type. More can be read on these new attributes in this TechNet blog by BenW. I hacked around with a similar approach, but Exchange would continually bark at me about not liking the object type when attempted to mailbox-enable via a cmdlet or the console.
I’m going to keep exploring and researching this to see if it’s even possible to perform the same ‘trick’ in Exchange 2007, or if it ends up being more work than just simply exporting the attributes, mail-disabling the objects, and then re-importing the desired attributes back in. But that’s for another day…
