A Collection of Random Thoughts : exchange 2007

Move Mailbox from a CSV Import file

benw — Mon, 02 Jun 2008 16:53:00 GMT

A while back, I had promised to write another post detailing how to use Import-CSV and then run Move-Mailbox against the users in that CSV file. Well, quite a bit of time has passed since then, and getting this figured out proved a little more difficult than I thought it would be. I finally got it worked out, though.

Here are the details of the setup. You have users that you want to split up between several target databases. In my CSV file, I have 3 columns, as outlined below (sample file)

Name, Username, TargetDB

A user, auser, "Server\Storage Group\Mailbox Database"
B user, buser, "Server\Storage Group\Second Database"
C user, cuser, "Server\Storage Group\Third Database"

The TargetDB column means that you will have to do a little bit of legwork in determining where you want to put the users, and populate that column, but it shouldn't take too much effort.

Next, we'll start writing the script itself.

##################################################################
#                                                                                                                                                                #
#                                   Script to move mailboxes multithreaded from CSV import                                    #
#                                                                                                                                                                #
##################################################################

write-output "Moving mailboxes from CSV import"

#First we are going to import from your csv file
#where the CSV file contains 3 columns. Name, Username and TargetDB

$users = import-csv c:\userimport.csv

#Now we are going to filter the list down and get a
#list of just the users on the first database

$db1 = $users| where {$_.targetdb -like "*mailbox database"} |
foreach { $_.name } | get-mailbox

#getting a list of the users on the second target database

$db2 = $users | where {$_.targetdb -like "*Second Database"} |
foreach { $_.name } | get-mailbox

#Repeat the above line for each additional database that you have.

#Now we move each group of users to their respective databases

$db1 | move-mailbox -targetdatabase "E2K7-2\First Storage Group\Mailbox Database" -confirm:$false -maxthreads:10

$db2 | move-mailbox -targetdatabase "E2K7-2\Second Storage Group\Second Database" -confirm:$false -maxthreads:10

#Repeat the above line for each additional mailbox database that you have

write-output "Completed Mailbox moves from CSV file"

I first tried to get this working with just one command, but kept failing on the target database portion. When I was creating my arrays, I had a separate array for the target database, but the problem I kept running into was that the value for the array was only being recognized as the last value in the CSV file. So if Third Database was the last value for TargetDB, that was where all users ended up being moved. After multiple failed attempts to correct that, I decided that the best way to approach this would be to filter the CSV and move all users with a common target database, then move on to the next group. It still achieves the desired result of being able to take advantage of multi-threading, and it also does everything in one shot.

If you have any suggestions for improvement, please feel free to pass on your suggestions.

Exchange 2007 Advanced Move Mailbox Powershell commands

benw — Wed, 29 Aug 2007 01:54:00 GMT

By now, you should be familiar with the day to day Powershell commands, so here is one that uses the foreach command. Foreach is used to loop through a given set of items (an array), and perform an action on each one.

As an example, let's say that you want to perform a Cross-Org mailbox move, but you want to use Get-Mailbox first to get a list of mailboxes. Just using the standard filtering, you have limited options. You can filter 1. By a specific Organizational Unit; 2. By a specific Exchange server; 3. Don't filter at all - return all users; 4. Specify an identity to only return a single mailbox. Now, that's nice that these filters exist, and they are pretty easy to use. You can reference the help for Get-Mailbox for more details (get-help get-mailbox -full). However, what if you only want to move a handful of mailboxes? You need to do some more work.

First, you'll need to define an array by specifying a variable. You also need to know the alias of the users that you are wanting to move.

$mboxes = "user1","user2","user3","user4"

You have now successfully created an array. Now, you can perform an action on that array using the Foreach command. The basic usage of the foreach command is as follows.

foreach ($<item> in $<collection>) {<command_block>}

One thing to remember is that $<item> also references a variable, but it is dynamically created, and you can call it whatever you want. In our case, the resulting command would look something like this. I've chosen to use $mb for the$<item> variable. We'll start out by simply getting the mailbox information for those users to make sure it works, then we'll move on to the more complex move portion.

Note that unless your current account has rights in both forests, you will still need to pass the -credential string, and you will need to define a variable for the credentials using get-credential. To make things easier, I always use $s for the Source Forest credentials, and $t for the Target Forest credentials.

foreach ($mb in $mboxes) {get-mailbox $mb -DomainController <source DC FQDN> -Credential $s}

You should now have a list on your screen that looks something like this.

Name	Alias	ServerName	ProhibitSendQuota
User 1	user1	2k3servername	unlimited
User 2	user2	2k3servername	unlimited
User 3	user3	2k3servername	unlimited
User 4	user4	2k3servername	unlimited

Now that we are sure that the results are being returned properly, let's include the move-mailbox command. First, I'll show you what doesn't work.

foreach ($mb in $mboxes) {get-mailbox $mb -DomainController <source DC FQDN> -Credential $s} | move-mailbox -TargetDatabase "Server\Storage Group\Database" -GlobalCatalog <target GC FQDN> -SourceForestCredential $s -SourceForestGlobalCatalog <source GC FQDN> -TargetForestCredential $t -AllowMerge -SourceMailboxCleanupOptions deletesourcemailbox

You might think this would work, because previous experience with Powershell has taught you about Pipelining, but it will return an error indicating you have an empty pipe element, which is not permitted. In order to get this to work, you actually have to include the Pipeline within the command block. I'm going to move the end brace } to the end of the statement.

foreach ($mb in $mboxes) {get-mailbox $mb -DomainController <source DC FQDN> -Credential $s | move-mailbox -TargetDatabase "Server\Storage Group\Database" -GlobalCatalog <target GC FQDN> -SourceForestCredential $s -SourceForestGlobalCatalog <source GC FQDN> -TargetForestCredential $t -AllowMerge -SourceMailboxCleanupOptions deletesourcemailbox}

The above command will loop through each user in your array, and perform the move-mailbox command. You should note that the command I used assumes that the user account has already been migrated to the target domain by using a migration tool such as the Active Directory Migration Tool, and that you have migrated SID History (The SID is used to match the source mailbox to a target account). The other option would be to include the -NTAccountOU parameter, and have Exchange 2007 create a disabled user account, but this is much less desirable, as it ends up creating a linked mailbox instead of a normal user account.

[update]
Thanks to comments from some of you, who pointed out that using foreach, while it *does* work as it is shown above, it isn't optimal because it passes the results serially. In other words, it means that it will pass the first result to move-mailbox, then it will wait to pass the next result until the first loop completes. This will result in move-mailbox being called 4 times (for the example above), more if you have a larger list. It also doesn't take advantage of the multi-threading capability of move-mailbox.

In order to make it work properly, you can either simply specify the array, or you can pass the array into the foreach loop (instead of specifying each item in the array). Examples below.

$mboxes | get-mailbox $mb -DomainController <source DC FQDN> -Credential $s | move-mailbox -TargetDatabase "Server\Storage Group\Database" -GlobalCatalog <target GC FQDN> -SourceForestCredential $s -SourceForestGlobalCatalog <source GC FQDN> -TargetForestCredential $t -AllowMerge -SourceMailboxCleanupOptions deletesourcemailbox

foreach { $mboxes } | get-mailbox $mb -DomainController <source DC FQDN> -Credential $s | move-mailbox -TargetDatabase "Server\Storage Group\Database" -GlobalCatalog <target GC FQDN> -SourceForestCredential $s -SourceForestGlobalCatalog <source GC FQDN> -TargetForestCredential $t -AllowMerge -SourceMailboxCleanupOptions deletesourcemailbox

What I'm learning here is that there is a LOT to learn about Powershell!!!

Thanks to Devin Ganger for pointing out the limitation, and thanks to Evan Dodds for helping with the correct usage. I'll be posting a followup to this with some more information on moving mailboxes using a csv file, and using other filters to get the list you want.

Exchange 2007 Cluster Setup - Did it complete?

benw — Tue, 07 Aug 2007 06:30:00 GMT

As you no doubt know by now, Exchange 2007 introduces different types of clustering. It still retains the traditional Single Copy cluster where all data is stored in a central location (i.e. SAN). It also introduces the concept of Cluster Continuous Replication, or CCR, where centralized storage is not required, rather each server contains a separate copy of the data. This is achieved by an initial "seeding", and is then maintained by replication of log files. Service Pack 1 for Exchange 2007 includes ~~yet a third type of cluster~~ a new technology for managing server failures, called Standby Continuous Replication, or SCR, but we'll leave that for another post.

[edit] as was pointed out to me, SCR isn't actually a clustered solution, as it does not use Windows clustering. I've thus modified the original post to reflect that. However, it can be used as the target for an Exchange 2007 cluster. More details to come when I post about SCR.

For today, I've installed a new CCR cluster, but I didn't allow it to complete. Let's have a look at the setup log. This is located in the c:\ExchangeSetupLogs directory. The one that contains the most information is ExchangeSetup.log. Since this log file contains a lot of information, I'll only post part of it.

[8/3/2007 4:46:12 PM] [0] Starting Microsoft Exchange 2007 Setup
[8/3/2007 4:46:12 PM] [0] **********************************************
[8/3/2007 4:46:12 PM] [0] Setup version: 8.0.685.24.
[8/3/2007 4:46:12 PM] [0] Logged on user: E12CCR\Administrator.
[8/3/2007 4:46:12 PM] [0] Command Line Parameter Name='mode', Value='Install'.
[8/3/2007 4:46:12 PM] [0] Command Line Parameter Name='sourcedir', Value='D:\i386'.
[8/3/2007 4:46:12 PM] [0] Command Line Parameter Name='fromsetup', Value=''.
[8/3/2007 4:46:12 PM] [0] ExSetupUI was started with the following command: '-mode:install -sourcedir:D:\i386 /FromSetup'.
[8/3/2007 4:46:17 PM] [0] Setup is choosing the domain controller to use
[8/3/2007 4:46:18 PM] [0] Setup is choosing a local domain controller...
[8/3/2007 4:46:20 PM] [0] Setup has chosen the local domain controller e12dc.E12CCR.com for initial queries
[8/3/2007 4:46:21 PM] [0] PrepareAD has been run, and has replicated to this domain controller; so setup will use e12dc.E12CCR.com
[8/3/2007 4:46:21 PM] [0] Setup is choosing a global catalog...
[8/3/2007 4:46:21 PM] [0] Setup has chosen the global catalog server e12dc.E12CCR.com.
[8/3/2007 4:46:21 PM] [0] Setup will use the domain controller 'e12dc.E12CCR.com'.
[8/3/2007 4:46:21 PM] [0] Setup will use the global catalog 'e12dc.E12CCR.com'.
[8/3/2007 4:46:21 PM] [0] Exchange configuration container for the organization is 'CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12CCR,DC=com'.
[8/3/2007 4:46:21 PM] [0] Exchange organization container for the organization is 'CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12CCR,DC=com'.
[8/3/2007 4:46:21 PM] [0] This machine is part of a Windows failover cluster.
[8/3/2007 4:46:21 PM] [0] This server is not an active node for any Clustered Mailbox servers.
[8/3/2007 4:46:21 PM] [0] Setup will search for an Exchange Server object for the local machine with name 'E12CCR2-N1'.
[8/3/2007 4:46:21 PM] [0] No Exchange Server with identity 'E12CCR2-N1' was found.
[8/3/2007 4:46:36 PM] [0] The following roles are unpacked:
[8/3/2007 4:46:36 PM] [0] The following roles are installed:
[8/3/2007 4:46:36 PM] [0] The local server does not have any Exchange files installed.
[8/3/2007 4:46:36 PM] [0] Setup will use the path 'D:\i386' for installing Exchange.
[8/3/2007 4:46:36 PM] [0] The server is cluster type: 'None'.
[8/3/2007 4:46:36 PM] [0] The requested cluster type: 'None'.
[8/3/2007 4:46:36 PM] [0] The installation mode is set to: 'Install'.
[8/3/2007 4:46:36 PM] [0] An Exchange organization with name 'First Organization' was found in this forest.
[8/3/2007 4:46:36 PM] [0] Active Directory Initialization status : 'True'.
[8/3/2007 4:46:36 PM] [0] Schema Update Required Status : 'False'.
[8/3/2007 4:46:36 PM] [0] Organization Configuration Update Required Status : 'False'.
[8/3/2007 4:46:36 PM] [0] Domain Configuration Update Required Status : 'False'.
[8/3/2007 4:46:37 PM] [0] Applying default role selection state

This simply shows an overview of the setup choices that have been made.

[8/3/2007 4:52:39 PM] [1] Setup launched task 'test-setuphealth -DomainController 'e12dc.E12CCR.com' -DownloadConfigurationUpdates $false -ExchangeVersion '8.0.685.24' -Roles 'ClusterMailbox' -ScanType 'PrecheckInstall' -SetupRoles 'AdminTools','Mailbox','ClusterMailbox' -CmsName 'CCR-EVS2' -CmsDataPath 'E:\Exchsrvr\MDBData' -CmsIPAddress '10.10.201.230' -CmsSharedStorage $false -CreatePublicDB $false'

This is showing the pre-requisite check tests that are being performed, and shows that the setup roles that have been selected are AdminTools, Mailbox, ClusterMailbox. Most of the rest of the log file just shows the progress of each role, so I won't bore you with that. Let's get on to the interesting part. Once the mailbox role finishes installing, setup runs the new-ClusteredMailboxServer to create the actual cluster. One nice thing is that you don't have to worry about creating the Exchange group in Cluster Admin as you had to do with Exchange 2003. Setup now creates it for you automatically. Ok - here is the failure. Note the section in Bold.

[8/6/2007 5:36:17 PM] [1] Processing component 'Mailbox System Attendant Dependent Tasks' (Configuring tasks dependent on System Attendant service).
[8/6/2007 5:36:17 PM] [1] Executing 'start-ClusteredMailboxServer -Identity:$RoleName', handleError = False
[8/6/2007 5:36:17 PM] [2] Launching sub-task '$error.Clear(); start-ClusteredMailboxServer -Identity:$RoleName'.
[8/6/2007 5:36:18 PM] [2] Beginning processing.
[8/6/2007 5:36:18 PM] [2] Administrator Active Directory session settings are: View Entire Forest: 'True', Configuration Domain Controller: 'e12dc.E12CCR.com', Preferred Global Catalog: 'e12dc.E12CCR.com', Preferred Domain Controllers: '{ e12dc.E12CCR.com }'
[8/6/2007 5:36:18 PM] [2] Searching objects "ccr-evs2" of type "Server" under the root "$null".
[8/6/2007 5:36:18 PM] [2] Previous operation run on domain controller 'e12dc.E12CCR.com'.
[8/6/2007 5:36:18 PM] [2] Start-ClusteredMailboxServer is trying to start clustered mailbox server ccr-evs2.
[8/6/2007 5:37:05 PM] [2] Start-ClusteredMailboxServer finished starting (bringing online) clustered mailbox server ccr-evs2.
[8/6/2007 5:37:05 PM] [2] [ERROR] Unexpected Error
[8/6/2007 5:37:05 PM] [2] [ERROR] Clustered mailbox server 'ccr-evs2' is not in a started (online) state (Failed). The cluster resource 'First Storage Group/Mailbox Database (ccr-evs2)' is in state (Failed).
[8/6/2007 5:37:05 PM] [2] Ending processing.
[8/6/2007 5:37:05 PM] [1] The following 1 error(s) occurred during task execution:
[8/6/2007 5:37:05 PM] [1] 0. ErrorRecord: Clustered mailbox server 'ccr-evs2' is not in a started (online) state (Failed). The cluster resource 'First Storage Group/Mailbox Database (ccr-evs2)' is in state (Failed).
[8/6/2007 5:37:05 PM] [1] 0. ErrorRecord: Microsoft.Exchange.Management.Tasks.NewCmsNotOnline: Clustered mailbox server 'ccr-evs2' is not in a started (online) state (Failed). The cluster resource 'First Storage Group/Mailbox Database (ccr-evs2)' is in state (Failed).
[8/6/2007 5:37:05 PM] [1] [ERROR] Clustered mailbox server 'ccr-evs2' is not in a started (online) state (Failed). The cluster resource 'First Storage Group/Mailbox Database (ccr-evs2)' is in state (Failed).
[8/6/2007 5:37:05 PM] [1] Setup is halting task execution because of one or more errors in a critical task.
[8/6/2007 5:37:05 PM] [1] Finished executing component tasks.
[8/6/2007 5:37:05 PM] [1] Ending processing.
[8/6/2007 5:40:48 PM] [0] End of Setup

The Setup UI will now show that setup has completed with an error. Ok, so let's re-run setup to allow it to complete. What's that? The Setup UI only allows you to Add or Remove roles. Oh yeah - since this was set up as a Cluster, you can't have any other roles on it, and you can't de-select the Active Cluster role. Now at this point, I can actually go in to Cluster Admin, and verify that all the resources are online. In the above case where my First Storage Group/Mailbox Databases (ccr-evs2) was in a failed state, I simply brought it online, and it came online just fine. Since all the resources are online, you might think that everything is hunky dory. Not so, my friend. We've got a BIG problem. The System Attendant Object was never fully provisioned. If you leave your cluster running in the above state, you'll see lots of issues related to many tasks that the System Attendant Mailbox is used for. In my above setup, if we look at the System Attendant object using ADSIEdit, we will find that there are no proxy addresses (BAD BAD BAD), and msExchPoliciesIncluded is not set. This will cause massive problems with Free/Busy, and you'll see NDR's being generated for any messages sent to your System Attendant mailbox (duh - it doesn't have an e-mail address)

OK - so how do you fix it? Well, before we get there, there is one more thing you need to look at that will tell you if setup encountered any problems that need to be fixed. Open up the registry, and navigate to

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\v8.0

and see which subkeys exist. You should see a separate key for Each role that is installed. For the above cluster, if setup had completed successfully, you would only see the following keys.

v8.0
   AdminTools
   MailboxRole
   Setup

In my case, however, I saw one more (bolded)

v8.0
   AdminTools
   ClusteredMailboxServer
   MailboxRole
   Setup

Viewing that key showed a Value with a name of "WaterMark" that contained a hex string. This Watermark is very important! It is how setup notes where it left off, and what still needs to be completed.

Ok - now on to the resolution. If you experience a failure during setup (clustered or not), the best way to resolve it in almost all cases is to run setup from the command prompt. The command-line version of setup is called from setup.com. For my cluster issue, since the Mailbox role completed, I don't have to actually run setup and select a role to install, rather I need to re-setup the cluster. The command I used was

setup.com /newcms /cmsname:ccr-evs2 /cmsipaddress:10.10.21.230 /cmsdatapath:e:\exchsrvr\mdbdata

When this command is run on an existing cluster with this same name, all setup will do is determine if there are any actions that have not been completed. In other words, it checks for a Watermark. In my case, it picked up at about 75% or so, and ran through to completion successfully. Inspecting the setup log after completion shows the following tasks (which I'd consider fairly important!)

[8/6/2007 5:51:55 PM] [1] Executing 'enable-SystemAttendantMailbox -Identity:$RoleFqdnOrName -DomainController $RoleDomainController', handleError = True
[8/6/2007 5:51:55 PM] [2] Launching sub-task '$error.Clear(); enable-SystemAttendantMailbox -Identity:$RoleFqdnOrName -DomainController $RoleDomainController'.
[8/6/2007 5:51:55 PM] [2] Beginning processing.
[8/6/2007 5:51:55 PM] [2] Searching objects "ccr-evs2" of type "ADSystemAttendantMailbox" under the root "First Organization".
[8/6/2007 5:51:55 PM] [2] Previous operation run on domain controller 'e12dc.E12CCR.com'.
[8/6/2007 5:51:55 PM] [2] Processing object "Microsoft System Attendant".
[8/6/2007 5:51:55 PM] [2] Applying RUS policy to the given recipient "Microsoft System Attendant" with the home domain controller "e12dc.E12CCR.com".
[8/6/2007 5:52:17 PM] [2] The RUS server that will apply policies on the specified recipient is "CCR-EVS2.E12CCR.com".
[8/6/2007 5:52:17 PM] [2] Saving object "Microsoft System Attendant" of type "ADSystemAttendantMailbox" and state "Changed".
[8/6/2007 5:52:17 PM] [2] Previous operation run on domain controller 'e12dc.E12CCR.com'.
[8/6/2007 5:52:17 PM] [2] Ending processing.

If you aren't installing a cluster, you may still see a Watermark value for one of the other roles (ClientAccess, HubTransport, Mailbox, UnifiedMessaging, etc.

If you have a watermark for one of those roles, you need to note which role has a watermark, then run the following

setup.com /roles:mb (or insert the name of the role that shows the watermark)

This will allow setup to process that role, and based on the watermark in the registry, it will continue where it left off. Once setup completes successfully, the watermark value will be removed.

I'm hoping and expecting that Service Pack 1 for Exchange 2007 will be able to handle issues like this one much better, as it should include a "Reinstall" option. If not, you can always fall back to the trusty command-line options.

Add-ExchangeAdministrator and setting the scope to multiple servers with powershell

benw — Wed, 23 May 2007 20:13:00 GMT

So you want to add a new Exchange administrator and set the scope to multiple servers, but the management shell won't allow you to do this?

Here is what happens.

Add-ExchangeAdministrator -identity <user> -role ServerAdmin -scope "server1","server2"

Error: Add-ExchangeAdministrator : cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'Scope'. Specified method is not supported.

Here's the solution.

First, you need to build an array that contains the servers in question.

[PS] C:\>$ExServers = "Server1","Server2","Server3"

[PS] C:\> foreach ($server in $exservers) { Add-ExchangeAdministrator -identity <user> -role ServerAdmin -scope $server }

Now the result is a success, and you will see the appropriate message indicating that the user has been added, and that to fully administer the Exchange server, you should add the user to the local admins group on the server.

Running Get-ExchangeAdministrator will also now show this user in the list with a separate entry for each server.

Now, one more note here. Remember that arrays are only maintained for your specific powershell session. As soon as you close Powershell, you will lose any defined arrays (or variables) unless you have taken actions (for example, modified your powershell profile) to include them.

Exchange 2007 and Recipient Type Details

benw — Thu, 05 Apr 2007 22:03:00 GMT

Now that you have been working with Exchange 2007 for a while, you may notice that in the Exchange Management Console, there are a few new things that you see. One of these is that when you look at objects, you now see a column labeled Recipient Type Details. This is, in fact, a new attribute that has been added for Exchange 2007. There is another attribute called Recipient Display Type. You will not see them with this name in AD, however. The mapping is as follows:

Recipient Display Type = msExchRecipientDisplayType
Recipient Type Details = msExchRecipientTypeDetails

These two attributes are new attributes that are added to the Active Directory Schema during Exchange 2007 setup. They are used in determining the type of recipient in the Address Book. They are displayed in the Exchange Management Console under Recipient Configuration, and in Exchange Management Shell if you perform a get- command and instruct the shell to return the full list (i.e. Get-Mailbox | fl )

Like many other Active Directory Attributes, these are represented by Integer Values in Active Directory. One important item to note here is that you do not want to be arbitrarily changing these values. The Recipient Display Type is something that should only be set by Exchange. Changing it via any other method is not supported.

I've included a couple of tables for reference. The first table covers the different values that can be assigned to the Recipient Display Type attribute.

Object Type	RecipientDisplayType (Binary)	Decimal Value	Value Name
Universal Distribution Group	00000000 00000000 00000000 00000001	1	DistributionGroup
Universal Security Group	01000000 00000000 00000000 00001001	1073741833	SecurityDistributionGroup
Dynamic Distribution Group	00000000 00000000 00000000 00000011	3	DynamicDistributionGroup
Linked Mailbox, Shared Mailbox, or User Mailbox	01000000 00000000 00000000 00000000	1073741824	ACLableMailboxUser
Room Mailbox	00000000 00000000 00000000 00000111	7	ConferenceRoomMailbox
Equipment Mailbox	00000000 00000000 00000000 00001000	8	EquipmentMailbox
Mail User, Mail Contact	00000000 00000000 00000000 00000110	6
Public Folder	00000000 00000000 00000000 00000010	2	RemoteMailUser
N/A (this represents a special “Organization” object to Outlook, but does not map to a specific exchange object type)	00000000 00000000 00000000 00000100	4	Organization
N/A (this represents a special “Private Distribution List” object to Outlook, but does not map to a specific exchange object type)	00000000 00000000 00000000 00000101	5	PrivateDistributionList

This second table is perhaps of more interest. In most situations, you will see objects appear as they should. For example, a new mailbox (for an existing user or a new user) should always show up as a User Mailbox. If your Exchange 2007 server co-exists with Exchange 2003 or Exchange 2000 servers, then all mailboxes on those 2000 or 2003 servers will show up as Legacy mailboxes. You may, however, find under certain circumstances that it does not appear correctly. For instance, after moving a mailbox from an Exchange 2003 server, which appears as Legacy Mailbox, to your Exchange 2007 server, it may now appear as a Linked Mailbox. If this happens, you need to investiage why. One possible cause could be if Associated External Account was set on the 2003 mailbox.

Also note that this attribute will not always be stamped with a value. For example, Groups do not appear to have this attribute set with a value. This leads me to conclude that Exchange is able to read this information from other attribute values as well (such as perhaps the GroupType attribute).

Although you should not be changing these values in a production environment, it is always fun to play around in a lab and learn more about what they do. But make sure you do your playing in a lab environment!

Object Type	RecipientTypeDetails (Decimal Value)	Value Name
User Mailbox	1	UserMailbox
Linked Mailbox	2	LinkedMailbox
Shared Mailbox	4	SharedMailbox
Legacy Mailbox	8	LegacyMailbox
Room Mailbox	16	RoomMailbox
Equipment Mailbox	32	EquipmentMailbox
Mail Contact	64	MailContact
Mail-enabled User	128	MailUser
Mail-enabled Universal Distribution Group	256	MailUniversalDistributionGroup
Mail-enabled non-Universal Distribution Group	512	MailNonUniversalGroup

Mail-enabled Universal Security Group	1024	MailUniversalSecurityGroup
Dynamic Distribution Group	2048	DynamicDistributionGroup
Mail-enabled Public Folder	4096	PublicFolder
System Attendant Mailbox	8192	SystemAttendantMailbox
Mailbox Database Mailbox	16384	SystemMailbox
Across-Forest Mail Contact	32768	MailForestContact
User	65536	User
Contact	131072	Contact
Universal Distribution Group	262144	UniversalDistributionGroup
Universal Security Group	524288	UniversalSecurityGroup
Non-Universal Group	1048576	NonUniversalGroup
Disabled User	2097152	DisabledUser
Microsoft Exchange	4194304	MicrosoftExchange

[Update]
Although I couldn't find it previously, some of this information is documented in the Technet Exchange 2007 documentation. If you happen to be experiencing an issue where a mailbox is showing up with the wrong Recipient Display Type, please reference the following links for details on how to correct that. Also note that in most cases, there is a reason for a mailbox showing up the way it is. For example, if you perform a cross-org mailbox move without first migrating the user account, it will show up as a Linked mailbox, and that is normal. What you don't want to do is simply modify this value without addressing the other reasons for the current value being stamped.

http://technet.microsoft.com/en-us/library/bb201749.aspx - How to Convert a mailbox
http://technet.microsoft.com/en-us/library/bb201694.aspx - How to Convert a mailbox to a Linked mailbox

[thanks to the comment of a visitor, it looks like I was off in my decimal conversions. I've edited the top table accordingly]