Jeremy Phillips

Last Thursday night I had the distinct privilege of participating in a real life Exchange 2010 disaster recovery scenario. Roughly 41,000 mailboxes on 22 databases had the DAG ripped out from underneath them accidentally. When I say ‘ripped out from underneath them’ I mean literally that; everything was removed, including all the cluster resources and mailbox servers. As far as AD was concerned these servers didn’t even exist. All we had left was the .edb files, catalog indexes and log files. The solution? Database portability.

Even though this was essentially a test environment, there were a number of live mailboxes that simply had to be recovered and we wanted to recover them all. The steps we took were rather straightforward;

1 | Find some live mailbox servers that had the spare capacity to mount 22 databases. Split the list of databases to be mounted among them.

2 | For each mailbox server, copy over the database and log directories so we had the data to use.

3 | Perform a soft recovery with eseutil /r on each database/log set to commit any uncommitted log files and ensure we could actually mount the data later in the process.

4 | Create the new mailbox databases: new-mailboxdatabase -name <name> -server <server> -EdbFilePath <path to recovery folder, e.g. c:\RecoverDBs\RecoverDB1\<name of original edb>.edb> -LogFilePath <path to logs, e.g. c:\RecoverDBs\RecoverLogs1>

Pro Tip: Use a new name for the database. If the old database was named DAG1-DB001, you might use DAG1-RecoveryDB001.

5 | Set the newly created databases to allow file restore: set-mailboxdatabase <db name> -AllowFileRestore:$true

6 | Copy in the database, logs and catalog data to the correct folders (those specified in step 4)

7 | Mount the databases one at a time: mount-database <DatabaseName>

8 | Once the database is mounted we can now re-home all the users with mail data there: get-mailbox -database <OriginalDatabaseName> | ?{$_.ObjectClass -NotMatch ‘(SystemAttendantMailbox|ExOldDbSystemMailbox)’} | set-mailbox -database <RecoveryDatabaseName>

9 | If you’re running with multiple copies then keep in mind that you’ve only got one live copy of the new database. You can either add a copy of the new database or do what we did and move them to databases on your new DAG that (hopefully) has multiple copies already. If you choose to go the route of moving them to existing healthy databases the command is: get-mailbox -database <RecoveryDatabaseName> | new-moverequest -TargetDatabase <HealthyDatabaseName>

Comments and/or questions are welcome in the comments. I just wrote this from memory so if I missed anything along the way please let me know.

1.) Launch an elevated command prompt. (Right Click on Command Prompt –> Run as Administrator)

2.) Execute the command wbadmin start systemstatebackup -backuptarget:D: while substituting D: for another drive letter if needed.

To my knowledge you can’t backup to a folder unfortunately.

I started using BareTail about 3-4 years ago when I was doing migrations (Quest Migration tools have a large number of logs) and I’ve been using it ever since then. If you have a need to monitor log files in Windows, go download BareTail from Bare Metal Software. It’s free, no installation or registration required. I just used it to tail some WDS logs as shown in the example below. It also does highlighting, supports files larger than 2GB and fully supports viewing files located on network shares.

I have WordPress Permalinks enabled but forgot to enable mod_rewrite after moving this site so everything was returning a 404. Since I moved this site back to my own server I had the pleasure of enabling mod_rewrite myself. Visions of a long night danced through my head as I thought I would have to recompile Apache in the process. Luckily it turns out that mod_rewrite is compiled in the Apache 2.2 port so all you have to do is make sure it’s enabled and allow overrides and enable options for the WordPress home directory.

1) Make sure this line: LoadModule rewrite_module libexec /apache/mod_rewrite.so is present in httpd.conf by issuing the below command. As long as it returns the line you’re good to go there.

host# grep mod_rewrite /usr/local/etc/apache22/httpd.conf
LoadModule rewrite_module libexec/apache22/mod_rewrite.so
host#

2.) Change the directory settings in your VirtualHost statement. To use a real example, change this:

<VirtualHost *:80>
ServerName jeremyphillips.org
ServerAlias www.jeremyphillips.org
DocumentRoot /home/www/jeremyphillips.org
</VirtualHost>

To this:

<VirtualHost *:80>
ServerName jeremyphillips.org
ServerAlias www.jeremyphillips.org
DocumentRoot /home/www/jeremyphillips.org
<Directory /home/www/jeremyphillips.org>
Options All
AllowOverride All
</Directory>
</VirtualHost>

3.) Lastly restart Apache.

host# apachectl restart