Exchange 2013 Mailbox database Disaster Recovery

In Exchange 2010 Microsoft introduced the Database Availability Group to implement redundancy on mailbox server level and mailbox database level. If a mailbox database (or a server) fails, another one can take over. This concept is carried forward into Exchange 2013 and Exchange 2016 and has improved ever since.

There are still customers that do not use a Database Availability Group and rely on a single server and a solid backup software solution. A backup of the mailbox database is created every night and this continue to run for years. You hope. Until disaster strikes…..

image

I got a call earlier today from a customer. He has been patching his Hyper-V host, and after a reboot his Exchange 2013 server didn’t come up properly. Well, after questioning it turned out that the Exchange server booted correctly, but that only one of three Mailbox databases mounted properly. So, two Mailbox databases (approx. 250 GB in size) seem to be corrupt and this is where the pain begins.

To ‘resolve’ the issue the customer tried to reboot the box again, tried to restore the databases from backup, tried a ‘soft repair’ and tried a ‘hard repair’. No idea what the latter are by the way, but that was according to the customer. But if you know anything about Mailbox databases in Exchange, then you also know that most destruction happens in the first 15 minutes!

If you rely on a single server and a backup solution for restoring services or a disaster recovery scenario you have to know the basics of Exchange database technology. Know what a mailbox database is (except for a large .edb file), know what transactional logging is and how the mailbox database, the transaction log file and the checkpoint file relate to each other. And related to this, it is of utmost importance that you know how to replay transaction log files into a Mailbox database.

Although old, these are good starting points:

Furthermore, you have to know how your backup solution works, and how to restore mailbox database into a production environment. There are streaming backups, but these are rare these days and VSS snapshot backups. You can find more detailed information in the following articles:

Besides the technical knowledge about the Mailbox database technology you have to perform regular ‘fire drills’. Restore a Mailbox database into production, restore using a recovery database, perform replaying of transaction log files, get your hands on ESEUTIL and see what the /G, /K, /P and /R are doing. It will save you a considerable amount of time when you know the technology and the tools, it will reduce risk of data loss and you are able to give a proper planning to your users/manager/customer when the mailboxes are available again.

If you don’t know this you’re playing with fire, and it will backfire to you, believe me!

Exchange Online PowerShell multi factor authentication (MFA)

It’s a good thing to enable multi-factor authentication (MFA) for Office 365 administrators. For web based management portals this is not a problem, just enter your username and password, wait for the text message to arrive, enter it in the additional dialog box and you’re in.

For PowerShell this has been more difficult, but MFA for PowerShell is available as well for some time now. When you login to the Exchange Admin Center and select hybrid in the navigation pane you can configure a hybrid environment (first option) or install and configure the Exchange Online PowerShell MFA module.

Click on the second configure button, and in the pop-up box that appears click Open to start the installation of the PowerShell module:

image

Continue reading Exchange Online PowerShell multi factor authentication (MFA)

A reboot is required to complete file operations on ‘exchangeserver.msi’

I already mentioned this in my blogpost about Exchange 2016 CU6 and Exchange 2013 CU17, but when upgrading an existing Exchange 2016 server to Exchange 2016 CU6, the setup application stops after step 5, 6 or 7 (random) with the following error message:

“A reboot is required to complete file operations on ‘E:\exchangeserver.msi’. Reboot the machine, and then run setup again”

image

After rebooting and restarting the setup application the upgrade finishes successfully.

Rebooting the Exchange 2016 server prior to starting the upgrade process does not prevent this from happening. Also, there’s no difference between Exchange running on Windows 2012 R2 or Windows 2016.

The installation process has been tested by Microsoft and TAP customers, and tests are still conducted. It is somewhat clear what the root cause is for this issue, it is an MSI package that’s causing this issue. Please be aware that the Microsoft setup application executes around 200 MSI packages, and if only one MSI package is having difficulties you can see issues like this. Because of the number of MSI packages it is not possible to check in advance if your server will experience this issue.

At this moment the only solution is to reboot the server when requested and restart the application program.

Exchange 2013 CU17 and Exchange 2016 CU6

On June 27, 2017 Microsoft has released its quarterly updates for Exchange 2013 and Exchange 2016. The current version is now at Exchange 2013 CU17 and Exchange 2016 CU6. Typically I don’t pay that much attention to this, all new developments seem to be for Office 365 and very little developments for on-premises Exchange deployment. But this time there are some interesting things I’d like to point out.

A couple of days before the release of Exchange 2016 CU6 Microsoft blogged about Sent Items Behavior Control and Original Folder Item Recovery. With the Sent Items Behavior Control, a message that’s sent using the Send As or Send on behalf of permission is not only stored in the mailbox of the user that actually sent the message, but a copy is also stored in the delegator mailbox sent items. This was already possible for shared mailboxes, but now it’s also possible for regular mailboxes (like manager/assistant scenarios).

The Original Folder Item Recovery feature is I guess on of the most requested features. In the past (before Exchange 2010) when items were restored after they were deleted, they were restored to their original location. With the Dumpster 2.0 that was introduced with Exchange 2010 this was no longer possible, and items were restored to the deleted items folder. In this case the items had to be moved manually to their original location. With the introduction of the Original Folder Item Recovery the restore of deleted items again takes place in the original folder.

Continue reading Exchange 2013 CU17 and Exchange 2016 CU6

create Shared Mailbox in Exchange Hybrid

Every now and then I get a question regarding creation of Room- or Shared Mailboxes in Office 365 when Exchange Hybrid is in place.There are multiple solutions available, but at the same time there are some restrictions as well. In this blog post I’ll discuss Room Mailboxes, Equipment Mailboxes and Shared Mailboxes.

Room Mailbox

To create a room Mailbox in your hybrid environment create a user account for this room mailbox first. In this example I’m going to create a Room Mailbox called ‘conference room 1st floor’ and have it created directly in Office 365 (for your information, I’ve tested this with Exchange 2010 hybrid as well as Exchange 2016 hybrid).

image

To create the Mailbox in Exchange Online, you can use the Enable-RemoteMailbox cmdlet in Exchange PowerShell. This will mail-enable the account in your on-premises environment and will automatically create a mailbox in Exchange Online the next time Azure AD Connect runs. For the Enable-RemoteMailbox cmdlet you need to use the -RemoteRoutingAddress (which should point to the Mailbox in Exchange Online) and for a Room Mailbox you have to use the -Room option. If you want to create a Shared Mailbox you can use the -Shared option, the result will be the same.

To create the Room Mailbox in Exchange Online we can use the following command:

Get-User -Identity Conference1 | Enable-RemoteMailbox -Room -RemoteRoutingAddress conference1@inframan.mail.onmicrosoft.com

image

When Azure AD Connect has run, the account has been provisioned in Azure AD and the Room Mailbox has been created. It is visible in Exchange Online EAC and permissions can be granted to other users can manage the Room Mailbox.

image

Resource (Equipment) Mailbox

To create a Resource (aka Equipment) Mailbox the process is very similar. First create a user account for the Equipment Mailbox in Active Directory and fill the appropriate attributes, like this:

av

To create the Equipment Mailbox directly in Exchange Online, execute the following in PowerShell (on your on-premises Exchange server):

Get-User -Identity AVEquipment | Enable-RemoteMailbox -Equipment
-RemoteRoutingAddress avequipment@inframan.mail.onmicrosoft.com

equipment

Again, when Azure AD Connect has run, the account is provisioned in Azure AD and the Mailbox is created in Exchange Online:

mbx

Shared Mailboxes

Createing Shared Mailboxes is a bit problematic, after all these years there’s still no option like -Shared when using the Enable-RemoteMailbox cmdlet in Exchange PowerShell so we have to figure out another way to create a Shared Mailbox in Exchange Online when using Azure AD Connect and a Hybrid environment.

<more to come soon>

 

Microsoft UC Specialist