Published: September 2008

Situation

Microsoft IT's messaging protection challenges are similar to those of other enterprise environments. Like most IT organizations, Microsoft IT faces an ever-escalating stream of spam, viruses, and unwanted messages that waste resources, distract recipients, put assets at risk, and provide an avenue for social hacking and phishing scams, among other security issues. In addition to standard threats, Microsoft IT notices an increase in advanced attacks that exploit messaging systems, involving spyware, worms, botnets, and polymorphic malicious software. The sheer volume of unwanted messages is staggering. Spam submission attempts have increased at Microsoft over the past five years by more than a factor of 10 and almost tripled from 11 million to 28 million submission attempts in the fiscal year of 2007/2008, as indicated in Figure 1. Although the existing strategy for messaging protection has proved effective, Microsoft IT constantly evaluates emerging technologies and new solutions to stay ahead of spammers and attackers without jeopardizing cost efficiency.

Figure 1. Spam trends at Microsoft over the past five years

Existing Messaging Protection Infrastructure

The rollout of Microsoft Exchange Server 2007 marked the last major upgrade to the company's infrastructure for messaging protection, which Microsoft IT conducted in the second half of 2006. During this rollout, Microsoft IT updated the messaging environment to use Hub Transport servers for internal message routing and Edge Transport servers for Internet message transfer, as illustrated in Figure 2. Six Edge Transport servers are distributed across two data centers (one in Redmond and one in Silicon Valley). These servers handle incoming Internet messages for all internal destinations, including additional Exchange Server organizations in separate forests. Edge Transport servers also exist in Dublin and Singapore, but these servers are dedicated for outgoing regional traffic and do not receive incoming messages from the Internet.

Figure 2. Messaging routing topology at Microsoft

For messaging protection, Microsoft IT relies on an in-depth defense strategy with antispam and antivirus controls at the Edge Transport servers, additional antivirus controls at the Hub Transport servers, junk e-mail processing at the Mailbox servers, and additional attachment blocking, spam filtering, and virus scanning at the client computers. This strategy proves effective to block spam and virus messages before they reach the Mailbox servers in Redmond, Dublin, Singapore, and Sao Paulo to the extent that user impact from spam, phishing, and virus attacks is minimal.

In keeping with Microsoft IT's goal of stopping harmful messages at the earliest possible point, Microsoft IT deployed Microsoft Forefront™ Security for Exchange Server on all Edge Transport and Hub Transport servers. The Edge Transport servers in Redmond and Silicon Valley perform the bulk of the antispam and antivirus processing. Through a series of connection, sender, recipient, and content filtering as well as virus scanning, Edge Transport servers stop approximately 98 percent of unwanted messages from the Internet before they reach the corporate messaging environment. The remaining five percent reach the Mailbox servers, where store threshold and recipient safe-list information determine whether the messages are legitimate or spam. Microsoft IT does not quarantine messages on Edge Transport servers due to the administrative and Helpdesk overhead associated with managing quarantined messages.

For detailed information about the messaging protection infrastructure that Microsoft IT implemented with Exchange Server 2007, see the technical white paper Microsoft Exchange Server 2007 Edge Transport and Messaging Protection at http://technet.microsoft.com/en-us/library/bb735142.aspx.

Opportunities for Improvements

As part of the ongoing effort to stay ahead of spammers and attackers, Microsoft IT analyzed the existing approach to inbound Internet messaging connectivity based on Edge Transport servers performing the majority of spam and virus filtering. Although the Edge Transport servers in Redmond and Silicon Valley helped Microsoft IT increase the effectiveness of messaging protection and lower false positives in comparison to previous conditions, additional opportunities existed for Microsoft IT to achieve improvements. For example, connection filtering on Edge Transport servers proves to be an effective antispam tool—more than 25 million submission attempts are blocked daily—but connection filtering does not prevent spam-sending hosts from establishing TCP/IP connections. In other words, more than 25 million unwanted connections are established before the Connection Filtering agent can accomplish its work. Stopping spammers and attackers before they establish TCP/IP connections would be an improvement to the existing messaging protection infrastructure.

Microsoft IT identified the following improvement potential in the existing strategy for messaging protection:

• Increase IT asset actualization Considering that more than 25 million spam submission attempts occur daily, Microsoft IT realizes that even the mere attempts to submit spam cause a significant drain on IT resources, specifically on network bandwidth, firewall capacities, and Edge Transport server resources. For every connection attempt, corporate firewalls must perform network address translation. Edge Transport servers must go through the TCP/IP handshake sequence before the Connection Filtering agent can check local IP allow and block lists as well as real-time block list (RBL) providers to determine whether to accept or block the remote host. For Microsoft IT, a preferred solution would stop spammers and attackers before they can establish a connection to the company's Edge Transport servers.
• Lower security risks Preventing spammers and attackers from directly reaching Edge Transport servers also helps to mitigate security risks. With direct messaging connectivity, attackers on the Internet can look up the company's mail exchanger (MX) records in Domain Name System (DNS), establish anonymous connections to available MX hosts, and launch attacks at the network and mail transfer layer, such as denial-of-service attacks and directory-harvesting attacks. Although corporate firewalls and Edge Transport servers include features to defend against these attacks, such as IP connection throttling and tarpitting, Microsoft IT prefers to avoid anonymous Simple Mail Transfer Protocol (SMTP) connections and the registration of the company's messaging hosts in public DNS MX records.
• Reduce administrative overhead Edge Transport servers simplify administration and maintenance through one-way replication of Active Directory® Domain Services (AD DS) data via EdgeSync, automatic block list and signature updates via Forefront Security for Exchange Server and Microsoft Update, and streamlined system configuration via Windows PowerShell™ scripts. Yet, continued sources of administrative overhead include monitoring system performance, auditing for security violations, detecting intrusions, tracking and responding to zero-day virus outbreaks, verifying false negatives and false positives, and granting legitimate senders incorrectly identified as spammers exceptions to bypass the antispam controls for up to 30 days. One way to lower this overhead is to reduce the overall volume of spam submissions. Another is to centralize the administration of antispam and antivirus controls in the first line of defense for the entire corporate messaging environment.

Solution

The solution that enables Microsoft IT to realize the identified improvement potential in its current strategy for messaging protection is Exchange Hosted Services. Exchange Hosted Services provided the necessary antispam, antivirus, policy filtering, and disaster recovery features that Microsoft IT needed to add a new first line of defense to its already comprehensive messaging protection infrastructure.

The idea is to route all messages to Exchange Hosted Services first, filter the messages in the Exchange Hosted Services environment, and then route legitimate messages to the corporate messaging environment. In this way, Microsoft IT can keep the more than 25 million daily spam submission attempts away from the company's messaging hosts, stop spammers before they can reach the Edge Transport servers, and centralize administration of antispam and antivirus controls. Since the time Microsoft acquired FrontBridge (later renamed Exchange Hosted Services), Microsoft IT has used Exchange Hosted Services for messaging protection of the e-mail domains windows.microsoft.com and winse.microsoft.com. The task now was to extend the reach of Exchange Hosted Services to the company's main domains, exchange.microsoft.com and microsoft.com, as illustrated in Figure 3.

Figure 3. Exchange Hosted Services mail flow at Microsoft

Requirements and Exchange Hosted Services Features

Although the switch to Exchange Hosted Services is technically straightforward—apart from updating DNS MX records, no software or hardware requirements exist—transitioning inbound Internet message transfer for an organization with almost 150,000 recipients requires careful preparation and planning. Microsoft owns approximately 480 e-mail domains, yet approximately 98 percent of the Microsoft user base relies on e-mail addresses in the microsoft.com domain for business communication. To ensure a seamless transition and consistent user experience before and after the switch, Microsoft IT collaborated very closely with the Exchange Hosted Services team, reviewed the existing Exchange Hosted Services deployment for the windows.microsoft.com and winse.microsoft.com domains, determined key requirements for the exchange.microsoft.com and microsoft.com domains, and selected appropriate Exchange Hosted Services features in strategy sessions and lab tests.

As an "in the cloud" offering from Microsoft Online Services, Exchange Hosted Services includes a comprehensive set of features, for protection from spam, e-mail–borne viruses, and other unwanted messages; Exchange Hosted Archive for regulatory compliance with retention requirements; Exchange Hosted Encryption for data encryption to help preserve confidentiality; and Exchange Hosted Continuity to maintain access to e-mail messages during and after emergency situations. For Microsoft IT, the most important features fall into the Exchange Hosted Filtering category, although it plans to implement Exchange Hosted Encryption in the future as well. Exchange Hosted Archive and Exchange Hosted Continuity are less important for Microsoft IT because archiving and high-availability solutions are already in place in the corporate messaging environment. Microsoft IT did not plan to carry out any internal changes or optimizations with the switch to Exchange Hosted Services.

Table 1 summarizes key technical requirements that Microsoft IT defined for the Exchange Hosted Services rollout and the corresponding Exchange Hosted Services features that enabled Microsoft IT to achieve these goals.

Table 1. Microsoft IT Technical Requirements and Exchange Hosted Services Feature Mapping

Architecture

Figure 4 shows the Exchange Hosted Services solution architecture that Microsoft IT implemented to meet the identified technical requirements. For most Exchange Hosted Services features, Microsoft IT uses the default settings. Customizations and adjustments primarily apply to IP allow list entries, blocked sender and recipient filtering rules, and a limited number of spam filter and policy rules that apply to the entire Microsoft organization, including all e-mail domains. For example, Microsoft IT uses global allow lists to accept all incoming messages from trusted senders, such as business partners, but blocks list servers and similar sources that are not relevant for business. Microsoft IT also blocks incoming messages addressed to aliases commonly used by spammers and specific valid recipients, such as unmonitored mailboxes and global distribution groups. In the spam filter configuration, Microsoft IT specifies that empty messages and messages with invalid or missing sender information should be marked as spam.

Figure 4. Inbound messaging protection with double spam filtering

Regarding the arrangement of security controls, it is important to note that Microsoft IT decided to implement double spam filtering for the initial phase after the Exchange Hosted Services rollout. Double spam filtering in the Exchange Hosted Services filtering network and on Edge Transport servers in the extranet is not a technical requirement, yet it enables Microsoft IT to ensure a consistent user experience. Microsoft IT assumes that users have grown accustomed to the Outlook Junk E-mail feature during the past two years since the transition to Exchange Server 2007 and wants to maintain the same level of user satisfaction following the switch to Exchange Hosted Services. Later, when users are familiar with the new antispam controls, Microsoft IT plans to deactivate double spam filtering. Moreover, Microsoft IT integrated the corporate Active Directory environment with Exchange Hosted Services by using Directory Synchronization Tool to perform directory services checks and to honor the Outlook Safe Senders List, which also helps to maintain user satisfaction and productivity.

In the Exchange Hosted Services solution architecture with double spam filtering, messages for recipients in the domains windows.microsoft.com, winse.microsoft.com, exchange.microsoft.com, and microsoft.com domains pass through the following stages:

1. SMTP connectivity Incoming Internet messages reach Exchange Hosted Services because the MX records for the windows.microsoft.com, winse.microsoft.com, exchange.microsoft.com, and microsoft.com domains point to the Exchange Hosted Services filtering network. The Exchange Hosted Services network is fully load balanced across 10 data centers in North and South America, Europe, and Asia. Incoming messages may reach the Exchange Hosted Services environment through any of these locations.
2. Spam prevention Exchange Hosted Services performs spam prevention checks based on an IP block list with 60 million IP addresses and a reputation database with known bad senders, in addition to directory services checks based on the organization's uploaded directory information, to block the vast majority of spam messages at the earliest point possible.
3. Policy enforcement At the next stage, Exchange Hosted Services performs policy enforcement according to default and custom policy rules. Policies can be based on keywords, sender domains, recipient domains, file names, file types, and other message characteristics; can support regular expressions; and can specify to allow, reject, redirect, encrypt, decrypt, or quarantine messages.
4. Spam protection Exchange Hosted Services performs algorithmic spam filtering, inspects the message headers, analyzes URLs contained in the subject line and message body, applies volume-based reputation, checks for known spam patterns and content types (such as Microsoft Visual Basic® Scripting Edition [VBScript] code in HTML-based messages), assigns spam scores, and either sends messages that exceeded the spam threshold to spam quarantine or rejects the messages. In addition to heuristics and fingerprint checks, Exchange Hosted Services relies on a team of analysts that monitor the spam and virus filtering processes in real time and write regular expressions to fine-tune policy and spam rules.
5. Message delivery to Edge Transport servers Exchange Hosted Services delivers all messages that successfully pass the spam checks to one of the Edge Transport servers in the extranet. Microsoft IT continues to use six Edge Transport servers, distributed across Redmond and Silicon Valley. In the unlikely event that all these servers are unavailable, Exchange Hosted Services queues the messages for up to five days and reattempts delivery every 20 minutes.
6. Double spam filtering Microsoft IT configures EHS to stamp a custom message header string (x-header) in messages that EHS determines to be spam. One possible EHS configuration is to quarantine all these marked messages. Yet, with the Microsoft double spam filtering configuration that does not use EHS quarantine, the EHS determination is subject to additional analysis on the Edge Transport servers, as shown earlier in Figure 4. For example, if RBL analysis on the originating IP address (not the EHS server IP address) determines that the e-mail message should have an SCL rating of seven to nine, then the Edge Transport server does not continue to process the message and instead rejects it, sending an NDR back to the sender. Using an NDR is important for preventing sender blackholing. Microsoft IT specifically configures Edge Transport servers to reject messages with an SCL rating of seven to nine to ensure a positive user experience. That SCL setting has been in place historically resulting in fewer messages being sent to the Junk E-mail folder than with a more relaxed threshold. Microsoft IT also added the Exchange Hosted Services hosts as internal SMTP servers to the Exchange Server configuration by using the Set-TransportConfig cmdlet. This configuration change affects the sequence of antispam checks on Edge Transport servers. For messages received from Exchange Hosted Services, Edge Transport servers now perform sender filtering and recipient verification prior to connection filtering because the MAIL FROM and RCPT TO verbs precede the message data (including custom headers) in the SMTP conversation. However, the effectiveness of most messaging protection controls remains unaffected, such as for content filtering and virus scanning.
7. Message routing and delivery to recipients Microsoft IT has historically been very aggressive in spam prevention and the current approach of double filtering maintains that position. If the Edge Transport server does not reject a message, it forwards the message to a Hub Transport server for further processing, routing, and delivery to the recipient's Mailbox server. Enabling the x-header stamp makes it possible for an Exchange transport rule on the Hub Transport server to check incoming e-mail messages, mark the massages that have an x-header with an SCL of 6, and direct the messages to the recipient's Outlook Junk E-mail folder. For detailed information regarding the antispam and antivirus controls that Microsoft IT uses on Hub Transport servers, Mailbox servers, and Outlook clients, see the technical white paper Microsoft Exchange Server 2007 Edge Transport and Messaging Protection at http://technet.microsoft.com/en-us/library/bb735142.aspx.

Deployment

The Microsoft IT Exchange Hosted Services deployment followed the milestone-driven process model outlined in the Microsoft Solutions Framework (MSF) with heavy emphasis on planning, scoping, testing, and stabilizing, as illustrated in Figure 5. The project commenced in January 2008 with strategy sessions, a review of the existing messaging protection infrastructure, and an evaluation of the Exchange Hosted Services configuration for the windows.microsoft.com and winse.microsoft.com domains. The project then progressed through lab deployments and a pilot phase with double spam filtering. The project reached a key milestone on June 9, when Microsoft IT updated the public MX records for the microsoft.com domain to point to Exchange Hosted Services. Many Microsoft users consider this the project end date, although several tasks remained to be completed, such as stabilizing the deployment and deactivating double spam filtering. Overall, the transition to Exchange Hosted Services was flawless.

Figure 5. MSF process model mapped to Exchange Hosted Services deployment stages

Microsoft IT ensured the success of the Exchange Hosted Services deployment by separating the project activities into the following four main iteration phases:

1. Envisioning and planning Key activities during this phase included determining business and technical requirements for the Exchange Hosted Services deployment, mapping available Exchange Hosted Services features to these requirements, determining deployment preferences, and categorizing Exchange Hosted Services features for immediate or later implementation. For example, during this phase, Microsoft IT narrowed down the project scope to incoming Internet mail only even though Exchange Hosted Services can perform both inbound and outbound spam filtering. Microsoft IT also decided to use Exchange Hosted Services only for the four most important Microsoft e-mail domains, yet continues to point the remaining 480 Microsoft e-mail domains directly at the Edge Transport servers in an effort to keep the extent of the configuration changes at a manageable level. Other important deployment decisions related to directory synchronization, administration and maintenance, and double spam filtering.
2. Developing For deployment plan verification, Microsoft IT created a live test domain named FBT.microsoft.com and pointed the domain's MX records to Exchange Hosted Services. The goal was to validate the Exchange Hosted Services functionality. Key questions revolved around the implementation of directory synchronization, double spam filtering, and how to gather metrics and performance statistics. To clarify these questions, Microsoft IT deployed Directory Synchronization Tool, solved encountered issues, and then monitored the synchronization processes for several weeks to ensure reliable operation. Microsoft IT also specified Exchange Hosted Services hosts as internal SMTP servers to enable double spam filtering, created dedicated receive connectors for Exchange Hosted Services communication, sent test messages, and gathered statistics based on performance counters for receive connectors. Even though dedicated receive connectors are not a strict requirement, Microsoft IT continues to use this configuration in the corporate messaging environment to facilitate targeted system monitoring and metrics gathering. Furthermore, Microsoft IT used the reporting and message tracking capabilities of Exchange Hosted Services to gain a better understanding of the processing details in the Exchange Hosted Services pipeline.
3. Stabilizing Following the successful completion of the lab tests, Microsoft IT added the microsoft.com and exchange.microsoft.com domains to the Exchange Hosted Services configuration and verified the reliability of directory synchronization, yet did not change the domains' public MX records yet. The MX record changes required formal approval from the service manager and program manager responsible for the project. Approval criteria were reliable directory synchronization without errors on a continuous basis, verification of policy filtering rules, and successful completion of Exchange Hosted Services filtering tests for the microsoft.com and exchange.microsoft.com domains. To perform these verifications, Microsoft IT submitted test messages by using clients that directly connected to the Exchange Hosted Services hosts without relying on public MX records for the microsoft.com domain. With the approval to move forward, Microsoft IT informed regional managers about the planned changes, changed the public MX records on June 9, 2008, and then closely monitored the messaging environment.
4. Deploying The transition to EHS was seamless and user impact was minimal. With the double filtering in place, users received the expected functionality of spam messages (SCL of 6) being routed to the Outlook Junk E-mail folder. The next steps for finalizing deployment are to analyze and verify performance, and to remove double filtering.

Deployment Challenges

Apart from general IT-related objectives, Microsoft IT has the company-specific goal to help product teams ensure quality, provide evidence of enterprise readiness, and drive innovation based on the actual needs of an IT organization. According to its mission to be the first and foremost customer of Microsoft, Microsoft IT not only deployed Exchange Hosted Services, but also carefully evaluated the implementation to identify and solve typical enterprise deployment challenges.

Directory Synchronization

One of the most important deployment challenges related to directory synchronization. In the previous Exchange Hosted Services deployment for the windows.microsoft.com and winse.microsoft.com domains, Microsoft IT did not synchronize directories because an automated directory synchronization solution was not available. Exchange Hosted Services merely filtered the messages and routed them to the corporate messaging environment. With the transition of the exchange.microsoft.com and microsoft.com domains, however, Microsoft IT determined that it was essential to synchronize directories to scan for valid and invalid addresses and honor the Outlook Safe Senders List directly at the Exchange Hosted Services perimeter.

The Exchange Hosted Services Directory Synchronization Tool provides the solution for automated directory synchronization. It runs as a Windows® service on a server in the corporate production environment, pulls recipient and safe sender information from AD DS, and transfers the data over Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) connections to Exchange Hosted Services Web services.

Yet, the tool has limitations. It performs a full synchronization during each cycle and might encounter issues with large directories. For example, the Microsoft directory includes approximately 480,000 recipient objects. Completing a synchronization cycle takes two hours. Microsoft IT noticed missed synchronizations during early stages of the deployment (the Exchange Hosted Services directory service automatically sends notifications in the event of synchronization errors), but was able to solve these issues in collaboration with the Exchange Hosted Services team. The tool now supports Windows Server® 2008 domain controllers.

Completing directory synchronization successfully is important because new employees will not receive messages from the Internet until their address information is uploaded to Exchange Hosted Services. It is also important for e-mail address changes and Outlook Safe Senders List updates to reach Exchange Hosted Services in a timely manner. Accordingly, Microsoft IT performs directory synchronization every 12 hours under normal conditions.

Taking the importance of directory synchronization into consideration, Microsoft IT deployed the Directory Synchronization Tool on seven Hub Transport servers in the corporate messaging environment for redundancy. However, it is important to point out that the current Directory Synchronization Tool version does not support load balancing. Only one instance of the Directory Synchronization Tool can run. The synchronization service is disabled on six Hub Transport servers and is set to start automatically on only the active Hub Transport server. The operations team must manually change the configuration to failover the service to one of these servers for maintenance or other reasons and uses Microsoft System Center Operations Manager to monitor the synchronization service.

Authenticated Distribution Groups

Authenticated distribution groups are restricted to receive messages only from authenticated senders, so that anonymous users, such as senders on the Internet, cannot send messages to these groups. Microsoft IT considered it important that Exchange Hosted Services blocks messages to these groups. There is no reason for Exchange Hosted Services to accept these types of messages and forward them to the Edge Transport servers. The receiving Edge Transport server will drop the message and generate an NDR, which can pose an issue during spam campaigns with high message volumes. A better approach is to stop messages to authenticated distribution groups at the perimeter before message submission is confirmed. The new Exchange Hosted Services version supports authenticated distribution groups.

Virus Scanning and Notifications

Virus scanning is a vital element of any messaging protection strategy. Initially, Microsoft IT decided to bypass the Exchange Hosted Services virus scanners and perform virus scanning only on Edge Transport servers and Hub Transport servers in the corporate messaging environment. It based the decision on the fact that Exchange Hosted Services preferred to drop virus-infected messages silently, which did not conform to Microsoft IT best practices. Microsoft IT prefers to generate notifications in an effort to avoid e-mail black holes along the message transfer paths.

Best Practices

Thorough planning and preparation enabled Microsoft IT to switch to Exchange Hosted Services with no noticeable disruption of business processes or user dissatisfaction. Customers who want to transition their environments should consider the following best practices:

• Focus on careful planning and preparation Although Exchange Hosted Services offers typical advantages of hosted services, including reduced infrastructure requirements and administrative overhead, the specific configuration depends on actual business and technical needs. Microsoft IT planned for technical requirements, user needs, staffing and support requirements, and so on before transitioning to Exchange Hosted Services.
• Master inbound message filtering before outbound Focusing on inbound message filtering first is a practical consideration because for most organizations, unwanted Internet messages are more prevalent than internal spam messages. Microsoft IT uses Forefront Security for Exchange Server on Hub Transport servers to block harmful messages internally and is systematically approaching inbound filtering through Exchange Hosted Services, although Exchange Hosted Services can handle both inbound and outbound filtering.
• Align technical requirements with configuration design Part of the planning and design phases of implementing Exchange Hosted Services deal with first gathering and documenting the business and technical requirements, and then preparing a comprehensive design for implementing the requirements. This makes giving documentation to other teams and ensuring that the environment is built according to specifications a straightforward process.
• Validate inbound message flow After configuring the aspects not related to Exchange Hosted Services and implementing specific Exchange Hosted Services features according to requirements, it is important to verify and validate inbound message flow from anonymous, trusted, and partner users. An organization can accomplish this by sending messages directly through Exchange Hosted Services and tracing the message by using the Exchange Hosted Services administration center.
• Verify directory synchronization It is important, especially in multi-forest and multi-domain environments, to ensure that synchronization functions as expected before proceeding with the implementation of filtering. Microsoft IT encountered some issues with synchronization at first, and it corrected them by monitoring, determining the root causes, and making configuration changes. It is important to note that Directory Synchronization Tool does not require MX records in order to function.
• Prepare thorough documentation For Microsoft IT, the deployment requirements for hardware and software were minimal and concerned mainly Directory Synchronization Tool. However, for the operations team to maintain the new technology and Exchange Hosted Services configuration settings, the design had to be defined and documented, and team members needed to be trained. Creating detailed documentation helps maintain a centralized repository of information, which can then be published on a shared workspace and used by team members.
• Create a dedicated receive connector Microsoft IT discovered that using a dedicated receive connector provided the option to track metrics and statistics with finer detail. One tool used for measurement is Performance Monitor.
• Consider double filtering As mentioned earlier, the Microsoft environment filters messages twice, one time at the Exchange Hosted Services level and one time at the Edge Transport server level. Although not strictly necessary, it adds another layer of protection and configuration control.
• Scan for viruses It is important to decide the level at which virus scanning takes place. Microsoft IT decided to scan for viruses on Edge Transport and Hub Transport servers to take advantage of the existing configuration.
• Use Exchange Hosted Services reporting Exchange Hosted Services has a very comprehensive reporting back end that an organization can use to generate reports about system performance for perimeter filtering, policy filtering, virus filtering, and custom rules filtering on a domain and sub-domain basis. Exchange Hosted Services also provides real-time data to trace messages and locate messages in case a support incident requires message status and tracing.
• Train staff before the cutover Microsoft IT pursues a layered approach to training in order to accommodate the various teams and roles, such as implementers, operations staff, Helpdesk staff, and technical support staff. Microsoft IT created a shared workspace that houses training materials and guides to ease the learning curve for personnel.
• Ensure a smooth user transition experience Users at Microsoft rely on and expect features like Outlook Junk E-mail Filter and allow lists. Correspondingly, Microsoft IT ensured that the transition would not affect those features for users by not using the EHS quarantine capabilities. It is a best practice to evaluate the features that users require, and verify their functionality on a trial basis before rolling out to all users. Additionally, it is important to monitor support tickets in order to understand performance trends, identify possible root causes of issues, and optimize the environment after rollout.
• Use test mode before applying new rules Test mode helps verify policy rule configurations and mitigate risks before pushing changes to production by marking messages as filtered, yet permitting them to pass. This enables Microsoft IT to verify how EHS would handle a message before implementing the change.

Benefits

The deployment of Exchange Hosted Services does more than provide Microsoft IT with an improved infrastructure for messaging protection. The advantages from Exchange Hosted Services directly translate to the following hard and soft business benefits:

• Improved performance Exchange Hosted Services is fully redundant, scalable, and load balanced across the global messaging infrastructure, in addition to offering fine-tuning options for customizable filters. Exchange Hosted Services also provides the reassurance of 99.999 percent uptime, 24-hour support, virus protection, spam detection at the perimeter, promised message delivery in less than one minute, fewer than one in 250,000 false positives, and a Microsoft-backed SLA.
• Lower total cost of ownership (TCO) Using Exchange Hosted Services decreases TCO by offloading hardware and staffing requirements for filtering and managing e-mail messages. For example, Exchange Hosted Services includes a centralized Web-based administration solution that synchronizes automatically. By using the Exchange Hosted Services to filter messages through a cloud-based perimeter, enterprise organizations can eliminate storage and other costs associated with the rising number of spam messages.
• Better IT asset actualization Corporate bandwidth is preserved for business-related computing because the messaging infrastructure is no longer processing and filtering the 25 million daily spam submission attempts in the internal messaging environment.
• Lower security risks Exchange Hosted Services enables Microsoft IT to lower risks through a dedicated team of analysts that proactively respond to messaging threats. When new threats emerge, Exchange Hosted Services identifies and rejects the messages related to the threats within a few hours. Exchange Hosted Services provides additional features to reduce security risks, such as stopping submission attempts of unwanted messages before establishing a TCP/IP connection.
• SLAs As an enterprise-ready solution, Exchange Hosted Services offers Microsoft IT strict SLAs, including 99.999 percent availability and message delivery in one minute or less.
• Increased employee productivity A major business requirement of the Exchange Hosted Services implementation is to provide a smooth transition experience for users and increase employee productivity. Exchange Hosted Services helps Microsoft IT achieve this goal by providing a consistent user experience.

Conclusion

In keeping with the ongoing goal of evaluating new technology, Microsoft IT knew that it needed an updated approach to messaging protection to fight the ever-increasing amount of spam and other unwanted messages. The objective for the new messaging solution was to provide a more secure way to fight increasingly sophisticated spam and other malicious software without losing functionality, while adding business benefits for other enterprise organizations.

To meet these goals, Microsoft IT deployed Exchange Hosted Services, which enables Microsoft IT to improve security for the existing messaging infrastructure by implementing a cloud-based protection environment that filters spam and other unwanted messages in the perimeter before the unsolicited messages reach the corporate environment through a TCP/IP connection. In addition to realizing security goals, Microsoft IT attained business benefits such as improved use of assets through increased corporate bandwidth, in addition to decreased overhead and TCO through implementation of a centralized Web-based administrative platform and elimination of internal spam storage. Microsoft IT also realized quality-of-service benefits such as 24-hour support and a Microsoft SLA in a fully redundant, scalable, and load-balanced infrastructure for global messaging.

Exchange Hosted Services enables Microsoft to remain proactive in the ongoing challenge of protecting the corporate messaging environment against spam and other threats. The new messaging protection provides a reliable and cost-efficient solution for enterprise organizations.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/online

http://www.microsoft.com/technet/itshowcase

© 2008 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, Forefront, Outlook, Visual Basic, Windows, Windows PowerShell, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.