All posts by jaapwesselius

Exchange, Uncategorized

Exchange 2016 CU7 and Exchange 2013 CU18

2 Comments

Microsoft has released its quarterly updates for Exchange:

  • Exchange 2016 CU17.
  • Exchange 2013 CU18.

It has been quiet around these updates, and they do not bring a whole lot of features.

Important to note is that the minimum Forest Functional Level (FFL) has been raised to Windows Server 2008 R2. Personally I think this is an indication that more exciting stuff is along the way, especially around Exchange 2016 (my personal expectation, don’t shoot the messenger :-))

There are schema changes in Exchange 2016 CU17, so when installing this update you have to execute the following commands:

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

When it comes to the .NET Framework, Microsoft is working on a new .NET Framework release (version 4.7.1). The upcoming quarterly update of December 2018 will support this version of the .NET Framework.

More information (well, not a lot more) can be found here: https://blogs.technet.microsoft.com/exchange/2017/09/19/released-september-2017-quarterly-exchange-updates/

 

Office365

MigrationTransientException: Target database GUID cannot be used (Mailbox database size limits in Exchange Online)

4 Comments

If you are designing Exchange 2016 (or have been designing Exchange 2013) environment you are aware of the The Exchange 2016 Preferred Architecture (https://blogs.technet.microsoft.com/exchange/2015/10/12/the-exchange-2016-preferred-architecture/) and articles like Ask the Perf Guy: How big is too BIG? (https://blogs.technet.microsoft.com/exchange/2015/06/19/ask-the-perf-guy-how-big-is-too-big/) which explain pretty much how to design an Exchange solid (and large) Exchange environment.

When it comes to Mailbox databases, the recommended size limit for non-replicated databases is 200GB and for replicated databases 2 TB (when running 3 or 4 copies of a Mailbox database).

One can only guess how Microsoft has designed their Exchange servers in Exchange Online, but we can assume that the Preferred Architecture is written with their Exchange Online experiences in mind.

Sometimes error messages that are generated in Exchange Online can reveal more information. While moving mailboxes from Exchange 2010 to Exchange Online in a hybrid configuration the following error message was returned in a migration batch for a number of Mailbox databases:

Error: MigrationTransientException: Target database ‎’07bdf507-ab94-479b-aeb6-1bfef1458c4c‎’ cannot be used: Current database file size: 1502835900416 Current space available inside database: 100237312 Allowed database growth percentage: 90 Maximum database file size limit: 1622722691784 Is database excluded from provisioning: ‎’False‎’. –> Target database ‎’07bdf507-ab94-479b-aeb6-1bfef1458c4c‎’ cannot be used: Current database file size: 1502835900416 Current space available inside database: 100237312 Allowed database growth percentage: 90 Maximum database file size limit: 1622722691784 Is database excluded from provisioning: ‎’False‎’.

Obviously it’s telling us the migration cannot proceed since the target Mailbox (in Exchange Online!) has reached its size limit. The following sizes are reported:

  • Current database file size: 1502835900416 (1,502,835,900,416 bytes, approx. 1.5TB)
  • Current space available inside database: 100237312 (100.237.312 bytes, approx. 100MB)
  • Maximum database file size limit: 1622722691784 (1.622.722.691.784 bytes, approx. 1.6 TB)

So, the maximum size limit for Exchange 2016 in Exchange is not really used in Exchange Online, but it’s getting close, which is interesting to see.

What I don’t understand is why this issue occurs in the first place. To me it looks like a failing part in the provisioning service but I have to admit I’ve never seen this before in the last couple of years so I expect it’s only one Exchange server that’s failing here.

Exchange

Exchange 2013 Mailbox database Disaster Recovery

2 Comments

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!

Office365

Exchange Online PowerShell multi factor authentication (MFA)

Leave a comment

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) →

Exchange

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

Leave a comment

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.