A quick post to share my happiness in getting this site listed in Microsoft Exchange Team Blog. It is listed under the “Other Cool Places” on the right hand side of the team blog. This is a real inspiration for writing more articles on Exchange Server and I will try to publish an article on a daily basis.

Thanks Nino Bilic (MSExchangeTeam) for the support.

Datacenter Activation Coordination (DAC) Mode is a property of a DAG which can be turned on or off. DAC mode is disabled by default and should only be enabled for DAGs with three or more DAG members that have been deployed in a multi-datacenter configuration. DAC mode shouldn’t be enabled for

• 2 member DAGs where each member is in a different AD site
• 2-16 member DAGs where all members are in the same AD site

In case you try to turn on DAC where it is not supported, an error will be returned.

Note: In the expected Exchange 2010 SP1, DAC mode will be extended to support two-member DAGs that have each member in a separate datacenter. In addition, DAC mode will be extended to support DAGs that have all members deployed in a single Active Directory site, including AD sites that have been extended to multiple locations. So in SP1, you can now use DAC mode for all DAGs with two or more members.

DAC mode is configured to avoid a “split brain syndrome”. I will explain with an example. Let’s say we have a four member DAG, with two servers in each datacenter. The primary datacenter hosts the witness server and hence will always be in quorum. Now, let’s say that a power outage occurs in the primary datacenter and the exchange admin activates the secondary datacenter with an alternate file share witness.

When the power is restored in the primary site, servers come online quicker than the WAN links. Hence, when the two DAG members and witness server comes online, it has a quorum (majority) and will try to activate the databases. This will cause a “split brain syndrome” where both datacenters think that they are hosting the active databases.

DAC mode was introduced to avoid this situation. When DAC mode is enabled and the DAG members come back online, they will leverage a protocol called Datacenter Activation Coordination Protocol (DACP) before trying to mount the databases.  The DACP is used to determine the current state of the DAG and whether Active Manager should try to mount the databases or not.

Now for the technical bit as to how DAC works!

Active Manager stores a bit in memory (either a 0 or  1) that tells the DAG whether it’s allowed to mount local databases that are assigned as active on the server. When a DAG is running in DAC mode, each time Active Manager starts up, the bit is set to 0, which means that it isn’t allowed to mount databases. When in DAC mode, the server must try to communicate with all other members of the DAG that it knows to get another DAG member to give it an answer as to whether it can mount local databases that are assigned as active to it. The answer comes in the form of the bit setting for other Active Managers in the DAG. If another server responds that it’s bit is set to 1, it means that servers are allowed to mount databases. Hence, the server starting up sets its bit to 1 and mounts its databases.

Let’s find how DAC helps in “split brain” scenario in our example. When power is restored to the primary datacenter, the servers come online before WAN links and all of the DAG members in the primary datacenter will have a DACP bit value of 0. Hence, none of the servers in the primary datacenter will mount databases as they cannot communicate with a DAG member that has a DACP bit value of 1.

DAC mode can be turned on by running the shell command below.

Set-DatabaseAvailabilityGroup –identity “dagname” –DatacenterActivationMode DagOnly

An interesting point to note for organizations going backup-less by enabling circular logging! If circular logging is enabled on a mailbox database, you cannot create a copy of that database. The error message displayed is self explanatory.

Database DB1 has circular logging enabled. It is not possible to add or remove database copies while circular logging is enabled. Please disable circular logging before adding or removing mailbox database copies.

Of course, you can disable circular logging and proceed with creating a database copy. So, what about organizations that want to use circular logging for one reason or the other? The process is to disable circular logging first, create a mailbox database copy and then enable circular logging. By default, circular logging is not enabled.

The process has to be reversed if you want to remove a database copy which has circular logging enabled.

Circular logging can be enabled or disabled using the console or shell. Launch the properties of the database and navigate to “Maintenance” tab. Check/uncheck the box for desired result.

Each time circular logging is enabled or disabled, the database has to be dismounted and mounted back for the changes to take effect.

It is important to configure the network adapter settings correctly for a DAG member. Few points that need to be noted:

• Single NIC for DAG members is supported.
• All DAG members should have the same number of networks, MAPI and Replication networks.
• DAG members can have only one MAPI network and zero or more Replication networks.
• Persistent static routes are used to configure traffic in a replication network.
• It is recommended to have atleast two DAG networks, MAPI and a replication network.

The MAPI network should be connected to the production network, so that it can talk with other Exchange servers, AD, DNS etc. The MAPI network (NIC) should be configured as given in the table below.

Configure the following as well for the MAPI network.

• The IP address can be manually assigned or configured to use DHCP. If DHCP is used, use persistent reservations for server’s IP address.
• The MAPI network typically uses a default gateway, although one isn’t required.
• At least one DNS server address must be configured. Using multiple DNS servers for redundancy.
• The “Register this connection’s addresses in DNS” checkbox should be checked.

The Replication network (NIC) should be configured as given in the table below.

Configure the following as well for the MAPI network.

• The IP address can be manually assigned or configured to use DHCP. If DHCP is used, use persistent reservations for server’s IP address.
• The Replication network typically doesn’t use a default gateway. If MAPI network has a gateway configured, then, no other networks should have a default gateway.
• DNS server address should not be configured.
• The “Register this connection’s addresses in DNS” checkbox should be unchecked.

Finally, the binding order has to be such that MAPI network comes first in the list.

Reference: Technet

In Exchange 2010, the way emails get routed changes when you have a DAG member that hosts both the Mailbox and HUB transport role. This change was brought in to ensure the protection of messages while it uses Dumpster 2.0

For example, let’s say that I have a server named EXCH1 which hosts both Mailbox and HUB role. Emails that are sent to a mailbox in EXCH1 will be handled by the HUB transport role present on the same server. This is the default behaviour.

Now, let’s say that we have a DAG with servers (EXCH1, EXCH2 etc) hosting all the three roles. When a message is sent to a mailbox located on EXCH1, the transport re-routes the email to a different hub transport server in the same AD site (say EXCH2) and that server delivers the email to the mailbox in EXCH1. This extra hop was added to put the message in the transport dumpster on a different HUB transport server.

In short, the HUB transport server role was modified so that it reroutes a message for a local mailbox server to another HUB transport server in the same site, if both HUB and Mailbox roles are on the same DAG member.

The Exchange Mail Submission service was also modified so that it would not submit messages to a local HUB transport server when the Mailbox & HUB transport role co-exist on a DAG member. Instead, it will try to load balance submission requests across other HUB transport servers in the same AD site and fall back to a local HUB server if there are no other available HUB servers in the same site.

Command Logging is a new feature in Exchange 2010 Console. It can be used to track all changes made using the exchange console. The list of commands can be exported into a file if needed.

The feature is not enabled by default. In order to turn it on, launch EMC (of course), navigate to View –> View Exchange Management Shell Command Log.

Clicking onto it opens the Command Log window.

Select “Action” and click on “Start Command Logging”.

From now on, anything that you do in the console will be logged. The log will be the cmdlets that was run in the background to make the actual changes.

As soon as the console is closed, the logged information is lost. You can export the log into a file if needed.

In order to stop the command logging, select “Action” and click on “Stop Command Logging”.

Useful feature if you want to log what changes you are making in the console or to share what you have done with your colleague.

Some organizations have strict security policies when it comes to email. Most of you have seen a request from HR or Legal asking you to block a particular user (maybe a temp) from sending and receiving emails from outside the organization.

This can be accomplished with transport rules or a combination of transport rule and shell command.

We can configure a transport rule to block the user from sending emails externally. There are two options, either we can delete the emails which the user tries to send without notifying anyone or we can send an NDR back to the user with a customized message.

Launch EMC, navigate to Organization Configuration –> Hub Transport –> Transport Rules. Create a new rule and give a meaningful name. Select “from people” in conditions page and select the mailbox account. We can also create a group and add the group if more number of users have to be blocked and unblocked on a regular basis.

From the actions page, select one of the options depending on your choice.

Configure any exceptions if needed, click on “New” and “Finish” to create the rule.

Now, let’s block the user from receiving emails from the internet. Everyone knows that the distribution groups in Exchange 2010 doesn’t accept emails from outside the organization by default. This is because of the check box “Require that all senders are authenticated” in the group’s property.

The same can be applied to a mailbox as well. This option is not exposed in the EMC and hence the shell has to be used. By default, anyone can send an email to a mailbox, as the “RequireSenderAuthenticationEnabled” is set to false.

Run the following command to block external emails for a user, say ChakkaRajith in my case.

Set-Mailbox –identity “ChakkaRajith” –RequireSenderAuthenticationEnabled $true

We can also block emails from internet to a user using transport rule. It is advisable to create a group, say “NoExternalEmails” and add members to it, if the user list changes frequently. Create a transport rule as explained above with the below conditions.

The steps are same for Exchange 2007 and is explained in my article posted in 2009.

A quick post to share the Exchange Server and Update Rollup build numbers.

Exchange 2007 SP1

Exchange 2007 SP2

Exchange 2010

Source: Microsoft Wiki Page

Anyone who has been in the Exchange field for a while should have come across this kind of a request atleast once; a staff goes on holidays without setting an out-of-office message and calls the IT department to set one for him/her. With 2010 and the new Exchange Control Panel (ECP), this request can be easily handled.

Login to the ECP as an administrator. Use owaurl/ecp or owaurl/owa and click Options.

Select “Another User” from the drop down window on the top left hand side. Allow pop-ups for this site.

Select the user for which you want to set OOF. I am selecting Chakka Rajith as an example.

Another window opens up. You will see a warning that “Administrator is working on behalf of the user”.

Click on “Tell people you are on vacation” link on the right hand side or navigate to Organize Email –> Automatic Replies.

Type in the OOF message and click Save.

Close the window, return to the administrator ECP section and log off.

The benefit in this method is that the admin account doesn’t have to be given explicit rights on the user’s mailbox. No messing around with ACLs!

The same can be done using Exchange Shell as well. Check my article (second half) for the steps.

Microsoft has a webcast detailing how their IT department deployed Exchange 2010. It goes into detail as to the number of Exchange servers they had and have now, where their datacentres are located etc.

Main points from MSIT Exchange 2010 deployment.

• MSIT uses physical servers for all Exchange 2010 servers.
• Hardware load balancers are used to load balance Exchange protocols and services (No WNLB!).
• Mailboxes are hosted on SAS drives in JBOD (Just a Bunch Of Disk) configuration.
• 30 days deleted item retention and litigation hold used for long term preservation of data.
• Backup-less Exchange environment.
• Four copies of each database. Intention is to reduce the number of copies to three.
• No site resilient copy of database.
• No lagged copies. Lagged copies were configured initially, but taken off.
• No Edge servers in use. Forefront Online Protection for Exchange (FOPE) is use instead.
• Cookie based load balancing for OWA & ECP and IP based for EWS, Autodiscover, EAS, RPC and UM.
• SCOM used for monitoring and Exchange 2010 management pack enhances reporting capabilities.
• 5GB mailbox limit in place.

View the webcast for more information.