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

how to earn money fast

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.