First things first – let’s cover some basic background: Exchange Server 2010 is an e-mail and calendaring application that runs on Windows Server 2008 and, like its predecessor Exchange Server 2007, can also integrate with your phone system. It is the seventh major version of the product and, while not revolutionary, it does include some important changes and lots of small improvements over Exchange Server 2007.

The scalability of Exchange Server 2010 has improved, especially when compared to the complex storage requirements of Exchange Server 2007. The user experience has also improved in Outlook Web App, and a lot of complex issues have seen solved, or the complexity has been removed, to make the administrator’s life much easier.

In this article I will give a brief overview of what’s changed in Exchange Server 2010, what the new features are, what features have been removed, and how it makes your life as an Exchange administrator easier.

1  Getting Started

Exchange Server 2010 will be available in two versions:

• Standard Edition, which is limited to hosting 5 databases.
• Enterprise Edition, which can host up to 100 databases.

However, the available binaries are identical for both versions; it’s the license key that establishes the difference in functionality.  Exchange Server 2010 is also only available in a 64-Bit version; there is absolutely no 32-bit version available, not even for testing purposes. Bear in mind that, as 64-Bit-only software, there’s no Itanium version of Exchange Server 2010.

Exchange Server 2010 also comes with two Client Access License (CAL) versions:

• Standard CAL – This license provides access to e-mail, calendaring, Outlook Web App and ActiveSync for Mobile Devices.
• Enterprise CAL – This is an additive license, and provides Unified Messaging and compliance functionality, as well as Forefront Security for Exchange Server and Exchange Hosted Filtering for anti-spam and anti-virus functionality.

This is not a complete list, and for more information about licensing you can check the Microsoft web site at http://www.microsoft.com/exchange.

2  What’s been removed from Exchange Server 2010?

As always, as new features come, old features go. There are inevitably a few that have found themselves on the “deprecated list” this time around, and so will not be continued in Exchange Server 2010 and beyond. Since this is a much shorter list than the “new features”, we’ll start here:

• There are some major changes in Exchange Server clustering: in Exchange Server 2007 you had LCR (Local Continuous Replication), CCR (Cluster Continuous Replication) and SCR (Standby Continuous Replication) – three different versions of replication, all with their own management interfaces. All three are no longer available in Exchange Server 2010.
• Windows Server Fail-over Clustering has been removed in Exchange Server 2010. Although seriously improved in Windows Server 2008, a lot of Exchange Administrators still found the fail-over clustering complex and difficult to manage. As a result, it was still prone to error and a potential source of all kinds of problems.
• Storage Groups are no longer available in Exchange Server 2010. The concepts of a database, log files and a checkpoint file are still there, but now it is just called a Database. It’s like CCR in Exchange Server 2007, where you could only have one Database per Storage Group.
• Due to major reengineering in the Exchange Server 2010 databases, the Single Instance Storage (SIS) is no longer available. This means that when you send a 1 MB message to 100 recipients, the database will potentially grow by 100 MB. This will surely have an impact on the storage requirements in terms of space, but the performance improvements on the Database are really great. I’ll get back on that later in this article.

3  What’s new in Exchange Server 2010?

Exchange Server 2010 contains a host of improvements and a lot of new features, as well as minor changes and improvements. Over the coming sections, I’ll provide an overview of the most significant updates and additions.

3.1 Outlook Web App

The most visible improvement for end-users is Outlook Web App (previously known as Outlook Web Access). One of the design goals for the Outlook Web App was a seamless cross-browser experience, so users running a browser like Safari, even on an Apple MacBook, should have exactly the same user experience as users running Internet Explorer.

Figure   1. Outlook Web App running on an Apple MacBook using a Safari browser!

Outlook Web App offers a very rich client experience and narrows the gap between a fully-fledged Outlook client and Outlook Web Access. To reinforce that experience, a lot of new features have been introduced. To name a few: Favorites, Search Folders, attaching messages to messages, integration with Office Communicator, a new Conversation View (which works very well!), integration with SMS (text) messages and the possibility to create Outlook Web Access policies, which give the Exchange organization administrator the ability to fine tune the user experience. The Web App is a feature which you will find mentioned throughout the book.

3.2 High Availability

The Exchange Server 2007 Cluster Continuous Replication (CCR) and Standby Continuous Replication (SCR) features are now combined into one new feature called database availability.

Database copies exist just as in an Exchange Server 2007 CCR environment and are created in a “Database Availability Group”, but it is now possible to create multiple copies. The replication is not on a server level as in Exchange Server 2007 but on a database level, which gives the Exchange administrator much more fine control and granularity when it comes to creating a high available Exchange organization. The servers in such a Database Availability Group can be at the same location, or other locations to create an offsite solution. There’s also no longer any need to install the Microsoft Cluster Service (MSCS) before setting up the Database Availability Group, as all cluster operations are now managed by Exchange.

3.3 Exchange Core Store functionality

Compared to Exchange Server 2003, Exchange Server 2007 dramatically decreased the I/O on the disk subsystem (sometimes by 70%). This was achieved by increasing the Exchange database page size from 4KB to 8KB and by using the 64-Bit operating system. The memory scalability of the 64-Bit platform makes it possible to use servers with huge amounts of memory, giving them the opportunity to cache information in memory instead of reading and writing everything to the disk.

One of the design goals of Exchange Server 2010 was to use a single 1TB SATA disk for the mailbox database and its log files. Another goal was to allow multi GB mailboxes without any negative performance impact on the server. To make this possible, the database schema in Exchange Server 2010 has now been flattened, making the database structure used by the Exchange Server much less complex than it was in Exchange Server 2007 and earlier. As a result, the I/O requirements of an Exchange Server 2010 server can be up to 50% less than for the same configuration in Exchange Server 2007.

As a result of the flattened database schema, Microsoft has removed Single Instance Storage (SIS) from Exchange Server 2010, but the improvements in performance are much more significant, and more-than-adequate compensation for the (comparatively minor) loss of SIS.

3.4 Microsoft Online Services

Microsoft is gradually moving “into the cloud”. Besides an Exchange Server 2010 implementation on premise, it is now also possible to host mailboxes in a datacenter; you can host your mailboxes with your own ISP, or with Microsoft Online Services.

Exchange Server 2010 can be 100% on premise, 100% hosted, or it can be a mixed environment, with some percentage of your mailboxes hosted and the rest on premise. This is, of course, fully transparent to end users, but it has its effects on the administration. Instead of managing just one, on-site environment, you’ll have to manage the hosted organization as well. This is can all be handled through Exchange Server 2010’s Exchange Management Console, where you can connect to multiple forests containing an Exchange organization.

3.5 New Administration Functionality

As a consequence of the major changes made to the High Availability features of Exchange Server 2010, the Exchange Management Console has also changed rather significantly.

Due to the new replication functionality, the Mailbox object is no longer tied to the Exchange Server object, but is now part of the Exchange Server 2010 organization. Also, since the concept of Storage Groups is no longer relevant, their administration has been removed from both the Exchange Management Console and the Exchange Management Shell. PowerShell cmdlets like New-StorageGroup, Get-StorageGroup, and so on, have also all been removed, although the options of these cmdlets have been moved into other cmdlets, like database-related cmdlets.

Speaking of which, Exchange Server 2010 also runs on top of PowerShell Version 2. This version not only has a command line interface (CLI), but also an Interactive Development Environment (IDE). This enables you to easily create scripts and use variables, and you now have an output window where you can quickly view the results of your PowerShell command or script.

In addition to PowerShell V2, Exchange Server 2010 also uses Windows Remote Management (WinRM) Version 2. This gives you the option to remotely manage an Exchange Server 2010 server without the need to install the Exchange Management Tools on your workstation, and even via the Internet!

One last small but interesting new feature is “Send Mail“, allowing you to send mail directly from the Exchange Management Console – ideal for testing purposes.

3.6 Exchange Control Panel

It is now possible to perform some basic Exchange management tasks using the options page in Outlook Web Access; not only on the user’s own properties, but also at an organizational level. With this method, it is possible to create users, mailboxes, distribution groups, mail-enabled contact, management e-mail addresses etc.

Figure   2. The Exchange Control Panel for basic management functions.

3.7 Active Directory Rights Management

Active Directory Rights Management Service lets you control what users can do with E-mail and other documents that are sent to them. It is possible, for example, for classified messages to disable the “Forward” option to prevent messages being leaked outside the organization. With Exchange Server 2010, new features have been added to the Rights Management Services, such as:

• Integration with Transport Rules – a template for using RMS to protect messages over the Internet.
• RMS protection for voice mail messages coming from the Unified Messaging Server Role.

Active Directory is discussed throughout this book, as the Exchange Server 2010 has a much close relationship with AD than previous versions of Exchange Server.

3.8 Transport and Routing

With Exchange Server 2010 it is possible to implement cross premises message routing. When using a mixed hosting environment, Exchange Server 2010 can route messages from the datacenter to the on-premise environment with full transparency.

Exchange Server 2010 also offers (at last) enhanced disclaimers, making it possible to add HTML content to disclaimers to add images, hyperlinks, etc. It is even possible to use Active Directory attributes (from the user’s private property set) to create a personal disclaimer.

To create a highly available and reliable routing model, the Hub Transport Servers in Exchange Server 2010 now contain Shadow Redundancy. A message is normally stored in a database on the Hub Transport Server and, in Exchange Server 2007, the message is deleted as soon as it is sent to the next hop. In Exchange Server 2010, the message is only deleted after the next hop reports a successfully delivery of the message. If this is not reported, the Hub Transport Server will try to resend the message.

For more High Availability messaging support, the messages stay in the transport dumpster on a Hub Transport Server, and are only deleted if they are successfully replicated to all database copies. The database on the Hub Transport Server has also been improved on an ESE level, resulting in a higher message throughput on the transport level.

3.9 Permissions

Previous versions of Exchange Servers relied on delegation of control via multiple Administrative Groups (Specifically, Exchange Server 2000 and Exchange Server 2003) or via Group Membership. Exchange Server 2010 now contains a Role Based Access Model (RBAC) to implement a powerful and flexible management model. .

3.10  Messaging Policy and Compliance

As part of a general compliance regulation, Microsoft introduced the concept of Managed Folders in Exchange Server 2007, offering the possibility to create some sort of compliancy feature. This has been enhanced with new interfaces in Exchange Server 2010, such as the option of tagging messages, cross mailbox searches and new transport rules and actions.

3.11  Mailbox Archive

Exchange Server 2010 now contains a personal archive; this is a secondary mailbox connected to a user’s primary mailbox, and located in the same Mailbox Database as the user’s primary mailbox. Since Exchange Server 2010 now supports a JBOD (Just a Bunch of Disks) configuration this isn’t too big a deal, and the Mailbox Archive really is a great replacement of (locally stored) .PST files.

3.12  Unified Messaging

The Exchange Server 2010 Unified Messaging Server Role integrates a telephone system, like a PABX, with the Exchange Server messaging environment. This makes it possible to offer Outlook Voice Access, enabling you to interact with the system using your voice, listen to voice mail messages, or have messages read to you. Exchange Server 2010 offers some new functionality like Voicemail preview, Messaging Waiting Indicator, integration with text (SMS) messages, additional language support etc. Unified Messaging is, unfortunately, a little outside the scope of this book, so you won’t find me going into too much detail later on.

4  Exchange Server 2010 and Active Directory

As far as Active Directory is concerned, its minimum level needs to be on a Windows Server 2003 level, both for the domain functional level as well as the forest functional level. This might be confusing, since Exchange Server 2010 only runs on Windows Server 2008 or Windows Server 2008 R2, but that’s just the actual server which Exchange Server 2010 is running on!

The Schema Master in the forest needs to be Windows Server 2003 SP2 server (Standard or Enterprise Edition) or higher. Likewise, in each Active Directory Site where Exchange Server 2010 will be installed, there must be at least one Standard or Enterprise Windows Server 2003 SP2 (or higher) server configured as a Global Catalog server.

From a performance standpoint, as with Exchange Server 2007, the ratio of 4:1 for Exchange Server processors to Global Catalog server processors still applies to Exchange Server 2010. Using a 64-Bit version of Windows Server for Active Directory will naturally also increase the system performance.

4.1 Active Directory partitions

A Windows Server Active Directory consists of one forest, one or more domains and one or more sites. Exchange Server 2010 is bound to a forest, and therefore one Exchange Server 2010 Organization is connected to one Active Directory forest. The actual information in an Active Directory forest is stored in three locations, also called partitions:

• Schema partition – this contains a “blue print” of all objects and properties in Active Directory. In a programming scenario this would be called a class. When an object, like a user, is created, it is instantiated from the user blueprint in Active Directory.
• Configuration partition – this contains information that’s used throughout the forest. Regardless of the number of domains that are configured in Active Directory, all domain controllers use the same Configuration Partition in that particular Active Directory forest. As such, it is replicated throughout the Active Directory forest, and all changes to the Configuration Partition have to be replicated to all Domain Controllers. All Exchange Server 2010 information is stored in the Configuration Partition.
• Domain Partition – this contains information regarding the domains installed in Active Directory. Every domain has its own Domain Partition, so if there are 60 domains installed there will be 60 different Domain Partitions. User information, including Mailbox information, is stored in the Domain Partition.

4.2 Delegation of Control

Figure   3. The Configuration partition in Active Directory holds all information regarding Exchange Server 2010 in an Administrative Group.

In Exchange Server 2003 the concept of “Administrative Groups” was used to delegate control between different groups of administrators. A default “First Administrative Group” was created during installation, and subsequent Administrative Groups could be created to install more Exchange 2003 servers and delegate control of these servers to other groups. The Administrative Groups were stored in the Configuration Partition so all domains and thus all domain controllers and Exchange servers could see them.

Just shift all letters in the word FYDIBOHF23SPDLT to the left and you get EXCHANGE12ROCKS.

Exchange Server 2007 used Active Directory Security Groups for delegation of control, and only one Administrative Group is created during installation of Exchange Server 2007, called “Exchange Administrative Group (FYDIBOHF23SPDLT)”. All servers in the organization are installed in this Administrative Group. Permissions are assigned to Security Groups and Exchange administrators are member of these Security Groups.

Exchange Server 2010 uses the same Administrative Group, but delegation of control is not done using Active Directory Security Groups, as Microsoft has introduced the concept of “Role Based Access Control” or RBAC. 

4.3 Active Directory Sites

Exchange Server 2010 uses Active Directory Sites for routing messages. But what is an Active Directory site?

When a network is separated into multiple physical locations, connected with “slow” links and separated into multiple IP subnets, then in terms of Active Directory we’re talking about sites.  Say, for example, there’s a main office located in Amsterdam, this has an IP subnet of 10.10.0.0/16. There’s a Branch Office located in London, and this location has an IP subnet of 10.11.0.0/16. Both locations have their own Active Directory Domain Controller, handling authentication for clients in their own subnet. Active Directory site links are created to control replication traffic between sites. Clients in each site use DNS to find services like Domain Controllers in their own site, thus preventing using services over the WAN link.

Figure   4. Two subnets in Active Directory, one for the main office and one for the Amsterdam Datacenter.

Exchange Server 2010 uses Active Directory sites for routing messages between sites. Using our current example, if there is an Exchange Server 2010 Hub Transport Server in Amsterdam and an Exchange Server 2010 Hub Transport Server in London, then the IP Site Links in Active Directory are used to route messages from Amsterdam to London. This concept was first introduced in Exchange Server 2007, and nothing has changed in Exchange Server 2010.

Exchange Server 2003 used the concept of Routing Groups, where Active Directory already used Active Directory Sites; Active Directory Sites and Exchange Server Routing Groups are not compatible with each other.  To have Exchange Server 2003 and Exchange Server 2010 work together in one Exchange organization, some special connectors have to be created – the so called Interop Routing Group Connector.

5  Exchange Server coexistence

It is very likely that large organizations will gradually move from an earlier version of Exchange Server to Exchange Server 2010, and Exchange Server 2010 can coexist, in the same forest, with (both) Exchange Server 2007 and Exchange Server 2003. It is also possible to move from a mixed Exchange Server 2003 and Exchange Server 2007 environment to Exchange Server 2010.

Please note that it is not possible to have a coexistence scenario where Exchange Server 2000 and Exchange Server 2010 are installed in the same Exchange Organization. This is enforced in the setup of Exchange Server 2010. If the setup detects an Exchange Server 2000 installation the setup application is halted and an error is raised.

Integrating Exchange Server 2010 into an existing Exchange Server 2003 or Exchange Server 2007 environment is called a “transition” scenario. A “migration” scenario is where a new Active Directory forest is created where Exchange Server 2010 is installed. This new Active Directory forest is running in parallel to the “old” Active Directory with a previous version of Exchange Server. Special care has to be taken in this scenario, especially when both organizations coexist for any significant amount of time. Directories have to be synchronized during the coexistence phase, and the free/busy information will need to be constantly synchronized as well, since you’ll still want to offer this service to users during the coexistence period.

This is a typical scenario when 3rd party tools like Quest are involved, although it is not clear at the time of writing this book how Quest is going to deal with Exchange Server 2010 migration scenarios.

6  Exchange Server 2010 Server roles

Up until Exchange Server 2003, all roles were installed on one server and administrators were unable to select which features were available. It was possible to designate an Exchange 2000 or Exchange 2003 server as a so called “front-end server”, but this server was just like an ordinary Exchange server acting as a protocol proxy. It still had a Mailbox Database and a Public Folder database installed by default.

Exchange Server 2007 introduced the concept of “server roles” and this concept is maintained in Exchange Server 2010. The following server roles, each with a specific function, are available in Exchange Server 2010:

• Mailbox Server (MB) role.
• Client Access Server (CAS) role.
• Hub Transport Server (HT) role.
• Unified Messaging Server (UM) role.
• Edge Transport Server (Edge) role.

These server roles can be installed on dedicated hardware, where each machine has its own role, but they can also be combined. A typical server installation, for example in the setup program, combines the Mailbox, Client Access and Hub Transport Server role. The Management Tools are always installed during installation, irrespective of which server role is installed.

By contrast, the Edge Transport Server role cannot be combined with any other role. In fact, the Edge Transport Server role cannot even be part of the (internal) domain, since it is designed to be installed in the network’s Demilitarized Zone (DMZ).

There are multiple reasons for separating Exchange Server into multiple server roles:

• Enhanced scalability – since one server can be dedicated for one server role, the scalability profits are huge. This specific server can be configured and optimized for one particular Role, resulting in a high performance server.
• Improved security – one dedicated server can be hardened for security using the Security Configuration Wizard (SCW). Since only one Server Role is used on a particular server, all other functions and ports are disabled, resulting in a more secure system.
• Simplified deployment and administration – a dedicated server is easier to configure, easier to secure and easier to administer.

I will explain each server role in detail, in the following sections.

6.1 Mailbox Server role

The Mailbox Server role is the heart of your Exchange Server 2010 environment. This is where the Mailbox Database and Public Folder Database are installed. The sole purpose of the Mailbox Server role is to host Mailboxes and Public Folders; nothing more. In previous versions of Exchange Server, including Exchange Server 2007, Outlook clients using MAPI still connected directly to the Mailbox Server Role, but with Exchange Server 2010 this is no longer the case. MAPI clients now connect to a service called “MAPI on the Middle Tier” (MoMT), running on the Client Access Server. The name MoMT is still a code name and will have been changed before Exchange Server 2010 is released.

The Mailbox Server Role does not route any messages, it only stores messages in mailboxes. For routing messages, the Hub Transport Server role is needed. This latter role is responsible for routing all messages, even between mailboxes that are on the same server, and even between mailboxes that are in the same mailbox database.

For accessing mailboxes, a Client Access Server is also always needed; it is just not possible to access any mailbox without a Client Access Server.

Figure   5. The Mailbox Server role is hosting Mailboxes and Public Folders.

Note that Internet Information Server is needed on a Mailbox Server role in order to implement the Role Based Access Control model (RBAC)  even if no client is accessing the Mailbox Server directly.

As I mentioned, Storage Groups no longer exist in Exchange Server 2010, but mailboxes are still stored in databases, just like in Exchange Server 2007. Although rumors have been circulating for more than 10 years that the database engine used in Exchange Server will be replaced by a SQL Server engine, it has not happened yet. Just as in earlier versions of Exchange Server, the Extensible Storage Engine (ESE) is still being used, although major changes have been made to the database and the database schema.

By default, the first database on a server will be installed in the directory:

Figure   6. The default location for the Mailbox Databases and the log files.

The <<identifier>> is a unique number to make sure that the Mailbox Database name is unique within the Exchange organization.

It is a best practice, from both a performance and a recovery perspective, to place the database and the accompanying log files on a dedicated disk. This disk can be on a Fiber Channel SAN, an iSCSI SAN, or on a Direct Attached Storage (DAS) solution. Whilst it was a design goal to limit the amount of disk I/O to a level that both the database and the log files could be installed on a 1TB SATA disk, this is only an option if Database Copies are configured and you have at least two copies of the Mailbox Database, in order to avoid a single point of failure.

6.2 Client Access Server role

The Client Access Server XE “Client Access Server”  role offers access to the mailboxes for all available protocols. In Exchange Server 2003, Microsoft introduced the concept of “front-end” and “back-end” servers, and the Client Access Server role is comparable to an Exchange Server 2003 front-end server.

All clients connect to the Client Access Server and, after authentication, the requests are proxied to the appropriate Mailbox Server. Communication between the client and the Client Access Server is via the normal protocols (HTTP, IMAP4, POP3 and MAPI), and communication between the Client Access Server and the Mailbox Server is via Remote Procedure Calls (RPC).

The following functionality is provided by the Exchange Server 2010 Client Access Server:

• HTTP for Outlook Web App.
• Outlook Anywhere (formerly known as RPC/HTTP) for Outlook 2003, Outlook 2007 and Outlook 2010.
• ActiveSync for (Windows Mobile) PDA’s.
• Internet protocols POP3 and IMAP4.
• MAPI on the Middle Tier (MoMT).
• Availability Service, Autodiscover and Exchange Web Services. These services are offered to Outlook 2007 clients and provide free/busy information, automatic configuration of the Outlook 2007 and Outlook 2010 client, the Offline Address Book downloads and Out-of-Office functionality.

At least one Client Access Server is needed for each Mailbox Server in an Active Directory site, as well as a fast connection is between the Client Access Server and the Mailbox Server. The Client Access Server also needs a fast connection to a Global Catalog Server.

The Client Access Server should be deployed on the internal network and NOT in the network’s Demilitarized Zone (DMZ). In order to access a Client Access Server from the Internet, a Microsoft Internet Security and Acceleration (ISA) Server should be installed in the DMZ. All necessary Exchange services should be “published” to the Internet, on this ISA Server.

Figure   7. The Client Access Server is responsible for providing access to (Internet) clients. The ISA Server is not in this picture.

6.3 Hub Transport Server role

The Hub Transport Server role is responsible for routing messaging not only between the Internet and the Exchange organization, but also between Exchange servers within your organization.

Figure   8. The Hub Transport Server is responsible for routing all messages

All messages are always routed via the Hub Transport Server role, even if the source and the destination mailbox are on the same server and even if the source and the destination mailbox are in the same Mailbox Database. For example in  Figure 8:

• Step 1:  A message is sent to the Hub Transport Server
• Step 2: A recipient on the same server as the sender means the message is sent back
• Step 3: When the recipient is on another mailbox server, the message is routed to the appropriate Hub Transport Server. This is then followed by… 
• …Step 4: The second Hub Transport Server delivers the message to the Mailbox Server of the recipient

The reason for routing all messages through the Hub Transport Server is simply compliancy. Using the Hub Transport Server, it is possible to track all messaging flowing through the Exchange organization and to take appropriate action if needed (legal requirements, HIPAA, Sarbanes-Oxley etc.). On the Hub Transport Server the following agents can be configured for compliancy purposes:

• Transport Rule agents – using Transport Rules, all kinds of actions can be applied to messages according to the Rule’s filter or conditions. Rules can be applied to internal messages, external messages or both;
• Journaling agents – using the journaling agent, it is possible to save a copy of every message sent or received by a particular recipient.

Since a Mailbox Server does not deliver any messages, every Mailbox Server in an Active Directory site requires a Hub Transport Server in that site. The Hub Transport Server also needs a fast connection to a Global Catalog server for querying Active Directory. This Global Catalog server should be in the same Active Directory site as the Hub Transport Server.

When a message has an external destination, i.e. a recipient on the Internet, the message is sent from the Hub Transport Server to the ‘outside world’. This may be via an Exchange Server 2010 Edge Transport Server in the DMZ, but the Hub Transport Server can also deliver messages directly to the Internet.

Optionally, the Hub Transport Server can be configured to deal with anti-spam and anti-virus functions. The anti-spam services are not enabled on a Hub Transport Server by default, since this service is intended to be run on an Edge Transport Service in the DMZ. Microsoft has supplied a script on every Hub Transport Server that can be used to enable their anti-spam services if necessary.

Anti-virus services can be achieved by installing the Microsoft Forefront for Exchange software. The anti-virus software on the Hub Transport Server will scan inbound and outbound SMTP traffic, whereas anti-virus software on the Mailbox Server will scan the contents of a Mailbox Database, providing a double layer of security.

6.4 Edge Server role

The Edge Server role was introduced with Exchange Server 2007, and provides an extra layer of message hygiene. The Edge Transport Server role is typically installed as an SMTP gateway in the network’s “Demilitarized Zone” or DMZ. Messages from the Internet are delivered to the Edge Transport Server role and, after anti-spam and anti-virus services, the messages are forwarded to a Hub Transport Server on the internal network.

Figure   9. The Edge Transport Server is installed between the Internet and the Hub Transport Server.

The Edge Transport Server can also provide the following services:

• Edge Transport Rules – like the Transport Rules on the Hub Transport Server, these rules can also control the flow of messages that are sent to, or received from the Internet when they meet a certain condition.
• Address rewriting – with address rewriting, the SMTP address of messages sent to or received from the Internet can be changed. This can be useful for hiding internal domains, for example after a merger of two companies, but before one Active Directory and Exchange organization is created.

The Edge Transport Server is installed in the DMZ and cannot be a member of the company’s internal Active Directory and Exchange Server 2010 organization. The Edge Transport Server uses the Active Directory Lightweight Directory Services (AD LDS) to store all information. In previous versions of Windows this service was called Active Directory Application Mode (ADAM). Basic information regarding the Exchange infrastructure is stored in the AD LDS, like the recipients and the Hub Transport Server which the Edge Transport Server is sending its messages to.

To keep the AD LDS database up to date, a synchronization feature called EdgeSync is used, which pushes information from the Hub Transport Server to the Edge Transport Server at regular intervals.

6.5 Unified Messaging Server role

The Exchange Server 2010 Unified Messaging Server role combines the mailbox database and both voice messages and e-mail messages into one store. Using the Unified Messaging Server role it is possible to access all messages in the mailbox using either a telephone or a computer.

The phone system can be an IP based system or a “classical” analog PBX system, although in the latter case, a special Unified Messaging IP Gateway is needed to connect the two.

Figure   10. Overview of the Unified Messaging Infrastructure.

The Unified Messaging Server role provides users with the following features:

• Call Answering – this feature acts as an answering machine. When somebody cannot answer the phone, a personal message can be played after which a caller can leave a message. The message will be recorded and sent to the recipient’s mailbox as an .mp3 file.
• Subscriber Access – sometimes referred to as “Outlook Voice Access”. Using Subscriber Access. users can access their mailbox using a normal phone line and listen to their voicemail messages. It is also possible to access regular mailbox items like messages and calendar items, and even reschedule appointments in the calendar.
• Auto Attendant – using the Auto Attendant, it is possible to create a custom menu in the Unified Messaging system using voice prompts. A caller can use either the telephone keypad or his or her voice to navigate through the menu.

The Unified Messaging service installed on the Unified Messaging Server role works closely with the Microsoft Exchange Speech Engine Service. This Speech Engine Service provides the following services:

• Dual Tone Multi Frequency (DTMF) also referred to as the touchtone (the beeps you hear when dialing a phone number or accessing a menu).
• Automatic Speech Recognition.
• Text-to-Speech service that’s responsible for reading mailbox items and reading the voice menus.

The Unified Messaging Server role should be installed in an Active Directory site together with a Hub Transport Server, since this latter server is responsible for routing messaging to the Mailbox Servers. It also should have a fast connection to a Global Catalog server. If possible, the Mailbox Server role should be installed as close as possible to the Unified Messaging Server role, preferably in the same site and with a decent network connection.

7  Summary

Exchange Server 2010 is the new Messaging and Collaboration platform from Microsoft, and it has a lot of new, compelling features. The new High Availability, management and compliancy features make Exchange Server 2010 a very interesting product for the Exchange administrator. In fact, the new features in Exchange Server 2010 will generally result in less complexity, which is always a good thing!

The whole eBook can be downloaded here.