Hello fellow Exchange Admins, Yesterday I exported a 30GB Mailbox as a .pst file to our SFTP server. At about 90% the MailboxExportRequest stalled with StalledDueToSource_DiskLatency.

No other exports were running from the source server. I even disabled all scheduled tasks that could have an impact on the database where the mailbox is mounted.

However, the export request always switched to: StalledDueToSource_DiskLatency

As a consequence, the export started to loop. It just created a new folder hierarchy and started to export the items again.

Therefore the export .pst was growing much bigger than the initial mailbox size. In other words, this can blow up your storage capacities if you have a large mailbox and leave the export overnight! Not to mention that the export is useless afterward.

In this post, I want to share how I worked around the StalledDueToSource_DiskLatency condition.

Let’s start at the beginning:

You can find more useful details on monitoring export requests here:

Monitor Mailbox Exports

The pain started whenever the export reached completion of 100%.
The job was relinquished due to large delays and unfavorable server health on the source server-side.

As can be seen in the image below the export status stayed inProgress.
While SyncStage was CopyingMessages and StatusDetail was StalledDueToSource_DiskLatency:

Therefore the export job was relinquished:

Eventually, the export started all over again. StatusDetail: CreatingFolderHerarchy:

Then PercentComplete was 10% again:

As a result, the size of the export PST grew much bigger than the initial mailbox size.

After all, the solution for me was to switch the mailbox database that hosts the mailbox to another copy within the DAG:

Work around StalledDueToSource_DiskLatency

After the database is switched to another server try to export the mailbox with a new export request.
Given that the new server has no performance or disk issues the export should complete in a normal manner.

Have a nice day

The post StalledDueToSource_DiskLatency Mailbox Export appeared first on Webbanshee.

Hello folks, Today I would like to share my experience so far on how to export a mailbox with New-MailboxExportRequest. There are a couple of parameters to query to get useful information about the status of an export request.

As long as everything goes smooth you will probably just need the percentage information. But when the New-MailboxExportRequest stalls or stops with an error you will be happy to have some additional parameters to query at your disposal.

So let’s get to the point straight away:

Start to export a mailbox with New-MailboxExportRequest:

After you have started the export request check the progress:

First, a short info on the -IncludeReport switch:

When this switch is used in accordance with select Report the ouptut looks like this:

The output displays the currently processed items. Depending on the mailbox size the output can get much longer. Below the report, the output of other parameters you have selected is displayed.

New-MailboxExportRequest relevant infos that can be selected:

Modify parameters of a mailbox export request:

To modify the parameters of an existing mailbox export request you will need to suspend the request first. This can be useful when you retrospectively want to change the BadItemnLimit or want to raise the priority.

Suspend the mailbox export request:

Now change the parameters [Example: BadItemLimit]

Resume the mailbox export request:

Remove-MailboxExportRequest

Here are two arguments to remove mailbox export requests you don’t need anymore:

• To export a mailbox with New-MailboxExportRequest with the same request name.
• Further, do some housekeeping and keep your environment clean and transparent.

Have a nice day!

The post Export Mailbox New-MailboxExportRequest appeared first on Webbanshee.

In this post, I would like to share how I got around a Mailbox Locked Mailbox Move issue. After we have successfully moved several hundred mailboxes to their new location some issues occurred with a few mailboxes.

Moves for those mailboxes could not be started with the -priority switch due to the fact that the target location wasn’t on-premise.

As a result, some of those boxes just stalled. Restarting the Mailbox Replication Service on the relevant source server did the trick. The stalled move requests could be reinitiated. Only one mailbox remained.

However, the remaining mailbox was locked. I tried to move the mailbox to another mailbox database but received the same error as with the move-request:

It seemed like the mailbox had a locked flag ( or something similar ) set in the information store of the source server that mounts the mailbox database for this mailbox. If so, I would have to restart the information store or reboot the server to wipe this flag. Not the first choice for a production server.

I never had this kind of mailbox locked mailbox move issue before.
So I started to google and fortunately found this article on dirteam.com.

The article made me confident that it is most probably locked in the information store on the source server. Switching the mounted mailbox database where the locked mailbox resides to another server just did it. Simple as that. Thank you, DirTeam!

Here the short procedure to solve the mailbox locked mailbox move issue:

After the mailbox database was mounted on another server I was able to start and complete the move of the last mailbox successfully.

Have a nice day!
 
 
If you run into other issues with move requests this could also be of interest:

Mailbox Moves
 

The post Mailbox Locked Mailbox Move Issue appeared first on Webbanshee.

Microsoft released another security update in April for Exchange 2019 CU9 and Exchange 2016 CU20. Here are our experiences on installing Exchange 2019 CU9 with KB5001779. We also installed Exchange 2016 CU20 with KB5001779 on our Exchange 2016 servers.

If you run a mixed environment consisting of Exchange 2019 and Exchange 2016 servers you may want to check the schema requirements before. You can find information on that in my post from March:

Exchange 2019 CU8 and Exchange 2016 CU19.

First, I want to mention installing the CUs went well and smoothly. Updating from Exchange 2019 CU8 and Exchange 2016 CU19 required less time than upgrading from Exchange 2019 CU5 and Exchange 2016 CU16 to the mentioned CUs. Also installing security update KB5001779 took only about 30-40 minutes.

These were the good things. What are the backlashes?

KB5001779 can break processes initiated by CMDlets you run from a 3rd party or self-developed application against Exchange.

To be more specific quoting Microsoft:

This Microsoft article was quite helpful in terms of what to expect:

April 2021 Exchange Server Security Updates

Tasks before installing Exchange 2019 CU9 with KB5001779 and Exchange 2016 CU19 KB5001779:

Order of install:

Sources:

Experiences after installing Exchange 2019 CU9 with KB5001779 and Exchange 2016 CU20 KB5001779:

In case you need information on other CUs take a look into the CU Archives

… or find a general description here: CU Install Exchange

Stay safe!

The post Exchange 2019 CU9 with KB5001779 appeared first on Webbanshee.