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.”
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.
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?
I run into this when adding a new product key for exchange svr 2013.
Paul
If we add a new database and a database copy on a send server, but decide not to restart IS right away … can this have an effect of the amount of time a content index takes to reach a healthy state?
Thanks
Kyle
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
Pingback: Managing Database Copies for Exchange 2016 DAGs
Pingback: Restoring Exchange 2016 Mailboxes with Recovery Databases
Hi Paul,
Un coup de main:
Dans PS,
Taper Restart-Service MSExchangeIS
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.
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.