How to import PST files in Exchange 2010

Turns out the way to import psts in Exchange 2010 SP1 has changed yet again.
In 2010 you were able to import mailboxen from the EMC, and in 2007 you would do it from another server/client which needed to be x86 and have the exchange management tools installed…
But to be honest i’m glad that’s no longer required.

So down to business:

To be able to import the psts, you  first need the apropriate role memberships/permissions.
To hand out these permissions open the EMS(note that you must have the “organization administration” role/permission)

Issue the following command:

New-ManagementRoleAssignment –Role “Mailbox Import Export” –User <your account>

Then close the shell and restart it, this is needed to enforce your permissions.
Now you are ready to import the psts command is as follows:

New-MailboxImportRequest -Mailbox mailboxname -FilePath \\server\share\file.pst

(please note that it is REQUIRED to use a unc path, this can be \\localservername in case the psts are stored locally. Also it MUST be in a share, so something like c:\folder\psts will not work.

After you completed the command, your request will be queued and progressed, to view this progress you can issue:


Unfortunately there is no such thing as % process or something…

If the import fails, it’s probably because there is a corrupt message(s) in the pst (check event log to verify)
Should this be the case you can add an extra argument allowing corrupt items to be skipped in the import process.

to do so enter

New-MailboxImportRequest -Mailbox mailboxname -FilePath \\server\share\file.pst -BadItemLimit <number of items>

You can import all the mailboxes at the same time, they will be processed one by one.

That’s it you’re done.

Outlook certificate error on hosted exchange

When you want to deploy hosted Exchange/multi domain Exchange, there are several things to take in consideration.
One of the things is certificates. To be honest the only thing needed is that your certificate is valid for YOUR domain, so not the client’s. When that is the case the client will be able to connect using outlook anywhere(rpc over http) however , for the clients to be able to use the “out of office assistant” and other funtions. You need to set up an autodiscover record for THEIR domain on their dns servers.
You’d think that you’ll just create an A record of Cname pointing to your mailserver, no it’s not that easy.

If you do this, then autodiscover will work, as well as all the OOOF functions etc… But your clients will receive an annoying certificate mismatch popup everytime they start outlook!

This can’t be helped, since the client will lookup but will be retargeted to , this is why there is a certificate mismatch.
Installing the certificate won’t help and nothing else will.

The only VALID solution to this, is to make an SRV record on the client’s dns as follows:

Service: _autodiscover
Protocol: _tcp
Name: @
Priority: 0
Weight: 0
Port: 443

Then remove all the A and CNAME records for autodiscover!