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

This is much easier in Exchange 2007 than it was in Exchange 2003 as here we can use PowerShell. I would like to mention that in case of using Ex 2007, we don’t even have to create the users in advance, the server will take care of that for you. For the full 2007 PowerShell reference guide please see this page http://technet.microsoft.com/en-us/library/bb123703%28EXCHG.80%29.aspx#NthruR

In short, in order to create a new user type in:

New-Mailbox -Name <String> -Database <DatabaseIdParameter> -Password <SecureString> -UserPrincipalName <String> [-DisplayName <String>] [-FirstName <String>] [-Initials <String>] [-LastName <String>]

You might notice that if you simply type a string in for the password you’ll get an error:

New-Mailbox : Cannot bind parameter 'Password'. Cannot convert value "[given_password]" to type "System.Security.SecureString". Error: "Invalid cast from 'System.String' to ‘System.Security.SecureString'."

The reason for this is that the given password has to be a secure string type. In order to create it, type in the following (has to be separate from the previous command):


$Password = ConvertTo-SecureString '<string>' -AsPlainText –Force

After this you could refer to the given password as $Password.

We usually use this command in two different ways. The first one is to use a scripting language (my preference is Python) to generate the commands with different names. I have a list with the thousand most popular first names and the thousand most popular surnames. My script simply combines the two, giving me quite a lot of options. The second method is to name the users using a counter such as User 1; User 2;… User n and use a cycle in PowerShell to generate all required user names, such as:

$Password = ConvertTo-SecureString '<password>' -AsPlainText –Force

for ($i=0; $i -le 10; $i++)

{

New-Mailbox –Name <name>$i -Database <dbname> -Password $Password -UserPrincipalName <UPname> -DisplayName "<name> $i" -FirstName <firstname> -LastName $i

}

If someone doesn’t like PowerShell or doesn’t have it (e.g. Exchange 2003), the batch files I mentioned earlier used in active directory work just fine. After creating the users using those the mailboxes can be assigned to them fairly easily. In Exchange 2007, we have to start the “create new mailbox” process and select “existing users” in the first window.

This will show all users in AD that don’t have mailboxes. Fortunately multiselection is allowed so we don’t have to handle them one by one. Exchange 2003 doesn’t have this feature but there’s an easy workaround. Do a search using Exchange 2003’s Active Directory Users and Computers application for all users and multiselect them. Right clicking once will open the context menu where we can select “Exchange tasks” and “Create exchange mailbox” from there.

Finally, the command to add full access rights to a specific user so all mailboxes could be opened (and managed) from one outlook:

foreach ($sg in Get-StorageGroup) { if ((Get-ExchangeServer
$sg.Server).Domain.Equals("DomainName.com")) { get-mailboxdatabase
-storagegroup $sg.Identity | add-adpermission -user UserName
-accessrights GenericAll; } }

How Does it Work?

The MyDistributionGroups management role is one of the built-in RBAC roles in Exchange 2010. This role gives end-users the ability to modify, view, remove, and add members to distribution groups they already own. In addition, the MyDistributionGroups Role provides the ability to create new distribution groups.

An end-users ownership of a group is designated by adding their account to the “Managed By” property of a distribution group. It is also set when the user creates a distribution group in ECP, once they’ve been assigned the MyDistributionGroups role.

Allowing users to add and remove distribution groups may not be desirable depending on your requirements, but keep reading, we’ll look at how you can restrict this later.

Assigning the MyDistributionGroups Role using ECP

To enable distribution group management for end-users, you first need to assign them the MyDistributionGroups role. The MyDistributionGroups role is considered a user role, and therefore is assigned using a Role Assignment Policy. By default, the MyDistributionGroups role is not added to the Default Role Assignment Policy, but you can use ECP to do this using the following steps.

Step 1. Log into OWA with an administrator account and click on Options in the top right corner.

Step 2. In the Select what to manage drop down, select My Organization and then click on User Roles.

Step 3. Highlight the Default Role Assignment Policy and then click the Details button.

Step 4. Under Roles You Can Assign, check My Distribution Groups.

Assign the MyDistributionGroups Role using EMS

You can also assign the MyDistributionGroups Role to the Default Role Assignment Policy using EMS. Use the New-MangementRoleAssignment cmdlet to perform the operation as shown here:

New-ManagementRoleAssignment -Role MyDistributionGroups -Policy "Default Role Assignment Policy"

Once you’ve added the MyDistributionGroups role to the Default Role Assignment Policy, your users will be able to manage their own distribution groups.

Creating and Assigning a Custom “Locked Down” Role

So, what if you only want users to manage the groups they own, and you do not want them adding or removing groups? Well, in that case you would need to create a custom role and add it to the Default Role Assignment Policy. The process for doing this is outlined in the following steps.

Step 1. First, you need to create a new child role based on the existing MyDistributionGroups role. In this example I’ll call the role “OwnerDistributionGroups”, but you can use whatever name makes sense in your environment. Use the following syntax to create the role:

New-ManagementRole -Name OwnerDistributionGroups -Parent MyDistributionGroups

Step 2. Next, you need to remove the New-DistributionGroup and Remove-DistributionGroup cmdlets from your new custom role. You’ll use the Remove-ManagementRoleEntry cmdlet to do this, as shown below:

Remove-ManagementRoleEntry OwnerDistributionGroups\New-DistributionGroup -Confirm:$false

Remove-ManagementRoleEntry OwnerDistributionGroups\Remove-DistributionGroup -Confirm:$false

Step 3. Now that you’ve got the custom role created and customized to meet your requirements, you can assign it to the Default RoleAssignment Policy using the New-ManagementRoleAssignment cmdlet:

New-ManagementRoleAssignment -Role OwnerDistributionGroups -Policy "Default Role Assignment Policy"

At this point, users will be able to manage the groups they own, but they will not be able to add or remove new groups.

Summary

Allowing users to create, add and remove their own distribution groups can be a big decision for some organizations. If you plan on enabling distribution group management, you may allow end-users to add and remove their own groups, or you may choose to keep it locked down. Either way, you now have more options with RBAC.

Are you planning to use the Personal Archive feature in Microsoft Exchange 2010 to get rid of all those nasty PST files on your network?

In a way, it is a reasonable call: with the secondary mailbox of Exchange 2010, your users will not need to generate PST files to try and comply to their mailbox quota limits….
… but you now have a new dilemma: what do you do with all the PST files already spread over your network?

Here are your options:

1. Do nothing –> I wish you good luck next time one of your end users contacts you because they lost a VERY IMPORTANT email.
2. Let your users import manually (or not) their PST files into exchange –>  Go to 1)
3. Take action to deal with this PST hell –> import them into Exchange yourself.

Sadly, Microsoft doesn’t make the import easy to do. For some reason, they got rid of the functionality in the Exchange Management Console GUI, and we are left with just a cmdlet, that is apparently rather  clumsy.

This is why Red Gate Software are currently developing a tool for a PST search and import into Exchange 2010. It is based on the existing PST Importer tool developed to complement Exchange Server Archiver, but works independently with Exchange 2010. It is still work in progress, but here is a preview of the tool:

Step 1 (optional if you know where your PST files are located): Find the PST files on your network, via a 4 step wizard.

Step 1: Find the PST files on your network.

Step 2: Search is completed (in this case returned 4 files) . Select the files you want to import, and click “New import list” to initiate the import.

Step 2: Search is completed (in this case returned 4 files)

Step 3: Set the destination mailbox. In this case, we automatically select the PST file owner, Anne.

Step 3: Set the destination mailbox

Step 4: Click “Import all now” to start the import.

Step 4: Start the import.

Et voila, now Anne can access her PST files in Outlook:

PSTs are imported and visible in Users’ Outlook mailboxes

So what do you think? Better or worse than a cmdlet? Post your opinion here! We’d love to hear your thoughts – the good, the bad, and the ugly.

How is this possible? Could it be that single instance storage never really had real benefits? Or maybe because it had been weakened in 2007 (so that only attachments within a storage group were single-instanced), we already paid the tax?

Well, the mystery has been solved: in Exchange 2010, MS introduced compression. In more detail,

“As a result of the new architecture and the other changes to the store and ESE, we had to deal with an unintended side effect. While these changes greatly improved our IO efficiency, they made our space efficiency worse. In fact, on average they increased the size of the Exchange database by about 20% over Exchange 2007. To overcome this bloating effect, we implemented a targeted compression mechanism (using either 7-bit or XPRESS, which is the Microsoft implementation of the LZ77 algorithm) that specifically compresses message headers and bodies that are either text or HTML-based (attachments are not compressed as typically they exist in their most compressed state already). The result of this work is that we see database sizes on par with Exchange 2007.”

http://msexchangeteam.com/archive/2010/02/22/454051.aspx

So! It seems that Microsoft has not been as off-hand with our storage as it seemed. The message from Redmond has mostly been, ‘Ah, storage is cheap – and even cheaper for Exchange 2010 – so losing SIS isn’t a big deal.’

But, heart-warmingly, they were looking out for our storage needs all along.… which makes me wonder, why the shyness about the compression? Yes, there will be a performance tax, but most Exchange servers are not performance-limited by the processor.

Is there some other disadvantage to compressing messages in the Exchange database? I can’t think of one.

What’s ‘large’?

If I ask you, ‘Does my butt look big in this?’ you know what I mean (and how to answer).  You might also think you know what I mean by, ‘Is my Exchange mailbox large?’  but by Microsoft’s definition, you’re probably wrong.

When the Microsoft Exchange team says ‘large mailbox,’ they don’t mean one that takes up a lot of space;  they mean one with a large number of messages in a single folder.

In other words, I can have 2000 messages each with a 4MB attachment, making an 8GB mailbox, and that is not large.  But if I have a mailbox with 17,135 items in the Inbox which take up 564Mb*,  that is getting large by current MS standards.

What goes wrong with large mailboxes?

According to MS, performance starts to suffer when the number of messages exceeds a certain limit, especially in ‘critical path’ folders like Inbox or Sent Items.

Importantly, Exchange performance for a single mailbox does not depend on the size of the mailbox.  In this Exchange sizing spreadsheet from MS, it shows that limits on the number of messages per folder, but no mention of total data size.

Table:  recommended limits for number of items in a mail folder

So what can you expect?  You get to 20,000 messages and everything hangs?  Not at all.   Normal  functions of reading and sending mail should behave fine.

According to the article Understanding Database and Log Performance Factors, the acknowledged performance issue is very specific:

• IF you have an Exchange 2007 server
• AND the end user is using OWA or Outlook in online mode
• AND this user sorts a folder with 20,000+ items differently
• THEN the system may be unresponsive.

Sorting hammers the Exchange server, and that, according to Microsoft, is the major scalability limitation.

What, that’s it?

Even I, a serial hoarder, don’t think that 100,000 messages in my Inbox is a happy thought.   More like a doomsday scenario.

What else in Exchange 2010 facilitates the ‘large mailbox’ ideal?  According to a Microsoft White Paper, Large Mailbox Vision (where now ‘large’ means large on disk)  the main limit on mailbox size is the expense of storage.  Therefore, they are ‘solving’ the problem of large mailboxes by database format changes that mean the Exchange server no longer needs to run on high-end storage.

By removing single instancing and introducing compression, the number of I/O operations has decreased to such an extent that you can use cheaper storage for your Exchange mailboxes (I’m oversimplifying here, but only a little).

Does that reduction in I/O operations help scalability?  In most cases, no.

If your users are running Outlook in cached mode, there is basically no relationship between the I/O load on the server and the size of mailbox possible.  Current mail accounts for most of the I/O burden.  Older data sits mostly unaccessed on the server.  The spec of the client machine has a much bigger effect on the end-user experience…..

Outlook Scalability Improvements

For anyone running Outlook in cached Exchange mode, the properties of OST files, not the Exchange server, make the biggest difference for large mailboxes.

Late in Outlook 2007,  there were major changes to the OST/PST file format to improve performance and scalability (countering major degradations introduced earlier in 2007).  Although this increases the file size on disk by about 20%, the responsiveness should be worth it.

No firm guidelines on maximum number of messages exist for Outlook, but this article on performance problems promises good performance for common actions like switching folders, even for ‘tens of thousands of items in a single folder.’

MS has also released some sizing guidelines, which apply to Outlook 2007 SP1 with the February 2009 cumulative update or higher (including Outlook 2010). These sizes are about 2.5x previous size limits  for similar performance:

• [PST/OST files] Up to 5 gigabytes (GB): This size should provide a good user experience on most hardware.
• Between 5 GB and 10 GB: This size is typically hardware dependent. Therefore, if you have a fast hard disk and much RAM, your experience will be better. However, slower hard drives, such as drives that are typically found on portable computers or early generation solid state drives (SSDs), experience some application pauses when the drives respond.
• More than 10 GB: This size is where short pauses begin to occur on most hardware.
• Very large, such as 25 GB or larger: This size increases the frequency of the short pauses, especially while you are downloading new e-mail. As described above, you can use Send/Receive groups to manually sync your mail.

Bear in mind, though, that an OST can be much larger than the reported mailbox size in Exchange; according to this MS KB, “if the mailbox size is 350 megabytes (MB), the .ost file size can be 475 MB or larger.”

Another major performance consideration is whether you keep the OST/PST files on a network share.  According to a KB describing the recent Outlook 2007 improvements, ‘This configuration is not supported by Microsoft and is known to cause performance issues generally. There are no workarounds or improvements planned….’

Summary

Effectively, Microsoft is telling us that since 2007, Exchange has had no problem with large (in disk space) mailboxes.  Apart from the relatively unusual case of users with more than 20,000 files per folder, the major issue was cost, plain and simple.

On the Outlook side, there are some limitations.  As the mailbox grows past 5Gb, degradations in cached Outlook performance creep in.

Importantly, though, this is the same for Exchange 2007 and Outlook 2007 SP2 as for 2010. There is no word of any improvements to support large mailboxes in Exchange 2010 and Outlook 2010, apart from for folders with more than 20,000 messages.

I hear all the time that ‘Exchange performance is slow because this mailbox takes up <number> Gb,’ but Microsoft says this does not happen.   I would love to hear from you if you can prove them wrong!

* my actual total at the time of writing this.  I’m not proud.