Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
How to install and move data from a server running POP3 to Exchange Server 2007.
Introduction
Microsoft released a new version of the Microsoft Transport tool and this new release has new capabilities
such as migrating from POP3 and IMAP4 servers to Exchange Server 2007. The process can be summarized
in a few steps: create a CSV list with all the mailbox information and import this file into Microsoft
Transporter, from there we can choose which accounts will be migrated, time range of the data to be
migrated, etc.
In this article series we are going to go through the entire process. We will start with the installation process,
how to define permissions to use Microsoft Transporter; and finally migrate some mailboxes from either
POP3 (Part 1) or IMAP4 (Part 2) to Exchange Server 2007.
The installation process is straightforward, download Microsoft Transporter, the version should be the
newest one.
The tool can be installed in either 32bit or 64bit versions of Windows Server 2003, Windows Vista or
Windows XP. The software requirements are .Net Framework 2.0, MMC 3.0, PowerShell 1.0 and Exchange
Server 2007 SP1.
End-User License Agreement. Click I accept the terms in the License Agreement and click Next.
Select Components and Install Location. In our case we are not going to play with Lotus Domino, then let us
install only Transporter for Internet Mail, and then click on Next, as shown in Figure 01.
Figure 01
Ready to install. Just click on Install button to start the Microsoft Transporter installation.
The process is totally straightforward and the Microsoft Transporter Suite can be installed in a workstation
or on the Exchange Server 2007 box as well.
In order to migrate from POP3/IMAP4 the user must have the Exchange Recipient Admin and Exchange
Impersonation rights in at least a single CAS Server.
To validate if the current user belongs to the Exchange Recipient Admin we can run the following
command:
To configure Exchange Impersonation we need to figure out first what the Distinguished Name of the CAS
Server is. Run the following Get-ClientAccessServer cmdlet (Figure 02):
The Exchange Impersonate permission can be assigned to a single CAS Server or all of them, if we are
going to specify the CAS during the mailbox migration wizard. To add the permission use the Add-
ADPermission cmdlet (Figure 03), using the following syntax:
Add-ADPermission –Identity <CAS Server Distingued Name> -User <user> -ExtendedRights ms-Exch-EPI-
Impersonation
In Figure 03 we will use the cmdlet syntax above with an extra parameter, that is –Whatif, which will
simulate the action that would be performed by the cmdlet. If everything goes well, we can remove the –
WhatIf and run the cmdlet again. In our example, we added it to a single CAS Server.
Figure 03
We will now move data from a generic POP3 Server to Exchange Server 2007, in order to accomplish this
task we have to create a .CSV file with the following columns:
SourceIdentity: The e-mail account that the user has in the POP3 Server
SourceServer: The name or IP of the POP3 Server
SourceLoginID: the account user name used to connect on the POP3 server
SourcePassword: the user’s password
TargetIdentity: the Exchange Server 2007 identity will receive the data from the previous POP3 Server
settings
We can create a .csv file directly in notepad or we can use Microsoft Excel to do this. Our list with some
users can be seen in Figure 04.
Figure 04
The TargetIdentity must exist before using the Microsoft Transporter tool, the value of TargetIdentity can be
any e-mail address (Primary or secondary). We can use the same CSV file to create the users or mailboxes in
case of a new environment. (To create objects using a CSV file please see this article on how to manage
mailboxes in Exchange Server 2007. at the end of this document)
Next, we are going to copy content from a generic POP3 Server to Exchange Server 2007. The user list was
created in the previous section and now we are going to import them into the tool and use the migration
wizard later on in order to copy the content. Before starting the copy we will see the current information that
a user has in the generic server which supports POP3 (Figure 05).
Figure 05
Okay, now we know the content that we are going to move, let us use the Microsoft Transport to copy the
content:
1. Open Microsoft Transporter Suite for Internet Mailboxes.
2. In the main screen click on Add Mailboxes... button. (Figure 06)
Figure 06
3. Add Mailboxes. Select the CSV file created in the Excel and click on Import. (Figure 07)
Figure 07
4. Security Warning. A message informing us that the password information contained in the CSV will be stored
in a file called InternetMailbox.tbin. Just click OK.
5. On the main screen we have three different views to work with: All Mailboxes, Mailboxes Ready for
Migration and Mailboxes Already Migrated. Let us click on All Mailboxes to see all the mailboxes imported
from the CSV file and let us start the migration of a single user, click on a single user and click on Migrated
Selected Mailboxes. (Figure 08)
Figure 08
6. Select Mailbox Type. Select POP and we are not going to use a secure connection to the POP3 Server (995
SSL), we also going to specify which CAS (Client Access Server) and in our case that CAS was the only one that
we gave Exchange Impersonate permissions. Click on Next. (Figure 09)
Figure 09
7. Select Data Range. We can specify a time range to migrate from the POP3 server to Exchange Server 2007.
We will get all the content, click on All e-mail and click on Next. (Figure 10)
Figure 10
Now, it is time to test if our migration went well. Log in using the user Anderson Patricio (the same user
whose mailbox was on the generic POP3 server) and we can validate that the current content in OWA is the
same as the POP3 server (Figure 11). Microsoft Transporter preserves the following characteristics:
attachments, rich content, status information (read or unread).
Figure 11
Conclusion
In this article we have seen how to copy content from a generic POP3 Server to Exchange Server 2007. The
ability to copy content from POP3/IMAP4 servers was introduced with Microsoft Transporter version
8.02.0012; before that all that was possible was copying data on the client side or using Exchange Server
2003 Migration Wizard.
In the next article we are going to move content from an IMAP4 server and we are also going to see how to
copy contents using the Exchange Management Shell.
In the first article we saw how to install Microsoft Transporter and the required steps that must be done
before starting the copy process from a POP/IMAP server to Exchange Server 2007. These steps are: install
Microsoft Transporter, set the Exchange Impersonation permission on a CAS Server and create the CSV file
that will be used by the Microsoft Transporter.
In this article I assume that those steps have been completed (permissions and CSV file) and we are now
going to go through the steps required to move from an IMAP Server and play with some features that are
found only when the IMAP protocol is used.
The wizard used by Microsoft Transporter Suite for Internal Mail to copy data from an IMAP4 server to
Exchange Server 2007 is a little bit different from the process performed in the first article. Using an IMAP4
Server as source we are able to configure two new items: Folder Mapping and IMAP4 authentication.
4. IMAP Folder Mapping. This is the first new feature when we use the IMAP protocol. For now we are
going to leave the default setting which is use the default folder mapping and click on Next. In the
next section we will validate how to change some settings to manage folders from the source server
during the migration using an XML file called FolderMap.xml. (Figure 02)
Figure 02
5. IMAP Authentication. This is the second new feature using IMAP. Microsoft Transporter is able to
use a single account to authenticate against the IMAP server and copy data to Exchange Server. This
account must have administrator credentials to log in to all accounts selected for migration on
Microsoft Transporter. We are going to explain this new feature in the next section, for now let’s
leave the default settings and click on Next. (Figure 03)
Figure 03
6. Select Data Range. We can define either a range or All e-mail to copy messages from the source
IMAP Server. (Figure 04)
Figure 04
7. Review Selected Mailboxes. An overview will be shown, just click on Migrate to start the copy from
the source IMAP server.
After this process we will be able to see all the messages, calendar, notes, Tasks in the Exchange server 2007
mailboxes.
Using the Administration Credential feature
When the IMAP protocol is used and the source server has the ability to allow an account to access another
user’s mailboxes, then we can use that specific account to log in to the source server to migrate the data, as
shown in Figure 05.
Figure 05
If we are going to use this resource we do not need to add the column SourcePassword into the CSV file
because that password will not be used.
Microsoft Transporter can use an XML file to match the IMAP source folders with the Exchange Server
2007 default folders. During the Microsoft Transporter installation a file called Foldermap.xml that can be
found at c:\program files\Microsoft Transporter tools\Config is installed. We can use this file to create
our own definitions. For example: if the source mailbox receives all new messages in a folder called New
Items we are able to associate this folder to match with the default folder Inbox.
If a different folder exists in the source server it will be created in the Exchange Server 2007 mailbox, if the
folder already exists in the Exchange Server 2007 mailbox the content will be merged. Let’s use a couple of
scenarios to demonstrate how to use the mapping folder feature.
To configure a custom folder mapping file click on Use a custom folder mapping in the wizard section
named IMAP Folder Mapping, as shown in Figure 06.
Figure 06
Scenario 01: The user below (Figure 07) has a folder named Projects on the IMAP4 server. If we run the
Microsoft Transporter Wizard that folder will be created automatically in the user’s mailbox.
Figure 07
Let’s create a copy of the file Foldermap.xml and save it as CustomFolderMap.xml and add the following
parameters to that file (see Figure 08). That parameter will redirect all the information located in the Project
folder of the source mailbox to the Exchange Server 2007 mailboxes in subfolder Projects folder under the
Inbox folder.
Figure 08
Scenario 02: In this second scenario we do not want to move the contents of the source folder Projects. For
this scenario we can add the following parameters into our XML file.
Using the example above the folder Project will not be created in the destination mailboxes.
Conclusion
In this final article we have seen how to use the Microsoft Transporter Suite for Internet Mail to copy data
from POP/IMAP servers to Exchange Server 2007. We also saw how to configure extra options that can be
used with IMAP protocols, such as: using an administrator account to move all users without knowing the
user’s password and how to use a file to map folders from the source server to Exchange Server 2007.
Overview
In this article, we are going to approach a simple but important subject: the mailbox user management for
Exchange Server 2007.
It may seem a simple issue to discuss, but we will see some advanced points related to user management
tasks in order to assist beginners and advanced administrators. This article will be split into two parts; in this
first part we will review mailbox management and user level functionalities.
5. Introduction. We have to choose what kind of object we are creating, in Exchange Server 2007 we
have four different mailbox types:
- Resource mailbox: This is a mailbox specifically assigned to Meeting Rooms. Its associated user
account will be disabled in Active Directory.
- Equipment mailbox: This is a mailbox specific to resources, (i.e. TV, Projector and so on). As
with a Resource mailbox, this kind of mailbox will disable a user in Active Directory.
- Linked Mailbox: This kind of mailbox will be used in environments with multiple forests. This
specific feature will be explained in a later article on MSExchange.org.
In the Introduction window, select the appropriate mailbox type and then click Next to continue.
(Figure 02).
Figure 02: Choosing what kind of mailbox will be created
6. User Type. In the User Type window, we can choose either to create a new user or to assign an
existing user to the new mailbox. If we choose to assign it to an existing user, we will have to check
if the account does not already have a mailbox associated with it. Click Next to continue (Figure 03).
Figure 03: Creating a new user for a new mailbox
7. User Information. In the User Information window, we should fill out the personal information of
the user and select the Organization Unit where it will be created. After that click on Next (Figure
04).
Figure 04: Filling out the personal user data and OU localization
8. Mailbox Settings. On the Mailbox Settings page, we can define the mailbox information such as
Alias, Mailbox Server, and Mailbox Store where the new mailbox will be located. The policies for
Mailbox and ActiveSync can also be defined in this step. We can choose which fields we are going to
fill out and then click Next to continue. (Figure 05).
Figure 05: Choosing Server, Storage Group, Mailbox database and policies during the mailbox creation
process
9. New Mailbox. In the New Mailbox window, we will get a summary of all the information that we
selected in the previous steps. These parameters will be used by the PowerShell engine for the
creation of this mailbox object. To create the mailbox, click on New (Figure 06).
Figure 06: The parameters that will be used in the creation of the new mailbox
10. Completion. In the Completion window, we will see the cmdlet New-mailbox and the parameters
that we used in the creation process of this new mailbox.
Figure 07: The final screen of the New Mailbox Wizard, showing us the cmdlet used in the creation of the
mailbox
Another way to create users is by using the Exchange Management Shell. To do this, we can use a cmdlet
called New-Mailbox. There are many parameters associated with this commandlet, and the required
parameters for the cmdlet are the following:
Alias
Name
Database
OrganizationalUnit
UserPrincipalName
To create a user using Exchange Management Shell, we can run the following cmdlet:
New-Mailbox –alias <alias> -name <name> -Database <Database name> -OrganizationUnit Users –
UserPrincipalName <UPN value, example: Anderson@contoso.local>
If we do not type all the required parameters, we will get a prompt asking for the parameters that are
missing. In Figure 08, we can see that we have received the password prompt to fill out the password. After
the password was entered, the user was created.
Figure 08: Creating a mailbox through the cmdlet New-Mailbox in the Exchange Management Console
Another interesting feature is the one that lets an administrator create several users from a *.csv file. In the
following section, we will review a step by step procedure to create mailboxes:
1. First of all, we will have to create a *.csv file called recipients.csv on the root drive (C:\) and we
will type the column names for the file in the first line. Those columns will be the Alias, the Name
and UPN. in the following lines we will complete the user information (Figure 09).
Figure 09: Creating a csv file to be used in the creation of users through Exchange Management Shell
2. Once the user information is complete, we will have to create a variable in the Exchange
Management Shell that will keep the initial password for all of the accounts on the recipients.csv file.
To do so, we will type the following:
$Password = Read-Host “Type the default password for the new accounts:” -AsSecureString
Figure 10: Creating a variable to keep the initial password on the new accounts
3. In the following step, we will run two cmdlets using a pipe to create the new users using the *.csv
file. This is the syntax of our cmdlet:
4. To check if the users were created, we will go to the Exchange Management Console (Figure 12).
Figure 12: The new users created through the csv file
We can manage functionalities at the user level, enabling or disabling the following features:
OWA
Exchange ActiveSync
Unified Messaging
MAPI access.
This task can be completed in two different ways, both will be detailed in the following sections:
In some cases, we have to verify the functionalities that users have, and there is no way to do this user by
user. In Exchange Server 2007, this task is very easy, and can be done with a cmdlet called get-casmailbox
(figure 14).
Using this cmdlet, we can export the results to a *.csv file and analyze it in Microsoft Excel and generate
reports or analyze it any way we want.
Figure 14: All the users with their functionalities through Exchange Management Shell
To manage features using the Exchange Management Shell, we can use the cmdlet called set-casmailbox, as
follows:
To show you the real impact of the use of the Exchange Management Shell, here is an example.
Scenario: We have a company with fifty (50) branch offices and we have to disable MAPI access for all
users in Toronto.
First of all, we must insure that all the Active Directory information is consistent. In our scenario, all of the
users have the attributes City and StateorProvince filled out correctly. One example of this is shown in the
Figure 15 through cmdlets get-user | select name, recipientType, City, StateorProvince
Figure 15: Verifying the attributes City, StateorProvince of all the users
If all of the Active Directory information is consistent, we can use the pipe resource on the Windows
PowerShell where an output from one command is used as input for another cmdlet.
We will need some specific user attributes that we cannot get through get-mailbox because this cmdlet only
returns mailbox information. We will have to use the get-user cmdlet to filter the city attribute from users
and combine these results with the set-casmailbox cmdlet.
To resolve this, we can use this subset of cmdlets, as is shown in figure 16.
Figure 16: Disabling OWA access of all of the users located in Toronto city and Ontario State, and after that
a list of the new user features
Now, let’s check if everything worked as expected. None of the users who had the OWA feature set as
disabled will be able to access their mailboxes through Outlook Web Access. We can test it, trying to see if
the user Anderson.Patricio can access his mailbox with Outlook Web Access. We can see that everything
worked as shown in the next figure (Figure 17).
Figure 17: After authentication, the user receives the message that OWA is disabled
Conclusion
We have reviewed the steps required to create users (in the traditional way) by using the Exchange Management
Console. Then, we reviewed similar tasks using the flexibility of the Exchange Management Shell to help us to create
one or more users through commandlets. At the end of this article, we discussed how to manage some mailbox
features at user level.