• Demystifying Exchange 2010 database availability group (DAG)

    What is a DAG?

    A database availability group (DAG) is the base component of the high availability and site resilience framework that is built into Exchange 2010. A DAG is a group of up to 16 Mailbox servers that host a set of databases and provide automatic database-level recovery from failures that affect individual servers or databases. Exchange 2010 uses the same continuous replication technology found in Exchange 2007. Exchange 2010 combines on-site data replication (CCR) and off-site data replication (SCR) into a single framework which is the DAG. Once servers have been added to a DAG, administrators can add replicated database copies incrementally, and Exchange 2010 switches between these copies automatically, as needed, to maintain availability.

    When can I create a DAG?

    After you've deployed Exchange 2010, you can create a DAG, add Mailbox servers to the DAG, and then replicate mailbox databases between the DAG members. A DAG can be created using the New Database Availability Group wizard in the Exchange Management Console, or by running the New-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. When creating a DAG, you provide a name for the DAG, and optional witness server and witness directory settings. In addition, one or more IP addresses are assigned to the DAG, either by using static IP addresses or by allowing the DAG to be automatically assigned the necessary IP addresses using Dynamic Host Configuration Protocol (DHCP).

    Do I need to setup windows cluster for the DAG to work?

    No, there is nothing called a standalone or clustered Exchange 2010 installation. After you install a normal Exchange 2010 mailbox server, you need to run the New-DatabaseAvailabilityGroup cmdlet to create a DAG, once the DAG has been created, mailbox servers can be added to the DAG. When the first server is added to the DAG, a cluster is formed for use by the DAG. DAGs make limited use of Windows Failover Clustering technology, namely the cluster heartbeat, cluster networks, and the cluster database (for storing data that changes or can change quickly, such as database state changes from active to passive or vice versa, or from mounted to dismounted and vice versa). As each subsequent server is added to the DAG, it is joined to the underlying cluster (and the cluster's quorum model is automatically adjusted by the system, as needed), and the server is added to the DAG object in Active Directory. And because DAGs rely on Windows Failover Clustering, they can only be created on Exchange 2010 Mailbox servers that are running Windows Server 2008 Enterprise Edition or Windows Server 2008 R2 Enterprise Edition. In addition, each Mailbox server in the DAG must have at least two network interface cards in order to be supported

    What's happening when I create a DAG or join a server to an existing DAG?

    When the first Mailbox server is added to a DAG, the following occurs:

    -       The Windows Failover Clustering component is installed, if it is not already installed.

    -       A failover cluster is created using the name of the DAG.

    -       A cluster network object (CNO) is created in default computers container.

    -       The name and IP address of the DAG is registered as a Host (A) record in DNS.

    -       The server is added to DAG object in Active Directory.

    -       The cluster database is updated with information on the databases that are mounted on the added server.

    When the second and subsequent servers are added to the DAG, the following occurs:

    -       The server is joined to Windows Failover Cluster for the DAG.

    -       The quorum model is automatically adjusted:

    -       A Node Majority quorum model is used for DAGs with an odd number of members.

    -       A Node and File Share Majority quorum is used for DAGs with an even number of members.

    -       The witness directory and share are automatically created by Exchange when needed.

    -       The server is added to DAG object in Active Directory.

    -       The cluster database is updated with info on mounted databases

    Can I have DAG members from different subnets?

    Yes, during the cluster creation, the Add-DatabaseAvailabilityGroupServer task retrieves the IP address(es) configured while you are creating the DAG, takes whatever appropriate IP and ignores the ones don't match any of the subnets found on the server. This gives you the flexibility to have a DAG with members on the same or different subnets "in case you will have a DAG node in another datacenter".

    Can I use a 3rd party replication tool to replicate the databases in the DAG?

    By default, a DAG is designed to use the built-in continuous replication feature to replicate mailbox databases between servers in the DAG. If you are using third-party data replication that supports the Third Party Replication API in Exchange 2010, you must create the DAG in third party replication mode by using the New-DatabaseAvailabilityGroup cmdlet with the ThirdPartyReplication parameter, but note that Once this mode is enabled, it cannot be disabled.

    Can I encrypt the DAG network traffic?

    DAGs support the use of encryption by leveraging the encryption capabilities of the Windows Server operating system. DAGs use Kerberos authentication between Exchange servers. Microsoft Kerberos SSP’s EncryptMessage/DecryptMessage APIs handle encryption of DAG network traffic. Microsoft Kerberos SSP supports multiple encryption algorithms. The Kerberos authentication handshake picks the strongest encryption protocol supported in the list: typically AES 256-bit, potentially with a SHA Hash Message Authentication Code (HMAC) to maintain integrity of the data

    Can I compress the DAG network communication?

    DAGs also support built-in compression. When compression is enabled, DAG network communication uses XPRESS, which is Microsoft’s implementation of the LZ77 algorithm. This is the same type of compression used in many Microsoft protocols, in particular, MAPI RPC compression between Outlook and Exchange

    What is the minimum network interfaces required for a DAG?

    Although a single network is supported, we recommend that each DAG have at least two networks: a single MAPI network and a single Replication network. This provides redundancy for the network and the network path, and enables the system to distinguish between a server failure and a network failure. Using a single network adapter prevents the system from distinguishing between these two types of failures.

    What will happen if one of my DAG networks encountered a failure?

    In the event of a failure affecting the MAPI network, a server failover will occur (assuming there are healthy mailbox database copies that can be activated). In the event of a failure affecting the Replication network, if the MAPI network is unaffected by the failure, log shipping and seeding operations will revert to use the MAPI network. When the failed Replication network is restored, log shipping and seeding operations will revert back to the Replication network. To increase the high availability on your DAG, additional MAPI and/or Replication networks can be added, as needed. Also you can prevent an individual network from being a single point of failure by using network adapter teaming or similar technology.

    Can I host other roles on a mailbox server that is member of a DAG?

    Unlike Exchange 2007, where clustered mailbox servers required dedicated hardware, Mailbox servers in a DAG can host other Exchange roles (Client Access, Hub Transport, Unified Messaging), providing full redundancy of Exchange services and data with just two servers. This can be an excellent option for small and medium organizations where the number of mailboxes and email traffic doesn't require a dedicated hardware for each role.

  • Facts about Exchange 2007 SP2…

    Exchange 2007 SP2 is coming very soon and I thought of highlighting some important facts about it:

    • Installations of Exchange 2007 SP2 will require Windows Installer 4.5
    • Exchange 2007 SP2 will Include Exchange 2010 schema. This will not eliminate the need however to run PrepareSchema when you deploy Exchange 2010 as we still have some checks we want to run and preps we need to do for 2010. However you need to plan for a schema preparation before deploying SP2.
    • New blocking setup prerequisites to address: http://msexchangeteam.com/archive/2008/09/05/449764.aspx
    • Exchange Volume Snapshot Backup Functionality - A new backup plug-in has been added to the product that will enable customers to create Exchange backups when a backup is invoked through the Windows Server 2008 Backup tool. Exchange Server 2007 didn't have this capability on Windows Server 2008 and additional solutions were required to perform this task.

     

    Read more at http://msexchangeteam.com/archive/2009/05/11/451281.aspx

  • Update Rollup 9 for Exchange Server 2007 Service Pack 1 has been released

    We have released Update Rollup 9 for Exchange Server 2007 Service Pack 1 (KB 970162) to the download center. The release of the rollup via Microsoft Update will happen on July 28. Read the details at http://msexchangeteam.com/archive/2009/07/17/451835.aspx also KB 970162 has more details about this release and a complete list of all fixes included in this rollup.

     

    Note this important point in the article “Support for Windows Server 2008 R2 Domain Controllers in the environment (Note: Exchange Server 2007 itself is not supported to be installed on a Windows Server 2008 R2 system

  • Large Message Processing in Exchange, Part 1: Prevention and Planning

    An Excellent article that you should read at http://msexchangeteam.com/archive/2009/07/07/451737.aspx

     

    Thanks Scott Landry, Mohammad Nadeem and Bill Long for this great blog,

  • Exchange 2010 Archiving... Why to Archive???

    From few weeks I was reading about Exchange 2010 archiving and I thought of blogging about it to summarize what we can do with Exchange 2010 Archiving and what is the advantage from using it.

    Why Archive E-Mail:

    1. As data volume grows inside the mailboxes, outlook performance starts to decrease
    2. Archiving helps in eliminating PSTs. Let’s not forget that PSTs also add to further performance/management issues and adds lot of challenges to compliance and discovery
    3. Manual retrieval cost for old data can be huge (backup tapes, PSTs, etc...)
    4. PSTs are accessible on local machine only
    5. PSTs can be easily corrupted “can be a big issue without a backup”
    6. Lost laptop results in exposure of PSTs content

    Exchange 2010 Archiving features:

    1. Secondary Personal Archive. It acts as a secondary mailbox node. The archiving mailbox must be in the same database hosting the primary mailbox
    2. Controlled Retention Policies. It provides integrated retention policies on the folder/item level
    3. Multi Mailbox Search. Delegated non-IT compliance officers, HR, legal, etc... Can do a legal multi-mailbox search using a role-based GUI. Search can be filtered using multi criteria such as sender, receiver, expiry policy, message size, IRM protected items, etc...
    4. Legal Hold. Suspected mailbox can be put on legal hold to be included in a multi-mailbox search. Users can be notified in their outlook that their mailbox is under legal hold.
    5. Ease of Access. Appears alongside a user's primary mailbox in outlook or outlook web access
    6. Easy PST Migration. Supported drag & drop for PSTs to the personal archive for easy migration of existing PSTs
    7. Controlled Quota. Archive quota can be set separately from primary mailbox
    8. Retention Policies Integration. Mail in primary mailbox can be moved to the archive through integrated retention policies.

    Advantage of Archive:

    1. Compliance & Discovery. PSTs are difficult to be discovered by IT administrators. With Archiving it's possible for data discovery and legal hold for all mailbox content
    2. Data Protection. With PSTs it is very complex to protect the data inside the PSTs by the company backup system. With Archiving all mailbox content can be protected by the backup system.
    3. Quota Management. Previously users were forced to keep track on their quota and move data to their PSTs. Archiving allow for large mailboxes and for automatic archiving to the old data to the archive mailbox.
    4. Reduced Cost. No additional licenses required, it's a part of the Exchange 2010 ECAL
    5. Multi Storage Options. With Exchange 2010 & archiving you can host your data on DAS-SATA storage architecture to reduce storage costs

    So looking to the above, I can say that for most of the organizations who will be looking for getting rid of PSTs and giving large mailboxes for their users, Exchange 2010 Archiving will be your arm to do that.