Why Bother Running DAG Server Maintenance Mode Scripts?

In a comment on my article about installing updates on Exchange 2010 DAG members Greg asks:

I would like to know how many Exchange admins [ahem] server admins actually follow these steps when they patch, we have a lab where we just patch Server A in a two multi role server DAG reboot it, then patch Server B and reboot it, then balance out the databases evenly among them and call it an evening, no problems so far

To be fair we didn’t go to Exchange 2010 until SP3 so maybe things are more better with SP 3 but we don’t bother with any of the procedures above and use Exchanges built in intelligence.

Now Greg does say that this is how they patch their lab servers, so it isn’t clear whether this is how they treat their production servers. However it is still a topic worth discussing.

The short answer, from my point of view, is that running the DAG maintenance scripts is the wisest course of action. And I’m sure that anyone who has experienced a scenario where those scripts fail to switchover a database due to some other underlying condition at the time would agree with me.

For anyone else who is just running them because it looks like “the way it is done”, and is curious why this is the wisest course of action, let’s look briefly at the possible consequences of not running the DAG maintenance scripts during server maintenance.

Consider that Exchange Server is an application running on a Windows server. When someone tells that server to shut down or restart, Windows is going to shut down or restart. In most situations the Exchange Server gets little say in the matter.

In the process of Windows Server stopping Exchange services, the Primary Active Manager will try to switchover any active mailbox database copies to another DAG member. In a simple two-member DAG it is pretty obvious where the active database copy will end up. In larger DAGs there is a little more to it. If you want to dive into the full details read up on the Best Copy Selection process here.

If you do read that then you might notice the term “lossy failover”.

A lossy failover is a potential data loss scenario. And the default AutoDatabaseMountDial setting of “GoodAvailability” allows lossy failovers to occur. And even with Exchange Server’s ability to automatically attempt to recover data lost in a lossy failover, it is not a guarantee.

For a test lab this is not likely to be a concern, and most of the time I allow my own test lab servers to automatically patch and restart (on separate schedules) without my manual intervention.

From time to time there is a problem as a result of that, which requires me to apply a little bruce force and occasionally accept some data loss to bring all databases online again.

In a production environment I would really hate to put myself in that situation, or know that others are putting themselves in that situation simply because they can’t be bothered running the DAG maintenance scripts. My recommendation is to always use the DAG maintenance scripts during patching or other server maintenance on your DAG members.

About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Find Paul on Twitter, LinkedIn or Google+, or get in touch for consulting/support engagements.

Comments

  1. John Healy says:

    Thanks. Early in my Exchange 2010 experience I had an issue and called MS paid support. They told me that I only needed the scripts for Exchange roll-ups and not Windows patches.

    I am glad now that I run them in either case. I did have to discover that I needed a second quorum server to make them work in my 2 member DAG. If that appears in the documentation anywhere I have yet to find it.

  2. We run the dag maintenance scripts along with disconnecting the Forefront from our Exchange server each time we patch (Exchange and OS). Too many times we’ve had to reseed dbs and a 300gb db takes forever!

    I’ve gotten it so scripted that almost anyone in the department can run a patch cycle, if they ‘follow-the-bouncing-ball’.

    “step1-Start_dagMaintenance.cmd” – runs the ‘startdagmaintenance.ps1′ script.
    “step2-StopExchange_disableFF.CMD” – stops exchange and ff services (and now scom) needed for disconnecting ff.
    “step3-Install_Rollup.cmd” – maps to install folder of latest rollup and runs install. if doing OS patching, run WIndows Update.
    “step4-reconnectFF.Cmd” – reverses step 2.
    “step5-Stop_dagMaintenance.cmd” – reverses step 1 and starts a server reboot.

  3. Paul, just a short answer:
    In my opinion using the maintenance-scripts is mandatory. I have patched a lot of huge (cusomters) Exchange-Environments and used always the scripts – with the result of a happy healthy DAG after the Patch-Day :-)

    have fun, Jimmy

  4. Recently had issues installing Rollup 2 for Exchange 2010 SP3 when I put the dag Member into maintenance mode. The part where the rollup would stop Services, it would just hang. The only way I was able to install the rollup was not to run the maintenance script.

  5. Kanta Prasad says:

    Hi Paul,

    Hope you ar doing Great as always…..

    I am totally agree with Jimmy …… Thanks to Microsoft and Great minds like you, who have made such great Scripts and made the life of Exch. admins so easy… :)

    Thanks,
    Kanta Prasad

  6. Oliver Weber says:

    My collegue who is very knowledgeable with Orchestrator has written a nice workflow that fully automates patching – of course it incorporates the DAG maintenance scripts.

    So now the full patch cycle can be performed by non-exchange aware operations folks…and my sunday is free again…

    Oliver

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.