Archive for category Exchange 2010
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.
Soft Deleted Mailbox in Exchange 2010 (Continued)
Posted by Sam in Exchange 2010, Poweshell on 12 July, 2013
In my previous post I have talked about what happens behind the scenes when you disconnect a mailbox via EMC. Soft deleted mailboxes stay on the system for the whole retention period (by default 30 days) hence they still utilise space within Exchange DB, if you are running on low disk space then this might become an issue.
Luckily there is a solution to this issue, using Remove-StoreMailbox command in Powershell, follow the solution in this MS article http://technet.microsoft.com/en-us/library/gg181092(v=exchg.141).aspx
Soft Deleted Mailbox in Exchange 2010
Posted by Sam in Exchange 2010, Poweshell on 17 June, 2013
Have you ever wondered why there are so many disconnected mailboxes? That has flagged a big security alert in our firm, especially after finding out how IT staff used to disable user accounts! By disabling a mailbox, you are actually detaching that mailbox form it’s AD object, this orphaned mailbox is prone to deletion according to your Exchange mailbox retention policy (by default 30 days!).
We have also found few other mailboxes for active users but they are sitting in Disconnected Mailbox, by running the command:
Get-MailboxStatistics -Server ServerName | where {$_.DisconnectReason -eq ‘SoftDeleted’}
The result would show user display name for those mailboxes that had moved from one DB to another. Exchange would mark the source mailbox as SoftDeleted rather than the default Disabled – a mailbox gets flagged as Disabled when disabling mailboxes using the Disable command within the MS Exchange GUI or Disable-Mailbox via Powershell.
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 