Archive for January, 2013


Exchange 2010 DAG quick tips

Thanks for Exchange DAG, having a mail database that can recover from the failure isnt dream.

Admins no longer have to rely on a complicated shared disk clusters, avoiding headaches from troubleshooting a failed clusters, setting up complicated system or even having an expensive shared disks. (However, if you are running exchange, cost of shared disk should be negligible these days. )

Completely off topic, you should be able to but HP/3PAR SAN or Dell Equallogic for less than $50K (AUD).

Now to the point

These points are for the exchange admins who runs system for less than 1000 mailboxes, it may fit even 5000, but I would recommend you to follow best practice guide if you’re such size org.

1 MAPI and REPLICATED traffic on separate network ?

if you’ve read technet or several blog posts you should find that MAPI traffic should be separated from replication traffic. Now the keyword is SHOULD, its is not necessary. In my setup, we’ve got 10G ethernet and runing on top of Hypervisors. Less than 1000 users, and over 10G access layer network, you can imagine I didnt bother with dual NIC.

Single DAG network is SUPPORTED config as well as dual NIC config. It all depends on the MAPI traffic, but frankly, I would MOVE users and create new MBX servers when I get more than 500 users hitting single MBX servers. How big is your basket and how many eggs do you want to keep it together? Eh?

2 Cross site DAG ?

Continue on point 1, if you’re over multiple data centre and generally have single path to over WAN, (thx to route costs, or STP, most traffic would via a single pipe not multiple), again dual NIC was pointless for me.

3 DAG limits

A server can be only member of a single DAG, A DAG database can copied up to 16 DAG members, if you have even number of DAG members, you must have file server as the cluster witness server.

4 Alternate Witness WILL NOT take over when main Witness server is down.

read here (open new window), its a great blog from MS (why cant they make technet doc more like this), explaining how witness falls in the grand schema of things.

BTW, if you have odd number of servers, witness may not get used. Use CLUSTER command to verify what status your cluster is set as. There are several posts you can find with google that cluster quorum node was configured without witness.

5 Cross Site DAG

if you have majority number of server (thats including a witness server) at data centre thats no longer reachable, your database on the local network WILL SHUTDOWN.

eg DC A, with two mail servers and a file share as a witness, DC B, with two mail servers.

If DC B loses connectivity to DC A and mail servers in DC B isnt able to communicate to witness, it will treat the situation as non quorum status and cluster service will shutdown the mail database.

Cross site DAG isnt perfect, this is why some recommends to create multiple DAGs. (eg DAG1 for DC A users, DAG2 for DC B’s users.)

Now to troubleshoot

c:\>cluster <dagname> /quorum

if you’re monitoring the server’s services (like many admins do..) make sure you add CLUSTER SERVICE as well. If cluster service crashes DAG mail database will be dismounted together as well. (oh joy..)

i’ll try to add few more later on.


Cleaning up user profiles

having large number of users’ profile on the file server creates problem in the long run.
Number of Cookies on the share can cause headache of its own.
Using Citrix User Profile Manager reduces the headache, but its still not good enough to leave unused cookies.

To clean it up from the file server, I’ve written some simple script.

For Normal single Company

For Citrix Provider (Multi-tennant)

January 2013
« Feb    

Greyeye Tweets