Had an interesting issue the other day;
Installing a new 3-node Multi-Role Exchange 2010 deployment – like so;
(for reference, the CAS array will be fronted by a Hardware box provided by the customer – probably a NetScaler or something similar)
Each of the servers was installed – each created the default “Mailbox 00915125” style databases.
Now, typically I rename and move the EDB/Log location for these – it always seems simpler than moving the System-type mailboxes that are located on the first 2010 mailbox database in an organisation. I did so again in this instance, renaming them and moving them to the Mount points created similar to below;
All seemed to be going well – so I created the 3-node DAG (placing the inactive FSW on the vCentre server for later use) and now its time to create myself a secondary copy of one of the six databases.
I ran the usual “add Mailbox database copy” EMC wizard, selecting the second server as a target for a copy of “DB1”. However it copied over the initial EDB file, but wouldn’t copy over any logs (and therefore sat at ~30 logs to copy/replay).
Event log had one error message;
The internal database copy (for seeding or analysis purposes) has been stopped because it was halted by the client or because the connection with the client failed.
Helpful. A Google search turned up This Link – and yes indeed I have SnapManager for Exchange installed (this is a NetApp based deployment after all) – however I am past the version noted (in fact am running the latest 6.0.2.x revision) – and cannot see anything on the NetApp NOW portal regarding this error.
Regardless I removed SME – no joy.
I then tried seeding a second database (after removing the DB1 copy) – and found that out of my 6 databases three wouldn’t seed;
DB1 – formally the default MDB on SERVER01
DB3 – formally the default MDB on SERVER02
DB5 – formally the default MDB on SERVER03
Strange to see but a very clear pattern. So I deleted DB1 and recreated it (initially as DB1 – however this then seemed to inherit the same MailboxDatbaseCopy object in AD so it still didn’t work so I recreated it) as MDB1 and voila it seeded. Even after renaming it back to “DB1” it caught back up (and I tested it for failure heavily later on – note to self btw – do NOT delete the boot disks from the vSphere server on an Exchange 2010 deployment. They do come back – but its not pretty and makes you sweat!).
So in short, if you are having problems seeding a Database to a second node, and it is the default created with Exchange 2010 SP1 – delete and try again.
(For reference these servers were installed with 2010 SP1 and then updated with RU3 v 3)
Recently had a customer with a WAN-split DAG – in short the first node was in the UK and they wanted a second node in Singapore adding.
Got the following error message;
Add-DatabaseAvailabilityGroupServer -Identity DAG -MailboxServer SINGAPORE
In short, this was due to a the link between myself and Singapore being too slow – which confused me slightly as I thought it had been uplifted in 2010.
A quick call to the Microsoft partner helpline, and I got this cleared up;
In RTM the RPC timeout is 5 minutes – also DAG links must be <250ms ping on average (to be supported)
In SP1 the RPC timeout is 10 minutes – also DAG links must be <500ms ping on average (to be supported)
Sorry Mr Customer, your on RTM
This can be done either using the EMC or EMS. However I advise to use EMS in this instance, as using the EMC will not give you a status bar (whereas using the EMS will).
Update-MailboxDatabaseCopy -Identity DB1\MBX1 – DeleteExistingFiles
DB1 is the name of the database
MBX1 is the name of the target server requiring a reseed
N.B “DeleteExistingFiles” forces Exchange to remove any existing copies of the database from the target server (MBX1) and can be omitted if the files have been removed manually.
Add-DatabaseAvailbilityGroupServer -Identity DAG1 -MailboxServer MBX1
Adds MBX1 to the DAG called “DAG1”
Remove-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Removes MBX1 from the DAG called “DAG1”. Ensure there are no active mailbox copies on MBX1.
Typically when clustering the Exchange 2007 mailbox role, you would use one of the HT servers as a witness.
However with 2010 you are no longer required to move the HT/CAS roles onto separate servers – so where to place it?
Obviously the “official” MS answer would probably be to install an additional HT server into your organisation, but why when you have perfectly fine other servers in place?
I placed mine on the customers vSphere vCentre server. It’s always up, and is key to their environment, so I have no worries about it being neglected.
However when creating a DAG, I got an error message telling me that it could not enable the Share as it didn’t have permissions.
*** Ok – so this is where it gets confusing. Pre-SP1 (as pointed out in the comments by Devin) only required the following step;
1) Add the “Exchange Trusted Subsystems” group to the local administrative group on the server (if you are using a DC you will have to add it to the BUILTIN\administrators group, which I would prefer not to personally)
However, in an SP1 environment it looks like you also have to add the server you are attempting to use as a FSW to the “Exchange Servers” group. I have posted on Devin’s blog (http://www.thecabal.org/2009/12/busting-the-exchange-trusted-subsystem-myth/#comment-3282) to see if there can be any clarity on this matter – but it does seem like something changed in SP1.
Re-create the DAG (delete the one you got an error with) and voila, your selected server is now a witness to your DAG 😉