1

By chance, I've been asked to do some research on a migration from Exchange 2003 to 2010. I've been working with Exchange 2007 for some years but without any formal certification or the likes.

I've been reading a lot of educational material and whitepapers to get a grasp of the migration process and new concepts in 2010. My goal is to get a solid understanding of what is going on, make overall suggestions to the topology and be able to provide competent assistance in case we'll hire an external company to take care of the migration.

Overall topology:
I feel fairly confident about my overall understanding of the roles and principles of the high-availability setup - although I have few bonus questions I hope you can assist me with :)

  • 1x EDGE server
  • 2x CAS/HT servers configured with a CAS array via NLB
  • 2x MB servers configured in a simple DAG.

Now, for the above setup I've been wondering about a few things:

  • With 2 MB servers in a DAG, will I need a witness server in my setup?
  • Regarding mailbox databases - what is your strategy for splitting up the databases? By size, volume or...?

Certificates:
I admit, that my knowledge about certificates are fairly basic - I'm working on that :). When ordering a SAN certificate from our provider does this certificate also have to include internal addresses or simply the external FQDNs? What I mean is, that I need to include the mail.contoso.com, autodiscover.contoso.com and legacy.contoso.com but beside that, do any internal names need to be included? And what about multiple TLD extensions - do these need to be accounted for in the SAN certificate as well?

I think the above questions are what have been puzzling me the most. I'm eager for some feedback on this little project of mine and I appreciate any good advice :)

Ben Pilbrow
  • 12,041
  • 5
  • 36
  • 57
Christian A.
  • 47
  • 4

2 Answers2

3

If you have an even number of Mailbox servers in a DAG a file share witness is required, so in your case you will. Microsoft recommend you use a Hub Transport server as your witness server. If your witness server isn't an Exchange 2010 server, you'll need to add the Active Directory computer account to the Exchange Trusted Subsystem security group.

Also bear in mind that the disk layout on both your DAG servers must be identical. If on one server you have the Operating System on C:, your databases on E: and your transaction logs on F:, this must be the same on the other server.

You should split up your databases as you see fit really, and I'm not aware of any official guidelines. I will list you some common enough reasons though.

  • Mailbox Quotas
  • Separation of business units
  • Separation of physical locations
  • Performance. The less users a Mailbox DB has, the quicker it will be. If your database files are all on one volume though, your disk subsystem may then become a bottleneck.
  • Your recovery time objective. The smaller a database is, the quicker it can be restored in the event Something Bad Happens™.
  • By surname. There's no real rhyme nor reason to this one - it just distributes people across the available databases.
  • Randomly. Again, this is just to distribute people amongst databases evenly and only really works if you don't use databases for policy related things such as quotas. If you have more that one database and you don't specifically home a Mailbox when you create it, Exchange will just pick any one for you. FWIW you can exclude certain databases from this process using Set-MailboxDatabase <The DB Name> -IsExcludedFromProvisioning $true.

With regards to your certificate, you should run through the certificate wizard that Exchange 2010 provides you with. After you fill in the appropriate information, it will ultimately generate you a certificate request that you are able to send to a CA to generate a certificate. It handles all the various subdomains you need (ActiveSync, AutoDiscover, OWA etc) and is quite straightforward to complete.

Ben Pilbrow
  • 12,041
  • 5
  • 36
  • 57
  • thank you for your answer - I really appreciate it. I hadn't seen the recommendations from Microsoft about using a HT server as witness server. Thanks for pointing that out. Very nice list of things to take into consideration about the databases. Regarding the certificates, I have been looking at the wizard in Exchange 2010 which really is what have made me wonder about the internal FQDNs. Many of the fields in the wizard are filled out with local machine names from the beginning. I imagined to do as @Phil pointed out and create internal DNS records for the external names. – Christian A. Apr 19 '11 at 07:37
1

In answer to your certificates question, our set up is as follows

Our servers are all on our internal network/domain with FQDNs of, for example, [xxx].internal.lan. However, we have a split DNS set up so on our internal DNS servers, e.g. exchange.company.com is an alias for exchange.internal.lan

That way we can publish the server externally through our firewall and tell people to use exchange.company.com regardless of whether they are inside the network or outside.

We publish autodiscover, OWA, ActiveSync etc.

We therefore only need a single wildcard certificate for *.company.com that we use on the Exchange servers for e.g. autodiscover.company.com, exchange.company.com, etc. etc.

Phil
  • 3,168
  • 1
  • 22
  • 29
  • Hi @Phil, thank you for your reply. Microsoft recommends not using wildcard certificates for security reasons so I've mainly been looking into SAN certificates. But if I get what you're saying, you have only included the external FQDNs in your certificate and than you rely on your DNS to, when internal, direct the request strictly internal? – Christian A. Apr 18 '11 at 09:53