Exchange 2007 General Questions and Answers
Question 1>
So, many times I have been asked that Exchange 2007 SCC (Single Copy Cluster) – why can’t a hub transport role be installed on it?
Answer 1>
By default, connections to Hub Transport servers are automatically load balanced if more than one Hub Transport server is deployed in an Active Directory site. If one Hub Transport server is unavailable, the operational Hub Transport servers continue to accept connections. If all Hub Transport servers in an Active Directory site are unavailable, messages are queued until a Hub Transport server becomes available or the messages expire.
Load balancing of outbound connections to remote domains is achieved by specifying more than one Hub Transport server in the same Active Directory site as a source server for the Send connector. Load balancing does not occur when the source servers for a Send connector are located in different Active Directory sites.
So we do not need to and we cannot install HUB on SCC or CCR.
Exchange 2007 cluster setup is an integral part of the Exchange 2007 setup program, there is no need to install exchange and then configure the exchange server for the cluster. Once the MSCS is installed Exchange setup will detect that successfully and provide the option to install either Cluster Continuous Replication or a Single Copy Cluster in an Active clustered mailbox role or passive clustered mailbox role.
High availability for Exchange 2007 Hub Transport, Edge Transport, Client Access, and Unified Messaging server roles is achieved through a combination of server redundancy, Network Load Balancing, DNS round robin, as well as proactive server, service, and infrastructure management.
In general, you can achieve high availability for HUB Server Role using the following strategies and technology:
You can deploy multiple Hub Transport servers for internal transport high availability. Resiliency has been designed into the Hub Transport, as well as the Mailbox Submission Service on Mailbox servers, for deployment of Multiple Hub Transport servers.
Question2>
In a CCR environment, if I send a message to another mailbox on the same cluster, does it have to go out on the network to a hub transport and then back in again to the mailbox? If so, why?
Answer2>
Yes, If a message is sent to another mailbox on the same cluster, it does have to go out on the network to a hub transport server. This procedure lets us use the new feature named Transport Dumpster of HUB Transport server.
The bulk of the lost data that occurs during an automatic recovery is subsequently automatically recovered by a Hub Transport server feature called the Transport Dumpster. The transport dumpster is a required component for CCR deployments. The transport dumpster takes advantage of the redundancy in the environment to reclaim some of the data impacted by the failover. Specifically, Hub Transport servers maintain a queue of recently delivered mail.
This queue is bound by the amount of time mail is kept and the total space used. When a failover is experienced that isn’t lossless, CCR on the clustered mailbox server automatically requests every Hub Transport in the Active Directory Site to resubmit mail from the transport dumpster queue. The information store automatically deletes the duplicates and re-delivers mail that was lost.
The transport dumpster is only enabled for CCR. It is not enabled for local continuous replication or single copy clusters. The necessary condition for an e-mail to be retained in the transport dumpster is that it has at least 1 recipient whose mailbox is on a clustered mailbox server in a CCR environment.
The transport dumpster is designed to help protect against data loss by providing an administrator with the option to configure CCR such that the clustered mailbox server will automatically come online on another node, with limited amount of data loss. When this happens the system automatically re-delivers all the recent e-mails sent to users on this server, by taking advantage of the transport dumpster where these e-mails are still stored.
This helps to prevent data loss in most situations. Situations in which data loss is not mitigated by the transport dumpster includes:
- Drafts folder for any Microsoft Outlook clients in online mode.
- Appointments, contact updates, property updates, tasks, and task updates.
- Outgoing mail that is in transit from the client to Hub Transport. There is a period of time during which the e-mail only exists on the sender’s mailbox server.
In Exchange 2007 SP1, the transport dumpster feature has been improved:
Support for LCR The transport dumpster now includes support for LCR deployments. Unlike CCR, in which the request for transport dumpster redelivery is an automatic part of the recovery process, the process is manual in an LCR environment. The Restore-StorageGroupCopy cmdlet has been updated in Exchange 2007 SP1 to include the transport dumpster resubmission request. Thus, when an administrator activates a passive copy of a storage group in an LCR environment using the Restore-StorageGroupCopy cmdlet, the transport dumpster submission request occurs as part of the activation process.
Question 3>
If hub transport can’t be installed in a cluster, can it be installed on the physical nodes of the cluster? If not, why?
Answer 3>
No, it cannot be installed on the physical nodes of the cluster, because Exchange 2007 cluster setup is an integral part of the Exchange 2007 setup program, there is no need to install exchange and then configure the exchange server for the cluster. Once the MSCS is installed Exchange setup will detect that successfully and provide the option to install either Cluster Continuous Replication or a Single Copy Cluster in an Active clustered mailbox role or passive clustered mailbox role.
Question 4>
The transaction log size has been reduced from 5MB to 1MB, is it possible to increase it back to 5MB?
Answer 4>
No, It is not possible to increase it back to 5 MB and that’s the another change in Exchange Server 2007, that the transaction log files are now 1MB instead of 5MB as was the case in previous versions of Exchange. So what’s the reason behind this decision? Well in previous versions of Exchange if a crash destroyed the last few log files that hadn’t been committed to the database yet, you would need to restore or repair the database to have it mounted again. Exchange Server 2007 introduces a new feature called Lost Log Resilience (or LLR in short) which will hold the last few log files in memory until the database is shut down. This means that you will never have a case where part of for example log file 100 has been written to the database, but part of log file 99 hasn’t. The benefit of this is that if you don’t have anything against losing the last few log files, you can tell Exchange to simply throw away the data and mount the database.
So the reason why the log files has been reduced to 1MB is to reduce LLR exposure. Now if you lose the last log, it costs up to 1MB of the most recent data instead of 5MB.
Another improvement worth mentioning is that the log file sequence numbers now can go above 1 million. As you might be aware previous versions of Exchange had a limit of 1 million, so if a database had been running long enough and generated a million logs, you had to shut it down and start over from log #1 ("reset the log sequence"). This would happen every few years for most databases. With the smaller log sizes and the increasing amount of messages passing through most databases, the Exchange Product group decided 2 billion log files (per storage group!) would be a better maximum log number.
The log file size is changed from default 5MB to 1MB to support the continuous replication features in Exchange 2007. This reduces the window of data loss to significantly lower. In the ratio of 1:5.
Question 5>
Our servers create 1000’s of transaction logs per day, so as the transaction logs file size is reduced to 1 MB from 5 MB, won’t creating five times the number have an impact on the performance of the systems?
Answer 5>
No, because the in Exchange 2007 the generated log is 5 Times smaller than the previous version of exchange.
In fact we decreased the transaction log size to minimize the amount of data that can be out of sync between two copies of the Storage Group, for Example in CCR. This comes into play when, let's say, the production database hard drive crashes and you then need to take action to start the SG from the copy. Smaller transaction logs will give you a better chance of less data loss.
Jagmeet Singh,
Senior Support Engineer, Exchange Server Team
Reviewed by
M Sivagami Sundari,
Technical Lead, Exchange Server Team