Features Features Get Your New Features Here

Features! Features! Get Your New Features Here!

Reviewing the impressive list of new features and enhancements to Exchange 2007, everyone can agree that there are at least a few features that anyone can use. Customers have been asking for some of these improvements for many years, and others are new features that most customers had not even realized that they needed.

In the following sections, we will review the new features and provide a summary of what each provides. We'll discuss most of these features in more detail later in the book.

64-bit Architecture

For a long time, perhaps the most discussed (and perhaps the most controversial) enhancement to Exchange 2007 is that now Exchange 2007 server uses 64-bit extensions. Now your production servers will have to have x64 architecture-based Intel Xeon and Pentium processes or AMD64 architecture-based AMD Opteron and Athlon processors.

Although many people are thrilled with this change in the architecture, there are, no doubt, folks screaming, "What!!!?? I have to buy new hardware just to upgrade?!" A good response to this concern is that on most any messaging system upgrade, the hardware is replaced anyway. Certainly this is true for hardware that has been in production for more than three or four years. And the good news is that most server-class hardware that has been purchased since the end of 2005 or later probably already includes the x64 extensions. If you have existing hardware you want to use with Exchange 2007, confirm with your vendor that it will run Windows Server 2003 x64.

Note 

There is a 32-bit version of Exchange 2007, but it is not supported in production environments. Only 64-bit Exchange is supported in production.

Is the decision to move to 64 bits a bold move? Is the Exchange team forging the way to more robust applications? Well, to a certain degree, yes, but the move to the 64-bit architecture is more out of need than forging a bold, modern path. Anyone who has supported an older version of Exchange Server with a large number of mailboxes knows that Exchange is constrained by the amount of RAM that it can access and that Exchange significantly taxes the disk I/O system.

In order to provide additional features that organizations are now requiring, such as larger mailboxes, messaging records management features, improved message content security, transport rules, unified messaging integration, and improved journaling, Exchange Server clearly needs to be able to access more physical memory. With more RAM available, Exchange caching is more efficient and thus reduces the I/O requirements that are placed on the disk subsystem.

If you are not sure if your existing hardware supports the x64 extensions, there are a number of ways that you can check this, including confirming it with the hardware vendor. If the computer is already running Windows, you can get a handy little program called CPU-Z from www.cpuid.com. Figure 1.9 shows the CPU-Z program.

Figure 1.9: Using CPU-Z to identify the CPU type

Notice in the Instructions line of CPU-Z that this particular chip supports x86-64. This means this chip will support the x64 instruction sets. Intel chips will report that they support the EM64T instruction set.

Exchange Management

Exchange Server management with Exchange 2007 becomes more and more complex as administrators try to make Exchange work within their organizations particularly in larger organizations. Exchange 2000/2003 management of mail recipients was performed through the Active Directory Users and Computers console, while management of Exchange server related tasks and global recipient tasks is performed through the Exchange System Manager console. In Exchange 2007, all Exchange recipient administration tasks are now performed through the Exchange Management Console or the Exchange Management Shell.

Medium and large organizations usually develop specific needs to perform bulk changes to Exchange data, manage Exchange servers from the command line or scripts, and access or manipulate data stored in Exchange databases. Although making bulk changes or manipulating Exchange servers might seem like a simple task (after all, Windows, Active Directory, and Exchange Server are all from the same company), the truth of the matter is that it's not.

Performing bulk recipient tasks such as creating multiple mailboxes, changing many e-mail addresses, and configuring bulk properties must be performed through an application programming interface (API) or scripting interface such as Active Directory Services Interface (ADSI). Management of Exchange server properties may also need to be performed through ADSI.

Manipulation of Exchange server operations such as mounting and dismounting of databases, queue management, diagnostics logging, and tracking log management has to be handled through a number of Exchange-related APIs such as Extended Messaging Application Programming Interface (MAPI), Lightweight Directory Access Protocol (LDAP), Web Distributed Authoring and Versioning (WebDAV), CDO for Exchange Management (CDOExM), Windows Management Instrumentation (WMI), Distributed Component Object Model (DCOM), Remote Procedure Calls (RPCs), and the Internet Information Server management interface.

Finally, actually accessing or manipulating data stored in an Exchange database is also more complex than it might seem. A popular tool for Exchange 2003 administrators is the Exchange Merge (ExMerge) tool that allows data to be exported out of an Exchange mailbox and into a personal store (PST) file. Actual manipulation of data in the mailbox databases could be accomplished through MAPI, Collaborative Data Objects (CDO), Exchange Object Linking and Embedding Database (ExOLEDB) functions, or Web Distributed Authoring and Versioning (WebDAV) functions. None of these methods is either simple or trivial for nonprogrammers. Anyone that has ever tried to dismount or mount a mailbox database from a script can attest to the programming complexity involved in such a simple task.

Clearly, for any organization that is interested in customized management of Exchange (small, medium, or large organizations), Exchange 2003 and earlier versions left a lot to be desired, and required tasks could often not even be performed due to their difficulty. In the minds of many experienced Exchange administrators, this is a gaping hole in the Exchange management architecture.

With Exchange 2007, the management interface has been completely rewritten from the ground up. All management operations related to Exchange management - whether they are performed against an Exchange server, Active Directory, the Registry, or the Internet Information Server (IIS) metabase - have been broken up in to unique tasks. All Exchange tasks can be performed from the Exchange Management Shell (command-line interface); a subset of these tasks can be performed from the Exchange Management Console graphical user interface. Anything that can be performed from the Exchange Management Console can be performed via the Exchange Management Shell; there are advanced administrative tasks that can be performed only from the Exchange Management Shell.

The Exchange Management Console (shown in Figure 1.10) has been completely redesigned to make it easier to use, to better organize Exchange management tasks, to reduce the complexity, and to make administrative tasks more discoverable.

Figure 1.10: The new and improved Exchange Management Console

The new console is built on top of an entirely new scripting technology called PowerShell and a set of Exchange-specific extensions called the Exchange Management Shell. We will go into more details on the new management interface in Chapter 7, "Administering Exchange 2007."

Server Roles

In earlier versions of Exchange, once the Windows server was prepared to support Exchange, you simply installed an Exchange server. Then you would go about the process of customizing the Exchange configuration, configuring Internet Information Server, disabling unnecessary services, and preparing the server to assume the role you wanted it to assume, such as a mailbox server, a bridgehead server, Outlook Web Access front-end server, and so on.

Exchange 2007 officially introduces the concept of server roles at the point of setup. During the installation process, the setup program (Figure 1.11) asks the installer which roles the server will be performing.

Figure 1.11: Specifying server roles

When running setup, if you choose a custom installation, during setup you can specify the server roles by choosing from among the following options:

Mailbox Role	Supports mailboxes and public folders.
Client Access Role	Supports functions such as Outlook Web Access, Outlook Anywhere (RPC over HTTP), Windows Mobile ActiveSync, POP3, and IMAP4, and supports web services such as Autodiscover, the Availability service, and calendar sharing.
Hub Transport Role	Supports message transport functions such as delivering mail locally (to other Exchange servers in the organization) or externally (to an SMTP smart host such as an Exchange Edge Transport server).
Unified Messaging Role	Supports delivery of inbound voicemail, inbound faxing, and Outlook Voice Access features.
Edge Transport Role	Supports separate anti-spam and antivirus functions for inbound and outbound messaging. The Edge Transport server is installed on a stand-alone machine usually in a perimeter network.
Active Clustered Mailbox Role	Configures a server to support clustering as an active node. Only the Mailbox server role can be clustered. Clustered servers can be configured as part of a single copy cluster (SCC) or a clustered continuous replication (CCR) cluster.
Passive Clustered Mailbox Role	Configures a server to support clustering as a passive node. Only the Mailbox server role can be clustered.

Once a roles is selected, only the components necessary for that role are installed. This reduces the overhead on machines that are dedicated to a particular task (such as a Hub Transport server); ensures that no unnecessary executables, DLLs, or services are installed; and makes creating dedicated server roles much easier. In a small organization with only one Exchange server, the same server may be assigned the Mailbox, Hub Transport, and Client Access server roles.

Improved Message and Content Control

All messaging system administrators can relate to challenges such as adequately managing the content that is stored on their mail servers, keeping business-essential information available when it is required, removing content that is no longer necessary, controlling the flow of messaging information, and preventing disclosure of information. If one or more of these challenges has been a problem for you, then Exchange 2007 has solutions.

Messaging Records Management

Messaging records management (early on referred to as e-mail life cycle management) introduces to Exchange 2007 a whole new concept in the control of messaging content. Messaging records management allows administrators to more closely control the life of message content (e-mail, faxes, voicemail, calendar entries, and so on) from the moment the information is created on the Exchange server until the point at which that information no longer has business or legal value. This helps the organization to maintain important records as long as necessary but discard unnecessary information in a timely fashion. These are configured at the organization level so they will affect all Mailbox server roles.

To a certain extent, some of the features of messaging records management are distantly related to the Exchange 2000/2003 Mailbox Manager. There are a number of components to messaging records management:

Component	Function
Managed default folders	Default folders are found when an Outlook 2007 MAPI client uses its mailbox, including Calendar, Contacts, Deleted Items, Inbox, Junk E-mail, Sent Items, RSS Feeds, and so on.
Managed custom folders	Managed custom folders are folders that are created by the Exchange server administrator for users who are included in a managed folder mailbox policy. Storage limits and managed content settings can be applied to these folders.
Managed folder mailbox policies	Managed folder policies define which folders are included in a particular policy. Managed folder mailbox policies are then assigned to mailboxes.
Managed content settings	Managed content settings define retention settings and message journaling features for content such as messages, faxes, and voicemail.

Note 

You can now configure message journaling based on a specific type of content or folder.

Once a user has been assigned to a managed folder mailbox policy, any additional custom folders that must be created in that user's mailbox will show up in the Managed Folders folder in the root of the user's mailbox, such as those shown in Figure 1.12.

Figure 1.12: Managed folders assigned by the managed folder mailbox policy

Normally, content in these folders will be managed by the end user. Moving relevant content into these folders is their responsibility. In certain situations, managed content settings can accurately identify content types such as faxes or voicemail and can move those into the appropriate custom managed folders. A user can also build client-side rules that move content into their managed folders.

Message Transport Rules

Message transport rules are quite similar to Outlook rules and are even created using a wizard similar to one used to create Outlook rules. However, these rules are quite a bit more powerful and are executed on the Hub Transport servers. Since all messages are processed by a Hub Transport server whether they are inbound, outbound, or for locally delivery, you can build powerful policies to control the messages and data that flows within your organization. Transport rules can also be defined at your organization's perimeter by using an Edge Transport server.

Every transport rule has three components: conditions, actions, and exceptions.

Although we will cover a lot more about transport rules in Chapter 13, "Managing Messages in Transit," just to give you a taste of what you can do with transport rules, it is useful to highlight some of the cool things you can do with them:

• Append disclaimers to outgoing messages

• Implement message journaling based on recipients, distribution lists, message classification, or message importance

• Prevent users or departments from sending e-mail to another by creating an ethical wall (aka a Chinese wall)

• Intercept messages based on content or text patterns using regular expressions (REGEX) found in the message subject or message body

• Apply message classifications to messages based on sender or message content

• Take action on a message with a certain attachment or attachment type or an attachment size that exceeds a specified limit

• Examine and set message headers or remove data from the message header

• Redirect, drop, or bounce messages based on certain criteria

Journaling

Journaling messages is the process of keeping messages from one or more senders based on long-term storage, legal, regulatory, or human resources requirements. Exchange 2000/2003 essentially had one option for message journaling. Create an additional mailbox store and move any mailboxes that must be kept to that mailbox store. Exchange 2007 has introduced a lot of new options with respect to retaining messages:

• Messages can be retained based on folder or content type using managed content settings.

• Messages can be retained using transport rules by examining sender, recipient, message priority, message classification, or message content.

• Messages can also be retained using transport rules by keeping only internal or only external messages.

• Messages can still be retained based on the journal settings on the mailbox database.

• Messages can be retained using a new hub transport feature called a journaling rule (see Figure 1.13) that allows messages to be retained based on a single sender or distribution group membership.

• Messages can be sent to an SMTP address that is external to the Exchange organization, such as a Microsoft Office SharePoint Server 2007 server or a third-party service provider.

Figure 1.13: Creating a journaling rule

Message Classifications

Organizations that send confidential, proprietary, or classified information via e-mail often implement message classification templates. However, these client-side templates display the message classification only for the sender and the recipients; in previous versions of Exchange there was nothing within the message transport that could take action on or evaluate a classified message.

Exchange 2007 allows a message to enforce rules based on the classification of a message, such as Do Not Forward, Partner Mail, Attachment Removed, Company Confidential, Company Internal, Attorney/Client Privilege, and customized classification levels. The sender can assign the classification using Outlook 2007, Outlook Web Access 2007, or message transport rules can assign a classification based on sender, recipient, message content, importance, and so on. Figure 1.14 shows an example of a message that is being composed in Outlook Web Access and has had the built-in Attorney/Client Privilege classification assigned to it; the classification text is shown just about the address list. The server administrator can create additional classifications and customize the text strings.

Figure 1.14: Classifying a message using Outlook Web Access

Content Storage Improvements

As we mentioned earlier, e-mail systems have evolved not only in their complexity, but in the complexity (and size!) of the messages and mailbox content being sent and stored. Users demands for improved searching and indexing of their mailboxes have stretched the limits of most server hardware. The following list includes some of the improvements with respect to data storage and recoverability:

• Support for recovering moved or deleted mailboxes using a recovery storage group

• Volume Shadow Copy restoration to recovery storage groups on alternate servers

• Lost log resilience that allows a database to be recovered even if the last few log files are missing

Mailbox Databases

Even in a small or medium-sized organization, often mailbox size constraints are based solely on the ability to restore a certain amount of data given a specified maximum amount of time. To scale to larger mailboxes, the administrator must create more mailbox stores and storage groups. However, even Exchange Server 2003 Enterprise Edition allowed a maximum of only 4 storage groups and 20 mailbox stores.

Note 

In Exchange 2000/2003, we refer to mailbox databases as mailbox stores. In Exchange 2007, we simply call these mailbox databases.

In order to allow a server to scale to support larger mailbox sizes or more mailboxes, Exchange Server 2007 Enterprise Edition allows up to 50 storage groups and 50 mailbox databases. The maximum number of mailbox databases is 50; these can be configured in 50 separate storage groups or consolidated into as few as 10 storage groups of 5 databases each. Exchange Server 2007 Standard Edition supports a maximum of 5 storage groups and 5 databases. The recommendation from Microsoft is to scale outward on storage groups so that each database has its own transaction logs.

Smaller Transaction Logs

Experienced Exchange 2000/2003 administrators will immediately recognize an Exchange transaction log because they are always 5,120KB in size. Exchange 2007 transaction logs, however, are a bit smaller. In fact, the transaction log files are quite a bit smaller; 1,024KB to be exact.

The transaction log files are smaller because Exchange 2007 has two new high-availability features called local continuous replication and clustered continuous replication that allow log files to be copied to another location and replayed into a backup copy of their corresponding database. Reducing the log file sizes ensures that data is copied more quickly to the standby location.

Improved Search Features

Content Indexing has been completely rewritten in Exchange 2007 so that it is far more efficient than in previous versions and is more closely integrated with the information store service. Improvements have been made so that the indexing process is throttled back during peak loads and does not affect client use of the Exchange server. By default, each mailbox database automatically has a full-text index associated with it. Messages are indexed upon arrival rather than on a fixed schedule; the index is up-to-date and immediately available to clients.

Full-text search capabilities are available from both Outlook clients as well as Outlook Web Access. Searches can be by word, phrase, or sentence, and in addition to the message bodies, attachments such as Word documents, Excel spreadsheets, text files, and HTML files can be searched.

Improved High Availability Features

One of the biggest enemies of high availability is slow restoration times. As mailbox databases get larger and larger, restore times get longer and longer. Often this is used as a rationale for limiting user's mailbox sizes to less than what they really need to do their jobs effectively.

As mentioned earlier, Exchange 2007 includes two new high-availability features called local continuous replication and clustered continuous replication. These features use a feature similar to the SQL Server log shipping technology. When a transaction log is completely filled, it is shipped (copied) to an alternate location and committed to a backup or standby copy of the database. By ensuring that there is always an update-to-date copy of the mailbox database online that is nearly complete and ready to be put in to production, downtime due to a corrupted database can be greatly reduced.

Local Continuous Replication

Local continuous replication (LCR) is one of the most interesting new features of Exchange 2007. It helps to ensure that an alternate copy of a mailbox database is maintained on the local server. This feature was at one time called continuous backup. The concept of LCR is illustrated in Figure 1.15. A backup copy of the production mailbox database is maintained on the local server. As the production database's transaction logs are completely filled, the transaction logs are copied to the backup location (step 1) and committed to the backup copy of the database (step 2).

Figure 1.15: Local continuous replication

In the event that the production database becomes corrupted, the administrator can switch from the production database to the backup copy of the database.

Clustered Continuous Replication

Clustered continuous replication (CCR) is another interesting new high-availability feature of Exchange 2007. CCR introduces a whole new level of high availability and clustering to Exchange 2007. Unlike traditional single-copy clustering (SCC), in which there is only a single copy of the database, CCR not only has redundant hardware but a backup copy of the database. This backup copy of the database is kept current using replication technology similar to LCR. As transactions are committed to the production copy of a database, the log file is copied to the backup location and committed to the backup copy of the database.

CCR is implemented in the form of two-node, active-passive clustering. Quorum is maintained using a majority node set cluster; a third server acts as a "witness" by providing a file share on which the shared quorum database is located. The active node has one or more mailbox databases; the concept of CCR is illustrated in Figure 1.16. As transactions are committed to the active node's databases and transaction logs, the transaction logs are shipped (copied) to the passive node (shown in step 1).

Figure 1.16: Clustered continuous replication

Once the transaction log has been successfully copied to the passive node, the transactions in that log are committed to the corresponding database on the passive node (step 2). In the event of any type of failure on the active node, the passive node will automatically failover and assume responsibility for the clustered mailbox server (formerly called an Exchange virtual server).

When you're running Windows 2003, the active and passive nodes must be on the same IP subnet, but this is expected to change when the next version of Windows Server (currently code-named Longhorn Server) is released. If an organization has VLAN capability, it can conceivably place the two nodes of a CCR cluster in separate locations.

Clustered continuous replication will help to reduce the "cost of entry" for organizations wishing to move to Exchange clustering since it eliminates the need for costly shared storage such as storage area networks (SANs). Data storage for CCR clusters can be located on direct attached storage (DAS).

Improved Calendaring and Resource Management

Calendaring, resources, and out-of-office features were not as complete as most of today's sophisticated e-mail users require. Exchange 2007 and Outlook 2007 have improved each of these with new features and functions. For many of the calendaring and resource management features to work properly, Outlook 2007 is required and the Exchange 2007 Availability service must be configured on the Exchange Client Access servers.

Resource Management

One of the biggest hurdles that messaging system managers have had to overcome with Exchange is how to manage resource calendars. In earlier versions of Exchange, a resource calendar was nothing more than a mailbox whose calendar was shared to other users or a mailbox that had scripts or event sinks that allowed for automatic acceptance and processing of meeting requests for a particular resource. Exchange 2007 introduces the concept of resource mailboxes. At mailbox creation time (see Figure 1.17), the administrator designates the type of resource that is being created (room or equipment).

Figure 1.17: Resource type is designated when the mailbox is created.

Custom properties can then be set on this resource such as room capacity or audiovisual capabilities. This information can be viewed within Outlook 2007 when a user is looking for a resource that suits the user's requirements. The Resource Booking attendant provides features that control who can book a resource, for how long, and during which hours and provides conflict information.

Calendar Concierge

As users have become more sophisticated, their calendaring requirements have increased. The Calendar Concierge is a collection of features that allow for better management of user and resource mailboxes. The Exchange 2007 Calendar Assistant helps to keep out-of-date meeting requests from disturbing the user by ensuring that they are presented with only the most recent meeting request. The Calendar Assistant also reduces the amount of unnecessary messages relating to meeting requests, such as a Tentative response followed soon after by a Decline or Accept response. The user sees only the most recent message.

The Scheduling Assistant makes the process of scheduling a meeting using either Outlook 2007 or Outlook Web Access much simpler and recommends best meeting times based on requested attendees.

Availability Service

Earlier versions of Exchange used a system public folder for publishing a user's free/busy information. Periodically, the Outlook client had to connect to this public folder and update the user's free/busy times. Exchange 2007 introduces a new web service that runs on the Client Access server role and provides an interface to all users' free and busy times. Only Outlook 2007 clients are able to use this new web service, so the Availability service ensures that free and busy times published by older clients are accessible via the web service and free and busy times published by Outlook 2007 are available via the system public folder.

Out-of-Office Assistant

A number of improvements have been made to the simple Out-of-Office Assistant that was used by earlier versions of Outlook and Exchange. One of the most requested features for Out-of-Office is the ability to allow a user to schedule when their Out-of-Office (OOF) message starts being generated and when it stops. Other features include allowing users to select an internal and an external OOF message and to send an OOF message to only recipients that are in their own Contacts.

Additional administrative control is now possible with OOF messages to restrict which domains an OOF message is sent to and disable some users' ability to configure OOF messages.

Autodiscover

One of the most time-consuming things that an Exchange administrator has to do is to help configure Outlook clients to connect to the Exchange server. In the past, profiles had to be created via scripting or profile utilities. Exchange 2007 introduces a feature called Autodiscover that makes configuration of Outlook 2007 profiles much simpler. Once the user provides their name and their e-mail address (see Figure 1.18), Outlook 2007 automatically discovers the correct server and updates the server if the mailbox moves (even if the original server is no longer online).

Figure 1.18: Configuring Outlook 2007 for Autodiscover

New and Improved Outlook Web Access

Those of us who gushed when we saw the Outlook Web Access interface in Exchange 2003 thought a web interface could not get much better. For Outlook Web Access in Exchange 2007, the Exchange team started over from scratch to build a much more functional interface than ever before. Here are some of the new features in Outlook Web Access 2007:

• Ability to browse the global address list (GAL)

• Document access on internal file shares and Windows SharePoint services

• The ability to manage and remotely wipe Windows mobile devices

• Improved meeting booking features

• Ability to perform full-text searches on mailbox content

• Selectable message format (HTML or plain text) when composing a message

• Ability to set out-of-office messages, define them as internal or external, and schedule when they start

• Manage voicemail features such as their greeting, reset their voicemail PIN, and turn on missed call notifications

Edge Transport Services

The amount of spam and viruses that some organizations receive is staggering. Even small organizations are receiving tens of thousands of pieces of spam, dozens of viruses, and hundreds of thousands of dictionary spamming attacks each week. Some organizations estimate that as much as 90 percent of all inbound e-mail is spam or other unwanted content. Keeping as much of this unwanted content away from your Exchange servers as possible is important. A common practice for messaging administrators is to employ additional layers of message hygiene and security. The first layer is usually some type of appliance or third-party SMTP software package that is installed in the organization's perimeter network. The problem with these third-party utilities is that the administrator has to become an expert on an additional technology.

Microsoft's solution to this dilemma is the Edge Transport server. The Edge Transport server is a stand-alone message transport server that is managed using the Exchange Management Shell (EMS) and the same basic management console that is used to manage Exchange 2007. A server functioning in an Edge Transport should not be a member of the organization's internal Active Directory.

Functions such as transport rules are identical to those that run on an Exchange 2007 Hub Transport server. Content filtering (formerly referred to as the Intelligent Message Filter, or IMF) and Microsoft Forefront Security for Exchange are implemented on the Edge Transport server.

An example of how an organization might deploy an Edge Transport server is shown in Figure 1.19. Inbound e-mail is first delivered to the Edge Transport servers that are located in the organization's perimeter network where it is inspected by the content filter, Forefront Security for Exchange, and any message transport rules. The inbound message is then sent on to the internal Hub Transport servers. Additionally, the Exchange 2007 Hub Transport servers are configured to deliver mail leaving the organization to the Edge Transport servers rather than configuring them to deliver mail directly to the Internet.

Figure 1.19: Deploying an Edge Transport server

The Edge Transport server is a fully functional SMTP message hygiene system with many of the same features that are found in expensive message hygiene software packages and appliances. The following features are included:

• Per-user safe-sender and blocked sender lists are replicated from the user's mailbox out to the Edge Transport server.

• Recipient filtering is enabled when valid recipients are synchronized to the Edge Transport server's local Active Directory Application Mode (ADAM) database.

• Integrated Microsoft content filter is included for spam detection. Spam can be rejected, deleted, quarantined, or delivered to the user's Junk E-mail folder.

• Multitier quarantine allows messages that are highly likely to be spam to be quarantined in the perimeter network while maintaining a separate quarantine inside the network for messages that are still tagged as spam but with a lower Spam Confidence Level (SCL).

• Microsoft Forefront Security for Exchange Server (formerly known as Antigen) is available for the Edge Transport server when Enterprise client access licenses are used.

• Daily content filter and virus signature updates are available for organizations using Microsoft Forefront Security for Exchange Server.

• Real-time block lists (RBLs) and IP Reputation Service allow an IP address to be checked to see if it is a known source of spam.

• Sender ID filters allow for the verification of the mail server that sent a message and whether it is allowed to send mail for the message sender.

• Sender reputation filters allow a sender to be temporarily placed on a block list based on characteristics of mail coming from that sender, such as message content, Sender ID verification, and sender behavior.

Unified Messaging

The concept of unified messaging means that information from multiple sources is all accessed in a single location. This concept is by no means a new one; third-party vendors have had fax and voicemail gateways for most major e-mail systems. The Exchange 2007 Unified Messaging server role represents Microsoft's entrance into this market.

The Unified Messaging server role functions as just another Exchange server in your organization, but this role includes components that allow IP-based phone systems and IP/PBX (public branch exchange) gateways to interface directly with Exchange over the network. This is provided the IP phone system or IP/PBX can communicate using Session Initiated Protocol (SIP) over TCP or Real-Time Transport Protocol (RTP) for voice communication or T.38 protocol for real-time facsimile transport.

When the Exchange 2007 Unified Messaging role is integrated with an IP-based phone system or a PBX with an IP/PBX gateway, the following additional functions may be possible:

• Inbound voicemail is delivered directly to the user's mailbox.

• Inbound faxes are delivered directly to the user's mailbox.

• Users can call in to the phone system and have their e-mail read to them, listen to their schedule, or move appointments around on their schedule and notify attendees.

• Users can call in to the phone system and look up users from the global address list.

New Programming Interfaces

Much of the underlying infrastructure of Exchange 2007 has been completely rewritten. As a result, many of the application programming interfaces (APIs) used to access Exchange data and to manage Exchange components have been replaced with new APIs.

Exchange Management

Management of Exchange-related components and recipient objects is now performed with the new management API. All operations that can be performed have been defined as tasks. The management API provides access to all management functions via the Exchange Management Shell tasks, also known as cmdlets (pronounced "command-lets"). The Exchange Management Shell is a set of extensions for the Windows PowerShell. Exchange management functionality can be extended and accessed via managed code and custom scripts can integrate with and use .NET objects.

Transport Agents

All messages and message content traveling through the message transport system (on a Hub Transport server or Edge Transport server) can be manipulated using transport agents. Transport agents are written using managed code. They replace Exchange 2000/2003 transport sinks.

Exchange Managed APIs

Exchange Managed APIs extend the Microsoft .NET Framework by providing classes and data structures that allow custom programs to access and manipulate different parts of e-mail message content. Functions include accessing MIME content; filtering e-mail body content; converting message content between plain-text, HTML, and RTF formats; and reading or writing calendar items.

Web Services

One of the most exciting new APIs is the Web Services API. Web Services allows developers to write applications that can remotely access mailboxes, folders, and message content. Many of the new Exchange services - such as the Autodiscover service, Availability service, and Messaging Records Management - use the Web Services API. Services can be developed that can send notifications to client applications and provide synchronization of mailbox folders and items. The Web Services API provides these features:

• Ability to manage folders in a user mailbox, including creating, deleting, copying, changing, searching, viewing, and moving folders

• Ability to manage messages in a user mailbox, including creating, deleting, copying, changing, searching, viewing, moving, and sending messages as well as accessing message content

• Ability to enumerate distribution group memberships