I had written an article previously explaining the HP & Dell sizing tools for Exchange 2007. HP has released a similar tool for Exchange 2010, more info here. Dell has followed the path and has released a sizing advisor tool for Exchange 2010. Unlike other sizing tools, Dell Advisor is an online one and hence solutions cannot be reused. The tool supports DAG and DAS/SAN based storage.
Access the Exchange 2010 Advisor here
I had covered the topic of what to look for before creating a DAG in one of my previous article. In this one, I am going to highlight the facts you need to consider while designing a Database Availability Group. Without going over the DAG feature again, let me list the points to note.
Public folder replication is the process by which public folder content and hierarchy are replicated across multiple servers for fault tolerance. Public folder databases replicate two types of public folder information, hierarchy and content. Each public folder database retains a copy of the hierarchy where as content replicas exist only on the public folder databases that you configure. If you find that the public folder hierarchy on one server is different from the public folder hierarchy on other servers, you can synchronize the hierarchy using Update-PublicFolderHierarchy cmdlet.
Unlike in Exchange 2007 (CCR with only one public folder database in the org), you can't use continuous replication in Exchange 2010 to replicate public folders. In Exchange 2010, continuous replication is only for mailbox databases. A public folder database can be hosted on a mailbox server which is a member of a DAG, but you must configure multiple public folder databases across servers and configure public folder replication for data redundancy.
The concept of lagged database copies was introduced in Exchange 2007, implemented using Standby Continuous Replication (SCR). With SCR, we can delay the time when the logs have to be replayed to the SCR target. There is also the option of specifying truncation lag time, the option which allows us to delay the time before the log files are truncated. The maximum lag time for both the options is 7 days in Exchange 2007.
With Exchange 2010 DAG, the lag time for both replaying and deleting the logs have been increased to 14 days. This is good if your company wants to go backup-less. Of course, the company has to be aware of the risk of going without backups, as lagged database copies can’t be a solution for all recovery/restore issues.
The two parameters you need to know are ReplayLagTime and TruncationLagTime. The ReplayLagtime parameter specifies the amount of time that the Exchange Replication Service should wait before replaying log files that have been copied to the database copy location. The format for this parameter is Days.Hours:Minutes:Seconds. The default value is zero seconds.
The TruncationLagTime parameter specifies the amount of time that Exchange Replication Service should wait before truncating the log files that have replayed into a database copy. The time period begins after the log has been successfully replayed into the database copy. The format for this parameter is Days.Hours:Minutes:Seconds.
The lag times can be configured either while setting up the database copy (Add-MailboxDatabaseCopy) or after setting up (Set-MailboxDatabaseCopy).
For example, in order to setup the database copy of mailbox database MD1 to server Server1 with a replay lag time of 12 hours, run Add-MailboxDatabaseCopy –identity “MD1” –MailboxServer “Server1” –ReplayLagTime 12:00:00
The 70-663 exam, Pro: Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 is now available for candidates wishing to progress to the Microsoft Certified IT Professional (MCITP) Enterprise Messaging Administrator 2010 certification.
This exam is designed for candidates who are responsible for the Exchange messaging environment in an enterprise environment. They are senior administrators who act as the technical lead over a team of administrators. These candidates are a third level of support between the Exchange Recipient Administrator and the Exchange Server Administrator.
More information about the exam including skills measured is available here
Candidates who had already booked the beta exam successfully, but eventually got cancelled by Prometric/Microsoft can get a voucher code for a free 70-663 exam. Check my previous article for more information.
The new Forefront version for Exchange server provides a DNS Blocklist service out of the box. This means that we don’t have to subscribe to other third party companies for getting real-time blocklists. Forefront customers get the service for free. Forefront DNSBL is an aggregated list of multiple feeds from various RBL providers combined into a single lookup and hosted by Forefront Security on its own DNS infrastructure. The list of feeds includes both Microsoft internal contributing teams and external vendors like Spamhaus.
DNSBL solution is enabled out of the box without any manual work needed from the administrator to configure and maintain the filter. The DNSBL will start working immediately after the setup and there is nothing to configure. The feature is enabled by default, although it is advised to check whether the selection box is checked in the Forefront Console.
The query from DNSBL agent to the DNSBL provider is encrypted to make sure that the data is not used by non-Forefront customers. Only Forefront agent knows how to encrypt & decrypt the query.
A welcome feature and one more reason to deploy Forefront 2010 for Exchange!
Many exchange admins will be a bit confused when it comes to designing an Exchange 2010 environment with large number of users and three or more copies of databases. The question is how to design the 2010 system to withstand the worst possible failure and still provide a good experience for the users during failover.
One design recommended by Microsoft is to design for all database copies to be activated. For example, if you have 30 databases (active & passive together) hosted on one server, then the design should have processor and memory requirements for all those 35 databases to become active on the server during a failure. This is the best possible design but will be very expensive.
Another approach recommended by Microsoft is to design for targeted failure scenarios. A simple rule is to design for automatic single node failure in a two node configuration, double node failure in three server configuration (manual activation for second failure) and for automatic double node failures where the DAG has four or more nodes. The appropriate number of database copies is required to meet each of these configurations and the copies be randomly & evenly distributed. In this design approach, it is recommended to restrict the number of databases that can be activated on a server during a failover, so that the server doesn’t activate more databases than it was designed to handle and thereby giving a very poor user experience.
You can configure a hard limit for the number of databases that can be activated using the cmdlet below. For limiting the server to 25 databases, run
Set-MailboxServer –identity “servername” –MaximumActiveDatabases 25
When the maximum number is reached, the database copies on the server won't be activated if a failover or switchover occurs. If the copies are already active on a server, the server won't allow databases to be mounted. This is something that needs to be looked into while designing a highly available, high performance Exchange 2010 environment.
