However, note that to use the Personal Archive, you’ll need an Enterprise Client Access License (eCAL). A nice feature to see in this cmdle is the -IsArchive parameter, which is responsible for importing a PST file into the user’s Personal Archive. The request does not accept a local directory, so you have to use a file share, but there’s a snag here: when creating the file share, you have to grant the security group “Exchange Trusted Subsystem” read/write permissions on that file share. It takes a number of parameters, but the most important ones are, of course, the mailbox and the path to the file share where the PST file is located. The cmdlet to import PST files into the mailboxes is New-MailboxImportRequest. The ExAdmin user now has the appropriate permission, and can execute the cmdlets after he closes and re-opens the Exchange Management Shell.
New - ManagementRoleAssignment - Role " Mailbox Import Export" - User ExAdmin
ExAdmin needs to Logon as the administrator (in this case, the user that first installed Exchange Server 2010, or anyone else who has been given the Organization Administrator privilege) and execute the following command: However, when the ExAdmin initially opens the Exchange Management Shell and enters the appropriate cmdlet ( New-MailboxImportRequest) an error message is generated:īy default, no one has the required permission to perform these actions, and therefore the cmdlets are not available to enable the mailbox import functionality, the “Mailbox Import Export” role needs to be assigned to the ExAdmin user. Suppose we have an Exchange administrator (ExAdmin) and, after he implemented Exchange Server 2010 SP1 (including the Personal Archives), he is now responsible for importing the PST files into the Mailboxes and Archives.
The mailbox is still accessible while it is being moved ( and that’s true when moving from Exchange 2007 to Exchange 2010 or between Exchange 2010 Mailbox Databases), and the mailbox also continues to accept new messages as they arrive on the Hub Transport Server.Ī similar process is used for importing PST files into mailboxes (and exporting PST files from mailboxes, of course) the only difference is that the source of the mail is not a mailbox, but a PST file.įigure 1: The Mailbox Replication Service is responsible for moving and importing mail data Import Mailbox This is an online process, so users hardly notice that their mailbox is being moved. If it finds a move request, it will process it and start moving a mailbox from one Mailbox Database to another. The MRS is a process that runs on the Client Access Server, continuously scanning the Mailbox Database for move requests. The process is now integrated into the Mailbox Replication Service (MRS), the same engine that’s also responsible for moving mailboxes between Mailbox Databases. Microsoft has completely reengineered this, and built PST reading/creation logic directly into Exchange Server 2010 SP1. Importing PST files has always been difficult because the process relied heavily on some of the Outlook DLL’s, but this is no longer the case in Exchange Server 2010 SP1. Time for a closer look… Mailbox Replication Service Thankfully, things have changed in Exchange Server 2010 SP1 though.
Exchange 2010 powershell install#
You had to use a 32-bit management workstation, or you had to install the Mailbox Server role on your management workstation, or you had to install Outlook on your Exchange Server basically, there are all kinds of issues that can make the SysAdmin’s life difficult. Importing PST files in Exchange Server 2010 has always been difficult and prone to error. Importing PSTs with PowerShell in Exchange 2010 SP1 - Simple Talk Skip to content
0 kommentar(er)
