Download a PDF version of this image here: Exchange Server 2010 Architecture Poster

In part one of this series, we looked at how to identify the relevant machines on your network (i.e. machines which are currently offering refuge to PST files), and in part 2 we covered how to use the Exchange Management Shell to identify the filenames, owners and locations of the PST files those machines. This final video will complete the process, and cover the actual import procedure.

In the previous video I identified the machine names of the computers on my network for use in a subsequent search for PST files. In the next video I will look at the scripts that will setup the Import-Mailbox requests from these PSTs into the relevant mailboxes in Exchange.

In the next video I will go through finding PST files on your network.

In Exchange Server 2007 this is not too difficult to accomplish. Microsoft has released a whitepaper on how to configure virtual organizations (i.e. companies) in Exchange Server 2007. This whitepaper can be found on the Technet Website: http://technet.microsoft.com/en-us/library/bb936719(EXCHG.80).aspx – Configuring Virtual Organizations and Address List Segregation in Exchange 2007.

It is tempting to try this in Exchange Server 2010 as well, but you would be best off avoiding doing so. There are a couple of issues (that Microsoft is working on) that will block a successful rollout of Address List Segregation. Besides that, it is not supported and it will also break Exchange Server 2010. More information regarding this can be found on Dave Goldman’s weblog: http://blogs.msdn.com/b/dgoldman/archive/2010/05/10/critical-update-exchange-2010-address-list-segregation-and-current-support-stances.aspx – CRITICAL UPDATE – Exchange 2010 Address List Segregation and Current Support Stances

You may be aware that in Exchange Server 2010 SP1 there’s a /hosting switch, making Exchange Server 2010 SP1 “multi tenant”. This means you can create multiple virtual organizations in Exchange Server 2010 SP1, completely invisible for each other. There’s already quite some information on the Internet regarding installation of Exchange Server 2010 SP1 with the /hosting switch, but most of this information is not coming directly from Microsoft!

This “hoster edition” of Exchange Server 2010 SP1 is targeted towards hosting companies, companies that currently have HMC (Hosted Messaging and Collaboration) 4.5 running. This is basically the Hosted Version of Exchange Server 2007, including Hosted Sharepoint and Hosted OCS. This implementation of Exchange Server 2010 is absolutely not targeted towards enterprise customers!

There are a number of issues you have to be aware of when you want to deploy the “hoster edition” of Exchange Server 2010 SP1:

• You need an SPLA (Service Provider License Agreement) to use this version of Exchange Server 2010 SP1;
• The Forest Functional level is Windows Server 2008;

There is:

• No upgrade path (only a green field scneario);
• No support for Unified Messaging;
• No support for Edge and EdgeSync;
• No support for multiple forests;
• No support for multiple domains;
• No Exchange Management Console;
• No Public Folders;
• No Federation;
• No B2B features such as cross-premises message tracking and calender sharing;
• No IRM;
• No Outlook 2003 support (EnableLegacyOutlook);
• No Support for OCS 2007 R2, only from 3rd party;
• No Support for CRM;

When you try to start the Exchange Management Console you’ll see that it is not supported:

So, all configuration has to be done using the Exchange Management Shell. There’s some additional self service support on the Exchange Control Panel, but basically you’ll need to implement another 3^rd party Control Panel for configuring the Exchange organization. Or create your own Control Panel. Please bare in mind that hosting companies often have dedicated developers that are working on these scenarios.

Conclusion

If you want to implement Address List Segregation on Exchange Server 2010 you cannot use the 2007 version of the Address List Segregation whitepaper. It will break Exchange Server 2010. Although very tempting to use, the Hoster Edition of Exchange Server 2010 SP1 is not an alternative for the enterprise customers. Don’t try it, don’t even think about it, there’s too much complexity for the average enterprise customer. Besides the Service Provider licensing, there’s too much functionality that’s not supported by Microsoft directly, or it is supported by a 3^rd party. The best option is to wait and see if and when Microsoft releases the 2010 version of the Address List Segregation.

The following script does just that:

# Read in pst file locations and users
$strPSTFiles = Get-Content -Path "c:\pstdetails.csv"
foreach($strPSTFile in $strPSTFiles)
{
$strMachine = $strPSTFile.Split(',')[0]
$strPath = $strPSTFile.Split(',')[1]
$strOwner = $strPSTFile.Split(',')[2]

# Get network path for pst file
$source = "\\" + $strMachine + "\" + $strPath.Replace(':','$')

# import pst to mail box.
Import-Mailbox -PSTFolderPath $source -Identity $strOwner
New-MailboxImportRequest -FilePath $source -Mailbox $strOwner
}

The yellow highlighted text shows the Exchange 2010 RTM cmdlet, the red the Exchange 2010 SP1. Delete the unneeded version as appropriate.

The Exchange 2010 SP1 version of the script will execute in far less time, due to the asynchronous nature of the ImportRequest cmdlet. These requests are processed in the background and can be monitored with the Get-MailboxImportRequest cmdlet to observe their status.

There are quite a few potential pitfalls here:

1. The user’s machine must be on.
2. File sharing must be on, to allow for the file to be transferred.
3. Outlook must not be running on the remote user’s machine. If Outlook is running and has the PST file attached, the file will be locked and unable to be imported.
4. The PowerShell cmdlet used by Exchange to import PST files does not support passwords.

There are various things you could to augment this script.Some suggestions include:

•  Have WMI shut down Outlook on a remote user’s machine before attempting import http://www.computerperformance.co.uk/vbscript/wmi_process.htm
• It could be useful to generate a further file detailing a list of all the PSTs which failed to import, with the reason. These files could have been password protected, or the machine hosting them may have been shut down, or become disconnected since they were identified.

I hope you have found this series of articles on manually importing PST files into Exchange 2010 useful. Although, like me, I’m sure you feel that this is a bit of a mammoth task, particularly for the Powershell novice!

To automatically import PST files into Exchange 2010 without Powershell visit:
www.red-gate.com/products/pst_importer_2010. Here you can find out more information on PST Importer 2010 and download a free 14 day trial.

To start this, we  can query Active Directory for a list of all the machines attached to your domain. We can then use Windows Management Instrumentation (WMI) to search each of these machines for PST files. The file paths for these PSTs should hopefully give a clue as to which user they belong to, as they will be created in a directory path containing the username by default. We can also grab the file owner file attribute which should correlate with the file path.

This technique requires that all the machines in your network are switched on and accessible by WMI. A list of the machines which could not be queried can be provided as output

Notes about WMI:

By default WMI is blocked by the windows firewall in Windows 7 and 2008 R2. You’ll need to open up the ports on all your users’ machines. This can be done with the ‘netsh’ command, or through a change to group policy.

What are the implications of this? WMI is a powerful beast, and allows remote access to many aspects of a user’s machine. As such it could be considered a security vulnerability… It’s typically accessed though port 135. This not only permits access to WMI – but also any other DCOM components which may be installed on a machine, open for exploitation by Trojans and the like. Needless to say, the ports are blocked by default for a reason – so require careful consideration of the implications when opening. WMI will also not help you if the machines you wish to tinker with are subject to NAT (Network Address Translation). You’ll be unable to reach these machines. The following script generates a txt file (the filename defined on line 2) of all the computers on your domain to be searched. This can then be edited with notepad to remove those you don’t wish to search.

$strCategory = "computer"
$strOutput = "c:\computernames.txt"
$objDomain = New-Object System.DirectoryServices.DirectoryEntry

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.Filter = ("(objectCategory=$strCategory)")

$colProplist = "name"
foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)}

$colResults = $objSearcher.FindAll()
[bool]$firstOutput = $true
foreach ($objResult in $colResults)
{
$objComputer = $objResult.Properties;
if($firstOutput)
{
Write-output $objComputer.name | Out-File -filepath $strOutput
$firstOutput = $false;
}
else
{
Write-output $objComputer.name | Out-File -filepath $strOutput `
-append
}
}

The next script will generate a CSV (Comma separated values) detailing the network paths of the PSTS you need.

$strComputers = Get-Content -Path "c:\computernames.txt"
[bool]$firstOutput = $true
foreach($strComputer in $strComputers)
{
$colFiles = Get-Wmiobject -namespace "root\CIMV2" `
-computername $strComputer `
-Query "Select * from CIM_DataFile `
Where Extension = 'pst'"
foreach ($objFile in $colFiles)
{
if($objFile.FileName -ne $null)
{
$filepath = $objFile.Drive + $objFile.Path + $objFile.FileName + "." `
+ $objFile.Extension;
$query = "ASSOCIATORS OF {Win32_LogicalFileSecuritySetting='" `
+ $filepath `
+ "'} WHERE AssocClass=Win32_LogicalFileOwner ResultRole=Owner"
$colOwners = Get-Wmiobject -namespace "root\CIMV2" `
-computername $strComputer `
-Query $query
$objOwner = $colOwners[0]
$user = $objOwner.ReferencedDomainName + "\" + $objOwner.AccountName
$output = $strComputer + "," + $filepath + "," + $user
if($firstOutput)
{
Write-output $output | Out-File -filepath c:\pstdetails.csv
$firstOutput = $false
}
else
{
Write-output $output | Out-File -filepath c:\pstdetails.csv -append
}
}
}
}

This script will take as input a text file containing a list of machine names (conveniently the output of the first script), and will generate a csv file of all the pst files found on those machines, and the owners associated with them.

Find PST files across your network quickly and easily with PST Importer 2010. To find out more and to download a free 14 day trial please visit:
www.red-gate.com/products/pst_importer_2010

A PowerShell cmdlet in the EMS is used to perform the action. Use of this cmdlet requires that the current user has Import Export mailbox roles on their profile. Exchange 2010 RTM also requires that Outlook 2010 x64 is installed on the machine. This is no longer a requirement of Exchange 2010 SP1.

So, to import a single PST file into an Exchange 2010 mailbox:

• Install Outlook 2010 64-bit on the Exchange Server. By default, on a machine with no pre-existing Office installation, the 32-bit applications will install from the DVD’s autorun setup. Be sure to manually run the install from the x64 directory to install 64-bit Outlook. This step is not necessary for Exchange 2010 SP1, as this includes a MAPI provider.
• Enable import permissions for a security group your user belongs to (in this case ‘Mailbox Support’) with the command:New-ManagementRoleAssignment -Name "Import Export Mailbox Admins" `
-SecurityGroup "Mailbox Support" `
-Role "Mailbox Import Export"

• Import the PST file into the appropriate user’s mailbox with the following command:Import-Mailbox -PSTFolderPath pstfilepath -Identity exchangealias 

Exchange 2010 SP1 differs a little in that you don’t need to install Outlook 2010 x64, and rather than the synchronous ‘Import-Mailbox’ cmdlet, the asynchronous ‘New MailBoxImportRequest’ can be used.

This takes the form of:

New-MailboxImportRequest -FilePath pstfilepath -Mailbox mailbox

One of the advantages of this new cmdlet (other than being asynchronous), is that you can specify an additional –IsArchive parameter, which will import the PST into the user’s archive mailbox.

I did experience a few problems using these cmdlets during  my research for this guide. The Exchange 2010 RTM Import-Mailbox on one system refused to play nicely, throwing the following error:

Error:
Error was found for XXX because: Error occurred in the step: Approving object. An unknown error
has occurred., error code: -2147221219
+ CategoryInfo : InvalidOperation: (0:Int32) [Import-Mailbox], RecipientTaskException
+ FullyQualifiedErrorId : CFFD629B,Microsoft.Exchange.Management.RecipientTasks.ImportMailbox

Not a lot of help in itself – a little Googling and experimentation revealed four main causes for this error:

1. The appropriate role permissions had not been added to the user’s security profile.
2. The version of MAPI being used had somehow got confused. Running the ‘fixmapi’ command from the command prompt should fix this.
3. The PST file is password protected.
4. There is a bug in Exchange.

In my case I’d unfortunately hit the fourth case and the work around proved to be pretty horrific It may simply be worth waiting for a fix from Microsoft. To complete my task, I had to temporarily add a new domain controller to my network to host a new Exchange 2010 server. I then moved the mailboxes for which I had PSTs to import to this new server, performed the import, then moved the mailboxes back to their original Exchange Server, and removed the temporary server from the network. Upgrading the system to 2010 SP1 and using the ‘New-MailBoxImportRequest’ cmdlet  on the same system yielded the following error:

Couldn't connect to the target mailbox.
+ CategoryInfo : NotSpecified: (0:Int32) [New-MailboxImportRequest], RemoteTransientException
+ FullyQualifiedErrorId : 1B0DDEBA,Microsoft.Exchange.Management.RecipientTasks.NewMailboxImportRequest

Again, this appears to be a known issue, and apparently due to be fixed before the release of SP1.

In my next post I will go through finding PST files on your network the manual way.

Automatically import PST files into Exchange 2010 with PST Importer 2010. To find out more and to download a free 14 day trial please visit:
www.red-gate.com/products/pst_importer_2010

Error:
Error was found for (username) because: Error occurred in the step: Approving object. An unknown error
has occurred., error code: -2147221219
+ CategoryInfo          : InvalidOperation: (0:Int32) [Import-Mailbox], RecipientTaskException
+ FullyQualifiedErrorId : CFFD629B,Microsoft.Exchange.Management.RecipientTasks.ImportMailbox

Here is how I worked round it.

After doing some digging,  I found the site http://www.korneel.nl/?p=28 that  identifies most of the problems you might hit importing a PST file.

The cause for the error in my case transpired to be an acknowledged (according to the blog post) bug in exchange, presumably with an upcoming hotfix. However, it seems to be a generic error for all ills, as other solutions on the web suggest using the ‘fixmapi’ command (though admittedly referring to exchange 2007…). http://social.technet.microsoft.com/Forums/en-US/exchangesvrmigration/thread/82424f36-2611-4188-808e-df9aad36a5b7 (And the most common suggestion being adding the import export role to the user account.)

Another potential pitfall is the requirement for the 64bit version of outlook 2010 to be installed. It’s worth noting that by default an installation of Office 2010 on a clean machine will install the 32bit version.

As an unrelated aside,  installing the SP1 beta on exchange also caused a few problems – it required the manual installation of several hot fixes – and more annoyingly one package (UCMA 2.0 Runtime 64bit)– which despite coming as an ‘msi’ installation package, and on running giving all the signs it had installed successfully – had actually only ‘installed’ the installation files, which then had to be run separately. I’m sure these niggles will be ironed out before SP1 is released, but it wasn’t the friendliest of upgrades.

PST Importer 2010 provides a simple and transparent way to find and import PST files into Exchange 2010. To find out more information and to download a free 14 day trial please visit: www.red-gate.com/products/pst_importer_2010

This is what actually happens when an Exchange administrator initiates a New-MoveRequest, either from the Exchange Management Shell or the Exchange Management Console when moving a mailbox from EXMBX01 to EXMBX02 in the figure below.

The process of moving mailboxes is now performed by a service called Mailbox Replication Service or MRS. The MRS is running on the Client Access Servers.

1. The Administrator initiates a move request like New-MoveRequest –Identity J.Wesselius –TargetDatabase EXMBX02\MDB02. Now a special message is placed inside the System Mailbox of the current Active Directory site. This message tells that the Move Request is initiated and that its status is Queued;
2. The Mailbox Replication Service periodically scans this System Mailbox for these messages. The MRS will find the message and reads that the J.Wesselius mailbox is Queued;
3. The MRS will update the System Message to “In Progress” and will start moving the Mailbox data from EXMBX01 to EXMBX02. MRS will keep the old and the new mailbox in sync. The user is still connected via the CAS Server to EXMBX01, and arriving messages will be delivered via the Hub Transport Server to the Mailbox on EXMBX01;
4. At a certain point when almost all data is moved from the old to the new Mailbox the old Mailbox is locked. The last pieces of data are moved from the old to the new Mailbox. Also the Active Directory properties of the user are changed to point to the new Mailbox Database. At this point the status of the Move Request (i.e. the message is the System Mailbox) is changed from “In Progress” to “Completion in Progress”;
5. The new Mailbox is activated, the old Mailbox is soft deleted (which means that it is actually recoverable in SP1!) and the user needs to restart his client. When you move a Mailbox from an Exchange 2010 SP1 Mailbox Database to a Mailbox Database on another SP1 Mailbox Database the client does not need to be restarted.
6. Although the Mailbox is moved from server EXMBX01 to EXMBX2 the Move Request itself is not deleted. This has to be performed by the Administrator, either by using the Exchange Management Shell (Remove-MoveRequest) or by using the Exchange Management Console.

You can see the MRS run on the Client Access Server in the Windows Task Manager:

You can see the status of the move request by entering the following command in the Exchange Management Shell:

[PS] C:\download>Get-MoveRequest | ?{$_.status -eq “InProgress”}| Get-MoveRequestStatistics | ft Disp*,Per*,BytesTransferredPerMinute

DisplayName                 PercentComplete BytesTransferredPerMinute

———–                 ————— ————————-

Jaap Wesselius              66               134.2 MB (140,668,124 bytes)

Katie Price [HR Department] 66               119.9 MB (125,677,306 bytes)

[PS] C:\download>

The MRS is a throttled service, and it is fully configurable. There’s an MSExchangeMailboxReplication.exe.config file in the “C:\Program Files\Microsoft\Exchange Server\V14\Bin\” directory. You can use this config file to configure the throttling of the MRS by changing these entries:

• MaxActiveMovesPerSourceMDB
• MaxActiveMovesPerTargetMDB
• MaxActiveMovesPerSourceServer
• MaxActiveMovesPerTargetServer