ADSIEdit solves yet another problem for Exchange 2013 mailbox servers

Proving once again the usefulness of ADSIEdit, the “brain surgery” utility that fixes many problems in Active Directory, we see how KB2897047 describes using ADSIEdit to fix a small oversight that might have crept into Exchange 2013 servers after they had been upgraded to CU2 and indeed, an issue that might have persisted after the servers had been upgraded to CU3.

I call it an oversight because everything goes back to the introduction of the ”Managed Store” in Exchange 2013 RTM. As you might recall, the Managed Store is the from-the-ground-up rewrite of the Information Store to transform it from a monolithic process that is quite comfortable with the notion that it should seize and protect as much memory as possible on a mailbox server to a more elegant and useful scheme of controller and worker processes. (For more information on this transformation, see chapter 8 of Exchange 2013 Inside Out: Mailbox and High Availability)

In any case, Microsoft didn’t have as much information as it wanted to accumulate about how the new Managed Store operated in production circumstances when it released Exchange 2013 RTM, so the product group reduced the number of databases that can be mounted on an Exchange mailbox server running the enterprise edition from 100 (as used in Exchange 2010) to 50. This was a reasonable step to take at the time given that the early implementations were very much green-field deployments and 50 mounted databases allowed a reasonable load to be placed on mailbox servers.

The limit was subsequently lifted back to 100 with the release of Exchange 2013 CU2 in July 2013. Unfortunately, and this is where the oversight came in, someone forgot to tell the installation program that it could adjust the limit for mailbox or multirole servers when these servers were upgraded to CU2. On the other hand, servers that were newly installed with CU2 or CU3 received the correct 100-database limit.

Following the publication of KB2897047, I reviewed the settings for my mailbox servers and found that one still resolutely proclaimed its willingness to mount 50 databases and no more. Obviously I had not done a good job of checking things out after upgrading the server to CU2 and thereafter to CU3. But then again, I know of few administrators who pour over the settings held in Active Directory for mailbox or any other kind of servers, so I decided to grant myself a pass on this point.

Fortunately, (after you discover the problem) the fix is really easy. Start up the ever-useful ADSIEdit and navigate to the InformationStore property of a server to check the value of the msExchMaxStores attribute. If the value is 50, update it to be 100 as shown in the screen shot. Save the change and the new value will be used the next time that the Information Store service is started. Repeat for every mailbox and multirole server in the organization. (Question to self: what would happen if you changed the value to 125 or 150? Would Exchange be happy to mount so many databases? Answer to self: testing the theory would be boring. Life is too short. Move on).

It can be tiresome to look through every server in a large organization to detect and fix the problem so a small amount of PowerShell comes in handy. If you haven’t used PowerShell to manage Active Directory before, you might want to read the TechNet guide on the topic. Then you’ll be all set to execute the necessary command to return the value of the msExchMaxStores attribute as shown below:

Get-ADObject – Filter ‘ObjectClass –eq “msExchInformationStore”’ –SearchBase ‘CN=Servers,CN=Exchange Administration Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com’ –Properties msExchMaxStoresTotal, DistinguishedName | Format-List DistinguishedName, msExchMaxStoresTotal

Although appearing to be complicated, the command searches the Active Directory for contoso.com to locate any objects of class msExchInformationStore (there is one for each server that has the mailbox role installed) and returns the properties that are required (the value of msExchMaxStoresTotal and the distinguished name of the server. Naturally you’ll have to plug in the name of your forest and Exchange organization to make the command work, but once it does, you’ll get a list of all the servers and the value of msExchMaxStoresTotal on each. As you can see from the screen shot, all my servers are updated.

Oversights like this are regrettable as they demonstrate some lack of attention to detail in testing and development that is always worrisome in software. But at least it allows ADSIEdit to prove that it goes where other management interfaces such as EAC and EMS don’t.

Follow Tony @12Knocksinna