Exchange / SIP -Experience Messaging

BLACKBERRY ENTERPRISE SERVER SERVICES.

2009-03-31T12:20:00.001+05:30

Blackberry Attachment Service: Blackberry Attachment Service converts supported message attachments into format users can view on their Blackberry Devices.
Blackberry Collaboration Service: Blackberry Collaboration Service provides connection between organizations IM Server and Enterprise IM application on devices.
Blackberry Configuration Database: Blackberry Configuration Database is a relational Database that contains configuration data that BES components use. It includes :
- Details about the connection from BES to wireless network.
- User list.
- Address mappings between PINS and email address for Blackberry MDS Connection Service push features.
- Read only copy of each master encryption key.
Blackberry Controller:
Blackberry Controller monitors the BES Services and restarts them if they stop responding.
Blackberry Dispatcher:
Blackberry Dispatcher compresses and encrypts all the data that is sent to and from BB devices. It sends the data through the Blackberry Router to and from wireless network.
Blackberry Manager:
Blackberry Manager connects to the Blackberry Configuration DB. It's used to manage the BB Domain, including user accounts and device administration. The BB Domain consists of a single BB Configuration Database and all the BES Servers instances that use it.
Blackberry MDS Connection Service: BB MDS Connection Service allows BB devices to access web content, Internet, Organization's Intranet. It allows BB devices to connect to the intranet application or content servers for application data.
Blackberry MDS Integration Service:
BB Integration Service provides application level integration for BB MDS runtime applications on BB devices. You can use MDS Integration Service to install BB MDS runtime applications that are stored in MDS Application Repository on BB Devices. You can also use Integration Service to add, remove, and update applications.
Blackberry MDS Application Repository: Blackberry MDS Application Repository stores BB MDS runtime applications that developers can create and publish the MDS Studio or the BB plug in for MS Visual Studio Developer tools.
Blackberry Messaging Agent: BB Messaging Agent connects to your organizations messaging Server to provide messaging services, calendar management, address lookups attachment viewing, attachment download, and encryption key generation. It also acts as a gateway for BB synchronization service to access organizer data on messaging server. BB Messaging Agent synchronizes configuration DB and user mailboxes.
BB Policy Service:
BB Policy Service performs administrative service over wireless network. It sends IT Policies and IT Administration commands and provisions Service Books. It also sends service books to configure feature and component setting on BB Devices.
Blackberry Router:
BB Router connects to wireless network to send data to and from BB Devices. It also sends data within organization's network to BB devices that are connected to computers BB Device Manager.
Blackberry Synchronization Service:
BB synchronization service synchs organizer data between BB Devices and messaging server over wireless networks.

Architecture:

Blackberry Enterprise Server Message Flow:

Message Flow from Messaging Server to BB Device:

New Email message arrives in a user email box. Microsoft Exchange notifies the BB Messaging Agent.
BB Messaging Agent applies global filter rules to the message in the user's mailbox and filters the message which doesn't match the criteria.
BB Messaging Agent sends the first 2KB of the message to the BB Dispatcher.
BB Dispatcher compresses the first 2KB of the message, encrypts it with master encryption key of the BB device, and sends the encrypted message to BB Router.
BB Router sends the encrypted data to the wireless network over port 3101.
Wireless network verifies that the PIN belongs to a valid BB Device that's registered with the wireless network and sends the message data to the BB Device.
BB Device sends a confirmation to the BB Dispatcher. BB Dispatcher sends confirmation to the BB Agent. If the Messaging Agent did not receive any confirmation in 4 hours the Messaging Agent resends the message to wireless network again.
BB Device decrypts the message and decompresses the message so that the user can view it, and notifies user that new message has arrived.

Message flow from BB Device to Messaging Server:

A user sends message from BB Device. The BB Device assigns a "Refld" to the message. If the message is a meeting request, or calendar entry, BB Device appends the calendar information to a message.
BB Device encrypts the message and sends the message to the wireless network over port 3101.
The wireless network sends the message to the BES Enterprise server.
BB Dispatcher uses the master encryption key of the BB Device to decrypt and decompresses the message.
The BB Messaging Agent sends the message to the user's application.
BB Messaging Agent sends a copy of the message to the Sent Items view in the users email application.
The Messaging server delivers the message to the recipients.

Instant Messaging Session with BB Client and LCS 2005 Server:

User logs on to a collaboration client on a BB Device.
BB device compresses and encrypts the user ID and password and sends them through the BB Router to the Dispatcher over port 3101.
BB Dispatcher Service sends the request to the BB Collaboration Service over port 3200. If the BB Collaboration Service is located on remote computer, then the requests still remains encrypted using RIM proprietary protocol.
The BlackBerry Collaboration Service checks the BlackBerry Configuration Database to find out if the maximum number
of instant messaging sessions has been reached, and performs one of the following actions:
If the maximum number of sessions has been reached and a timeout limit is set, the BlackBerry Collaboration Service logs out any instant messaging sessions on BlackBerry devices that are out of coverage, and any instant messaging sessions that are no longer sending status messages to the BlackBerry Collaboration Service. If there are no idle sessions, the BlackBerry Collaboration Service sends a "Server Busy" status message to the BlackBerry device and rejects the login request. If the maximum number of sessions is not set and the number of sessions equals the total number that the Microsoft® Real-Time Communications API supports, the BlackBerry Collaboration Service sends a "Failed" status message to the BlackBerry device and rejects the login request
BB Collaboration Service then checks with Configuration Database to check whether the user has permission to use the collaboration client and places the request in queue for IM Connector.
On the computer that hosts the Blackberry Collaboration Service the MSMQ software version 3.0 or later sends the request in XMPP format, encrypted with AES to IM Connector. BB Collaboration Service opens the connection using TLS.
BB IM Connector creates a RTC client object for the session which maintains an open TLS connection between the collaboration client and LCS Server 2005 for the duration of the session.
BB IM Connector returns the acceptance to the local queue on the BB Collaboration Service.
The BlackBerry Collaboration Service returns the acceptance, in encrypted and compressed format, through the BlackBerry Dispatcher to the BlackBerry device, and creates a cache of the connectivity information to maintain the new instant messaging session.
The collaboration client on the BlackBerry device starts the instant messaging session using the RTC connection object.

Message Attachment Flow:

A user receives a message with an attachment on a BB Device.
BB Messaging Agent verifies that the format of the attachment is valid for conversion.
IF the format is not valid "Open Attachment" Option does not appear on the BB Device. If valid then the user clicks "Open Attachment" option.
Attachment viewer sends a request to the BB Messaging Agent which connects to BB Attachment Service over port 1900.
BB Attachment Service retrieves the attachment in binary format from the user's message stores using BB Messaging Agent link to the Messaging Server. The BlackBerry Attachment Service distills the attachment and extracts the content, layout, appearance, and navigation information from it.
The BlackBerry Attachment Service organizes, stores, and links the information in a proprietary DOM in a binary XML style.
The BlackBerry Attachment Service formats the attachment for the BlackBerry device and converts the formatting is based on the request for content (for example, page and paragraph information, or the available BlackBerry device information (for example, screen size, display, or available space).
The BlackBerry Attachment Service sends the UCS data to the BlackBerry Messaging Agent using a TCP/IP connection over port 1900.
The BlackBerry Messaging Agent sends the converted attachment to the BlackBerry Dispatcher.
The BlackBerry Dispatcher compresses the first portion of the attachment, encrypts it with the master key of the BlackBerry device, and sends the first portion of the attachment to the BlackBerry Router.
The BlackBerry Router sends the first portion of the attachment to the wireless network over port 3101, which verifies that the PIN belongs to a valid BlackBerry device that is registered with the wireless network.
The wireless network delivers the attachment to the BlackBerry device. The BlackBerry device sends a delivery confirmation to the BlackBerry Dispatcher, which sends it to the BlackBerry Messaging Agent. If the BlackBerry Enterprise Server does not receive a delivery confirmation within 4 hours, it sends the attachment data to the wireless network again.

Activating Blackberry device over wireless network.

User contacts IT to activate the BB Device.
Administrator uses BB Manager to create a temporary activation password for the user account and communicates the password to the user.
To activate the device over wireless network, the user opens the activation application on BB Device and types the appropriate email address and the activation password.
BB Device sends an activation request message to the email account. The message contains information about the BB device, such as routing information and the public keys for the BB Device.
BES sends the BB device an activation response that contains routing information about the BES server and the public keys for the BES Server.
BES and the BB Device establish a master encryption key. BES and BB Device confirm knowledge of the master encryption key to one another. If the confirmation succeeds, the activation proceeds and further communication between BES and the BB device is encrypted.
BES sends the IT Policy to the BB Device. If the BB Device cannot accept the IT Policy the activation does not complete.
BES sends the appropriate service books to BB Device. The user now can send and receive messages on the BB device.

Exchange Server 2007 Active Directory Site and Connector Selection Algorithms

2008-03-16T19:27:00.001+05:30

When multiple paths exist to a destination, Exchange Server 2007 Routing uses deterministic algorithms to choose one of the paths. The algorithms are deterministic because one of the paths is always chosen (as long as the contributing factors do not change). This article describes the AD Site and Connector Selection algorithms used by Routing.

AD Site Selection Algorithm

If a recipient (such as a user mailbox) is located in the remote AD site (or accessible from the remote AD site such as an Exchange Server 2003 mailbox accessible via the first hop RGC homed in the remote AD site) and multiple paths exist to get to that AD Site, Routing chooses one path deterministically in the below order until a single path is left:

a) Path with the lowest cost from source site to the destination site.

b) The path with the least number of segments (i.e., hops).

c) Alphanumerically lower preceding AD Site name.

The term "cost" here can refer to either AD replication cost or the Exchange cost configured on the AD Site Links. If an AD Site Link has been configured with Exchange cost, it will be used as the cost of the Site Link by Exchange Server 2007 Routing. Otherwise, AD replication cost is used. Exchange cost is provided as a means to override AD replication cost, if it is necessary to alter AD topology for Exchange specific purposes.

Some examples illustrating the site selection algorithm are provided below.

Example 1

In the topology below, there are two least cost paths (of total cost 15) for mail sent from site A to R1 in Site D - {A-B-D} with number of segments 2 and {A-B-C-D} with number of segments 3. {A-B-D} is chosen because it has lesser number of segments.

Example 2

In the topology below, mail to R1 from Site A has two equal least cost paths with same number of segments (2) - {A-B-D} and {A-C-D}. Path {A-B-D} is chosen because B is alphanumerically lower than C.

Example 3

In the topology below, mail to R1 from Site A has two least cost paths of the same number of segments (3) - {A-B-D-E} and {A-C-D-E}. Path {A-B-D-E} is chosen because B is alphanumerically lower than C (the site preceding the destination site E is the same in both cases, so the site names preceding that site (D) are compared.)

Other Notes

Using the site selection algorithm described above, once the destination AD Site has been chosen, Exchange Server 2007 Routing attempts to direct relay to the destination. Direct relay can be short circuited due to some factors that are described below.

Hub sites

Hub sites can short circuit direct relay. If a hub site exists in the least cost path (note: the least cost path is chosen first and then the presence of hub site is checked for to determine if the direct relay is short circuited), the mail will stop at a Hub Transport Server in the hub site before it is relayed to the destination. If there are multiple Hub Sites along the least cost path, the mail will stop at each Hub Site along the path before it is relayed to the destination AD Site. The diagram below shows a least cost path from AD Site A to AD Site E. B and D are Hub Sites. The mail from A to recipient R1 will first stop at B and then again at D before it is delivered to E.

Delayed fan-out

If multiple recipients of a single message share part of or the entire least cost path, a single copy of the message is sent with these recipients until the bifurcation point. When the mail reaches the bifurcation point, the message is bifurcated and a separate copy is sent to each recipient. In the diagram below, the least cost path for R1 is A-B-C-D and least cost path to R2 is A-B-C-E. If mail is sent from Site A to recipients R1 and R2, a single copy of the message containing R1 and R2 is relayed to Site C which is the bifurcation point. In Site C, the message is bifurcated and a copy containing R1 is sent to Site D and a copy containing R2 is sent to Site E.

In the example above, if B happens to be a hub site, then a single copy of the message containing R1 and R2 is sent to B. B will then relay a single copy of the message to C. In Site C, the message is bifurcated to D and E.

Back off

Another factor that can prevent direct relay to the destination is if SMTP connection cannot be established to any of the Hub Transport servers in the destination AD site. In that case, a back off mechanism is employed and mail will be queued at the site closest to the destination site (which could be the source site if all the intermediate sites are down).

Connector Selection Algorithm

If an external recipient can be routed using more than one send connector and these connectors all meet the message size constraints, Exchange Server 2007 Routing chooses one of the connectors deterministically. The selection algorithm varies slightly depending on whether the choice is between multiple Exchange Server 2007 connectors or between Exchange Server 2007 and Exchange Server 2003 connectors.

Note that Exchange Server 2007 routing does not load balance among multiple connectors. Load balancing can be accomplished by adding multiple source servers to a single connector. Instead, it will always choose one of the connectors deterministically following the two core tenets of Exchange Server 2007 Routing - least cost and deterministic routing. Load balancing will be covered in a separate article.

Below is the connector selection algorithm used by Exchange Server 2007 Routing:

a) Connector with the most specific address space match.

b) At this point, if the choice is between two or more Exchange Server 2007 connectors, the following selection method is followed:

Cost of the connector (which is the sum of the cost to get to one of the source transport servers of the connector and the cost of the address space; the former is 0 if the source transport servers are in the local AD site).
Closer proximity (Local Server is closer than Local AD Site which is closer than Remote AD Site).
Alphanumerically lower connector name.

If the choice is between two or more Exchange Server 2003 connectors, the following selection method is followed:

Cost of the connector (which is the sum of the cost to get to one of the source transport servers of the connector and the cost of the address space).
Alphanumerically lower connector name.

If the choice is between an Exchange Server 2007 and an Exchange Server 2003 connector:

Exchange Server 2007 connector is always chosen over Exchange Server 2003 connector.

The cost is overridden when the choice is between Exchange Server 2007 and Exchange Server 2003 connectors because Exchange Server 2003 is not aware of Exchange Server 2007 costs (i.e., the cost of the AD Site links). Preferring Exchange Server 2007 connectors also avoids routing loops. Because Exchange Server 2003 is not aware of Exchange Server 2007 connector costs, it is possible that it views Exchange Server 2007 connector has lower cost than an Exchange Server 2003 connector although the former may have a higher cost. Because of this, Exchange Server 2003 server can route to a higher cost Exchange Server 2007 connector. If Exchange Server 2007 always chose the least cost connector, it would route the mail back to the Exchange Server 2003 connector. This can cause routing loops as mail ping pongs between Exchange Server 2007 and Exchange Server 2003 routing groups. To break the loop, when the choice is between an Exchange Server 2007 and an Exchange Server 2003 connectors, Exchange Server 2007 Routing will always choose the Exchange Server 2007 connector regardless of the cost. Keep in mind that Exchange Server 2007 connector is only preferred over Exchange Server 2003 connector when both have the same address space match for a recipient.

Here are some examples illustrating this algorithm.

Example 1

In the topology below, there are two candidate connectors, C1 on the local server and C2 in the remote AD Site C, for emails sent from the local server in AD Site A to user@subdomain1.domain1.com. C2 is the more specific address space match and is chosen.

Example 2

In the topology below, there are two candidate connectors, C1 on the local server and C2 in the remote AD Site C, for emails sent from the local server in AD Site A to user@subdomain1.domain1.com. Both connectors have the same address space match for user@subdomain1.domain1.com and same cost (15). C1 has a closer proximity than C2 and will be chosen.

Example 3

In the topology below, there are two candidate connectors, C1 and C2, for emails sent from AD Site A to user@subdomain1.domain1.com. In this case, since both connectors have the same address space match for user@subdomain1.domain1.com, same cost (5 + 10 = 15), and same proximity (Remote AD Site), connector name acts as the tie breaker and C1 will be chosen.

Example 4

In the topology below, if mail is sent to user1@subdomain1.domain1.com from AD Site A, there are two candidate connectors - C2 homed in AD Site D and C1 homed in Exchange Server 2003 Routing Group 1. Both have the same address space match for user1@subdomain1.domain1.com.

C2 total cost = 15:

Cost to remote AD Site (5) +

Address space cost (10)

C1 total cost = 11:

Cost to remote AD Site (5) +

Cost of RGC 1 (5) +

Address space cost (1)

Although C1 has a lower total cost than C2, C2 is chosen because it is homed on an Exchange Server 2007 server.

Other Notes

Some notes related to connector selection:

1) Exchange Server 2007 supports scoping connectors to an AD Site (similar to Exchange Server 2003 supporting scoping per Routing Group). Scoping the connector affects the visibility of the connector. If a connector is scoped to an AD Site (by prefixing Local: to the address space), then it will not be visible in other AD Sites. It will also not be visible to other routing groups (because Exchange Server 2003 servers see Local: and the fact that the connector is homed in Exchange Server 2007 Routing Group and will ignore it). In such a case, although there may be two connectors configured in the organization, to the connector selection algorithm executed on the Hub Transport Server in an AD Site, it may look like there is a single connector.

2) After choosing one connector deterministically using the algorithm described in this section, if the connector happens to be homed in a remote AD site, it is possible that there may be multiple paths to get to that AD site in order to reach the connector. In that case, AD Site Selection algorithm described in Section 1 comes into play in order

SIP Signaling Overview

2007-12-06T16:03:00.001+05:30

SIP is based on the request-response paradigm. The following sequence is a simple example of a call set-up procedure:

1. To initiate a session, the caller (or User Agent Client) sends a request with the SIP URL of the called party.

2. If the client knows the location of the other party it can send the request directly to their IP address; if not, the client can send it to a locally configured SIP network server.

3. The server will attempt to resolve the called user's location and send the request to them. There are many ways it can do this, such as searching the DNS or accessing databases. Alternatively, the server may be a redirect server that may return the called user location to the calling client for it to try directly. During the course of locating a user, one SIP network server can proxy or redirect the call to additional servers until it arrives at one that definitely knows the IP address where the called user can be found.

4. Once found, the request is sent to the user and then several options arise. In the simplest case, the user's telephony client receives the request, that is, the user's phone rings. If the user takes the call, the client responds to the invitation with the designated capabilities* of the client software and a connection is established. If the user declines the call, the session can be redirected to a voice mail server or to another user.

* "Designated capabilities" refers to the functions that the user wants to invoke. The client software might support videoconferencing, for example, but the user may only want to use audio conferencing. Regardless, the user can always add functions - such as videoconferencing, white-boarding, or a third user - by issuing another invite request to other users on the link.

SIP has two additional significant features. The first is a stateful SIP server's ability to split or "fork" an incoming call so that several extensions can be rung at once. The first extension to answer takes the call. This feature is handy if a user is working between two locations (a lab and an office, for example), or where someone is ringing both a boss and their secretary.

The second significant feature is SIP's unique ability to return different media types within a single session. For example, a customer could call a travel agent, view video clips of possible holiday destinations, complete an on-line booking form and order currency - all within the same communication session.

SIP Methods

The commands that SIP uses are called methods. SIP defines the following methods:

SIP Method	Description
INVITE	Invites a user to a call
ACK	Used to facilitate reliable message exchange for INVITEs
BYE	Terminates a connection between users or declines a call
CANCEL	Terminates a request, or search, for a user
OPTIONS	Solicits information about a server's capabilities
REGISTER	Registers a user's current location
INFO	Used for mid-session signalling

SIP responses
The following are SIP responses:

1xx Informational (e.g. 100 Trying, 180 Ringing)
2xx Successful (e.g. 200 OK, 202 Accepted)
3xx Redirection (e.g. 302 Moved Temporarily)
4xx Request Failure (e.g. 404 Not Found, 482 Loop Detected)
5xx Server Failure (e.g. 501 Not Implemented)
6xx Global Failure (e.g. 603 Decline)

They closely resemble HTTP responses

Diagram 1 below depicts a simple call set-up process.

| Download this for PC (203k) | Download this for MAC (242k) |

Notes: - All provisional (1xx) responses have been omitted for clarity. The route taken by the ACK, and any later in-call signalling can vary. As by the time the two user agents have exchanged INVITE and 200 OK messages they potentially know each others actual destinations it could be sent end-to-end. However, any of the proxies in the initial signalling path that wants to can insist on remaining in the signalling path for the rest of the call.

In this example, user 1, who resides in the domain here.com, wants to call user 2. User 1 knows user 2 because they usually reside within the same domain. User 1 therefore sends an INVITE for sip:user2@here.com to a local proxy server, shown in the diagram as SIP Stateful Proxy Server 1. The Proxy Server in turn sends the INVITE to a Redirect Server to try and identify the current location of sip:user2@here.com. The Redirect Server determines that user 2 does not presently reside within the domain here.com but can be found for today at there.com. The Redirect Server returns this information to Proxy Server 1 in a 302 Moved Temporarily response which lists the new address to try for user 2 as sip:user2@there.com.

As this represents a final response to the INVITE, the Proxy Server ACKs this response. Then Proxy Server 1 has a choice, it can either return the 302 response directly to user 1 for them to try or it can try the suggested location itself on user 1's behalf. In this example Proxy 1 attempts to locate sip:user2@there.com be modifying the original INVITE and sending it on. As Proxy1 doesn't know of another Proxy Server that controls the domain there.com it chooses to route the INVITE to a Stateless Proxy which should know where to route the INVITE next. This Stateless Proxy then routes the INVITE on to another Stateful Proxy, which does control the domain there.com. Of course in real life there may be many more hops than this. Stateful Proxy 2 then locates user 2 and completes the routing of the INVITE. User 2 then accepts the call by responding with a 200 OK message. This 200 OK response follows the same path that was taken by the INVITE back to user1. To complete the call set up user 1 must then confirm it received this response to its INVITE request by sending an ACK. Potentially it could send this ACK directly to user 2 but, in this example, both Stateful Proxy Servers indicated in the INVITE requests they routed on that they wanted to remain in the signaling path for the duration of the call. As a consequence, the ACK is routed through both of these proxies, as will any subsequent SIP messages related to this call, such as those for call tear down.

Inside a SIP message

The Request line and header field define the nature of the call in terms of services, addresses, and protocol features. The message body is independent of the SIP protocol and can contain anything.

Edge Transport Server and step by step configuration of Edge Server

2007-08-08T16:55:00.001+05:30

How an Edge Transport server works

Because an Edge Transport server sits at your network perimeter, It is the one server in an Exchange Server 2007 organization that is exposed to the outside world (although this server should still be protected by a firewall).

In Exchange Server 2003, the NNTP and SMTP services have to be installed before you're allowed to install Exchange Server. These services are no longer required in Exchange Server 2007.

The pre-installation checks will actually fail if NNTP is installed on Exchange Server 2007, because it does not support the NNTP service. Likewise, the Exchange 2007 Setup wizard also checks to make sure that the SMTP service is not installed.

The SMTP service is forbidden because it is actually an Internet Information Services (IIS) component. Fearing that IIS might be vulnerable to attack, the Exchange Server development team completely rewrote the SMTP service using managed code. The new and improved SMTP service gets installed as a part of Exchange Server 2007.

The relationship between an Edge Transport server and Active Directory

Microsoft has also made some changes to Exchange Server's dependency on Active Directory. Exchange Server 2007 requires access to Active Directory, but the Edge Transport server role is an exception.

It would be a huge security risk to give a perimeter server read and write access to Active Directory. So an Edge Transport server uses Active Directory Application Mode (ADAM) instead.

What this means is that critical portions of Active Directory are copied to an Active Directory partition that resides on the Edge Transport server. Consequently, the server has the necessary configuration information -- but you eliminate the risk of exposing sensitive Active Directory data.

Edge Transport Server role rules

Microsoft created the concept of server roles in Exchange 2007 as a way of making the newest Exchange version more modular. Various roles can be combined on a machine so Exchange Server can perform its required tasks without unnecessary overhead or security risks that could potentially be introduced by running unnecessary code.

Normally, a single Exchange 2007 server can host multiple server roles -- an Edge Transport server is again the exception. Because an Edge Transport server needs to be hardened (and because it doesn't have direct access to Active Directory), no other Exchange 2007 server roles can be run on the same machine.

Step 2: Install the Edge Transport server

Installing an Edge Transport server in an Exchange Server 2007 environment is pretty straightforward:

Insert your Exchange Server 2007 installation CD. The Windows Autoplay feature should execute the Setup.exe file. When the Exchange Server 2007 splash screen appears, click Step 4: Install Microsoft Exchange to launch the Setup wizard.
Click Next to bypass the Setup wizard's Welcome screen.
Accept the End User License Agreement and click Next.
Setup will ask you if you would like to enable error reporting. Error reporting will automatically send information regarding server errors to Microsoft. Decide whether or not you want to enable error reporting and then click Next.
The Edge Transport Server role is only available through a custom installation, so choose the Custom Exchange Server Installation option and click Next.
You should now see a screen asking you which Exchange Server roles you want to deploy. Deselect all the roles, and then select the Edge Transport Role checkbox.
Before moving on, pay attention to the disk space requirements displayed on this screen. The Edge Transport Role only requires 724 MB of disk space, but it's still a good idea to make sure that your server has sufficient disk space. If necessary, this screen gives you the option of changing the installation path.
Click Next and Setup will perform a quick readiness check.
Assuming that there are no readiness issues, click the Install button and Setup will begin copying all of the necessary files.
When the installation process completes, click Finish.

Step 3: Create an Edge Subscription

Exchange 2007 Edge Transport servers do not have direct access to Active Directory data because of the inherent security risk it would introduce. But the server still needs access to some configuration information stored in Active Directory.

To solve this problem, an Edge Transport server copies the necessary information from the Active Directory database to an Active Directory Application Mode (ADAM) partition.

Setup does not automatically extract the necessary Active Directory information though. Instead, you have to create an Edge Subscription. An Edge Subscription is essentially a one-way trust with the Active Directory database (the Edge Transport Server trusts the Active Directory, but not vice versa).

Once the subscription has been established, Exchange Server will use the EdgeSync synchronization service to copy the necessary configuration information from Active Directory to the Edge Transport server.

Edge Subscription caveats

Before I show you how to create an Edge Subscription, I need to warn you that doing so will completely undo any custom configurations that you might have applied to the Edge Transport server. Specifically if the Edge Transport server contains any of the following types of items, they will be deleted:

Accepted domains
Message classifications
Remote domains
Send connectors

The server's InternalSMTPServers list of TransportConfig objects will also be overwritten during the Edge Subscription process.

As an added precaution, the Edge Subscription process modifies the Exchange Management Shell so that it can no longer be used to manage the abovementioned objects. If you need to modify any of these types of objects in the future, you need to do it on a non-Edge Transport server. Your changes can then be replicated to the Edge Transport server via the EdgeSync service.

Up to this point, the Edge Transport server you created in Step 2 has no knowledge of your Exchange Server organization, and vice versa. Because of this, you can't just click a magic button and expect Active Directory information to be imported into the Edge Transport server. Instead, you have to make the Exchange Server organization aware of the Edge Transport server's existence.

The process involves exporting the Edge Transport server's configuration information to an XML file, which can then be imported into your Exchange Server organization.

How to set up an Edge Subscription

Open the Exchange Management Shell on the Edge Transport server, and enter this command:
New-EdgeSubscription –file "C:subscription.xml"
At this point, Exchange will display a rather ominous warning message. This warning just tells you about all of the types of objects that will be overwritten or deleted during the subscription process. When the warning asks you if you want to continue, press Y and the command will go to work.
When you execute this command, Exchange Server will create an XML file named subscription.xml, which it will place in the root directory on the Edge Transport server's C: drive. The command also creates an ADAM account. This account is used for the purpose of securing the configuration data as it's replicated from Active Directory.
Now we need to import the subscription.xml file into the Hub Transport server in order to create the Edge Subscription.
Copy the XML file to a location where it will be accessible to the machine that you are going to be using to set up the Edge Subscription. My personal recommendation is to copy the file to a USB thumb drive and then erase it from the Edge Transport server (for security reasons).
Once the file has been copied to an accessible location, log in to your Hub Transport server using an account that is both a local administrator and a member of the Exchange Organization Administrator's group.
Open the Exchange Management Console and navigate through the console tree to Organization Configuration -> Hub Transport.
Select the Edge Subscription tab shown in Figure A and then click the New Edge Subscription link found in the Actions pane.
Figure A: This is the Edge Subscriptions tab.

The New Edge Subscription dialog box asks you which Active Directory site the Edge Transport server should become a part of. If your organization consists only of a single site, then there is no grand decision involved. If you have multiple sites though, then you should make the Edge Transport server a member of the site that has the fastest (or most reliable) network connectivity to the perimeter network.
Figure B: Create the subscription to the Edge Transport server here.

After you choose the Active Directory site in which the Edge Transport server should be included, it's time to import the XML file that you created earlier.
Use the Browse button to browse for and select the subscription.xml file.
Verify that the Automatically Create A Send Connector for this Edge Subscription checkbox is selected, then click the New button to import the XML file and create the Edge Subscription. (A send connector is used any time that messages are sent to the Internet through the Edge Transport server.)

The process of creating an Edge Subscription is kind of anticlimactic, but there is actually quite a bit going on behind the scenes. Specifically, Exchange Server creates a secure, authenticated communications channel between the Hub Transport server and the Edge Transport server. Once data can be transmitted securely, Exchange Server begins replicating data from Active Directory to the Edge Transport server's ADAM partition.

Step 4: Replicate Active Directory data to the Edge Transport server

The Edge Transport server does not receive a complete copy of Active Directory for security reasons, but there is still quite a bit of information that gets replicated, including:

The safe senders list
The Remote Domains list
The Accepted Domains list
Recipient data including email address, contacts, distribution lists, etc.

After the initial replication completes, it is up to Exchange Server to keep the information in the ADAM partition up to date. Remember that the Edge Transport server is not a domain controller. This means that the ADAM partition is not updated through the normal Active Directory replication process.

Instead, Exchange Server keeps the ADAM partition synchronized with Active Directory. The EdgeSync synchronization does not occur nearly as quickly as true Active Directory replication though. Exchange Server synchronizes changes to configuration-related data hourly; it synchronizes changes to recipient data once every four hours.

Of course, there may be situations in which waiting four hours for a directory synchronization to occur is simply impractical. Fortunately, there is a way to force a manual EdgeSync synchronization. Just open the Exchange Management Shell and enter this command:

Start-EdgeSynchronization

Now that you have created an Edge Subscription, you must wait for the initial synchronization to complete. The amount of time it will take varies depending on the size of your Active Directory and the size of your Exchange Server organization. If possible, recommend just letting the synchronization run overnight.

The next step is to verify that the Edge Transport server has received the necessary information from the Hub Transport server. Since a full directory comparison would be unfeasible, there are a couple of specific things you can spot check to verify that the Edge Transport server is working correctly:

First, go to the Edge Transport server and open the Exchange Management Console to verify that the send connector was created successfully. The only primary containers you should see in the console tree should be the Edge Transport container and the Toolbox container.
To make sure that the send connector was created successfully, select the Edge Transport container. The lower half of the details pane will display a series of tabs. Select the Send Connectors tab and verify that a send connector is present and enabled.

If your organization only contains a single Active Directory site, the send connector should look like this:

edgesync – default-first-site-name to Internet Enabled

edgesync – Inbound to Default-First-Site-Name Enabled

As you can see, the send connector actually consists of two different components: an inbound connector and an outbound connector. Both of these connectors should be created automatically.

If for some reason the send connector doesn't exist, you can use the New Send Connector option found on the Actions pane to manually create one (there is also an option to enable the send connector if it is disabled for some reason).

Before you create a send connector though, make sure that the Accepted Domains list has been replicated to the Edge Transport server. If the Accepted Domains list has been synchronized, but there is no send connector, you may have simply forgotten to select the checkbox to automatically create it when you set up the Edge Subscription.

If the send connector is missing and the Accepted Domains list has not been synchronized though, there is clearly some sort of problem occurring.

To check the Accepted Domains list, go to the Hub Transport server, open the Exchange Management Shell, and enter this command:

Get-AcceptedDomain

Exchange Server should return a list of the accepted domains, as shown in Figure C.

Figure C: Get-AcceptedDomain will retrieve a list of the accepted domains.

Now that you have a list of the accepted domains in hand, go to your Edge Transport server, open the Exchange Management Shell and issue the Get-AcceptedDomain command.

The Edge Transport server should produce a list of accepted domains. All you have to do now is to verify that the two lists match each other. If the Edge Transport server contains a partial list of accepted domains, then synchronization is most likely working, but probably has not completed yet.

If you have given synchronization time to complete, but the Accepted Domains list is empty, then there is probably some sort of communications problem between the Edge Transport server and the Hub Transport ser

Step 6: Configure Edge Transport server email filtering agents

The Edge Transport server that we've configured so far serves no real purpose other than to isolate your back-end Exchange servers from the Internet. You can make your Edge Transport server much more useful by configuring it to filter out spam, viruses and malware prior to it arriving at your Hub Transport server.

First, you need to understand though that all filters on an Edge Transport server are enabled automatically by default. What this means is that if you create a filter, it immediately goes into effect.

Over time, you can gradually filter messages more aggressively as you are able to confirm that legitimate email messages are not being filtered out. Of course, you have the option to disable filters, but doing so allows messages that would normally be filtered to pass into your Exchange 2007 organization.

Edge Transport servers filter spam and malware by making use of connection filters. Any messages flowing into the Edge Transport server's receive connector is processed by the Connection Filtering Agent. It's the Connection Filtering Agent's job to filter out spam and malware prior to messages being delivered to the recipient.

When you open the Exchange Management Console on an Edge Transport server, you will notice that there are only two available containers: Edge Transport and Toolbox. When you select the Edge Transport container, the details pane will display the various options for creating a filter, as shown in Figure D.

Figure D: You can create several different types of filters.

Notice that the bottom portion of the details pane contains a series of tabs. The Antispam tab is selected by default; it allows you to create several different types of spam filters.

Content filtering

One of the most useful spam filters is the Content filter. Its job is to use a mathematical algorithm to determine the probability of an email message being spam, and then filter it accordingly. The content filter uses the same Spam Confidence Level (SCL) ratings as Microsoft Outlook.

You can access the content filter by right clicking on Content Filtering and selecting Properties. The properties sheet contains three tabs that are worth paying attention to: Custom Words, Exceptions, and Action.

The Custom Words tab allows you to enter words or phrases that can be used to flag an email message as spam. For example, you might enter phrases such as "online casino," "herbal Viagra," or "Bank of Nigeria." Keep in mind though that using the custom word filter has limited effectiveness because most spam messages are designed to avoid using trigger phrases.
The Exceptions tab allows you to enter email addresses that the content filter should ignore. For example, if you have a sales email address and you want to make sure that no legitimate messages are ever accidentally filtered as spam, you could enter that mailbox's email address on the Exceptions tab.
Exceptions are applied on a filter by filter basis. So entering an email address into the Exceptions tab will keep the content filter from blocking email messages sent to that mailbox -- but it will not prevent other filters from blocking email messages.
By far the most important tab on the Content Filtering properties sheet is the Action tab, shown in Figure E. The Action tab allows you to set thresholds at which a message should be considered as spam. This tab allows you to delete, reject, or quarantine messages based on their SCL rating. A message's SCL rating is based on the percentage chance that the email message is spam. For example, a message with an SCL rating of 9 is 90% likely to be spam, while a message with an SCL rating of 3 has only a 30% chance of being spam.

Figure E: You can set the threshold at which a message should be filtered.

It is usually best to initially configure an Edge Transport server to provide minimal filtering and then gradually increase the aggressiveness of the filtering over time as you begin to understand the impact of the various filters.

Initially, I recommend only filtering messages with an SCL rating of 8 or higher. I tend to be a little bit conservative though. The default settings have a more aggressive SCL rating of 7 or higher.

IP filtering

Edge Transport server also filter spam by looking at the sender's IP address. There are four different filters that are designed to filter messages based on IP address: IP Allow List, IP Allow List Providers, IP Block List, and IP Block List Providers

The IP Allow List allows you to enter the IP addresses of senders whose messages should never be treated as spam. For example, if you are worried about losing important email messages from customers, you might enter the IP address of your customer's mail server.
The IP Allow List Providers section lets you specify any IP allows list providers that you want to use. IP allow list providers maintain lists of domains that are virtually guaranteed to never send spam. Exchange Server is able to cross-reference these lists in an effort to determine whether or not spam is known to come from the sender's domain.
The IP Block List is designed to allow you to enter the IP addresses of mail servers from which messages should always be treated as spam. You can enter individual IP addresses or entire ranges of addresses.
The IP block List Providers section works similarly to the IP Allow List Providers section -- except that it allows you to enter the name of any block list providers that you want to use. An example of such a provider is Spamhaus, which maintains a list of domains from which spam is known to originate.
Like the content filter, the IP Block List Providers filter also allows you to create an exceptions list in case you don't want the filter to apply to certain mailboxes. The IP Block List filter does not offer the ability to use exceptions.

Recipient filtering

Recipient filtering blocks email messages sent to specific recipients. This is useful if you have Exchange Server mailboxes that should never receive email from the outside world. You can use recipient filtering to prevent email messages from being sent to individual mailboxes or to entire domains.

As you can see in Figure F, the Recipient Filtering properties sheet also allows you to block any email message sent to a recipient who is not listed in the Exchange Global Address List.

Figure F: You can block messages sent to specific mailboxes or domains.

Sender filtering

Sender filtering works by allowing you to filter email messages from specific senders. This filter is very flexible in that it allows you to enter individual email addresses, entire domains, or even whole domain ranges. This means that you could block a specific domain, such as Contoso.com, or you could block all domains within a specific domain hierarchy, such as .com or .net.

The Sender Filtering properties sheet contains an Action tab that lets you control what happens when a blocked sender sends an email message to your Exchange Server organization. By default, the message is rejected, but you have the option of stamping the message with a Blocked Sender stamp and processing the message any way.

Sender ID filtering

Sender ID filtering is designed to prevent domain spoofing techniques that are commonly used by spammers and in phishing scams. Sender ID works by comparing the IP address from which a message has originated against a list of the IP addresses of mail servers that the domain's owner has authorized to send email on behalf of the domain.

By default, the Edge Transport server is configured to stamp messages with the Sender ID result and then continue processing the email. The reason for this is that, although Sender ID screening is an effective antispam technique, Sender ID technology has yet to be widely adopted. Many senders have not yet registered their mail server addresses.

Sender Reputation filtering

The Sender Reputation filter is one of the more interesting filters. It can collect information about recent email messages received from individual senders and domains. If the sender or the domain has been a source for spam, then the sender's reputation is decreased.

In addition to message history, a sender's reputation is also based on whether or not the sender's mail server is configured as an open proxy. When a message is received from a sender, Exchange Server uses the sender's SMTP address to perform a test against the sender's mail server to determine whether or not it is configured as an open proxy, as shown in Figure G. If the server is an open proxy, the sender's reputation is decreased.

Figure G: You can see if a sender's mail server is configured as an open proxy.

The Sender Reputation filter allows you to set a sender reputation threshold value. When this threshold value is exceeded, the sender is temporarily added to the IP Block List. As you can see in Figure H, Exchange Server allows you to control the duration of the block.

Figure H: You can block senders with bad reputations for any length of time.

Step 7: Set up Edge Transport server advanced content-filtering features

In Step 4, I showed you some basic techniques for configuring an Edge Transport server to filter out spam, viruses and malware. Now let's review some more advanced content-filtering features.

Puzzle validation

Any inbound email message that passes through an Edge Transport server is analyzed and then assigned a Spam Confidence Level (SCL) number, which correlates to the percentage chance that the email message is spam. As we all know though, sometimes messages that are perfectly legitimate have some of the same characteristics as spam, and oftentimes these email messages are incorrectly rejected.

To help with these types of situations, Microsoft has created a mechanism for reducing false positives called puzzle validation. Puzzle validation only works when the sender is using Exchange Server 2007 and Outlook 2007. Assuming that the sender meets these criteria, Microsoft Outlook will digitally postmark each message that is sent. The digital postmark is essentially a hash based on the sender's identity.

When an Edge Transport server receives an email message, it checks to see if the message contains a digital postmark. If the message does contain such a postmark, the server creates its own hash based on the sender information contained in the email message.

If the number that is derived through this computation matches the contents of the digital postmark, the message is less likely to be spam. The Edge Transport server then lowers the message's SCL level accordingly.

If an inbound message does not contain a digital postmark, or if the message contains an invalid digital postmark, the message is not automatically classified as spam. Instead, the SCL that had already been calculated for the message continues to be in effect.

You can enable puzzle validation by opening the Exchange Management Shell on the Edge Transport server and execute the following command:

Set-ContentFilterConfig[-OutlookEmailPostmarkValidationEnabled $True

If you should decide later on that you want to disable puzzle validation, you can do so by entering this command:

Set-ContentFilterConfig[-OutlookEmailPostmarkValidationEnabled $False

Attachment filtering

Most of the filtering capabilities I have talked about so far can be found in just about any antispam product. One feature that helps to set an Edge Transport server apart from some of the other antispam products available is attachment filtering.

Since just about everybody uses antispam filters, some spammers choose to place their messages in documents that are attached to an email so that the message will be more likely to pass through the spam filter. At best, these types of messages are annoying, but they often also contain offensive and malicious content.

Since you probably don't want these types of messages reaching your end users, you can configure your Edge Transport server to scan email attachments -- not just the messages themselves -- and remove unwanted content.

Attachment filtering can be applied to both inbound and outbound email messages. One of the primary techniques for filtering inbound messages involves blocking file extensions for which you know that nobody in the organization has any legitimate business need.

At the very least, you should block executable files (.EXE, .BAT, .COM, .PIF, etc.) as a way of helping to keep viruses out of your organization. Keep in mind though that blocking executable files does not completely guarantee that no viruses will find their way into your organization.

It is still very common for legitimate looking messages to contain links to malicious files rather than including the file as an attachment. Such messages are harmless unless a user decides to click on the link. Fortunately, Microsoft Outlook contains some mechanisms to prevent users from accidentally executing malicious code from a link found in email.

Blocking unused file types and specific filenames

Blocking executable files is just the beginning of what you can do though. You can also block unused file types. For example, if you know that nobody in your organization uses Microsoft Excel, then you could block .xls files.

Although blocking certain file extensions certainly has its place, you also have the option of blocking specific files. For example, suppose that the latest email virus is a message with an attachment named virus.exe. You could actually configure Exchange Server to block any file named virus.exe.

I have talked a lot about preventing unwanted content from reaching your mailbox server, but remember that you can also use attachment filtering to block outbound message attachments.

At the very least, I would recommend configuring Exchange Server to prevent executable files from being emailed to the outside world. Although I'm sure that you probably take the appropriate precautions to prevent viruses, even the most cautious organizations can inadvertently become infected with viruses.

If an infection does occur, you don't want a virus to email itself to all of your company's clients. Not only could you potentially infect your clients, it might make your clients think twice about doing business with you if you send them viruses.

Attachment filtering is also good for making sure that confidential documents are not leaked to the outside world. For example, if you had a super secret document named Evil_Plan_for_World_Domination.doc, you could prevent someone from emailing the document to the outside world (accidentally or on purpose) by blocking the document's filename. The filter won't help you if someone renames the document prior to sending it though.

In order to implement attachment filtering, you need to make three basic decisions:

Which filename or file extension you want to block
If the block should apply to inbound email, outbound email, or both
What will happen when the Edge Transport server finds an email message with an attachment that has been blocked

You have three options for dealing with blocked attachments:

Reject the message: Doing so will prevent delivery to the intended recipient and will issue a non-delivery report (NDR) to the sender.
Strip the attachment from the email message:The offending attachment will be removed and replaced by a notification telling the recipient that an attachment has been removed. The nice thing about using this option is that if a message contains multiple attachments, then any email attachments that have not been blocked will still be available to the recipient.
Silent delete: This option deletes the email message just like the reject option does. The difference is that the silent delete option does not produce non-delivery reports.

Checking the filter status of a filename or file extension

There are a handful of different Exchange Management Shell commands that are used to filtering email attachments. In the commands below, filename.ext is a generic representation of the filename of your choice.

Check the status of a file or file extension to see if it is currently being blocked:
Get-AttachmentFilterEntry filename.ext
Block a particular filename:
Add-AttachmentFilterEntry –name filename.ext –Type FileName
Remove a block on a filename:
Remove-AttachmentFilterEntry –Identity Filename:filename.ext
If you want to work with an extension as opposed to a specific filename, leave the Type setting set to filename, but enter the extension as a wildcard. For example, if you wanted to block .exe files, you could use the following command:
Remove-AttachmentFilterEntry –Identity Filename:*.exe
You can perform a reject, strip, or silent delete on blocked files or file types using the Set-AttachmentListConfig command and then specifying the desired action. If you set the action to Reject, you also have the option of specifying the contents of the non-delivery report, as shown below:
SetAttachmentFilterListConfig –Action Reject –RejectResponse "This attachment is not allowed"

When inbound email messages are rejected

When an email message is rejected by an Edge Transport server, it does not simply fall into some email black hole. Instead, Exchange Server embeds a rejection message into the SMTP non-delivery report (NDR). The default rejection message simply states: "Message Rejected Due to Content Restriction."

What you might not realize though, is that you can customize this message to meet your needs. The only real restriction is that your message can not exceed 240 characters in length. The command for customizing the rejection message through the Exchange Management Shell is:

Set-ContentFilterConfig –RejectionResponse "I don't want your spam. Stop bothering me."

Note that the actual message text must be enclosed in quotation marks.

Exchange 2007 – Exchange Rockers

2007-07-03T12:28:00.001+05:30

How to Create a New Address Rewrite Entry

For more information about address rewriting, see Planning for Address Rewriting
(http://technet.microsoft.com/en-us/library/bb123966.aspx)

To perform the following procedures on a computer that has the Edge Transport server role installed, you must log on by using an account that is a member of the local Administrators group on that computer.

Important:

The Address Rewriting Inbound agent and the Address Rewriting Outbound agent must be enabled so that address rewrite entries are applied to e-mail messages that enter and leave the Edge Transport server. If address rewrite entries have been created, but the Address Rewriting agents are disabled, Exchange Server 2007 will not apply the address rewrite entries. To verify whether the Address Rewriting agents are enabled on the Edge Transport server, run the following command:
Get-TransportAgent
For more information about the Get-TransportAgent command, see Get-TransportAgent.
To enable the Address Rewriting agent if it is not enabled, run the following command:
Enable-TransportAgent -Identity "Address Rewriting Inbound agent"
Enable-TransportAgent -Identity "Address Rewriting Outbound agent"
For more information about the Enable-TransportAgent command, see Enable-TransportAgent.

Address Rewriting Procedures

There are three major address rewriting scenarios that Exchange Server 2007 can perform. The following list provides a brief explanation of each scenario and a link to the procedure that you use to implement each scenario:

Rewriting a single e-mail address You can rewrite the headers of e-mail messages that are sent to and from specific internal e-mail addresses when messages are sent to and from the Internet.
When you configure Exchange Server 2007 to rewrite a single e-mail address, the headers of e-mail messages that are sent to and from that e-mail address are rewritten. For example, the internal address joe@contoso.com can be rewritten so that it appears to be support@contoso.com when e-mail is sent from that account to the Internet. When replies to that e-mail address or new messages to that address arrive, Exchange Server 2007 rewrites the recipient address in the header of the inbound messages by using the internal address joe@contoso.com.
When you rewrite e-mail addresses, there is a one-to-one correlation between the internal e-mail address and the external e-mail address. This correlation enables Exchange Server 2007 to automatically rewrite e-mail messages to and from the Internet.
For more information, see How to Rewrite a Single E-Mail Address.
Rewriting a single domain You can rewrite the headers of e-mail messages that are sent to and from recipients that send messages from specific internal domain names when messages are sent to and from the Internet.
When you configure Exchange Server 2007 to rewrite a single domain, the headers of e-mail messages that are sent to and from that domain are rewritten so that the messages appear to be originating from another domain that the administrator has specified when they are sent to the Internet. When new messages, or replies to messages that originated from the rewritten domain, arrive at the Edge Transport server, Exchange Server 2007 rewrites the recipient address in the header of the inbound messages with the internal domain and delivers the message to the recipient.
For more information, see How to Rewrite All E-Mail Messages from a Single E-Mail Domain.
Rewriting multiple sub-domains You can rewrite the headers of e-mail messages that are sent from mailboxes that are located in one of multiple internal sub-domains. When you rewrite multiple sub-domains, you have the following options:
Rewrite e-mail messages from all sub-domains This option enables you to rewrite all sub-domains to a single external domain without exception. All e-mail messages from all sub domains will be rewritten.
Rewrite e-mail messages from specific sub-domains You may have to rewrite e-mail messages from specific sub-domains, but do not want to affect other sub-domains. This option is especially convenient when you have many sub-domains but only want to rewrite addresses for a few of them. Exchange Server 2007 lets you configure address rewriting for only those specific sub-domains without creating many exceptions.
Rewrite e-mail messages from all sub-domains with exceptions You may have to configure address rewriting for many sub-domains, but may also have to prevent some sub-domains from being rewritten. Instead of having to create individual address rewrite entries for each sub-domain, Exchange Server 2007 lets you create an address rewrite entry that encompasses all sub-domains and then lets you specify exceptions for those sub-domains that you do not want to rewrite.
For more information, see How to Rewrite All E-Mail Messages from Sub-Domains.

For More Information

For detailed syntax and parameter information, see New-AddressRewriteEntry.

For more information about address rewriting, see the following topics:

Exchange 2007 Features

2007-07-01T20:07:00.001+05:30

Built-in Protection

Exchange Server 2007 includes built-in protection with features like Edge Transport, Hosted Filtering Integration, and anti-spam filtering and extensibility for antivirus protection. See the table below for more information.

Anti-spam and Antivirus

Feature	Type	Description
Edge Transport server role		This server role is for perimeter network deployment. It supports Simple Mail Transfer Protocol (SMTP) routing, provides anti-spam filtering technologies and support for antivirus extensibility. The Edge Transport server should be isolated from the Active Directory directory services, but can still leverage Active Directory for recipient filtering by using Active Directory Application Mode (ADAM). EdgeSync in Exchange Server 2007 publishes pertinent organization information, encrypted, to the Edge Transport server for use in robust recipient filtering and respects Microsoft Outlook safe sender lists on the Edge. Communications between the Edge Transport server and the internal network in an Exchange Server 2007 organization are encrypted by default. Edge Transport includes anti-spam technologies that protect at many layers.
Anti-spam	Connection Filtering	Exchange Server 2007 provides an integrated, IP based block-and-allow list based on sender reputation. Lists are automatically updated as new versions become available. Administrators can establish additional IP allow-or-deny lists as needed.
Anti-spam	Sender and Recipient Filtering	Sender reputation is dynamically analyzed and updated. When the Edge Transport server spots specific trends from a given domain, it can impose certain actions to either quarantine or reject incoming messages. Sender ID is also used to verify that each e-mail message originates from the Internet domain from which it claims to come from based on the sender's SMTP server IP address. Once a Sender ID record has been verified, the results can be cross-referenced to past traffic patterns and sender reputation, creating an associate weight into the domain reputation. Finally, recipients are validated, and administrators have the ability to block messages sent to non-existent user accounts or internal-only distribution lists
Anti-spam	Safe Sender List Aggregation	Via EdgeSync, the Edge Transport server respects Outlook 2003 and Outlook 2007 safe sender lists to help reduce false positives.
Anti-spam	Sender ID	Exchange Server 2007 embeds support for Sender ID, an e-mail industry initiative designed to verify that each e-mail message originates from the Internet domain from which it claims to come based on the sender's SMTP server IP address. Sender ID helps prevent domain spoofing and protect legitimate senders' domain names and reputation and helps recipients more effectively identify and filter junk e-mail and phishing scams.
Anti-spam	Content Filtering	Content is analyzed using the Intelligent Message Filter (IMF), Exchange Server's implementation of Microsoft SmartScreen content filtering technology. SmartScreen is based on Microsoft Research's patented machine-learning technology. Anti-phishing capabilities are also built-in to the IMF to help detect fraudulent links or spoofed domains and protect users from these types of online scams. When used with Outlook 2007, a phishing warning or block appears in the user interface. Customers are protected from emerging spam attacks through the automatic filter updates for Exchange Server 2007, which are published on a frequent basis. Should the administrator require additional control, the Edge Transport server enables customization, including the ability to add words or phrases to the filter.
Anti-spam	Outlook E-Mail Postmark	Exchange 2007 verifies Outlook E-mail Postmarks attached to messages sent from Outlook 2007. The Outlook E-mail Postmark can reduce false positives for messages from legitimate senders that have little to no reputation.
Anti-spam	Spam Assessment	In addition to scanning message content, the IMF consolidates guidance from Connection, Sender/Recipient, Sender Reputation, Sender ID verification, and Outlook E-mail Postmark validation to apply a Spam Confidence Level (SCL) rating to a given message. Administrators can preconfigure actions on the message based on this SCL rating. Actions may include deliver to the inbox or junk mail folder, deliver to the spam quarantine, or reject outright and no deliver.
Anti-spam	Service Resilience	The Edge Transport server role controls the inbound SMTP message receipt rate for increased availability. This control, coupled with the ability to detect open proxy machines, can aid in preventing denial of service attacks. Tar pitting is supported to slow the server response for certain SMTP communication patterns, minimizing exposure to directory harvest attacks.
Anti-spam	Anti-spam Stamp	Messages filtered by the Edge Transport server role are stamped with information, including why the message was considered spam and which combination of filters and reputation services (IP, domain, sender, recipient, content) determined its spam assessment. Administrators may use this information in an aggregate way to understand the effectiveness of filtering across their multilayered approach and tune appropriately.
Anti-spam	Two-Tiered Spam Quarantine	The Exchange Server 2007 environment enables two-tiered spam quarantine. First, administrators have access to a Spam Quarantine housed in the perimeter network. Using Outlook, administrators can access the Spam Quarantine to search for messages, release to the recipient, or reject and delete. Messages with borderline SCL ratings (borderline definition configured by the administrator) may be released to the end user's junk mail folder in Outlook, and are converted to plain text for further protection.
Anti-spam	Consolidated Management	Management of the Edge Transport Server role and corresponding rules is consistent with the rest of the Exchange environment and can be performed using the Exchange Management Console graphical interface or the Exchange Management Shell for automation. Finally, the administrator can leverage notifications through Microsoft Operations Manager (MOM) or reports within Exchange to analyze the effectiveness of their anti-spam filters.
Antivirus Extensibility	Attachment Filtering	To effectively protect against worms delivered via e-mail, the administrator can strip attachments based on their size, content or file type. Zip file manifests can be examined as well for offending file types.
Antivirus Extensibility	Edge Protocol Rules	As a reactive defense mechanism, protocol rules provide a layer of protection before antivirus signature updates become available. Administrators can filter on known text patterns in malware carriers and drop the connection.
Antivirus Extensibility	Antivirus Stamp	Messages scanned in the Exchange environment can be assigned an antivirus stamp. This stamp identifies which engine did the scanning, which signature was used, and when the message was last scanned.
Antivirus Extensibility	Deep Integration for Antivirus Scanning	Antivirus solutions can be more tightly integrated in the Exchange Server 2007 environment. Antivirus solutions have access to the Multipurpose Internet Mail Extensions (MIME) parsers and can scan the message stream in transport (on Edge Transport or Hub Transport servers). Catching viruses in transport helps prevent their delivery and storage in Exchange mailboxes.
Hosted Filtering Integration		Exchange Server 2007 provides integration with Exchange Hosted Services, offering off-site protection against spam and viruses.

Confidential Messaging

Feature	Type	Description
Intra-Org Encryption		All mail traveling within an Exchange Server 2007 organization is encrypted by default. Transport Layer Security (TLS) is used for server-to-server traffic, Remote Procedure Call (RPC) is used for Outlook connections, and Secure Socket Layers (SSL) is used for Client Access traffic (Outlook Web Access, Exchange ActiveSync, and Web Services). This prevents spoofing and provides confidentiality messages in transit.
SSL Certificates Automatically Installed		SSL certificates are installed by default in Exchange Server 2007, enabling broad use of SSL and TLS encryption from clients such as Outlook Web Access and other SMTP servers.
Opportunistic TLS Encryption		If the destination SMTP server supports TLS (via the "STARTTLS" SMTP command) when sending outbound e-mail from Exchange Server 2007, Exchange Server will automatically encrypt the outbound content using TLS. In addition, inbound e-mail sent to Exchange Server 2007 from the internet will be encrypted if the sending server supports TLS (Exchange Server 2007 automatically installs SSL certificates).

Compliance

Feature	Type	Description
Transport Rules		Exchange Server 2007 includes a policy engine based on rules that execute on Hub Transport servers. With Transport Rules, administrators and compliance officers can establish and enforce regulatory or corporate policies on internal or outbound e-mail, voice mail, or fax. For example, using a wizard in the Exchange Management Console or the command line in Exchange Management Shell, rules can be written that would prohibit communication between members of distinct distribution lists, append a disclaimer to any message being sent externally, or BCC the compliance officer anytime a specific phrase appears in the subject or content of a message.
Messaging Records Management		Various corporate retention policies exist for e-mail, voice mail, and fax communications. With Managed Folders, a user can organize messages into Outlook folders that are provisioned and managed by the administrator. An automated process scans the inbox and these folders to retain, expire, or journal communications based on compliance requirements.
Flexible Journaling		Journaling is flexible in Exchange Server 2007. Journaling can be triggered per database, per distribution list, or per user. All messages can be journaled, or just those sent internally or externally.
Multi-Mailbox Search		Using the Microsoft standard search technology, content in Exchange Server 2007 mailboxes is fully indexed and searchable using a variety of criteria. If compliance or legal requirements require information discovery, administrators can search across multiple mailboxes within an organization with a single query, routing the results to a Microsoft Windows SharePoint Services site or mailbox that can be made available via Outlook to HR, compliance officers, or others.
Archive Integration		Journaled messages can be archived to any SMTP address, including an Exchange mailbox or Windows SharePoint Services site.

Business Continuity

Feature	Type	Description
Local Continuous Replication		Availability can be increased using continuous replication of data across multiple disks on a single server. This establishes a second copy of the production database on the local server that is kept up-to-date automatically. In the event of a disk failure or data corruption, switching over to the copy database provides a less costly and less complex recovery solution for the administrator.
Cluster Continuous Replication		Availability can be increased using replication in an active/passive cluster. Data recorded on the active server node is copied to the passive server node, enabling a copy of not only server configuration and settings but data as well. By not requiring shared storage, the active node and passive node can be located in separate geographical locations without the performance impact of synchronous replication solutions. Automated failover to the passive server node is transparent to the end user, dramatically reducing the risk of data loss by relying on logs and queues and providing a less costly and less complex recovery solution for the administrator.
Fast and Fewer Backups		Backups can be run against the copy of the production database on either the local server or passive server node, decreasing the performance impact on production. Continuous Replication also reduces the frequency of costly, full disk or tape backups currently used for disaster recovery.
Database Portability		In the case of a complete server failure, an empty dial tone mailbox database can be created on a new server, enabling users to send and receive e-mail while recovery is underway. A backup of the mailbox database can then be recovered into the dial tone database even though the original database in the backup was created on a different server.

Top of page

Operational Efficiency

Exchange Server 2007 helps IT professionals administer, automate, and deploy more efficiently. See what features are included with Exchange Server 2007 for operational efficiency in the table below.

Administration and Automation

Feature	Type	Description
Exchange Management Console		Improves the graphical user interface for management. Management actions are easily discovered through the action pane, and the navigation tree is simplified to three levels deep. Exchange management and troubleshooting tools are integrated in the toolbox. The Exchange Management Console is built upon the Exchange Management Shell; actions taken in the Console are also available, and visible, through the command line shell.
Exchange Management Shell		The Exchange Management Shell, based on Microsoft Windows PowerShell, is a highly extensible and flexible management environment that complements the graphical interface available through the Exchange Management Console. It enables rapid management through a scriptable command line for automation, batching, and reporting and integrates with Active Directory. To help administrators quickly learn the syntax of the Exchange Management Shell and build custom scripts, wizards in the graphical Exchange Management Console display the command line syntax for each action the administrator has specified via the wizard. This text can be cut and pasted directly into the Exchange Management Shell or into a script file.
Extended Integration with Active Directory		Use of Active Directory sites helps automate new server discovery and configuration within the organization. The topology of an Exchange Server 2007 environment is defined and managed through Active Directory, alongside other servers in the infrastructure.
Exchange Management Pack for Microsoft Operations Manager		Manual configuration for synthetic transactions has been dramatically reduced or eliminated. All synthetic transactions are now accessible from the Exchange Management Shell. Rules directly align with Exchange Server 2007 server roles. New reports are introduced for Exchange ActiveSync, unified messaging service availability, message hygiene features, and server performance. Exchange Best Practices Analyzer (ExBPA) integration features are also included.
Exchange Troubleshooting Tools		In addition to the deep integration of Exchange Best Practices Analyzer, Exchange Server 2007 provides several troubleshooting tools within the toolbox in the Exchange Management Console. These tools are kept up-to-date with the latest information and capabilities through integration with Microsoft Update. Included in the toolbox are the Exchange Mail Flow Troubleshooter, Exchange Database Troubleshooter, and the Exchange Performance Troubleshooter. The Exchange Mail Flow Troubleshooter can diagnose and help remediate inbound and outbound e-mail failures. The Exchange Database Troubleshooter isolates database mounting failures, is used to manage recovery storage groups, and walks the administrator through dial tone recovery. Finally, the Exchange Performance Troubleshooter identifies the cause of Outlook or Exchange performance problems and advises on remediation.
Flexible Permission Model		Permissions become more granular and straightforward to manage in the Exchange Server 2007 environment. The permissions model enables a set of new, predefined administrator "roles."
Automatic Server Updates		Automates Exchange Server updating and patching using either Microsoft Update on the Web, Windows Update Server on-site, or Microsoft Systems Management Server, soon to be released as System Center Configuration Manager.

Deployment

Feature	Type	Description
Server Roles		Exchange Server 2007 is a modular system of five server roles–Edge Transport, Hub Transport, Mailbox, Client Access, and Unified Messaging – that reduces the time required for installation; minimizes manual, post-install configuration by the administrator; and limits the surface area available for attack to increase security. Administrators also gain the flexibility to deploy only the features and services necessary on a given server and manage accordingly. All server roles, with the exception of Edge Transport, can be deployed on a single server, and only the Hub Transport and Mailbox server roles are required for Exchange Server 2007 installation.
Setup		A new setup process goes from installation to configuration and reduces complexity by incorporating the modular, server role architecture of Exchange Server 2007 into the process. Microsoft Windows Installer technology provides distinct installation packages and smart default settings. Exchange Best Practices Analyzer (ExBPA) is integrated with a setup process to perform prerequisite checking and identify potential deployment errors. To ease deployments in large environments, Exchange Management Shell scripts can be used to automate server installation and provisioning.
Exchange Best Practices Analyzer		Embedded in the Exchange Server 2007 setup process and available through the Exchange Management Console toolbox, the Exchange Best Practices Analyzer can be used to proactively examine the topology and individual servers for configuration discrepancies that may lead to service outages and reliability problems in the future. The Analyzer surfaces warnings or error messages to the administrator and information on how to address the warning or error. It is recommended that the Exchange Best Practice Analyzer be run periodically against an Exchange environment to ensure optimal configuration.
Autodiscover		Configuring Outlook 2007 to connect with Exchange is easier than ever before. If logged on to the network, Exchange Server 2007 automatically completes all inputs required for the user to initiate the connection. Even for users not logged on to the network, connecting Outlook 2007 to Exchange Server 2007 using Outlook Anywhere (formerly known as RPC over HTTP or RPC/HTTP) requires only the user name, e-mail address, and password; no Exchange server name is required. In the event of a mailbox move, migration or disaster, Autodiscover eliminates the need for users to change their settings by automatically detecting the new server and reconfiguring the connection.
Single Migration Engine		Exchange Server 2007 provides a single, comprehensive tool for administrators to perform intra or inter-organizational migrations, minimizing migration complexity.

Scalability and Performance

Feature	Type	Description
Native x64		As a native 64-bit application, Exchange can access more memory, ensuring high performance and reliability as mailbox sizes and the number of user accounts per server increase.
Storage Optimization		With reduced input/output (I/O) requirements (up to 75 percent reduction in I/O per second) enabled by the larger memory caches available on x64 systems, Exchange Server 2007 makes better use of existing storage systems and also allows administrators to use low-cost options like Direct Attached Storage, even in demanding, enterprise environments.
Optimized Browser Access		Outlook Web Access (OWA) 2007 delivers improved performance and decreased latency. Increased client caching reduces server roundtrips, thereby reducing bandwidth usage and providing an optimal user experience when accessing over slow connections.
Simplified Routing and Optimized Bandwidth		Message routing is automatically determined, and mail is delivered using the most direct route by default. Administrators can also configure schedule and priority to optimize bandwidth usage.

Extensibility and Programmability

Feature	Type	Description
Web Services Application Programming Interface (API)		Developers now have a simple way to embed information from the Exchange Server 2007 mailbox or calendar within line-of-business or other custom applications. The Exchange Web Services API provides a single, documented, standards-based API to be called from any client, language, or platform.
OWA Web Parts		Developers can easily embed Outlook Web Access functionality into their custom portals and portal applications using OWA Web Parts.
Free/Busy Web Service		The Free/Busy Web Service offers a flexible, extensible way to access free/busy information in Exchange Server 2007. Used by clients such as Outlook, Outlook Web Access, and mobile devices based on Exchange ActiveSync, the Free/Busy Web Service allows developers to embed free/busy information in line-of-business or custom applications
.NET Integration		Commands or scripts used in the Exchange Management Shell can be called from managed code such as C# or VB.NET. This allows developers to build custom applications which organizations may use to execute common management tasks in the messaging environment.

Top of page

Anywhere Access

Exchange Server 2007 offers features that allow you and your employees anywhere access to e-mail, calendaring, and more. See what features are included with Exchange Server 2007 for anywhere access in the table below.

Calendaring

Feature	Type	Description
Calendar Attendant		The Calendar Attendant reduces scheduling conflicts by limiting calendar items (request, declines, accepts) in the inbox to the latest version. The Calendar Attendant also marks meeting requests as tentative on recipient calendars until users can act on the request and relies on the Exchange Server 2007 free/busy Web service for always up-to-date availability information.
Resource Booking Attendant		The Resource Booking Attendant enables resources, including meeting rooms or other equipment, to be automatically managed. Resources can auto-accept requests when available or decline and provide details explaining the decline. Administrators can set granular policies on resources, including available hours or scheduling permissions.
Scheduling Assistant		The Scheduling Assistant helps users efficiently schedule meetings by providing visual guidance on the best and worst dates and times to meet based on meeting invitees and required resources.
Schedulable Out of Office		Out of Office (OOF) messages can now be scheduled to begin and end on specific dates and times, reducing the likelihood of a user's out of OOF not being set. A separate out of office message can be sent to external recipients, a capability the administrator can enable or disable. Out of Office messages can also be set or unset from a mobile device.

Mobile Messaging

Feature	Type	Description
Search		Information can be quickly found from a mobile device using the search capability of Exchange ActiveSync. When executing a search from a mobile device, both the local device store and the user's entire Exchange mailbox are queried. Results found through the over-the-air search of the Exchange mailbox can be rapidly retrieved to the device. This capability enables access to information sent or received days, weeks, or even months before, regardless of the storage limitations of the mobile device.
Direct Push		Mobile devices incorporating Exchange ActiveSync maintain a secure connection with Exchange Server 2007, receiving new or updated e-mail, calendar, contacts, and tasks as soon as they arrive on the server. This push method optimizes bandwidth usage while keeping users up-to-date.
Rich Experience on a Breadth of Devices		Users can get a familiar experience on a range of mobile devices without requiring the organization to deploy expensive third-party software or services. The Exchange Server 2007 ActiveSync protocol is licensed for use by Windows Mobile, Nokia, Symbian, Motorola, Sony Ericsson, Palm, and DataViz. Given the breadth of partners, device choice continues to expand.
Device Security and Management		Administrators may choose to enforce policies on devices used in their organizations including requiring PINs of varying length and strength and enforcing a device wipe of data and applications, should the device be lost or stolen. These controls become granular with Exchange Server 2007, allowing per-user policies. Device usage can be tracked and managed centrally within the Exchange Server environment.
LinkAccess		When a user receives a link to a Windows SharePoint Services site or file share while using a mobile device, Exchange Server 2007 uses LinkAccess to retrieve and display the document, no VPN or tunnel required.
Calendaring and Out of Office		With Exchange Server 2007, users have many new options when accessing their calendar from a mobile device using Exchange ActiveSync. They can reply to a meeting invitation with a message, forward the invitation to another person, and view acceptance tracking for meeting attendees. Out of Office messages can also be set from the mobile device.

Web-based Messaging

Feature

Type

Description

Outlook 2007 Experience

Outlook Web Access, an AJAX application since its first release with Exchange Server 5.5, provides a rich, Outlook like experience in a browser. New features in Outlook Web Access 2007 enable users to:

•	Schedule Out of Office messages and send to internal and/or external recipients
•	Use the Scheduling Assistant to efficiently book meetings
•	Access SharePoint documents without a VPN or tunnel using LinkAccess
•	Use WebReady Document Viewing to read attachments in HTML even if the application that created the document is not installed locally
•	Access RSS subscriptions
•	View content in Managed E-mail Folders
•	Retrieve voice mail or fax messages through Unified Messaging integration
•	Search the Global Address List

Access Security

Outlook Web Access 2007 security is improved. Two-factor authentication is supported, and administrators can enforce HTML-only document viewing to avoid information being left behind on public kiosks.

Self-Service Support

The Outlook Web Access 2007 Options menu allows users to quickly and easily resolve many of the most common sources of helpdesk calls on their own. OWA users can request a Unified Messaging voice mail PIN reset, issue a remote wipe request to their mobile device should it be lost of stolen, and add senders to their safe or block list all within Outlook Web Access.

Outlook Web Access Light

Outlook Web Access Light provides a rich Outlook Web Access experience over slow connections and enables many of the new features in Outlook Web Access 2007, including schedulable Out of Office messages (internal and external), Really Simple Syndication (RSS) subscriptions, and Managed E-Mail Folder access.

Exchange Server 2007 mailboxes are fully indexed by default, allowing users to quickly search for information from Outlook Web Access. Re-indexing is significantly faster than Exchange Server 2003, and search spans both content within the e-mail itself and data contained in attachments.

Remote Document Access

LinkAccess

When a user receives a link to a Windows SharePoint Services site or file share while working remotely using Outlook Web Access, Exchange Server 2007 uses LinkAccess to retrieve and display the document, no virtual private network (VPN) or tunnel required.

Remote Document Access

WebReady Document Viewing

Outlook Web Access 2007 can transcode a variety of document types – including Microsoft Word, Microsoft Excel, Microsoft PowerPoint, and PDF files – from their native format into HTML so that they can be viewed in a client browser even if the application that created the document is not installed on the client. This allows users to be productive from almost any machine and keeps viewed documents safe, even on kiosk machines, since HTML documents are purged by Outlook Web Access at logoff or session timeout.

Unified Messaging

Feature	Type	Description
Voice Messaging System		Voice mail can now be stored in the mailbox and accessed from a unified inbox in Outlook, Outlook Web Access, on a mobile device, or from a standard telephone. This unification improves employee productivity by simplifying access to the most common types of communications. It also dramatically reduces cost by removing the need for a standalone voice mail system and by taking advantage of any existing investments in Active Directory. Exchange Server 2007 Unified Messaging can be connected with a legacy private branch exchange (PBX) infrastructure through an IP gateway, or can be directly connected with certain IP PBX installations.
Fax Messaging System		Faxes can now be stored in the mailbox and accessed from the user's unified inbox in Outlook, Outlook Web Access, or their mobile device. Unified Messaging centralizes the management of inbound fax services within the Exchange infrastructure.
Speech-Enabled Automated Attendant		The Attendant answers calls using an automated operator, with customizable menus (e.g. "press 1 for sales"), and global address list directory lookups (e.g. "who would you like to contact?"). Callers can interact with the Automated Attendant through touch tone menus or their voice using speech recognition.
Self-Service Voice Mail Support		Using Outlook Web Access, users can request a reset of their voice mail PIN, set their voice mail greeting, record their out-of-office voice message, and specify mailbox folders to access when calling in by phone to hear e-mail messages through text-to-speech translation.
Outlook Voice Access		Users can access their Exchange mailbox using a standard telephone, available anywhere. Through touch tone or speech-enabled menus, they can hear and act on their calendar, listen to e-mail messages (translated from text to speech), listen to voice mail messages, call their contacts, or call users listed in the directory.
Play on Phone		Exchange Unified Messaging allows users to playback voice messages received in their Exchange inbox on a designated phone. This feature is useful when a user is in a public place and does not want to play the voice mail over their computer speakers. Play on Phone routes the voice mail to a cell phone, desk phone, or other number specified by the user.