Hello and welcome to the Third edition of the Consultants’ Corner.
In this edition, I will address some of the questions that have reached me through “I have heard that. . .” statements. Unfortunately, in our field some people are reluctant to admit they might not know the answer, and instead give false or misleading statements and opinions. In an effort to help you avoid being a victim to such misguided answers, I will share with you some common misconceptions that I have encountered with my own consulting clients.
I have heard that I can’t upgrade from Exchange 2007 to 2010 in place, and that the same is true for OS (I cannot upgrade from Windows 2008 SP2 to Windows 2008 R2.) Is this true?
The first part is correct, but the second part is only partially correct. Some applications, like Exchange, do not support in place OS upgrade, so you must bring in new hardware, install the new OS on it, and shift the application from the OLD system to the NEW system. Other applications support in-place OS upgrades, such as Domain Controllers and file servers.You must know the application being used, and always check its supportability for in-place OS upgrades. Be cautious as some people get confused between the Exchange OS upgrade statement and the general in-place upgrade statement.
I have heard that I cannot use my SAN as a storage device with Exchange 2010, but I have invested a lot in the SAN. What should I do?
The new Exchange 2010 Architecture makes Exchange 2010 deployment possible on SATA-II disks. However, that does not mean that Exchange 2010 will not benefit from the SAN performance edge. You can still use the SAN and benefit from it.
I have heard that we need the FSW when we deploy a DAG. I am planning to deploy 3 node DAG clusters, but where should I place the FSW?
You do not need the FSW if you deploy an odd number of cluster nodes since with an odd number you can have the majority. The FSW is required for even number of nodes since you might get an equal number of nodes in each site and thus will not be able to form majority which will cause the cluster to fail. DAGs uses the MNS (Majority Node Set) quorum model so when the cluster node can form majority, they can start the cluster service.
I have heard that Exchange 2007 and 2010 introduce database portability, so instead of moving mailboxes can I copy the EDB file, import to an Exchange 2010 mailbox server and then be done?
DB portability is a nice feature that enables you to move EDB files between servers in case of failure and import them to a new server on different HW, but this can’t be done between different versions of Exchange. Thus, EDB files from Exchange 2007 must be imported to an Exchange 2007 server. You cannot import them to an Exchange 2010 server.
I have heard that I need to buy special hardware to load balance my Internet connectivity as well as my WAN connectivity. However, I cannot afford those fancy boxes. What I can do instead?
There are some simple tricks that you can use to load balance or failover in case of internet or WAN connectivity problems.
For load balance, you can use TMG 2010 and the built-in ISP redundancy to provide HA and NLB for the network connection. If you load balance internet using other methods then prepare the cash!
For HA there is a simple trick: either use TMG 2010, or configure your router or Firewall (whatever the routing device is) to have 2 static routes with different priority. Make the lowest priority your primary link in case the primary link drops, then the device will use the backup route. This is a simple yet effective option.
I hope these answers helped clarify any misleading statements you may have encountered. If you are not sure about something or have a technical question that has you stumped, let me know! Email your questions to ESE@ENowinc.com.
Make sure you catch my next article where I will share with you some cool Exchange 2010 SP1 features.
Until then, wishing you the best uptimes and the fastest Exchange servers.