Sunday, November 20, 2011

Five things to reconsider when designing Exchange Server 2010

Five things you don’t do when designing a new Exchange Server 2010 environment.

When it comes to designing a new Exchange Server 2010 environment, a lot of techies think that this isn’t so hard. They just think “Let’s put some servers and install some Exchange roles on it and the job is done”. Especially when installing these servers in a virtual environment like VMware or Hyper-V these things happen. Techies often think hey it’s virtual, therefore my design boundaries are unlimited. Well wrong, wrong, wrong thinking.



Therefore I have created a list with some things you don’t do when implementing Exchange Server 2010.

I could write whole book about this subject but some things just take experience and expertise to do the job properly.

  • Don’t think Exchange 2003 or Exchange 2007 like;


A lot of engineers or IT administrators think that if they have 1 Exchange 2003 server in their current environment, it will automatically does the trick when implementing 1 Exchange 2010 Server in their new environment. In some cases this can actually be true, in most cases however it isn’t. Because Exchange Server 2010 is using 64-bit architecture, the load of the server(s) running Exchange on it will automatically be higher.


The other fact you see a lot is the quote “Hey I have this set-up in Exchange Server 2007, let’s do the same thing in Exchange Server 2010”. Why this is wrong thinking? Well first of all Exchange Server 2010 is not Exchange Server 2007. As Exchange Server 2007 was considered as a pretty unstable messaging system, especially when working with CCR clusters, Exchange Server 2010 is not. Microsoft made a lot of improvements in for example database optimization by removing SIS (Single Instance Storage). Because of this, Microsoft realized a IOPS win of 85%. Another mayor improvement is the realization of DAG (Database Availability Groups). Creating a DAG to fore fill your HA needs is pretty simple, however designing the optimal DAG configuration does take some consideration.




  • Don’t install all Exchange roles on as many servers you can find;


When it comes to Exchange Server 2010 it is best practice to deploy multi-role servers in almost all circumstances. The great thing about Exchange Server 2010, also mentioned in the previous remark, is that because of the mayor improvement of IOPS load it is not needed anymore to install all roles separately. Another advantage of multi-role servers, is that if for one reason you need an extra server, you can just install a new one which is exactly the same as your current Exchange servers. This makes your administration and documentation easier and hey we all want that right.




  • Think to easy about HA (High Availability);


Never think to easy about HA. Installing two CAS or HUB servers, doesn’t automatically gives you HA. You always need to consider a proper load-balancing solution. Best practice is a hardware load balancer, or when running virtual a virtual hardware load balancer. Why? All clients are using your CAS server(s) to contact their mailbox and Exchange organization information. Think about what happens when a client is switched to another IP by switching to wireless or when a client is connected via outlook anywhere and gets a new IP address from it’s provider or when the request is going to one CAS server and the reply is coming from another. You don’t want this. Another reason to think about load balancing is service provided failover. When a services of one Exchange CAS or HUB transport server is not available, a hardware load balancer is aware of this and will automatically redirect traffic to the remaining servers in the load balancing server. This could also be nice if you want to put one server into maintenance to update or something else.




  • Don’t forget security from outside boundaries;


A lot of Exchange admins think hey Exchange Server 2010 is secure, why the need of a reverse proxy? Well pretty simple. Your CAS server for example are domain joint servers which are in all cases located in your internal network. What happens when a potential unwanted individual is able to use a backdoor on your system? Right this individual is now on the internal network with access to your complete Active Directory and all the information what’s in it. You don’t want this. Therefore always implement a proper reverse proxy solution like Forefront TMG or UAG to protect your internal network.




  • Design by need;


Before deciding on how many servers, how much storage, how much memory and how many CPU is needed, always write down the following facts:






      • How much mailboxes do you have in your organization?

      • What is the total amount of mail data in your organization?

      • How many e-mail does an average user receives / send per day?

      • Do you have any quota’s or does you organization wants any?

      • Is your organization using pst files as archives?

      • If yes how much storage do all pst files take?

      • Is there any way to clean up all mailboxes before migration?

      • Are you still using an older version of Outlook then Outlook 2007?

      • Etcetera…




Having these facts written down gives you a better understanding in the circumstances that you need to consider when creating you design.


In all cases, leave your thoughts and experience with previous Exchange Server versions as they are and try to look into the new technology features and design recommendations. If you are uncertain in how to do it, just hire a consultant or architect specialized in Exchange Server solutions, like me ;).

No comments:

Post a Comment