Archive for category DAG
Couldn’t open backup file handle while performing Exchange DB seed via Powershell
Posted by Sam in DAG, Exchange 2010, Poweshell on 4 November, 2013
The error above is the outcome of running Udate-MailboxDatabaseCopyStatus -Identity DB_NAME -DeleteExistingFiles and the DB status went to Failed and Suspended. The reason is that the backup was kicked off and the handle for the DB was no longer available.
You could check the status of the backup on the DB by running Get-MailboxDatabaseCopyStatus -Identity DB_NAME | fl *backup*
Two ways to get over this, either to wait for the backup to finish or to reboot the server and stop the backup and that should fix the issue, the seeding process needs to start from scratch.
Move database between two DAG’s
Posted by Sam in DAG, Exchange 2010 on 15 October, 2013
Ever wondered how to move a whole database from one DAG to another without going through mailbox by mailbox migrations? For what reason? (you might ask)
We had to split two remote sites to two separate DAG’s to limit DAG dependability on link between them due to some reliability issues. This has caused us problems in the past and lots of headaches to keep users happy.
The original setup consisted of two multi-role Exchange 2010 servers in a stretched DAG with File Share Witness (FSW) being in Site A. If the link goes down or becomes intermittent then all DB’s would fail over to Site A and Site B will have no or very limited access to their mailboxes (See figure below).
What we needed to achieve is to have both sites working even during link failures, which isn’t possible with one DAG, hence the proposal of two DAG’s. Using the current design above we have managed to split users according to site into their own DB’s and activated those DB’s on their respective sites.
In order to create a second DAG and migrate DB’s across to new DAG, we followed following steps:
1. Make sure all DB’s are in sync (healthy)
2. Ensure all required DB’s for second DAG are activated on the swing server (i.e. in our diagram MBX2).
3. Remove any DB copies that tie that server with MBX1 before attempting to evict it off DAG1.
4. ENSURE YOU ARE REPLICATING AD CHANGES AT EACH STEP! OTHERWISE YOU WOULD HAVE SPLIT BRAIN ISSUE AND CAUSE YOUR DB TO FAIL. LISTEN TO ME WHEN I SAY I AM TELLING YOU FROM ‘EXPERIENCE‘ 🙂
5. Evict MBX2 from DAG1 ( Under Organization Configuration – Mailbox – Database Availability Group – right click on the DAG you want to evict MBX2 from and click on Manage Database Availability Group Membership).
6. Select MBX2 (in our case) and click on X to remove it.
7. Now, now right click on the DAG that you want to join and follow the same steps above to add MBX2 to the DAG.
8. Setup your DB copies.
This process should be seamless to end users with no interruptions to service, just make sure AD topology is updated at each step to avoid any DB downtime.
I hope this article will help you to save some time and effort in regard to DB re-allocation rather than mailbox-by-mailbox migrations. Of course mailbox-by-mailbox replications has it’s benefits, if you have lots of white space which you want to recover rather than dismounting the DB and running an offline defrag which is time consuming and it requires downtime depending on the size of the database.
Offline seed of Exchange 2010 DB in DAG environment
Posted by Sam in DAG, Exchange 2010, Poweshell on 27 February, 2013
Adding a member server to the DAG is an easy and worthy process, as it could provide protection against server failures and for remote sites it could save on bandwidth in regard to RPC (Outlook client) traffic to mail server.
In our situation, we have a stretched cluster which extends the DAG over a microwave link. copying a database over that link could take days, or weeks especially if we are talking about several databases with over 300 GB in size. This article will take you over offline seeding, this process proved successful in our case and very effective, but in order to get a successful result each of the steps outlined below have to be covered in that order.
Steps to offline seed Exchange 2010 DB
1. Before you even start, you should stop backing up the databases. Backups could truncate your logs files and cause the database to fail at the other end if any of the logs are missing.
2. Using DISKSHADOW.EXE tool, this tool is part of Windows 2008/2008 R2. With this tool we will be able to create a read only copy of the database volume before copying it to an external or network media.
3. At the command prompt, type DISKSHADOW.EXE
4. You can query available disk shadows by running: list shadows all
5. Set the snapshot as crash consistent type : Set Context Persistent
6. Add your volume ready for a snapshot (in our case the K drive): add volume K: alias kdrive
8. To create the VSS snapshot type: create
9. To expose the snapshot as a read only, type: expose %kdrive% Z:
10. Now at that point you should be able to see a Z drive available, it will give you a read only access which allows you to copy the content to a USB drive or directly to the target if the bandwidth permits. In our case we shipped it on a USB drive to our other remote site where we loaded it onto a temp drive on the target Exchange server. After copying the database, you can remove the volume and snapshot by running the following command using the Diskshadow.exe utility:
unexpose Z:
delete shadows volume K:
11. At this point we can create another database copy by running this Exchange PS command: (Make sure to use the -seedingpostponed key)
Add-MailboxDatabaseCopy -Identity DatabaseName -MailboxServer TargetExchangeServerName –SeedingPostponed
12. Place the database .db file in its corresponding directory
13. Then run PS: Resume-MailboxDatabaseCopy “DatabaseName\TargetExchangeServerName“
Now Exchange would validate the database and copy the required and missing log files form the source Exchange server.
SysCloud.dev 