How to recover data from an Exchange 2013 database after a complete Active Directory loss?

Scenario: a single Exchange 2013 server in a Windows Server 2003 AD domain; one DC malfunctioned months ago and was dismissed (without proper demotion, no less); the other DC died yesterday and there are no available backups. Simply put, that AD is no more.

The Exchange server is fully operational, but of course Exchange itself is not; however, the database files are safe and it was even possible to bring the database to a clean shutdown state.

The AD domain will have to be rebuilt from scratch; no really big loss, it's a small company, 20 PCs will need to be rejoined to a new domain and 20 users will face a clean user profile, some file shares will need to be re-ACLed, but overall it's not a big disaster (although it definitely taught them that, while having a single DC just means asking for troubles, having a single DC and no backups of it is quite a lot more insane).

The company isn't actually interested in bringing Exchange up again: they acknowledged their total unfitness for running anything more complex than a file server and are wholeheartedly moving to Office 365; however, they want to recover their Exchange data.

I can build any lab environment I need, thus bringing up a new AD and a new Exchange 2013 server is no issue; however, what do I actually need in order to mount the recovered database in a new AD/Exchange environment?

I did this several years ago with Exchange 2003, and it was a royal pain; it worked, but it needed every single bit of Exchange configuration to match, starting from the AD and Exchange Organization names up to the database paths and user names. However, we have Exchange 2013 now, which has lots of nice improvements that should make things easier: administrative/routing groups don't exist anymore, the new storage architecture abolished storage groups and decoupled databases from servers, and finally there are the fabled database portability (which however is only stated to work between servers in the same organization) and the absolutely lovable recovery databases.

What I know: the name of the defunct AD domain, the name of the Exchange server, the database name and its file paths, the Exchange 2013 version (CU3).
What I don't know: the name of the Exchange Organization (I can guess but I can't be sure), the user logins (same as above).

How many of these parameters still need to match in order to mount an Exchange database and run several MailboxExportRequests? Has this restore process improved a bit or is it still painfully manual? Would a recovery database help things (I only need to mount the DB and export data, not to actually use it)?

Can it even be as simple as "just bring up a new Exchange server, create an empty database, copy over the recovered files, mount the DB and export everything"... or are we definitely not quite there yet?

Turned out this is a lot easier than I expected.

Any Exchange 2013 database can be mounted on any Exchange 2013 server, regardless of the organization and/or Active Directory domain (although the same or higher CU level is probably required for the server).

If a foreign database is mounted on a server, it will work perfectly and can even be used to store new mailboxes; all mailboxes in the DB will be treated as disconnected ones, and they can be connected to user accounts, can be used without any issue and can (of course) be exported.
Database portability, indeed! Looks like we are there yet, after all.

So, the process to recover data from an Exchange database when the original environment is unavailable goes as follows:

• Build a new Active Directory domain and a new Exchange 2013 server (or even use an existing one, if you have it available); they can be named as you wish, all names are completely irrelevant.
• Create a new empty mailbox database; the DB name and the file paths don't matter at all.
• Allow the database to be overwritten from a restore.
• Get the EDB file from the original server and ensure it's in a clean shutdown state (if it's not, use eseutil and the original transaction logs to perform a standard database recovery).
• Place the EDB file where the new Exchange server expects to find the new database (you can rename it if needed).
• Mount the database.
• Get a list of the mailboxes in the database using the Get-MailboxStatistics cmdlet.
• Create as many user accounts as required to reconnect the mailboxes you want to recover.
• Connect the mailboxes in the database to the new user accounts using the Connect-Mailbox cmdlet.

That's it; now you can use the recovered maiboxes, or you can export them to PST files using the New-MailboxExportRequest cmdlet.

If all you want to do is recover items, then yes, it is as simple as you say, but your steps are a bit off.

1. Install new Exchange server.
2. Create new mailbox databases. (Make sure they are circularly logged to speed up the restore time.)
3. Mount old databases as recovery databases.
4. Restart-Service MSExchangeIS
5. For each mailbox: run the New-MailboxRestoreRequest command.

In case it wasn't obvious, you'll need enough free space to have a second copy of the mailbox databases.

Note that any special folder permissions, delegations, Full Access and Send As rights will be broken or missing.

However, the bright side of all this is that NOTHING needs to match. You simply provide source and target mailboxes to the New-MailboxRestoreRequest and it copies the items.

You will probably have to figure out the old x.500 addresses and add them to the new mailboxes. Otherwise, replying to old messages won't work.