Exchange 2010 to 2013 MIgration Gotchas

This is just some notes and gotchas that I've come across during our Exchange 2013 migration. They're not in order, but I'll be adding more as we go along and I'll clean them up a bit when we are all cut over.

1. The creation of a DAG requires a witness server during setup.
   - Even if you're running an odd number of nodes, you have to use a witness server for Dynamic Quorum.

2. If using Mount Points for Database storage, create the volumes and Mount Points manually on each node, prior to creating databases and copies.
   - There are a couple of guides that miss this step, and if you only create the folder structure on one node, and let the copy creation set up folders, it puts them in the root of whatever drive you created the database on - for instance if you created C:\ExchDBs with mount points on node 1, and then create a copy to node 2, it will create the C:\ExchDBs folder on node 2, but that folder will actually be using space on C:\.

3. Creating Databases and copies requires restarting the Information Store service on whichever node you created them on. This is because Exchange 2013 uses a different RAM management model, but it also means you'll require downtime during creation...although DB creation doesn't happen all that often, this is pretty annoying since it's now a maintenance window item.

3a. Creating a Recovery Database also requires the Store to be restarted...which is super annoying because who wants to wait for a maintenance window to restore mailboxes?

4. IP-less DAGs are awesome! We had an issue, which required changing the NICs on the VM's. The servers themselves were not happy about this change, but Exchange didn't even blink - everything came back just as it was because the DAG didn't rely on VIP's, DNS names, Cluster Name Objects (CNO).

4a. There are very few backup solutions which will work with IP-less DAGs, because they do not have a VIP or CNO, and these backup apps cannot recognize the DAG without it. DPM 2012 does in fact work great because it uses Exchange VSS, making it DAG-aware.

4b. Going along from point number 4: During a full power outage (like when we had to shutdown for NIC changes) when running DAC mode, databases will be dismounted (and will not mount) to protect them from split-brain. When enough servers are back up and running to regain quorum, you need to start the DAG Service on each alive node by running:

  Start-DatabaseAvailabilityGroup -Identity "DAG name" -MailboxServer "server name"

5. With Dynamic Quorum (in Server 2012), you can even run the Start DAG command on one running server, as long as the witness is available, to force the DB's to mount...pretty neat!

6. When creating DB copies, make sure to postpone seeding. First-time Replication was terrible and we got nothing but errors and had to reseed the copies on the first couple ones we created.
   - When we postponed seeding, and started it later, it went with no problems.

7. When deleting the annoying Default Databases, you have to move the Arbitration mailboxes (like always) but you also need to move the mailbox for your admin account that is used for the install.

8. Exporting a certificate from Exchange 2010 CAS removes the SMTP binding and all mailflow stops, Edge Sync dies, and you have to re-bind the services to the cert.
   - We probably jumped on this part too soon: we were waiting for infrastructure team to get our Load Balancers ready and we wanted to get as much Exchange stuff done as we could. Doing so broke our production 2010 environment.

9. When migrating UM custom greetings, keep your filenames short. For some reason, the greetings would get criss-crossed from one Auto-Attendant to another. After shortening the filenames, it worked as it should.