If you would like to read the other parts in this article series please go to:
Exchange 2007
Many users are asking if this tool works also with Exchange 2007. When I first heard about it, this thought came to my mind: “I bet it doesn’t as it is probably based on the Exchange 2010 New-MailboxImportRequest cmdlet!” Then, I read that Microsoft’s comment on this is that they haven’t tested the tool against Exchange 2007 and it might or might not work. This to me says that it probably works but Microsoft doesn’t want to support it! So, let’s give it a try!
First, I decided to go for it and test the tool without any changes besides the requirement to only import to archive (Figure 2.18 in the second article of this series). Using the search I had already done I tried importing the same PST to a mailbox in Exchange 2007. I thought I would have to change the permissions on the service account at least, but it worked straight away without any issues!
Once I logged in to Outlook Web Access I had all the PST’s content in my mailbox:
Figure 4.1: Import Results in Exchange 2007
Notice that even though the PST file doesn’t have a Calendar, Contacts or Tasks folders, for example, they were created when importing to a 2007 mailbox but not on a 2010 mailbox.
The other difference is that some items were marked as unread while in the 2010 mailbox they were left as read.
Does this prove that the tool doesn’t use the 2010 PowerShell cmdlet I was thinking about, but probably some intellectual property acquired from RedGate? It could use both the New-MailboxImportRequest cmdlet for Exchange 2010 and the Import-Mailbox cmdlet for Exchange 2007 but from Microsoft’s comment I really doubt it.
In order to confirm this, I used the Search-AdminAuditLog cmdlet in Exchange 2010 to look at all actions performed by the service account used but didn’t find anything. This to me proves it doesn’t use the Exchange cmdlets.
Office 365
So what about Office 365? The process of importing PSTs to Office 365 is practically the same and when importing to an on-premise Exchange environment. The only differences are:
-
We need to configure the Online Connection Settings (Figure 2.16 in the second article of this series);
-
To create an Import List we select Cloud Import List instead of OnPrem Import List from the New Import List button;
-
We can’t use the Set to File Owner button;
-
We don’t need any Exchange server as the import is done directly from the Console to Office 365!
After you configure the Online Connection Settings and create an Import List, you are ready to go. Again, you will have to set the Destination Mailbox manually. When you click in Set Mailbox… a list of all your Office 365 mailboxes will appear for you to choose from. Please note that if you just configured the Online Connection Settings screen, it will take some time until all the information is retrieved so you might have to wait for a bit (in my case it took around 30 minutes)…
I then started the import process but shortly after I got an error: “Import Error: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)”
Looking at the tool’s logs in %ProgramData%\Microsoft\Exchange\PST Capture\Logs I found the following (amongst other information):
21:11:23.101|Error |PstToolImporting |7 |Failed to create message from MAPI. Subject was ‘-‘
System.Runtime.InteropServices.COMException (0x800706BA): The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
in Microsoft.Exchange.PSTCapture.MapiLib.msgclass.GetSubject()
in RedGate.ExchangeArchiver.MAPI.Engine.MapiMessage.get_Subject()
in RedGate.PSTImporterForExchange.ImportEngine.PstEwsImporter.CreateMessageProblem(String message, String folder, MapiMessage msg, Boolean warnOnly)
Unfortunately, this didn’t reveal very useful (I don’t have an e-mail with the subject “-“!) except for emphasising the fact the tool uses RedGate’s own code. Searching for information, I found many users having the exact same error! Some say it is the firewall but in my case it was already disabled… Unfortunately, I haven’t been able to fix this issue yet…
Because I was keeping an eye on the import progress, it looked like it was able to import some messages. After logging in to my Office 365 e-mail account, I confirmed this was the case – it just didn’t import all of them:
Figure 4.2: Import Results in Office 365
Troubleshooting
To finish this article, let’s explore some of the most common issues found with this tool.
Password Protected PSTs
If you try to import a password protected PST file, you will get the “Import error: Incorrect password” error. In this case, the user has to select the Save this password in your password list option in Outlook for the tool to be able to import the PST:
Figure 4.3: Set PST Password
Opened PSTs
PSTs that are currently opened by users will not be imported! The tool will display a message similar to: “Agent Error: The process cannot access the file <pst file> because it is being used by another process.”
Error Opening Mailbox
If you get the error below, make sure you have Outlook 64-bit installed on the PST Capture host computer:
Figure 4.4: Error Opening Mailbox
TCP Port
If the default port (TCP 6674) is changed then make sure the firewall(s) has an exception for the new port.
Error While Retrieving Mailboxes
You will get the error below if you are importing to an on-premise Exchange environment and the Central Service is not able to communicate to an Exchange Client Access Server:
Figure 4.5: CAS Server Offline
No Contact From Agent
As explained before, the error shown below can have many causes, the most common ones being:
-
The computers have been turned off;
-
The firewall is blocking the communication;
-
The agent’s service is not running.
Figure 4.6: Agent’s Status
Logs
If you want to see exactly what the tool is doing or need to troubleshoot any problems, the tool writes diagnostic logging information to logs that can be found at: %ProgramData%\Microsoft\Exchange\PST Capture\Logs
Deficiencies
After working with this tool for a few days and performing practically every action it can do, I only have a few suggestions/comments to make:
-
There is no option to select a date range. It might be useful for some users to only import e-mail items from the last 2 years, for example;
-
There is no option to just import certain folders from the PST or to exclude certain ones as you can with the New-MailboxImportRequest cmdlet;
-
All PSTs are copied to the Staging Area and then deleted even if the import is successful or not. It would be useful if they were kept, at least when the import fails, so they don’t have to be copied every time we try to import them. It might be done this way so we are certain we are importing the correct file and the most recent version of it. Yet, having that option would be nice;
-
In all my tests, everything from the PST’s Deleted Items folder was imported to the Inbox folder. Possible bug?
-
No matter how I tried, I couldn’t make the tool import a PST from a mapped network drive, even after I made svc_PSTCapture account member of the Domain Admins group;
-
There could be an option to delete successfully imported PST files from the client computer to make sure users don’t continue to use them;
-
A final report would help keep track of all the PSTs that have already been imported and which ones haven’t.
Conclusion
Administrators have always struggled to contain the use of PSTs. With so small mailbox quotas in the “old days”, there was not much to do besides implementing a 3rd party (expensive) archive solution. With the introduction of Exchange 2010, Personal Archives and the possibility of using cheaper storage, mailbox quotas are now bigger than ever and PSTs don’t make much sense in most cases. This is where the Microsoft PST Capture Tool comes into play and helps administrators import all those PSTs back into Exchange.
All in all, I think this is a brilliant tool! Can’t give all the credit to Microsoft as I don’t know how better or different this tool is when compared to the last one from RedGate, but whoever developed it did a great job!
If Microsoft pays attention to the feedback from the online community, I will not be surprised if an updated version gets released soon. Having said that, as it is, I think the tool will meet practically everyone’s needs.
If you would like to read the other parts in this article series please go to:
