Hello Everyone and thanks in advance for any insights and your time. It is greatly appreciated.
Trying to update 2013 Exchange (cluster with DAG) servers to newest CU23 update and getting an error when I go into maintenance mode. It still lets me do it, but I stopped when I saw the error.
We have two databases and I am trying to understand what this means.
The server I was trying to update was not the active holder of the DB (they show as active on the other one) at the time.
Does this mean there will be an issue even though the db is not on that server?
[PS] E:\Microsoft Exchange\exchsvr\Scripts>.\StartDagServerMaintenance.ps1 -servername tghpass
The following objects are hosted by 'tghpass', before attempting to move them off: `n(Database='ADMINDB01', Reas
on='There were database redundancy check failures for database 'ADMINDB01' that may be lowering its redundancy and putti
ng the database at risk of data loss. Redundancy Count: 1. Expected Redundancy Count: 2. Detailed error(s):
tghvspass:
Database 'ADMINDB01' does not have enough copies configured to meet the validation criteria.
') (Database='CLINICDB01', Reason='There were database redundancy check failures for database 'CLINICDB01' that
may be lowering its redundancy and putting the database at risk of data loss. Redundancy Count: 1. Expected Redundancy C
ount: 2. Detailed error(s):
tghvpass:
Database 'CLINICDB01' does not have enough copies configured to meet the validation criteria.
'))
Laszlo Denes
Technical Analyst Servers
Information Systems
The Salvation Army Toronto Grace Health Centre
650 Church Street, Toronto, ON M4Y 2G5
f: 416-925-3211
Exceptional and compassionate care for all.
Those two databases don’t have at least two healthy DAG copies (for whatever reason). So they can’t be moved.
Exceptional and compassionate care for all.
________________________________________
NOTICE: This message, including any attachments, may contain privileged or confidential information and is intended for use only by the individual to whom it is specifically addressed (or those responsible for the delivery of the message to such person). Any
distribution, copying or disclosure is strictly prohibited without the written consent of the sender. If you are not the intended recipient or have received this message in error, please notify us by reply email and permanently delete the original transmission
from us. Thank you for your cooperation. If you have any questions about this message please contact the Information Systems Department, Salvation Army Toronto Grace Health Centre, 650 Church St., Toronto, ON M4Y 2G5. Phone: (416) 925-2251
--
You received this message because you are subscribed to the Google Groups "ntexchange" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ntexchange+...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ntexchange/b69f481f7bb945e29fe68df1d6893ba5%40TGHVSEX2013ACT.torontograce.org.
Odd thing is that they are not mounted on that server i.e. it has healthy copies according to all tests I ran, but they are passive healthy.
Laszlo Denes
Technical Analyst Servers
Information Systems
From: ntexc...@googlegroups.com [mailto:ntexc...@googlegroups.com]
On Behalf Of Michael B. Smith
Sent: Thursday, September 2, 2021 2:09 PM
To: ntexc...@googlegroups.com
Subject: [ntexchange] RE: DB error when going into maintenance mode
To view this discussion on the web visit https://groups.google.com/d/msgid/ntexchange/3af42ab81211447c90918270e426bef8%40smithcons.com.
I’m guessing you have a two-node DAG. It’s going to throw this error if a database redundancy count goes down to 1 – which it will if you put one of your two nodes into maintenance mode. We have a couple of test DBs with only two copies and we see this message when the passive copy is in maintenance mode.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntexchange/d982154540c54c9ab6ff4a5c0b246453%40TGHVSEX2013ACT.torontograce.org.
Yes, perfect that is exactly it. Two 2013 Exchange servers (clustered) with a DAG. DB x 2 is always active on one server and passive (healthy) on the other. Normally if I fail over the active one it fails over the DB to the other one. I got thrown off by this because we don’t do this often and I could not account for the error since the DB was not on the server I put into maintenance mode at the time. This makes perfect sense. Thank you very much.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntexchange/02c339e50c044956a18592a8849adbd7%40DT-EX151.boselaw.com.