No matter how long you work with software, it’s impossible to master every possible detail, especially when you’re talking about a complex product like Exchange 2013. Which brings me to reveal two small, but to me, interesting changes that have occurred recently. I say “recently” because I am not quite sure when Microsoft made the changes, but that hardly matters in a world when frequent updates are expected.
The first change is a new (again, to me) parameter for the Set-MailboxDatabase cmdlet. The parameter is AutoDagExcludeFromMonitoring and its description is:
“The AutoDagExcludedFromMonitoring parameter replaces the mechanism used in Exchange 2010 to exclude a mailbox database from the Database One Copy Alert script that alerts an administrator when a replicated database has only one healthy copy available. If this property is not set to True for a database and there is only one copy of the database, alerts will be issued.”
An EHLO post describes the Exchange 2010 Database One Copy script, which is used to signal the 4113 event if a database “owned” by a Database Availability Group (DAG) is not deemed to be redundant because only one copy exists. The script used in Exchange 2010 was replaced in Exchange 2013 RTM by code running in the Microsoft Exchange Replication service. I think TechNet is wrong when it asserts that alerts are issued for "replicated" databases. The example of the 4113 event shown below is for a database within a DAG that has only one copy and has never been replicated.
There are many good reasons why you might have a single-copy database within a DAG. That database might be used for testing purposes, or to migrate information from an older email system, or by applications that need to create and send messages but have no need to retain the items. In any case, the Replication service monitors for single-copy databases and reports them if found. The service has no knowledge of how the database is used; it simply knows that the database has only one copy and that’s not a good thing when you have what should be a highly available DAG.
Set-MailboxDatabase –Identity “VIP” –AutoDagExcludeFromMonitoring $True
But you know what the database is used for and can make the decision to tell the Replication service to ignore it by setting the AutoDagExcludeFromMonitoring parameter to $True. When this is done, no more 4113 events are logged for the database, which then allows you to focus in on events logged for databases that you want to be redundant. [Update: I've been told that setting the parameter to $True will also stop dismounted database alerts]
I like the ability to tweak reporting in this manner. At least, I did until I discovered that the setting doesn't work. I could set the parameter to $True but 15 minutes later, the parameter had been reset to $False and the alerts continued to flow. How odd! In any case, the bug has been reported to Microsoft and they are examining the issue with a view to fixing it in a future cumulative update. I hope this happens soon because I think the functionality is useful.
The other change that recently came to light was when MVP Jaap Wesselius (one of the great speaker line-up for Exchange Connections next September) pointed out that the TechNet now notes that the MaintenanceSchedule parameter for Set-MailboxDatabase is deprecated and that it “no longer does anything.”
On the one hand I wasn’t too surprised to learn this because Exchange 2013 uses a workcycle model for maintenance, meaning that background maintenance of Information Store database structures and content happens all the time, increasing in temp when user demand on system resources is low and decreasing as user demand grows. It therefore doesn’t make much sense to set a maintenance schedule as a property of a database.
However, even in Exchange 2013 CU5, EAC cheerfully allows administrators to set a customized maintenance schedule for a database (set command logging for EAC and you'll see the code that EAC runs to set the schedule). It’s true that EAC signals a warning that the facility is deprecated when you save the new schedule, but it is saved. The same occurs if you set a new schedule by running Set-MailboxDatabase in EMS. So TechNet is wrong on that the parameter “no longer does anything.” It might have no effect, but it does something.
All of this goes to prove that you have to keep your wits about you to keep up to date with changes that are made to a major product like Exchange 2013. It makes the job interesting – or demanding.
Update June 27: Scott Schnoll of Microsoft explains all about why the blessed AutoDAGExcludeFromMonitoring parameter doesn't work as planned. Apparently all will be well in Exchange 2013 CU6!
Follow Tony @12Knocksinna
