Home » Exchange Server » Warning: Please Restart the Microsoft Exchange Information Store Service After Adding New Mailbox Databases

Warning: Please Restart the Microsoft Exchange Information Store Service After Adding New Mailbox Databases

On an Exchange 2013 server running Exchange 2013 RTM CU1 or later you may be presented with a warning message after adding a new mailbox database.

“Warning: Please restart the Microsoft Exchange Information Store service on server E15MB1 after adding new mailbox databases.”

restart-is-new-db

This warning can occur on mailbox servers that are members of a database availability group, as well as standalone mailbox servers.

Despite the warning the new database will mount and be available to host and serve mailbox data.

The warning did not appear in Exchange 2013 RTM, although the reasons for the warning were present in RTM.

To help you understand this warning here is a slide from the Exchange Server 2013 Architecture Deep Dive session at TechEd Australia 2012.

exchange-2013-ese-cache

Note in particular that last bullet point:

“Restart service process when adding/removing copies…”

As Scott Schnoll explains in the presentation, in previous versions of Exchange the entire ESE cache would be allocated to the Information Store (store.exe) process.

In Exchange 2013 a change was made so that each individual database now runs as a separate worker process, and therefore each worker process has their own ESE cache.

The server needs a way to allocate each worker process a share of the available memory for ESE cache. The factors for this allocation are:

  • the amount of memory that the server has
  • the number of databases on the server
  • whether those databases are active or passive

Scott also makes the point in the video that this applies when you make significant changes to your database layout. This may mean that the implications for adding a single database are not that serious, hence the warning rather than a hard error.

However, this is a new operational challenge for Exchange administrators so the best practice for this has yet to be established. At face value it appears that database creation is no longer an “anytime” activity with no impact.

To quote Scott from that session recording:

“Hopefully that is something that will change at a later date…”

So what to do about it? We know the warning is valid, so if we assume that the implications for not taking the advice are serious then we have to restart the service.

Standalone Mailbox Servers – there is no alternative but to restart the Information Store service during an arranged outage window.

Database Availability Group Members – after adding a new database and configuring the desired database copies, a series of rolling restarts of the Information Store services across each DAG member would then be required, putting each server into maintenance mode then taking it out of maintenance mode again. This would be a similar process as installing cumulative updates.

I would anticipate that if this warning condition remains in place that database creation will become a planned maintenance activity that occurs during the same window as monthly security patching or quarterly cumulative update installation.

For a deeper look at the reasons behind this check our Tony Redmond’s article here.

What are your thoughts on this?

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

7 comments

  1. Ben Owens says:

    Hi, it’s a very annoying situation. The database mounts and shows as available and if you have a single server solution then scheduling in that downtime for something like a information store restart isn’t always easy. The question is would you continue to use the new database without restarting the information store if you needed to work on it asap and then schedule a restart of the information store down the line such as the next weekend?

    • My view is that the adding of the database should be planned for a time when the store service can be restarted.

      If the database needs to be urgently added then surely that justifies a more urgent store restart as well (eg first available out of hours window, such as late that same evening).

      On a well-specced server I assume it is fine to begin using the database but I would not begin to load it up with many mailboxes without the store service restart happening first.

      • Ben Owens says:

        No, I agree. The instance I had in mind was adding a mailbox to hold a small amount of public folders only; Not a wise decision for a DB holding a large amount of live mailboxes.

  2. Akshay Bahiram says:

    We created a DB last Sat; & also moved few mailboxes from cloud to back to core. BUT didn’t restart IS.
    # Monday morning people from those DBs came complaining that they are unable to access outlook but OWA was working fine.
    # I tried configuring their Ol on my system just to make sure nothings system specific but yeah same thing on my system as well
    # I moved my mailbox on those DBs & even I started experiencing the same issue.
    # I activated the other copy & things were like back to normal.
    # Then I resarted the IS for the server in Question & mounted the original copy wiith issues & it was working fine

    I am keen on understanding did this issue occurred just coz we did not reastart IS.

    PS We are on E15 CU10

Leave a Reply

Your email address will not be published. Required fields are marked *