Microsoft releases updates for Exchange 2007, 2010, 2013

Today, Microsoft released its latest updates for Exchange 2007, 2010 and 2013.

The updates for Exchange 2007 and 2010 mostly evolve around the Daylight Saving Time changes and a bunch of fixes for the latter version.

Cumulative Update 6 for Exchange 2013 doesn’t introduce any new feature or feature changes, but I’m happy to see that the Hybrid Configuration Wizard bug – which caused the HCW to fail – is now included by default. An Interim Update was already available, but it’s nice to see it included into the full build.

Along with a bunch of other fixes, Cumulative Update 6 now also closes the gap with Office 365 when it comes to Public Folder performance and scalability: you can now also deploy up to 100,000 public folders on-premises. Along with this change, there are some other (minor) behavioral changes which Microsoft outlined beautifully here.

For more information on these updates, have a look at the following announcements for Microsoft:

Exchange 2013

Some thoughts on using the Exchange Integration Pack for Orchestrator…

Recently a customer decided to start using System Center Orchestrator to automate some of the recurring tasks with regards to the management and support of their Exchange organization. More specifically, they wanted to create a custom interface to which the support organization would get access to in order to request specific actions like mailbox moves, message tracking logs etc. This would allow them to execute some (basic) tasks themselves without needing any Exchange permissions or being forced to use PowerShell or the Exchange Management Console.

In fact, Orchestrator is very powerful when it comes down to automating things like this. The Integration Packs for products like Exchange, Active Directory and SharePoint allow you to easily develop such solutions.

What is described below are merely some thoughts I had while building the solution along with a colleague of mine. I’m in no way an expert in the use of Orchestrator, but that’s why I thought this information might be interesting to you.

Before diving into the quirks which may (or may not) be “by design”, let’s have a look at what we were trying to build.

The solution

The customer wanted to have a custom interface (not specified what it needed to be) which would allow members of the Service Desk to request message tracking information without the need for an Exchange administrator to intervene. After some debates on whether or not PowerShell should be leveraged to develop such a GUI, we decided to move forward using SharePoint lists. SharePoint lists are easy to setup and use and because it was already heavily used within this organization, it seemed like the logical step.

In order not to complicate things, we decided that we would ask the support engineer for the following information:

  • Sender Email Address
  • Recipient Email Address
  • Date + Time (hour)

 To enter the information into the SharePoint list, a custom form was created which also took care of data validation. As such, the engineer would be able to enter only a sender address, a recipient address or both. The date + time are always required and needed to be in a specific format (yyyy-mm-dd). The reason why we chose to do data validation in the form is two-fold. First, it’s extremely easy to do and secondly, it would save us quite a bit of code later on when building the solution in Orchestrator. The date + hour indication are used to indicate for what time the message tracking logs are requested. We found that 95% of all requests all were within a 24 hour timespan. That’s why the code we built (more about that later) would look in the message tracking logs 12 hours before and 12 hours after the indicated time.

Whenever an engineer would enter a new item in the list, it should automatically get processed by Orchestrator which would then fetch the information from the Message Tracking logs and write it to a CSV file which would be attached to the list item in SharePoint when finished processing.

All-in-all, the requirements were are pretty straight forward which should make the final solution relatively easy to build. In order to meet these requirements, we needed to following components in Orchestrator:

  • SharePoint Integration Pack
  • Exchange Integration Pack
  • Active Directory Integration Pack

Below is a screenshot of the actual runbook which we built:


As you can see, it’s not the most advanced runbook (and maybe not the most efficient either). However, it does the trick. As you will notice, we did built in some logging (in order to have a history what happened) and also do some data validation using the built-in capabilities of Orchestrator.

The quirks

Monitor Item Lists activity

The first problem we came across was using the “Monitor List Items” activity. When first adding this activity to the runbook, it automatically detects all the fields in the list and allows you to use them throughout the runbook as published data from that activity:


The problem, though, is that – for some reason – it doesn’t pick up changes made to the list after the activity has been added to the runbook. When you have designed your SharePoint list to have all the necessary fields from the get-go, this probably isn’t much of an issue. In our case, unfortunately, the customer tends to changes his mind once in a while…
No matter what we tried, newly added fields would not show up in the published data for that activity. The only workaround is to remove the activity and add it again. While this might work for very simple workflows, in larger workflows – like the one above – dealing with this is particularly painful. Especially because the published data from the activity is used in multiple places. This means that when you remove/re-add the activity, you have to go in to all the other activity where you referenced the data and ‘reconfigure’ it. Again, this is not a big problem if you know this up front, but it can cost you some time if you decide to make changes to the SharePoint list. So one word of advice: plan carefully!

Exchange Management Shell code

The Exchange Integration Pack allows you to directly run a bunch of Exchange PowerShell commands when you add the Run Exchange Management Shell activity. Pretty easy, right?!  Not really. As it turns out, not everything you can do in the Exchange Management Shell works in this activity.

For instance, in the Exchange Management Shell, the following code would work beautifully:

[code language=”powershell”]Get-TransportServer | Get-MessageTrackinglog[/code]

Bizarrely enough, this won’t work here. Instead, you have to break the pipeline as follows:

[code language=”powershell”]$servers = Get-TransportServer
$servers | Get-MessageTrackingLog[/code]

My best guess is that the runbook activity is already executing a pipeline which limits what you can do with it. Again, this isn’t a big problem. But it’s just something to keep in mind when developing code to be used in Orchestrator.

Here’s the code I (we) used:

[code language=”powershell”]#Defining Variables

$Subject = "{MT-Subject from "Monitor List Items"}"
$Sender = "{MT-Sender from "Monitor List Items"}"
$Recipient = "{MT-Recipient from "Monitor List Items"}"
$data = "{MT-Date from "Monitor List Items"}"
$Hour = "{MT-Hour from "Monitor List Items"}"

#Check Date Input
[datetime]$inputdate = $date+" "+$Hour+":00:00"
[datetime]$startDate = $inputdate.AddHours(-12)
[datetime]$endDate = $inputdate.AddHours(+12)
$returnMsg = "Input date format invalid"

#Convert DateTimes back into usable format
$strStartDate = $startDate.ToString("yyyy/MM/dd HH:mm:ss")
$strEndDate = $endDate.ToString("yyyy/MM/dd HH:mm:ss")

#Construct cmdlet
$cmd += "Get-MessageTrackingLog -Server `$_.Name"

if($Subject -ne $null -and $Subject -ne ""){
$cmd += " -MessageSubject `"$Subject`""
if($Sender -ne $null -and $Sender -ne ""){
$cmd += " -Sender `"$Sender`""
if($Recipient -ne $null -and $Recipient -ne ""){
$cmd += " -Recipient `"$Recipient`""

$cmd += " -Start `"$strStartDate`""
$cmd += " -End `"$strEndDate`""

#workaround for Orchestrator limitation (limitation while executing pipeline)

$servers = Get-TransportServer
$result = $servers | %{
Invoke-Expression $cmd

$result | Select EventID,Source,Sender,Recipients,MessageSubject,MessageID[/code]

Exchange Management Shell code output

This is probably the biggest quirk we had to deal with. When you execute code within Orchestrator, the output from the code is then pushed to the next activity (provided that you subscribed to the data, of course). In this case, if multiple results came back from the Exchange Management Shell activity, it would fire the following activity for each result. To avoid this and to bundle the results and send them off to the next activity as a whole, you need to “flatten” the output first:


That was easy, wans’t it…? Well, that wasn’t really the problem either. When you take a closer look at the symbol used for separating the results, you’ll notice that we reverted to using a rather rarely used symbol. There’s a specific reason.

Here’s why: for some (stupid) reason, the results which are returned by the EMS runbook activity look like the following:

“[EventId: RECEIVE]
[Source: SMTP]
[MessageSubject: email, please add me to your LinkedIn network]
[MessageId: somethinghere@somethingelse]
,[EventId: SEND]
[Source: SMTP]
[MessageSubject: email, please add me to your LinkedIn network]
[MessageId: somethinghere@somethingelse]”

No this is not a weird way of display a hash table, it’s literally a large string which is passed on. This makes it incredibly difficult to deal with. In fact, there is no way that you can just push this into a CSV file and make something useful out of it without dealing with the output first.

A quick look on the internet, brought me to the following article:

The author of that article suggested to parse the code and to convert the output into something usable. This seemed fair enough to me and I decided to re-use the code (although I needed to modify it to make it work in our case). This was then added to a second activity called “Convert Output” which is the “Run .NET Script” runbook activity. Here’s the code I used:

[code language=”powershell”]$inputText = "{Command Output for "Get MessageTracking Results"}"

if($inputText -ne ""){

$collection = $inputText.Split("¶")
$returnCollection = @()
foreach ($item in $collection)
$keypairCollection = $item.Split("`n")

$EventID = $keypairCollection[0].Trim().TrimStart("[").TrimEnd("]").TrimStart("EventId: ")
$Source = $keypairCollection[1].Trim().TrimStart("[").TrimEnd("]").TrimStart("Source:").TrimStart(" ")
$Sender = $keypairCollection[2].Trim().TrimStart("[").TrimEnd("]").TrimStart("Sender: ")
$Recipients = $keypairCollection[3].Trim().TrimStart("[").TrimEnd("]").TrimStart("Recipients: ")
$MessageSubject = $keypairCollection[4].Trim().TrimStart("[").TrimEnd("]").TrimStart("MessageSubject: ")
$MessageId = $keypairCollection[5].Trim().TrimStart("[").TrimEnd("]").TrimStart("MessageId: ")

$obj = New-Object -TypeName PSObject
Add-Member -InputObject $obj -MemberType NoteProperty -Name "EventID" -Value $EventID
Add-Member -InputObject $obj -MemberType NoteProperty -Name "Source" -Value $Source
Add-Member -InputObject $obj -MemberType NoteProperty -Name "Sender" -Value $Sender
Add-Member -InputObject $obj -MemberType NoteProperty -Name "Recipients" -Value $Recipients
Add-Member -InputObject $obj -MemberType NoteProperty -Name "MessageSubject" -Value $MessageSubject
Add-Member -InputObject $obj -MemberType NoteProperty -Name "MessageId" -Value $MessageId

$returnCollection += $obj
$output = $returnCollection | convertto-csv -delimiter ";"
[string]$output = "No messages could be found with the specified parameters."

You might still wonder why I had to use the ¶ symbol as a delimeter for the output from the “Get MessageTracking Results” activity… The problem with parsing the code is that you have to split the individual results returned by the activity. Using a regular comma or semi-colon is out of the question as it’s quite likely that the subject for a message contains that same character which would cause the output conversion to fail (I found out the hard way). So we needed to decide on a symbol which allowed us to safely parse the code. Hence the ¶ symbol. For now, this does mean that if someone uses the ¶ symbol in the subject and it is returned by the message tracking logs, the above code will fail and there won’t be any output for the message tracking request.

If you have a better alternative: feel free to comment and let me know!

Some final thoughts

All in all, Orchestrator proves to be quite a flexible platform to perform tasks like the one described in this article. Especially the combination with SharePoint makes it very easy to build ‘custom’ tools which can be used by anyone without needing to provide them with permissions in Exchange (even though RBAC provides a nice framework to do just that). I only wish that some of the quirks got solved as it will remove the need for additional steps (and code) which only add complexity…

Exchange 2013 PowerShell

Microsoft releases Exchange 2013 Cumulative Update 5 and Exchange 2010 Update Rollup 6

Today, Microsoft released Cumulative Update 5 for Exchange 2013 and Update Rollup 6 for Exchange 2010.

Exchange 2013 Cumulative Update 5

Next to a ton of bug fixes, Microsoft made changes to a few components including:

  • Offline Address Book generation
  • Hybrid Configuration Wizard

Except for the above changes, it looks like CU5 will mostly consist of fixes. By the looks of it and as Tony Redmond already pointed out CU5 promises to be a stable release. Whether it will stay that way is something only time will tell…

Installing Cumulative Update 5

Installing CU5 is no different from older versions. You can also immediately upgrade from any previous version of Exchange 2013 to CU5. There is no requirement to install SP1 (a.k.a. CU4) first.

After installation, Microsoft warns there might be a Managed Availability probe which went into overdrive and repeatedly restarts a newly added service called the Microsoft Exchange Shared Cache Service. However, this service isn’t used in CU5 (planned for the future?) and as such there is no impact at all.

However, if you are worried about your application log filling up with events from Managed Availability, you can disable the probe. More information can be found here.

This update also includes Active Directory changes, so you will be required to extend the AD schema. Given that you’re used to it by now, this shouldn’t present much of a problem. For more information on how to deploy a Cumulative Update, I suggest you have a look at the following article by ExchangeServerPro: 

Installing Cumulative Updates and Service Packs for Exchange Server 2013

You can download Cumulative Update 5 from here. The original release announcement is here.

Exchange 2010 Update Rollup 6

This update seems mainly to be a routine update to Exchange 2010. As expected, there are no major revelations except for a bunch of updates and fixes:

  • 2960652 Organizer name and meeting status field can be changed by EAS clients in an Exchange Server 2010 environment
  • 2957762 “A folder with same name already exists” error when you rename an Outlook folder in an Exchange Server 2010 environment
  • 2952799 Event ID 2084 occurs and Exchange server loses connection to the domain controllers in an Exchange Server 2010 environment
  • 2934091 Event ID 1000 and 7031 when users cannot connect to mailboxes in an Exchange Server 2010 environment
  • 2932402 Cannot move a mailbox after you install Exchange Server 2010 SP3 RU3 (KB2891587)
  • 2931842 EWS cannot identify the attachment in an Exchange Server 2010 environment
  • 2928703 Retention policy is applied unexpectedly to a folder when Outlook rule moves a copy in Exchange Server 2010
  • 2927265 Get-Message cmdlet does not respect the defined write scope in Exchange Server 2010
  • 2925273 Folder views are not updated when you arrange by categories in Outlook after you apply Exchange Server 2010 Service Pack 3 Update Rollup 3 or Update Rollup 4
  • 2924592 Exchange RPC Client Access service freezes when you open an attached file in Outlook Online mode in Exchange Server 2010
  • 2923865 Cannot connect to Exchange Server 2010 when the RPC Client Access service crashes

You can download Rollop Update 6 from here.

Microsoft’s original release announcements can be found here.

Blog Exchange Exchange 2013 News

You get an error “StalledDueToMailboxLock” when moving mailboxes to Office 365 in a hybrid configuration.

Recently, a customer of ours experienced an issue while moving mailboxes to Office 365 in a Hybrid Configuration. After the move request was generated, they would end up with a status “StalledDueToMailboxLock” after a short while. The move request would then stay in that state for an indefinite amount of time.

Although I wasn’t able to test everything myself, first hand, a certain mailbox move was reported to proceed after been in the “StalledDueToMailboxLock” for about 2 days. Obviously, this isn’t the pace you’d want your mailboxes to be moved to Office 365 and some further investigation is needed.

Before any “deep” troubleshooting was done, we checked if there wasn’t something that could cause a mailbox lock, maybe a process that was blocking access to the mailbox like a misconfigured Anti-Virus. However, we soon found out that everything seemed normal…


Whenever a move requests fails or seems to be hanging in a specific state for a while, it’s always a good idea to take a look at the Move Request Statistics using “Get-MoveRequestStatistics”:

Get-MoveRequest <Identity> | Get-MoveRequestStatistics –IncludeReport | fl

The command above will immediately output the results on-screen. However, for requests that have been running for a while, the amount of information from the command is too much to handle through the console. As an alternative, you can either output it to e.g. a text file using Out-File or – and in my opinion this is much easier to handle – export it to an XML file using the Export-Clixml command:

Get-MoveRequest <Identity> | Get-MoveRequestStatistics –IncludeReport | Export-Clixml c:\moverequeststats.xml

Now, you can open that XML file in a more specialized XML-reader (or just Internet Explorer if you want) and go through its content.


In this particular case, the problem was caused by Exchange Web Services. Somewhere in the XML file (and multiple times), you’d find the following reference:

<S N=”Message”>Communication with remote service ‘ CAS1.fqdn ( caps:05FFFF)’ has failed. –&gt; The call to ‘ CAS1.fqdn ( caps:05FFFF)’ failed. Error details: The remote endpoint no longer recognizes this sequence. This is most likely due to an abort on the remote endpoint. The value of wsrm:Identifier is not a known Sequence identifier. The reliable session was faulted..

Similarly, we also found the exact same reference, but for another CAS:

<S N=”Message”>Communication with remote service ‘ CAS2.fqdn ( caps:05FFFF)’ has failed. –&gt; The call to ‘ CAS2.fqdn ( caps:05FFFF)’ failed. Error details: The remote endpoint no longer recognizes this sequence. This is most likely due to an abort on the remote endpoint. The value of wsrm:Identifier is not a known Sequence identifier. The reliable session was faulted..

This points out that the move request was trying to connect over different Client Access Servers. However, when keeping in mind the load balancing requirements for Exchange 2010, it’s clearly stated that using EWS without affinity is not supported:

Exchange Web Services   Only a subset of Exchange Web Services requires affinity. Availability Service requests don’t require affinity, but subscriptions do. All aspects of Exchange Web Services experience performance enhancements from affinity. An affinity timeout value of 45 minutes is recommended for Exchange Web Services clients to ensure that periodic polling for events associated with a subscription are not directed to a new Client Access server resulting in inefficient new subscriptions for each request. We don’t support the use of Exchange Web Services without affinity.

Edit note: as you might’ve guessed, this problem happened because on-premises an Exchange 2010 hybrid server was used. If that would’ve been an Exchange 2013 environment, this wouldn’t have happened as there’s no need to keep affinity for EWS.


So, because of this, we took another look at the load balancer configuration. To confirm whether or not it was the load balancer causing the issue, we temporarily bypassed them and connected directly to one of the CAS servers after which we found out that the move requests processed successfully.

The efforts now turned back to the Load Balancer and it was found out that the affinity for EWS, which was configured in the first place, wasn’t applied correctly. After correcting the settings in the Load Balancers everything worked as expected.


I would like to thank William Rall (MSFT) for his efforts and time. He quickly pointed out the root cause, which helped us determine what caused the problem. His feedback also allowed me to dive deeper into the XML and find what I was looking for. Admitted: diving into the XML without actually knowing what to look for, isn’t always easy!

Blog Exchange Hybrid Exchange

Exchange 2010 Service Pack 3 has been released!

Microsoft just released the long-anticipated release of Service Pack 3 for Exchange 2010. Many of you have been waiting impatiently for this Service Pack as it brings you one step closer to deploying Exchange 2013!

Yes, you read it well: one step closer. As a matter of fact. Exchange 2010 SP3 will allow you to coexist with Exchange 2013 Cummulative Update 1. Given that CU1 isn’t available just yet, you’ll have to be a little more patient… If you want more information, have a look at this article for the Exchange Product Group >

You can download the Service Pack from here:

A word of caution!

It seems that Service Pack 3 will also update the database schema of your databases. Once a database schema has been updated to SP3 you can no longer mount them on a pre-SP3 Mailbox Server. This means that you have to be particularly careful when updating Mailbox server that are part of a Database Availability Group!

Make sure to review the release notes before upgrading in your production environment:

If you’re looking for more information on what’s new in Service Pack 3, have a look here:

Have fun!


Exchange 2013

New Exchange 2007/2010 Rollup Updates released!

Today, Microsoft released the following updates for Exchange 2007 and Exchange 2010:

  • Exchange 2010 Service Pack 2 Update Rollup 6 (KB2746164)
  • Exchange 2007 Service Pack 3 Update Rollup 10 (KB2788321)

Exchange 2010 Service Pack 2 Update Rollup 6

This updates contains many, many fixes amongst some quite important ones! However it’s still not the Exchange 2013 coexistency-update you have all been waiting for! Rumors are, however, that Service Pack 3 is waiting just around the corner…

I’ve highlighted some of my personal favorite fixes in this release by going through the list. I will dive deeper into it when I had the chance to review them more thoroughly.

Fixes/updates included in the Update Rollup are:

  • 2489941 The "legacyExchangeDN" value is shown in the "From" field instead of the "Simple Display Name" in an email message in an Exchange Server 2010 environment

  • 2717453 You cannot move or delete a folder by using Outlook in online mode in an Exchange Server 2010 environment

  • 2733608 Corrupted Japanese DBCS characters when you send a meeting request or post a reply to a posted item in a public folder in an Exchange Server 2010 environment

  • 2734635 Folder-associated information (FAI) items are deleted when you run the New-InboxRule cmdlet or change Inbox rules in an Exchange Server 2010 environment

  • 2737046 AutoPreview feature does not work when you use Outlook in online mode in an Exchange Server 2010 environment

  • 2741117 High CPU utilization by Microsoft Exchange Replication service on Client Access servers in an Exchange Server 2010 environment

  • 2746030 Incorrect ExternalURL value for EWS is returned by an Exchange Server 2010 Client Access server

  • 2750188 Exchange Service Host service crashes when you start the service on an Exchange 2010 server

  • 2751417 Synchronization fails if you sync an external device to a mailbox through EAS in an Exchange Server 2010 environment

  • 2751581 OAB generation fails with event IDs 9126, 9330, and either 9338 or 9339 in an Exchange Server 2010 environment

  • 2760999 "The signup domain ‘org’ derived from ‘<TenantDomainName>.org’ is not a valid domain" error message when you use the Hybrid Configuration wizard in an Exchange Server

  • 2776259 Msftefd.exe process crashes if an email attachment has an unexpected file name extension or no file name extension in an Exchange Server 2010 environment

  • 2779387 Duplicated email messages are displayed in the Sent Items folder in a EWS-based application that accesses an Exchange Server 2010 Mailbox server

  • 2783586 Name order of a contact is displayed incorrectly after you edit the contact in an Exchange Server 2010 environment

  • 2783631 User-Agent field is empty when you run the Get-ActiveSyncDeviceStatistics cmdlet in an Exchange Server 2010 SP2 environment

  • 2783633 You cannot move or delete an email message that is larger than the maximum receive or send size in an Exchange Server 2010 environment

  • 2783649 Private appointment is visible to a delegate in an Exchange Server 2010 environment

  • 2783771 Mailbox on a mobile device is not updated when EAS is configured in an Exchange Server 2010 environment

  • 2783772 Edgetransport.exe process crashes after a journal recipient receives an NDR message in an Exchange Server 2010 environment

  • 2783776 You cannot perform a cross-premises search in a mailbox in an Exchange Server 2010 hybrid environment

  • 2783782 Error message when you use Scanpst.exe on a .pst file in an Exchange Server 2010 environment

  • 2784081 Store.exe process crashes if you add certain registry keys to an Exchange Server 2010 Mailbox server

  • 2784083 Week numbers in the Outlook Web App and Outlook calendars are mismatched in an Exchange Server 2010 environment

  • 2784093 SCOM alerts and event ID 4 in an Exchange Server 2010 SP2 organization that has Update Rollup 1 or later

  • 2784566 Exchange RPC Client Access service crashes on an Exchange Server 2010 Mailbox server

  • 2787023 Exchange Mailbox Assistants service crashes when you try to change a recurring calendar item or publish free/busy data in an Exchange Server 2010 environment

  • 2793274 A new option is available that disables the PermanentlyDelete retention action in an Exchange Server 2010 organization

  • 2793278 You cannot use the search function to search for mailbox items in an Exchange Server 2010 environment

  • 2793279 Exchange Server 2010 does not restart when the Microsoft Exchange Replication service freezes

  • 2793488 Internet Explorer freezes when you connect to the OWA several times in an Exchange Server 2010 environment

  • 2810616 Email message delivery is delayed on a Blackberry mobile device after you install Update Rollup 4 for Exchange Server 2010 SP2

  • Have a look at the following page for the official announcement:


Exchange 2007 Service Pack 3 Update Rollup 10

Compared to Update Rollup 6 for Exchange 2010 SP2, this update turns pale… There seems to be only a single (public) fix. Of course, one could argue that that might be a good thing of course!

Blog Exchange

Microsoft Released Exchange 2010 SP2 Update-Rollup 5 v2

After the latest debacle from Microsoft where Exchange 2010 SP2 UR5 got pulled due to a bug, Microsoft re-released the UR as version 2.

For more information on the UR, have a look at the following KB-article:

However, I would wait a few more days (even weeks) before deploying this update. It’s not that I do not trust Microsoft or the Exchange Product Group, but – for once – I’d like to make sure we’re not running into any other unexpected issues. After all, Microsoft has had a bad track record with the stream of latest Update Rollups of which some even had to be pulled more than once.

Additionally, make sure to read Tony Redmond’s blog on this subject. There’s an interesting analysis of the different fixes as well as some other thoughts worth reading through:

Note   next to Exchange 2010 SP2 UR5, Microsoft also released UR9 for Exchange 2007 SP3 ( and UR7 v3 for Exchange 2010 SP1 (

Read the original announcement from the Exchange product team here:

Blog Exchange

Exchange 2010 SP2 Update-Rollup 4 released

Earlier today, Microsoft released Update Rollup 4 for Exchange 2010 Service Pack 2.

The update includes a new feature as well as an important update that I would like to call out:

  • Calendar & Task (items) now support Retention Tags. Before this was not the case, as tags could only be applied to mail items/folders. Although tags for Calendar/Task (items) can only be configured by an Administrator (PowerShell), they will at least prove useful for companies that (heavily) rely on the use of Retention Policies to keep their mailboxes clean. If you are already using Retention Policies or are looking to implement them, there are some caveats to look out for when installing UR4. These items have been well described by Ross Smith IV in his article. I suggest you take a look at them.
  • a fix for a vulnerability in WebReady Document viewing that was recently reported. When the vulnerability was first reported, you were advised to temporarily disable this feature using the following command:
    [sourcecode language=”powershell”]Get-OwaVirtualdirectory | ?{$_.OwaVersion –eq ‘Exchange2007’ –or $_.OwaVersion –eq ‘Exchange2010’} | Set-OwaVirtualdirectory –WebReadyDocumentViewingOnPublicComputersEnabled:$False –WebReadyDocumentViewingOnPrivateComputersEnabled:$False[/sourcecode]

    After installing UR, you can safely re-enable the feature by using the following command:
    [sourcecode language=”powershell”]Get-OwaVirtualdirectory | ?{$_.OwaVersion –eq ‘Exchange2007’ –or $_.OwaVersion –eq ‘Exchange2010’} | Set-OwaVirtualdirectory –WebReadyDocumentViewingOnPublicComputersEnabled:$True –WebReadyDocumentViewingOnPrivateComputersEnabled:$True[/sourcecode]


Other updates/fixes that are included are:

  • 2536846  Email messages sent to a mail-enabled public folder may be queued in a delivery queue on the Hub Transport server in an Exchange Server 2010 environment
  • 2632409  Sent item is copied to the Sent Items folder of the wrong mailbox in an Exchange Server 2010 environment when a user is granted the Send As permission
  • 2637915 “550 5.7.1” NDR when an email message is sent between tenant organizations in a multi-tenant Exchange Server 2010 environment
  • 2677727  MRM cannot process retention policies on a cloud-based archive mailbox if the primary mailbox is in an on-premises Exchange Server 2010 organization
  • 2685001  Retention policies do not work for the Calendar and Tasks folders in an Exchange Server 2010 SP1 environment
  • 2686540  Journal report is not delivered to a journaling mailbox in an Exchange Server 2010 environment
  • 2689025  Performance issues when you use the light version of Outlook Web App in an Exchange Server 2010 environment
  • 2698571  Some email messages are not delivered when you set the MessageRateLimit parameter in a throttling policy in an Exchange Server 2010 environment
  • 2698899  Add-ADPermission cmdlet together with a DomainController parameter fails in an Exchange Server 2010 environment
  • 2700172  Recipient’s email address is resolved incorrectly to a contact’s email address in an Exchange Server 2010 environment
  • 2701162  User A that is granted the Full Access permission to User B’s mailbox cannot see detailed free/busy information for User B in an Exchange Server 2010 environment
  • 2701624  ItemSubject field is empty when you run the Search-MailboxAuditLog cmdlet together with the ShowDetails parameter in an Exchange Server 2010 environment
  • 2702963  The “Open Message In Conflict” button is not available in the conflict notification message in Exchange Server 2010
  • 2707242  The Exchange Information Store service stops responding on an Exchange Server 2010 server
  • 2709014  EdgeTransport.exe process crashes intermittently on an Exchange Server 2010 server
  • 2709935  EdgeTransport.exe process repeatedly crashes on an Exchange Server 2010 server
  • 2713339  Multi-Mailbox Search feature returns incorrect results when you perform a complex discovery search in an Exchange Server 2010 environment
  • 2713371  Throttling policy throttles all EWS applications in Exchange Server 2010
  • 2719894  The Microsoft Exchange RPC Client Access service consumes 100 percent of CPU resources and stops responding on an Exchange Server 2010 Client Access server
  • 2723383  Incorrect time zone in a notification when the Resource Booking Attendant declines a meeting request from a user in a different time zone in an Exchange Server 2010 environment
  • 2724188  A subject that contains colons is truncated in a mixed Exchange Server 2003 and Exchange Server 2010 environment
  • 2726897  Event 14035 or Event 1006 is logged when Admin sessions are exhausted in an Exchange Server 2010 environment

Please have a look at KB2706690 and MS12-058 for more information regarding the update.

The update can be downloaded from the following webpage:

Blog Exchange

Disappearing (online) archives after moving your mailbox to Office 365…

Office 365 offers great ways to enhance the functionalities of your on-premises deployment. By running the Hybrid Configuration Wizard (which Steve Goodman explains in this article) you can configure both environments to act as one; allowing you to make use of features such as e.g. Online Archives (EOA).

With Exchange Online Archives, your primary mailbox stays in your on-premises Exchange server, whereas the archive will – as the name might have given away – be hosted in Office 365. If you’re interested in finding out more about Online Archives, I suggest that you take a look at Bharat Suneja’s session at TechEd this year: “Archiving in the cloud with Exchange Online Archiving

The problem

To me, one of the most interesting things about a hybrid deployment is the flexibility it offers. You can put a few mailboxes in Office 365, try them out and move more to the service if you like it.

If you are looking to take that approach, this information might be interesting for you!

Imagine the following: you are trying out Office 365 and decide to use Online Archives to start with. You provision the archives and life is great! After a while you decide you want to use more and you decide to move some mailboxes to Office 365. However, after your users have been moved to Office 365 they start complaining that their archive is empty.

It seems that – although this scenario is supported – there are some issues with the provisioning process when you move a user to Office 365 that previously already had an Online Archive: it get’s “wiped”. At least, that’s how it looks like.

At first, I though the data would reappear after a while, so I made sure that I waited long enough. Unfortunately even after a few days, the archives was still empty.

I decided to do some tests, to make sure this wasn’t a standalone case. Perhaps something went wrong during the move. To my surprise, tests confirmed what was going on: although the archive contained items prior to the move, they are now empty.

To explain what happens, let me describe the process I used to reproduce this issue.

This first screenshot show the details of the on-premises mailbox that has a cloud-based archive (EOA) enabled. This archive contains 4 (test) items:


Afterwards, I moved the mailbox through the Exchange Management Console using the “New Remote Move Request”-wizard.

Because on-premises only a mailbox exists, you don’t have the option to move an archive (which is normal):

The move completed successfully, and after having waited long enough (DirSync etc.). I verified the mailbox’s settings:


The interesting part here is that the Archive, although having the same GUID, appears to have been moved to the same database as the mailbox. Before the archive resided in database “EURPRD04DG032-db055” whereas now it’s in “EURPRD04DG030-db041”.

To ascertain myself that this wasn’t causing problems, I decided to do another test. When executing the MoveRequest, I specified to what database the archive should be moved to. I made sure that the target database of the Online Archive was set to the database it was already residing in before moving the mailbox:
[sourcecode language=”powershell”]New-MoveRequest “Testmivh5” –RemoteHostName “” –targetdeliverydomain “” –&lt;strong&gt;ArchiveTargetDatabase &lt;/strong&gt;“EURPRD04DC032-db055” –RemoteCredential Get-Credential)[/sourcecode]

Note   this cmdlet was executed from a remote PowerShell connection to Exchange Online.

After the move completed (successfully btw), I – again – waited long enough for DirSync/replication/provisioning to occur. I deliberately didn’t force DirSync to ensure that wasn’t causing any issues either. But alas, none of that helped: the archive was again empty.

A quick look at the object’s attributes revealed that – although a target database parameter was provided – the archive still got moved to the same database as the user:


Then, I was thinking that the ‘old’ archive perhaps got disabled and that a new one was created. Although this would be strange since the GUID of the archive remains the same, I thought it was worth a try. Again: no joy! No disconnected mailboxes were to be found.

After all this testing, I had reasons enough to call Microsoft Support. After a few calls back and forth, they recently came back to me confirming that this is a known issue and that they’re currently working on it.

Until today I’m still not sure what the cause of the problem is. I haven’t received any feedback yet either. Of course, I will keep you posted as soon as I find out more!

Temporary workaround

It might sound too obvious, but the workaround is simple: either create both archive and mailbox in the cloud or create the (both!) on-premises first and move them together to the cloud. Both cases work just fine!


Although the last thing you’d want to experience is data-loss, I’m well aware that only a few customers, world-wide, would try this scenario. Nevertheless, it’s an issue that should be addressed quickly.

In our case, we have lost only a single archive worth a few hundred megabytes of emails. I can imagine that losing the wrong kind of emails might be a real big issues for some companies. I haven’t asked, but I’m pretty confident that – even though the emails seem lost – Microsoft can somehow recover the data so that you don’t really “lose” anything. I honestly cannot imagine otherwise.

Does this mean that I discourage using features like EOA? Absolutely not. I still have my hosted archive and I am pretty happy with it. Apart from some inconveniences which I will write about another time, it provides me with everything I need. Furthermore, it allows us to give everyone a relatively large archive without having to bear the costs of additional storage.

Until later!

Blog Exchange Hybrid Exchange Office 365