Microsoft Exchange Server 2007 Most organisations classify Exchange 2007 as a critical business system and consequently cannot afford to lose a single email let alone an entire database.  Dataplex architect, implement and manage Exchange environments for our clients no matter what the scale.  Beyond the mailbox, Dataplex can also leverage email security products to maximise and protect your investment.

Exchange 2007 is the Microsoft messaging and collaboration server designed to help your business communicate more effectively. Along with the rich client functionality provided by Microsoft Office Outlook, Exchange 2007 offers mobile, remote, and desktop e-mail access with state-of-the-art security and privacy.

Exchange Server 2007 provides a complete messaging system that can run on a single server – meaning that all Exchange services reside on one server, as with the Microsoft Small Business Server product. However, there are significant gains in deployment, management, and security that come from having a flexible, modular system that can be installed across more than one machine. This concept was first introduced in Exchange 2000 Server; where a front-end server could be configured to proxy inbound Internet client protocols to the appropriate mailbox server. Front-end servers are optional and can reduce the load on mailbox servers and simplify Microsoft Office Outlook® Web Access (OWA) and Exchange ActiveSync (EAS) user access. Having front-end servers in medium-size and large organisations made Exchange more scalable by concentrating particular tasks on a limited number of servers.

In Exchange Server 2007, role-based deployment has been expanded, allowing you to assign predefined roles to specific servers. These roles allow organisations to control mail flow, increase security, and distribute services, as shown in the following illustration.

Client Access role. Similar to the front-end server in earlier versions of Exchange, this server proxies Internet client traffic to the correct mailbox server.

Mailbox role. This role hosts user mailboxes stored in databases that can be replicated or clustered.

Hub Transport role. This role provides internal routing of all messages – from Edge servers, Unified Messaging (UM) servers, or between two users on the same mailbox database. The Hub Transport role is also where messaging policy is enforced for
messages moving within and outside the organisation.

Unified Messaging role. This role enables PBX integration to allow voice mail and fax messages delivered to Exchange mailboxes, and provides voice dial-in capabilities to Exchange Server. This role and its services are explained in more detail later in this paper.

Edge Transport role. This server resides outside your internal network and provides on-premise e-mail security, antivirus, and anti-spam services for Exchange. Off-premise filtering can be provided by Exchange Hosted Filtering, discussed later.


The 64-Bit Advantage

Over the last several years, Exchange servers have been rapidly growing in number and average size of mailboxes. There are several reasons for this – consolidated Exchange 5.5 sites, less expensive hardware, less expensive WAN bandwidth, increased information store size limits, and users sending more e-mail. For all of these reasons and more, organisations have implemented fewer large servers in place of several smaller distributed servers. This strategy has several cost and management benefits, but as more and more users are put on fewer and fewer servers, at some point performance becomes an issue.

Using 64-bit hardware and operating system allows for increased performance and scalability by giving Exchange considerably more resources. A 32-bit architecture only allows up to 4 GB of addressable memory, and that is split between the kernel and applications . Increasing the server and hardware architecture to 64-bit can allow the operating system to address up to 16 Exabytes of memory. (Current hardware limitations are between 16 and 64 GB of RAM.) A 64-bit processor also has more cache capacity, or internal registers that are twice as big as 32-bit processor registers and allow applications such as Exchange to be written in such a way that more of the application resides on the processor – greatly increasing performance and allowing Exchange servers to grow along with increased messaging demands.

Another area where 64 bit has a considerable impact on performance is in the number of input/output operations per second (IOPS). A 32-bit Exchange server with a large database can experience high IOPS if the disk subsystem is not configured correctly. This means designing your storage subsystem for performance and not capacity – using several smaller disk drives rather than fewer large disk drives, with a lot of the disk space going unused.

Early tests have shown that Exchange Server 2007 running on 64-bit hardware required roughly 75 percent fewer IOPS than Exchange Server 2003 running on the same hardware. Another way to look at this is that Exchange Server 2007 requires a quarter of the disks that Exchange Server 2003 requires for the same performance. This means that Exchange Server 2007 can support more and larger databases than earlier versions of Exchange. It also means that disk subsystem design can be planned for capacity and performance.


Maximizing Availability

As availability requirements have increased over the years, so has the dependability of Exchange Server and the hardware it runs on. When Exchange was first released in the mid-1990s, expectations for e-mail as a communication tool were not much different than for paper mail. But as users became more tech-savvy and dependence on e-mail grew, so too did the need to guarantee Exchange availability.

To increase messaging availability, redundancy can be built into the Exchange architecture that includes things like multiple front-end servers, multiple e-mail routes between sites and the Internet, and Public Folder replicas. However, increasing the availability of Exchange servers that host mailboxes can be challenging and costly.

One (but no longer the only) method for increasing availability for Exchange mailbox servers is to use an Exchange cluster. Using a Windows cluster of two or more nodes with Exchange provides redundant servers so that if a node or a service on a node fails, the other node can assume the Exchange services.

What is obvious here is that the Exchange services are redundant, while the Exchange mailbox databases are not. Therefore, Exchange clusters increase availability by adding redundancy to Exchange services; until now, providing database redundancy was only possible using third-party hardware or software solutions.


Cluster Continuous Replication

To provide redundancy for Exchange services and information stores, Exchange Server 2007 provides Cluster Continuous Replication (CCR). Similar to clustering solutions available with earlier versions of Exchange, CCR uses Windows Clustering Services to provide virtual servers and failover capabilities. However, with CCR, shared storage is not required because each node has its own copy of the information stores This allows customers to implement a variety of storage options such as Direct Attached Storage, Serial Attached SCSI, and Storage Area Networks. This solution uses a form of log file shipping that is found in databases such as Microsoft® SQL Server™.

On the active node, transactions are written to the transaction log. When the current transaction log is full, the passive node pulls a copy of the transaction log from the active node to the passive node. A service on the passive node then posts the transactions from the replicated transaction log into the database on the passive node.

If the active node fails (either planned or unplanned), the cluster fails over to the passive node that mounts the databases and continues providing Exchange services. Transactions logs on the new active node are then replicated over to the new passive node as needed.

Aside from the benefits of having your databases replicated across multiple nodes, you can also back up the database and transaction logs on the passive node without impacting performance on the active node. After backup is complete on the passive node, and the proper transaction logs are deleted, the transaction logs on the active node are also deleted. The cluster nodes must be on the same subnet, but if the subnet spans physical networks, you can place the active node and passive node in different physical locations. This means that replicating your Exchange databases to a remote disaster recovery site is now possible.

Also, since the reasons for having to restore from backup are reduced with CCR, you may be able to reduce your operating costs by re-evaluating your backup strategy and decide if the same schedule, backup type, and number of tapes are needed.


Local Continuous Replication

Local Continuous Replication (LCR) takes the database replication technology from CCR and applies it to a stand-alone Exchange Server 2007 server. With LCR, databases are replicated to another location on the local server. If the database becomes corrupt or a disk fails, the Information Store can be pointed to the local copy and service can continue.

Ideal for small or medium-sized organisations, LCR allows for rapid recovery from disk or database issues and only requires an additional disk or disks to host the database replicas. While backups (with off-site storage) are a must for disaster recovery, LCR is an affordable way to provide increased availability.



Simplifying Outlook configuration with Auto discover

In the past, Outlook profile configuration could be challenging because most users don’t know the name of an Exchange server needed to resolve their profile. With the new Auto discover feature, users only need to know their user name, password, and e-mail address to configure an Outlook profile.

Auto discover is run when Outlook is started – periodically in the background – and if the connection to the Exchange server is lost. The process Auto discover follows when determining profile information is:

1. Outlook locates an Auto discover service on a Client Access server using DNS.
2. The Auto discover service on the Client Access server uses configuration information from Active Directory to build a configuration template for Outlook. The configuration template includes information about Active Directory and the Exchange Server 2007 organisation and topology.
3. Outlook downloads the configuration information from the Auto discover service.
4. Outlook then connects to Exchange by using the downloaded configuration settings.

Dataplex Exchange Services

Assessment and Health Checks

Already have Exchange Server 2007 deployed? Dataplex Consultants can perform a detailed assessment and health check of your environment.

Design

Without careful design, an Exchange implementation can leave an organisation with an environment that is at high risk for malicious attack, nearly impossible to administer, inconsistent with business needs and difficult to expand or alter. The best implementations are based upon sound, consistent advice that adhere to best practice and real world experiences, contact Dataplex to see how we can ensure your Exchange implementation is right from the start.

Implementation and Migration

Implementing a new Exchange Server or Migrating from legacy messaging solution? Dataplex Systems are experts in ensuring the deployment of Microsoft Exchange Server is successful and meets your requirements. As messaging is a critical part of any infrastructure it is imperative that the implementation is right from the start and this is achieved using Dataplex Project Management Services.


Exchange RSS Feed