Exporting Mailbox Content

Export-Mailbox is a task developed by the migration team to allow Administrators to export content from active mailboxes to a folder inside other active mailboxes. The initial idea for this task was to be a complete replacement for ExMerge. The implementation of some of this functionality was problematic and it required more time than initially planned. In this post I will describe what we are missing, which workarounds are available, and some of our future plans.

The need for an ExMerge replacement

ExMerge is a tool created by Microsoft Support in the Exchange 5.5 timeframe, used to allow Administrators to export and import mailbox content to/from PST files. Over the years this tool became popular since, because of its flexibility, it could be used in a number of scenarios where specific tools did not exist. As a result of this popularity, the Exchange team took on development ownership of ExMerge for Exchange 2003 and released it as a tool over the web.

Even though ExMerge proved to be a helpful tool for Exchange Administrators, there were several problems that needed to be addressed in Exchange 2007:

• Separate Code Base: One of the goals for Exchange 2007 is to reduce the number of separate tools and code bases supported for migration operations. ExMerge has always been completely separate from all shared Exchange migration code. This has caused several technical problems like the need to support an independent PST provider (that is why the current version is not able to support mailboxes larger than 2 GB and Unicode) and so on. These issues have caused delays in updates, limited functionality and extra support costs for customers and Microsoft as well.
• Independent Tool: Besides the technical implications of having a separate code base, the fact that ExMerge is an independent tool has caused a lot of unintended consequences regarding the scenarios where it is used. Every time a tool is used for something it was not designed for the risk of unintended consequences and bugs increase. Also, over use of the Exmerge tool works as an incentive to under use our other migration tools where they are better suited. This adds extra cost to the management of Exchange.

Export-Mailbox

Export-Mailbox was built to address scenarios where mailbox content needs to be copied from one active mailbox to another without actually migrating the whole mailbox object. Source and target servers used by export-mailbox need to be part of a Single Forest or Resource Forests. That is, mailbox content can only be exported to mailboxes within the same forest.

The following versions are supported by export-mailbox:

• Source Server:
• Exchange 2000 SP3 (or later)
• Exchange 2003 SP2 (or later)
• Exchange 2007
• Target Server:
• Exchange 2007

Exchange Permission requirements:

• Logon account for the user who is running Export-Mailbox needs to be a member of "Exchange Servers Administrators" for source and target Server. Permissions for previous Exchange Servers remain the same as they were for Exchange 2003 Move Mailbox Task (Exchange Administrator).

Current functionality available for Export-Mailbox

Pre-Validation and New and Improved Logging

Export-Mailbox benefits from a pre-validation functionality similar to the one present in move-mailbox. This feature saves time by identifying most errors right away before the export begins, instead of waiting until they happen during an actual export.

Also available for Export-Mailbox is the comprehensive log feature: Event logs, a XML Report and a troubleshooting log. All logs are enabled by default and are located at <ExchangeRoot>\Logging\MigrationLogs\.

Export-mailbox available options

• Export mailbox content from a active mailbox to a folder inside another mailbox
• Filter content to be exported based on:
• List of included or excluded Folders (included using –IncludeFolders or excluded using -ExcludeFolders)
• Message subject (-SubjectKeywords)
• Message and attachments content (-ContentKeywords)
• Attachment file names (-AttachmentFilenames)
• Message locale (-Locale)
• "OR" search of Message subject, message content and attachment content (-AllContentKeywords)
• Date range (-StartDate and –EndDate)
• Delete content from source mailbox after exporting it to target mailbox
• Automatically exports dumpster items as regular messages in the target mailbox

Features postponed

The following options were not included for Exchange 2007:

- Exporting content directly to a PST file: Part of the challenge here was to adapt our code to the Outlook PST provider, which provides the most up to date PST functionality. Currently Administrators can export content to folders inside one or more mailboxes and then manually export this content to PST files using Outlook. Also, Exchange 2007 will not actively block access from ExMerge clients supported by Exchange 2003. This is not a scenario officially tested but customers have reported that running ExMerge from an Exchange 2003 server and accessing Exchange 2007 databases indeed works. Native Exchange 2007 support for this PST is being planned to be part of Service Pack 1.

- UI interface: Since most of the common scenarios for ExMerge were related to bulk operations we have decided to focus on delivering the needed functionality first and a GUI later. There is no defined date for the creating of such interface for the export-mailbox task at this point.

Customer scenarios and examples

These are the supported customer scenarios for Export-Mailbox:

1. Exporting mailbox content during litigation process

During a litigation process, Administrators may need to regularly export mailbox content from selected users. These searches will be based on criteria defined by lawyers. This content will be exported from one or more source mailboxes into a temporary mailbox that the lawyers can access. The lawyers would then process the data and send the data to opposing counsel.

1. Exporting email content to former users

When accounts are about to be removed from a server (as in college students graduating or users leaving a hosting account)administrators might want to send mailbox content to the former users that for some reason could not manually copy the email content themselves. Admin would use the Export-Mailbox option to export the data to some intermediary mailbox and then manually export data to end users via PST files.

1. IT Emergency Response Process

In the course of daily operations of an IT Emergency Response organization, administrators need the ability to scan a large number of messages based on specified criteria, and perform mass deletion of any suspect email found. By using Export-Mailbox and the –DeleteContent parameter along with specific filter options, they are able to search and delete such messages.

Export-Mailbox examples:

Exporting mailbox content based on Organizational information:

Export all content from all mailboxes where user Title starts with VP to a folder called VPData in the Administrator mailbox:

Get-user | where { $_.Title -ilike "VP*" } | export-mailbox -TargetFolder "VPData" -TargetMailbox Administrator

Export all content from all mailboxes from the Accounting department to a folder called AccountingData in the Administrator mailbox:

Get-user | where { $_.Department -Eq "Accounting" } | export-mailbox -TargetFolder " AccountingData" -TargetMailbox Administrator

Using filtering when Exporting mailbox content:

Export all content from UserMailbox1's mailbox received between 02/02/05 and 02/05/05 to a folder called User1Data in the UserMailbox2's mailbox:

Export-mailbox -id UserMailbox1 –StartDate "02/02/05" –EndDate "02/05/05" -TargetFolder 'User1Data' -TargetMailbox UserMailbox2

Export all content from the Sent Items folder of UserMailbox1's mailbox to a folder called User1SentItems in the UserMailbox2's mailbox:

Export-mailbox -id UserMailbox1 -IncludeFolders "\Sent Items" -TargetFolder ' User1SentItems' -TargetMailbox UserMailbox2

Filters out content from the Deleted Items folder and only exports messages that are in Japanese to a folder called User1JapaneseItems in the UserMailbox2's mailbox:

Export-mailbox -id UserMailbox1 -ExcludeFolders "\Deleted Items" -Locale ja-jp -TargetFolder 'User1JapaneseItems' -TargetMailbox UserMailbox2

Using filtering to Export and delete mailbox content:

Export and delete all messages that contain "Confidential" in their subject from all mailboxes from the DB1 database to a folder called ConfidentialData in the Administrator mailbox:

Get-mailbox -database 'DB1' | export-mailbox –SubjectKeywords "Confidential" -TargetFolder "ConfidentialData" -TargetMailbox Administrator –DeleteContent

Export and deletes all messages that have an attachment that contains the word "movie" in its name from all mailboxes from the DB1 database to a folder called MovieAttachmentMessages in the Administrator mailbox:

Get-mailbox -database 'DB1' | export-mailbox –AttachmentFilenames "movie" -TargetFolder "MovieAttachmentData" -TargetMailbox Administrator –DeleteContent

Export and deletes all messages that contains the word "virus" in its body or in its attachment body from all mailboxes from the DB1 to a folder called VirusMessages in the Administrator mailbox:

Get-mailbox -database 'DB1' | export-mailbox -ContentKeywords "virus" -TargetFolder "VirusMessages" -TargetMailbox Administrator –DeleteContent

- Paul MacKnight

Introduction

One of the most common questions we hear is, "How do I open another user's Calendar in Exchange 2007?" One of the most common misconceptions around this functionality is the level of permissions that are required. This Tech Tip was written to clarify the requirements necessary to open another person's shared Calendar using OWA and how they differ from the requirements that are necessary to open another user's mailbox using the new explicit logon feature in OWA.

Opening another user's Calendar

In legacy Exchange, users who had permission to another user's Calendar could open the Calendar in OWA by entering a simple URL in the form of http(s)://mail.fourthcoffee.com/exchange/alias/calendar. It was the inclusion of ExIFS in legacy Exchange which made it possible to make simple http requests to items and folders on the M: drive. Since we no longer have this in Exchange 2007, we use 'web parts' and the syntax has changed. In order to open another user's Calendar in Exchange 2007 you now need to enter a URL using the following syntax.:

https://mail.fourthcoffee.com/owa/e2k7user@fourthcoffee.com/?cmd=contents&f=calendar

The example above opens the Calendar in Day view. The URL can be further modified to open the user's Calendar in Weekly view:

https://mail.fourthcoffee.com/owa/e2k7user@fourthcoffe.com/?cmd=contents&f=calendar&view=weekly

The only requirement to make this work in Exchange 2007 is for the target user to add you with the desired permission level using Outlook. To share a folder using Outlook, right click on the folder in the Outlook navigation pane and select "Sharing..." from the folder properties menu and add the user and the desired permission level for the user to the folder.

Opening another user's Mailbox

Provided you have the appropriate permissions, you are still able to open another user's mailbox using a Url similar to https://mail.fourthcoffee.com/owa/e2k7user@fourthcoffee.com as in Exchange 2003. However, OWA in Exchange 2007 also includes a new method for accomplishing the same through a feature in the UI.

To open another user's mailbox, simply click the drop-down arrow next to your user name and enter the other user's name or alias in the "Select mailbox" field and click Open.

Unlike accessing a single folder in another user's mailbox (such as the Calendar), this functionality requires that you have full mailbox access to the target user's mailbox. To achieve this level of permission you use the Exchange Management Shell and enter the command as documented in the following example:

Add-MailboxPermission e2k7user1 –AccessRights FullAccess –user fourthcoffee\e2k7user2

Where, e2k7user1 owns the target mailbox and e2k7user2 is the user you're granting permissions to. Note, granting e2k7user2 access as described will allow them to open e2k7user1's mailbox but not send mail on behalf of e2k7user1.

If you need to later remove the FullAccess right from e2k7user2, use the Remove-MailboxPermission task in the same manner.

For additional information, please see previous post called Web Part URLs supported by Exchange 2007 Outlook Web Access.

- Joe Turick

This blog post continues to explore how Exchange uses WMI in representing the Status and Monitoring node in Exchange System Manager. In this post, we will cover general troubleshooting of ESM "status" problems.

Using the monitoring node, you can view the list of servers in your organization and their current status to ensure that your servers are operating. You can also verify that the connectors you have established between servers are available to transmit messages.

To verify server and connector status: Start Exchange System Manager > Navigate to Monitoring and Status > Tools > Monitoring and Status. Click Status. All connectors and servers in your organization are listed in the details pane. They are identified by administrative group and display a status of Available or Unreachable. Where do I start if the status shows Unreachable?

Having WMI problems?

Start troubleshooting by testing if WMI works. A simple test would be to open the Computer Management console (compmgmt.msc), expand 'Services and Applications', select 'WMI Control', right-click and select 'Properties. There is some basic computer/OS information listed on the General tab that is obtained from WMI. If you cannot see any of that data, you may be having problems with the WMI engine. Ensure that that the WMI services are started and inspect your event logs for errors. If you are not having problems with WMI (failure to connect, event 9098, etc...) try the following:

Run wbemtest.exe.

If wbemtest.exe is not on your path, this could be the problem. The system environment's PATH variable should contain %windir%\system32\wbem. If it doesn't add it and reboot.

In wbemtest, hit Connect, type 'root/cimv2' in the top text field and hit 'Login'. Then hit 'Enum Classes...', leave the text box empty, but select 'Recursive' and hit OK. You should see a list of 600+ objects (count displayed in top left).
If you get an error here, your WMI service is not functioning.

In wbemtest, hit Connect, type 'root/cimv2/applications/exchange'. Then hit 'Enum Classes...', leave the text box empty, but select 'Recursive' and hit OK. You should see a list of about 57 objects (count displayed in top left).

Double-click the ExchangeClusterResource line, then hit the "Instances" button, look for an error dialog or an error message above the list box. Repeat for all classes that start with "Exchange". It is normal for some of the classes to report no instances.

Turn up WMI Logging by going into the Compmgmt.mmc console & restart the winmgmt service. You turn verbose logging by right-clicking 'My Computer', select 'Manage', expand 'Services and Applications', select 'WMI Control', right-click and select 'Properties', click on the 'Logging' tab, select 'Verbose' and add three zeroes to the 'Maximum size' field, making it 65536000.Wbemcore.log will have a lot of interesting information. For more information, refer to:

310315 Troubleshooting monitoring and status in Exchange and in Small Business Server

http://support.microsoft.com/default.aspx?scid=kb;EN-US;310315

288590 Error "0x8004100e" and event ID 9097 occur when you run the System Attendant in Exchange Server 2003

http://support.microsoft.com/default.aspx?scid=kb;EN-US;288590

Run this script on each server. This will tell us what each server has in its own routing table.

set WMI = GetObject("WinMgmts:root/cimv2/applications/exchange")

set objs = WMI.InstancesOf("ExchangeServerState")

for each obj in objs

text = obj.Name + " = " + obj.ServerStateString

if obj.Unreachable then

text = text + " (Unreachable)"

end if

if obj.ServerMaintenance then

text = text + " (Maintenance)"

end if

WScript.Echo obj.Name + " = " + obj.ServerStateString

Next

When running this script on server X, if the server line says "Unreachable", it means that the routing engine of server X cannot connect to its routing master. Whenever a server is unreachable, its state is irrelevant (it may be very stale).

You can run the script from a command prompt also:

cscript wmitest.vbs >%computername%.txt

Winroute

Winroute is a very important tool for inspecting routing info. Run winroute from the problem server

There is some tracing (not much) present that can be gathered using regtrace. For additional information about how to use the Regtrace utility, click the following article number to view the article in the Microsoft Knowledge Base:

238614 How to set up Regtrace for Exchange 2000

http://support.microsoft.com/default.aspx?scid=kb;EN-US;238614

The information the System Attendant gathers is displayed in the userdata field associated with a server object in Winroute. Here is some information about winroute one needs to be aware of in troubleshooting such issues.

The userdata field is 8 bytes long and looks like: 0701000000000000

The first byte (07) is ignored, byte 2 indicates maintenance mode is on/off, bytes 3 - 8 represent: queues, disk, memory, cpu services, cluster in that order.

A value of 81 in the 2^nd byte of the User Data field, means the server is in maintenance mode

This is how it would look like in Exchange System Manager

A blank User Data field, means the System Attendant has/did not populate the data

This is how it would look like in Exchange System Manager

Following is an example where everything is good - server is not in maintenance and no resources are being monitored.

This is how it would look like in Exchange System Manager

For more information, refer to:

832281 Link state issues and routing issues in Exchange 2000 Server and in Exchange Server 2003

http://support.microsoft.com/default.aspx?scid=kb;EN-US;832281

Miscellaneous Troubleshooting tips:

1. Verify RPC (launch event viewer and connect to another server, WMI and DCOM permissions is working
2. Run EXBPA in health check mode and permissions mode.

Check to see if the computer account for the Exchange server has an explicit Deny permission for the Receive As permission assigned.

For more information on permissions, refer to:

899393 Event ID 1025 is logged two times in the Application log with the "EcGenerateNRN: Error: 0x80070005" and "EcGenerateReadReport: Error: 0x80070005" error codes on a computer that is running Exchange Server 2003 or Exchange 2000 Server

http://support.microsoft.com/default.aspx?scid=kb;EN-US;899393

1. On a particular exchange server, in ESM under Tools | Monitoring and status |Right Click on "Status" connect to another Exchange server and check to see the status of computer object. Does this work?
2. Right click on the exchange server, select properties | security tab | advanced options. Make sure the "Allow inheritable permissions from parent to propagate to this object" is checked (it should be).
3. Open gpedit.msc, computer configuration | windows settings | security settings | local policies | user rights assignment | Access this computer from the network and check to see if all the Users and groups (authenticated users and everyone) that are required exist.
4. Run telnet <Remote_server_name> 691 to make sure 691 port is opened to the remote Exchange server.
5. Make sure there are no communication problems with firewalls being in place.
6. Debug trace data from the routing engine (aka regtrace). Here are the steps for that:

• On the problem server, stop the routing engine service.
• From Start/Run, type regtrace and leave the window open temporarily.
• Go to the following key in regedit: HKLM\Software\Microsoft\MosTrace\CurrentVersion\DebugAsyncTrace
• Add a reg_multi_sz value called Modules
• Enter the following values in it on separate lines: RESVC REAPI Routing
• Switch back to the regtrace application, select all checkboxes on the Traces tab.
• Select the File option on the Output tab. C:\trace.atf is usually the default and is fine. Specify 50MB for file size.
• The threading tab shouldn't have anything selected.
• Click Apply to begin the tracing. Don't click OK otherwise the window will close.
• Start the routing engine service. Let it run for about 5 minutes.
• Switch back to the regtrace application. Set it to "No Tracing". Remove all checkmarks on the Traces tab.
• Delete the Modules value from the registry and send us the trace.atf file for further analysis.

9. Gather DSACLS from a good server and bad server and windiff them.

The server X on startup will connect to the master on 691 and request to attach. The master will then authenticate server X by seeing if the computer account of server X has the "Send As" right on the master's server object. The Exchange Domain servers group will have the "Send As" rights on the master and any members of this group will benefit from that. This group is present on Server Y's ACL list with the proper entry and if the other servers are working okay, then it further supports that the group is okay. In some cases, Server Y to deny Server X the ability to connect to master, it must mean Server Y is seeing some problem with the ACL list that is enough to prevent Server X from connecting. In that case, add Server X explicitly to Server Y's ACL list with Full control.

If you notice in the DSACLS output for Server X there might be a bunch of duplicate ACLs which usually happens if someone does the following:

a) Remove the "Inherit Permissions from Parent" checkbox and select the Copy option

b) Select "Inherit Permissions from Parent" again which will then create a duplicate set of ACLs in addition to the ones created by choosing Copy above.

I have seen instances where having duplicate entries have caused issues.

10. In ESM, navigate to servers-> Server X "property" and under the "security" tab. By default, exchange servers should be under "Exchange Domain Servers" which have the correct privileges. However, manual settings or the fact that if an exchange server in question is a DC may have this privilege denied because of it being under other groups. Check to see if the account serverX$ has "send as" privilege. One can run exchutil /v /all to verify this.

More information:

257265 General troubleshooting for transport issues in Exchange 2000 Server and in Exchange Server 2003

http://support.microsoft.com/default.aspx?scid=kb;EN-US;257265

- Nagesh Mahadev

Introduction

When selecting hardware for your Exchange servers, there are many things that you must consider. Two of the most critical resources are processor and memory.

This article, an update to an article original posted on 3/13/2006, provides processor & memory guidelines for minimum, recommended and maximum recommended configurations. There are several factors that go in to choosing the right hardware for an Exchange 2007 deployment. This article provides rule of thumb guidance on the primary factors which determine the proper memory and processor configuration for a given Exchange 2007 role. In separate articles we will cover other critical pieces to Exchange 2007 sizing such as storage and network hardware. Additional guidance will be provided as available throughout the Exchange Server 2007 development process.

Exchange 2007 server hardware requirements are different than previous versions of Exchange (2003)

The primary hardware difference between Exchange 2003 and Exchange 2007 is the move from a 32-bit platform (Exchange 2003) to a 64-bit platform (Exchange 2007). Exchange 2007 will only be supported in production environments when it is running on an x64 edition of Windows Server 2003 (Note: The Exchange 2007 Admin only installation is supported for production when using both the x64 and x86 versions of the software running on their respective processor platforms). The change from a 32-bit platform to a 64-bit platform requires a new approach to choosing server hardware for Exchange; especially processor and memory:

Processor types supported by Exchange 2007

Exchange 2007 is only supported in production when the following are true:

• Running the x64 version of Exchange 2007
• Running on Windows 2003 x64 Editions
• Running on x64 compatible processors

The following processors support x64 versions of Windows 2003, thereby supporting Exchange 2007 deployments:

• AMD Opteron
• Intel Xeon processor with Intel® EM64T

Each of these vendors also ship x64-capable desktop processors which can also run x64 versions of Windows 2003 (e.g. AMD Athlon64 and Intel Pentium D with EM64T) but for the sake of simplicity, this article will concentrate on processors designed for server deployments.

It's important to note that the Intel Itanium (IA64) processor will not work with Windows 2003 x64 Editions, and thus it will not work for Exchange 2007 deployments. Exchange 2007 is designed to run only on x64 capable processors such as those listed above; Exchange 2007 will not run on Itanium based systems.

Regardless of which server processor you select, it is necessary to have the server product pass the Designed for Windows test suite to ensure Microsoft support. Servers listed on the Windows Server Catalog meet these criteria. If your server is not listed, check with your vendor to see if either the "Designed for Windows" logo testing is in progress or the server has passed the testing and is pending a website update.

Multi-core processor considerations for Exchange 2007

Exchange 2007 benefits significantly when running on multi-core processors. The performance benefit for Exchange from dual-core technology depends upon the specific processor utilized. The findings from Exchange 2003 dual-core testing have been summarized in Microsoft Knowledge Base article 827281, CPU and memory scalability for Exchange Server 2003 and for Exchange 2000 Server. Also, the performance benefit of specific dual-core implementations can be seen by comparing the MMB3 results of a 4-processor, single-core based server to a 2-processor, dual-core based server. These results have been published at the Performance Benchmarks for Computers Running Exchange Server 2003 Web site. The benchmark is in the process of being updated for Exchange 2007. Exchange 2007 benchmarks will be published when available.

Multi-core processors are an attractive option for Exchange 2007 servers based on price and performance. Please ask your server vendor about dual-core benefits for Exchange, specific to a given hardware architecture.

Hardware specific memory considerations for Exchange 2007

Exchange 2007 enables much better memory utilization than Exchange 2003 due to its 64-bit architecture. Because of the virtual address space limitations of a 32-bit platform, Exchange 2003 is limited to using 4 GB or less of physical memory. In contrast, customers running Exchange 2007 on Windows 2003 x64 Editions can efficiently utilize upwards of 32 GB of memory (Mailbox role). Note: 32 GB is not a physical limitation, rather the most cost-efficient current maximum memory configuration. Depending upon the number of memory slots in a server, this cost-efficient maximum memory configuration could be even less than 32GB (e.g. 16GB). This change needs to be factored in when choosing server hardware. The following factors should be considered:

• Server Maximum Memory Configuration - Different server architectures have different memory limits. We recommend that you check the following technical specifications of the server to determine the criteria that affect the maximum memory configuration to ensure that the appropriate amount of RAM can be installed in to an Exchange 2007 server economically:

• Memory Speed - Some server architectures require slower memory to scale up the memory to ten's of gigabytes in a given server (e.g., maximum server memory is limited to 16GB with PC3200 or 32GB using PC2700). You should check with the manufacturer to make sure that the memory configuration target for Exchange 2007 is compatible in terms of speed.
• Memory Module Size - What is the largest memory module size the server will support? Generally, the larger the memory module, the more expensive it is; 2x1GB DDR SDRAM memory modules generally cost much less than 1x2GB DDR SDRAM memory modules. When planning for an Exchange 2007 server, make sure the maximum memory module size allows you to meet your target memory requirements
• Total Number of Memory Slots - How many memory modules will a given server support? The total number of slots multiplied by the maximum memory module size will provide the maximum memory configuration for the server. Also, keep in mind that memory modules must sometimes be installed in pairs.

Applying the processor and memory configuration factors to specific Exchange 2007 server roles

The following chart can be used to assist in purchasing server hardware destined to be used for Exchange 2007 server roles. The goal of this chart is to provide minimum, recommended and recommended maximum configurations.

Minimum: The minimum processor/memory configuration suitable for specific Exchange 2007 server roles (also defined in System Requirements). Minimum hardware requirements must be met to receive Microsoft Product Support Services.

Recommended: This is the recommended processor/memory configuration for specific Exchange 2007 server roles. Recommended can be defined as "the best configuration based on price and performance." The recommended configuration also provides a balance between processor and memory capacity. The goal is to match the memory configuration to the processor configuration so the system will effectively utilize the processors without becoming bottlenecked on memory and vice versa.

Maximum Recommended: This is the maximum recommended processor/memory configuration for specific Exchange 2007 server roles. Maximum is defined as "the upper bound of viable processor/memory configurations for Exchange 2007 based on price and performance." Maximum is a guideline and not a "support criteria" and does not take in to account the resource requirements of 3^rd party applications. The recommended maximum may change over time based on price changes and technology advancements.

Processor Configuration Table for Exchange 2007

Edge Transport Role

Edge transport is extremely efficient in design and thus requires moderate processing power. Also, fault tolerant Edge Transport deployments will utilize multiple servers to provide redundancy. The Recommended configuration on 2 x Processor Cores takes this fault tolerant deployment consideration in to account. Large enterprises, with a large volume of inbound/outbound SMTP traffic will be able to utilize 4 x Processor Core servers to reduce aggregate Edge Transport server count. Processor utilization is based on several factors such as: message rate, average message size, number of agents enabled, anti-virus configuration, 3^rd party applications etc.

Hub Transport Role

The recommended configuration for Hub Transport is 4 x Processor Cores in deployments where Hub Transport is deployed along with several Mailbox servers and thousands of mailboxes. 8 x Processor Core servers can be efficiently utilized when message hygiene is configured on the Hub server (A/V, Anti-Spam). 1-2 x Processor Core configurations can be considered for deployments where there are not enough mailboxes (message traffic) to utilize a 4 x Processor Core configuration. Processor utilization is based on several factors such as: message rate, average message size, number of agents enabled, Forefront Mailbox Virus Scanning configuration, 3^rd party applications etc.

Client Access Server Role (CAS)

Exchange 2007 architecture has moved significant client specific functions from the Microsoft Exchange Store to the Client Access Server. Messages are now converted on the CAS server when accessed with non-MAPI clients (e.g. POP3/IMAP4). Also, Outlook Web Access rendering is now performed on the CAS server as opposed to the Mailbox Store in previous versions of Exchange. These architectural changes allow CAS to offload significant processing from the Mailbox role and to allow it to effectively utilize 4 x Processor Cores. Similar to Hub Transport, servers with 1-2 x Processor Cores can be utilized for CAS in deployments where there are not enough mailboxes/non-MAPI client traffic to utilize 4 x Processor Core servers.

Unified Messaging Role (UM)

The recommended configuration for the Unified Messaging role is 4 x Processor Cores. Multiple Cores are well utilized on the UM server for several architectural functions such as Voicemail WAV to WMA conversions. Similar to previous roles, 1-2 x Processor Core configurations may be utilized when the mailbox count/UM utilization does not necessitate 4 x Processor Core configurations.

Mailbox Role

The recommended configuration for the Mailbox role is based predominantly on mailbox count and user profile. A 4 x Processor Core server provides a good balance between price and performance and should be able to host several thousand mailboxes. Rule of thumb sizing for the Mailbox server role requires an understanding of the average client user profile. This profile can be collected using the Microsoft Exchange Server Profile Analyzer or with 3^rd Party tools/applications. The following table lists generic/common Outlook knowledge worker profiles:

There are several factors that go in to doing Mailbox server sizing for Exchange 2007 which are above and beyond the user type listed above. These include Exchange 2007 features such as Local Continuous Replication (LCR), Forefront Mailbox Virus Scanning, 3^rd Party applications, 3^rd Party mobile devices, and Microsoft Outlook client version/mode (Online vs Cached Exchange Mode etc.). Rule of thumb sizing used primarily for budgeting purposes can be accomplished by calculating that 1000 Average profile mailboxes will require 1 x Processor Cores. E.g. A 4000 Mailbox server with an Average usage profile can be estimated to require 4 x Processor Cores. A Heavy usage profile will effectively double the required processor cycles (or halve the number of users per processor core;500 Mailboxes/Processor Core). On the other hand, a 2000 Mailbox server with an Average profile can be estimated to require a 2 x Processor Core server. The maximum number of processor cores the Exchange 2007 Mailbox role will efficiently utilize is eight. Deploying Exchange 2007 Mailbox on servers with greater than eight cores will not provide significant scalability improvements.

***Concurrency: Concurrency is defined as the percentage of the total number of users on a server that are connected and using the server at a given peak period of time. Concurrency is difficult to measure since users may use multiple clients/devices and different versions of Outlook have various connection counts to the server. For a fully utilized server, concurrency is generally in the 75-80% range. The guidance in this article assumes this average concurrency profile.

Sizing additional processing capacity for Local Continuous Replication (LCR)

Local Continuous Replication (LCR) has all of the Exchange 2007 Mailbox role services as well as the Exchange 2007 Replication Service running on the same server. On an LCR Mailbox server, there is additional processing overhead generated from the Replication Service copying and playing in logs to the target database copy. This additional processing cost is roughly 20% and should be factored in when sizing LCR Mailbox servers.

Multi-Role (Mailbox, Hub, CAS)

The Multi-Role configuration has similar guidance and limitations as the Mailbox role. To accommodate CAS and Hub Transport utilization on a single server with the mailbox, reduce the 1000 Mailboxes/core calculation based on the Average client profile by 20% (800 Mailboxes/core) when performing rule of thumb sizing for Multi-Role servers. The maximum recommended processor core configuration is listed at 4 for the Multi-Role configuration to indirectly provide guidance on the maximum number of users recommended to be hosted in this scenario. Neither Clustered Continuous Replication (CCR) nor Single Copy Cluster (SCC) support hosting the Hub nor CAS server so a Multi-Role server has to be non-clustered by definition. It is a good idea to cluster Mailbox servers that host thousands of user to ensure patch management and server failures do not have a significant impact on up time. The more users hosted on a Mailbox server the more user "pain" is caused by server downtime. For this reason, the recommended maximum processor core configuration for the Multi-Role server is listed at 4. While the this configuration will perform well up to 8 processor cores, it is not recommended due to the availability concerns outlined above.

Memory Configuration Table for Exchange 2007

Once the number of processor cores have been estimated to be required per server role are understood; baseline memory recommendations can be applied. The following table illustrates the Minimum, Recommended and Maximum memory configurations for Exchange 2007 server roles.

Edge/Hub Transport Roles

The Edge and Hub Transport roles do not require substantial quantities of memory to perform well in optimal conditions. Generally, 1GB of RAM per processor core (2GB minimum total) is sufficient to handle all but the most demanding loads/scenarios. There is one significant memory factor that should be taken in to account for large deployments:

Large Queue Scenarios: Exchange 2007 Edge/Hub Transport servers are designed to handle scenarios where extremely large queues build up (e.g. 1 million messages in a single server queue). Edge/Hub Transport servers hold the queued message recipient information in memory to optimize the SMTP send and message retry operations. When sizing Edge/Hub Transport servers for large queue scenarios, use the following table to estimate the memory requirements:

The recommended maximum memory configuration of 16GB is based on the Edge/Hub Transport servers handling 1 million messages with an average number of recipients each. Most deployments will be optimally configured with the "Recommended" memory configuration of 1GB per processor core (2GB minimum total).

Client Access Server Role (CAS)

In general, memory utilization on CAS has a linear relationship with the number of client connections and the transaction rate. Based on the current recommended configuration for processor and memory, a CAS server will be balanced in terms of memory/processor utilization (will become processor bound at roughly the same point it becomes memory bound). For the majority of deployments, 4GB (1GB/core) is sufficient and recommended for CAS operations. Large scale deployments, which utilize RPC/HTTP (Outlook Anywhere) as the primary client access type; should consider 2GB/core or 8GB max recommended. This is because the Client Access Server only proxies Outlook client requests to the Mailbox server and the memory footprint per client connection is much more of a factor than the processor utilization per connection.

Mailbox Role

The memory configuration process for the Mailbox role is more involved than the other roles since the optimal memory configuration depends upon the mailbox count and the client profile (similar to estimating processor core requirements). Memory sizing for the Mailbox role is critical to reducing the I/O requirements of the server. The more memory you add to the Mailbox server, the less I/O will be generated by the Exchange databases. There is a point of diminishing returns; in which adding additional memory to the server may not be justified based on price/performance. Memory guidance outlined here takes this point of diminishing returns in to account based on current memory prices and performance metrics. Also, defining the memory configuration of the Exchange 2007 Mailbox server is required prior to defining the storage requirements/configuration. The following table can be used to assist in estimating the memory requirements of a given mailbox server with a given number of hosted mailboxes with a given profile type (taken from previous profile table).

Recommended Maximum Memory Configuration for Mailbox

Recent x64 based servers have the ability to scale up their memory configuration to 64GB and beyond. There are several reasons why Microsoft does not recommend maximum memory configurations for Mailbox that go beyond 32GB.

Cost: Based on current memory prices (specifically 4GB DIMMs), it is cost prohibitive to expand the physical memory capacity of a server beyond 32GB. Generally, the cost of physical RAM is linear up to 32GB; beyond this the cost trend is exponential. Beyond 32GB, for many configurations, it is less expensive to add disk drives as opposed to memory.

Non-Transactional I/O: The Mailbox server utilizes additional physical RAM by caching more data and thus reducing the database I/O footprint for transactional I/O (I/O that is generated by send/receive/client processing of email). There are several sources of non-transactional I/O generated on the Mailbox server. These include Online Maintenance (e.g. Online Defrag), Offline Maintenance (e.g. offline defrag, database repair operations), Backup/Restore operations, Mailbox Management Processes (e.g. Email Lifecycle Management (ELC)), All of these operations require database I/O to properly maintain and recover the server. Although Exchange 2007 has reduced transactional I/O significantly; adequate storage performance is still required for proper maintenance of the Mailbox server. For this reason, there is a point of diminishing returns when adding memory to the server. In general, the purpose of adding memory to the Exchange Mailbox server is to reduce the storage requirements (specifically performance) and thus storage cost. Due to non-transactional I/O requirements; the storage requirements of the system may not be significantly reduced by adding server memory beyond 32GB.

Cold State Operation: Cold state is defined as the state of the Mailbox server immediately following a server reboot or store.exe process restart. The Database Cache, which is used to cache database read/write operations, is small in size (or "cold") during this period so it has a significantly diminished ability to reduce read I/O operations. As the Mailbox server processes messages, the Database Cache Size grows which increases the effectiveness of the cache and subsequently reduces the I/O footprint of the server. The larger the physical memory size of the server the longer it takes the Database Cache size to reach its optimal size. If the storage is designed/sized for a server with a large amount of physical RAM (>32GB), and the I/O profile of the users assumes an optimal Database cache state (large/warm cache); then the client experience may be compromised due to insufficient disk performance during these “cold state” periods. Similar to the Non-Transactional I/O case; the storage subsystem requirement may be the same for a server that has been populated with 32GB of RAM as a server that has been populated with greater than 32GB of RAM.

While the Exchange 2007 Mailbox role will utilize memory greater than 32GB, for the reasons outlined above; 32GB is the maximum recommended memory config and is considered the point of diminishing returns in terms of both cost and performance.

Required Minimum Memory Configuration for Mailbox based on the number of Storage Groups

The maximum number of Storage Groups configurable in Exchange 2007 has been increased to 50 in the Enterprise Edition (up from 4 with Exchange 2003). This increase provides much greater flexibility in server/storage architecture, but the increase has a significant effect on the memory utilization of the Exchange 2007 Mailbox server so Storage Group count is now a factor in minimum memory configuration for Mailbox and Multi-Role servers. Increasing the number of Storage Groups primarily effects the Database Cache utilization of ESE (Extensible Storage Engine). The ESE Database Cache is used for both read and write activity. Due to the way Checkpointing works, adding a Storage Group effectively increases the amount of the Database Cache used for write activity. This has a positive impact of reducing database write I/O; but if too many Storage Groups are configured on a server with insufficient physical memory, the effectiveness of the database read cache may be reduced which may have an overall negative effect on the performance of the server. For this reason, minimum hardware requirements for Mailbox and Multi-Role uses the following table to provide specific minimum memory requirements based on Storage Group count configured on a per server basis.

*** This table includes the 2GB minimum memory requirement. Mailbox and Multi-Role Server configurations must meet the requirements outlined in the above table to receive Microsoft support.

The minimum physical memory requirements based on SG count closely match our recommendations on memory sizing based on mailbox count and profile (detailed above).

Example 1: A 4000 user Mailbox server with a heavy user profile would calculate out to 22GB of RAM (2048MB+ (4000*5MB)). Based on the above support requirements, the administrator will have the flexibility to use up to 44 Storage Groups. Additional RAM would be required to deploy greater than 44 Storage Groups based on the above supportability requirements.

Example 2: A 1000 user Mailbox server with a light user profile would calculate out to 4GB of RAM (2048MB+(1000*2MB)). Based on the above support requirements the administrator will have the flexibility to use up to 8 Storage Groups. Additional RAM would be required to deploy greater than 8 Storage Groups based on the above supportability requirements.

Memory Recommendations for Local Continuous Replication (LCR)

Local Continuous Replication (LCR) has all of the Exchange 2007 Mailbox role services as well as the Exchange 2007 Replication Service running on the same server. The Exchange 2007 Replication Service will work well on a LCR server based on the provided memory guidance but to ensure that the ESE Database Cache maintains optimal efficiency under LCR, it is recommended to provision an additional 1GB of physical RAM to Exchange Mailbox and Multi-Role servers (above and beyond the memory guidance listed above).

Multi-Role (Mailbox, Hub, CAS)

The Multi-Role configuration has similar guidance and limitations as the Mailbox role. To accommodate CAS and Hub Transport role on a single server with the Mailbox role, the recommended base memory configuration is 4GB as opposed to 2GB. Memory guidance based on mailbox count and profile is the same as the Mailbox role. The maximum recommended memory configuration is listed at 8GB for the Multi-Role configuration to indirectly provide guidance on the maximum number of users recommended to be hosted in this scenario. Neither Clustered Continuous Replication (CCR) nor Single Copy Cluster (SCC) support hosting the Hub nor CAS server so a Multi-Role server has to be non-clustered by definition. It is a good idea to cluster Mailbox servers that host thousands of user to ensure patch management and server failures do not have a significant impact on up time. The more users hosted on a Mailbox server the more user “pain” is caused by server downtime. For this reason, the recommended maximum memory configuration for the Multi-Role server is listed at 8GB. While more memory is supported in this configuration, it is not recommended due to the reason outlined above. The minimum requirements based on Storage Group count listed above apply to Multi-Role (includes Mailbox) server configurations.

Summary

With effective planning and an understanding of the basic processor and memory requirements for specific Exchange 2007 server roles, a balanced/cost effective topology can be easily attained.

- Matt Gossage

I search the Exchange Team Blog frequently to provide content for customers I work with as this site is full of great information on Exchange. I found a way to make the searches even easier with Internet Explorer 7 and wanted to share it.

Using IE7 since early in the beta, first on Windows XP SP2, then on Windows Vista I discovered the Search Provider feature located in the upper-right-hand corner of IE7.

I then figured out how to build a search provider for IE7 by creating it in the Windows Registry. I also made this easier by using .REG files so I could double-click and install the search provider.

You can do this even easier by going to the Add Search Providers to Internet Explorer 7 site and following the instructions to Create Your Own. You just need to enter a search in the upper-right hand corner of this blog for TEST. Here's the URL for the Microsoft Exchange Team Blog:

http://msexchangeteam.com/search/SearchResults.aspx?q=TEST

Then you copy the resulting URL to the clipboard and use the Create Your Own tool at the Add Search Providers to Internet Explorer 7 site, paste the URL into Step 3, give it a name in Step 4 and click the Install button.

Now, with two simple mouse clicks you can select the down arrow in the search provider field in the upper-right hand corner of IE7:

Then, change to The Microsoft Exchange Team Blog search provider from the search provider list.

Enter your search words and press the Enter key or click the Search icon (you do not have to be on the blog site itself for this to work).

Then receive the results:

It's that easy! Now try it yourself!

- Dan Kelley

Policies in Exchange are designed to enable flexible administration of large numbers of Exchange objects. A policy is a collection of configuration settings that can be applied to one or more Exchange objects of the same class. This blog post gives an overview of Exchange 2007 policies: E-mail Address Policy (EAP), Exchange ActiveSync mailbox policy, Unified Messaging (UM) mailbox policy, and managed folder mailbox policy. Policies available in Exchange 2003 that are removed or changed in Exchange 2007 are also covered.

E-mail Address Policy (EAP)

EAP defines the proxy addresses that are stamped onto recipient objects. In Exchange 2007, every EAP must link to an existing accepted domain object. This is required so that e-mails sent to e-mail addresses defined by the EAP can be routed by Exchange 2007 transport servers. The relationship between EAP and accepted domains in Exchange 2007 and is covered in my recent post Recipient Policies and Accepted Domains.

Manage E-mail Address Policies

In the Exchange Management Console, the E-mail Address Policies tab of the Hub Transport node under the Organization Configuration work center is the place to create and configure e-mail address policies. If multiple policies apply to the same recipients, the policy with the highest priority (the lower the priority number, the higher the priority) takes precedence over any matching policies with a lower priority.

The PowerShell tasks used to manage e-mail address policies are <verb>-EmailAddressPolicy.

How EAP Enforces E-mail Address for Associated Recipients

The E-Mail Addresses property page of a recipient in the console allows management of recipient e-mail addresses. You can select whether to automatically update the e-mail address for this recipient based on e-mail address policies by checking or/unchecking the "Automatically update ..." checkbox at the bottom of this property page.

If a recipient is configured to automatically update the e-mail addresses based on e-mail address policy, all primary e-mail addresses (default reply addresses) of e-mail address types will always be set from the e-mail address policy. If you try to edit the primary address to a different e-mail address, it will always revert to the one specified by the e-mail address policy. Which policies applying to a recipient are up to the filtering rules of the policies.

The PowerShell command line to configure a mailbox to automatically update the e-mail addresses based on EAP is:

Set-Mailbox <mailboxid> -EmailAddressPolicyEnabled:$True

The command line to configure automatic update of e-mail addresses based on EAP for another type of recipient is similar.

Removal of Recipient Update Services (RUS)

In Exchange 2003, RUS is used to update e-mail addresses for recipients. This service processes e-mail address policy in an asynchronous way, which can be unreliable and unpredictable. Exchange 2007 doesn't rely on RUS to update e-mail addresses any more, instead it uses a predictable, synchronous e-mail provisioning process. Once an e-mail address policy is changed, the e-mail addresses for all associated recipients are updated synchronously.

See Evan's Top Exchange 2003 Recipient Problems and how they're fixed in Exchange 2007 and Goodbye RUS posts for a more detailed cover of removal of RUS in Exchange 2007.

Exchange ActiveSync mailbox policy

With Exchange 2007, you'll be able to create multiple Exchange ActiveSync (EAS) mailbox policies to have more control for mobile deployments. Exchange 2003 SP2 first introduced EAS policies; however Exchange 2003 can only create only a single global policy which applies to all users not specifically excluded. Exchange 2007 EAS policies are per-user policies, so you can create as many policies as needed to meet your company's security requirements.

Manage EAS Policies

In the console, the Exchange ActiveSync Mailbox Policies tab of the Client Access node under the Organization Configuration work center is the place to create and configure EAS policies.

The PowerShell tasks for managing EAS policies are <verb>-ActiveSyncMailboxPolicy.

Apply an EAS policy to a Mailbox

Each mailbox can have zero or one ActiveSync mailbox policy applied. Below is the console GUI to associate an ActiveSync mailbox policy to a mailbox.

An example PowerShell command line to assign an EAS policy to a mailbox is:

Set-CASMailbox <mailboxid> -ActiveSyncMailboxPolicy (Get-ActiveSyncMailboxPolicy "Corporate Mobile Policy").Identity

Unified Messaging (UM) mailbox policy

UM is a brand new feature introduced in Exchange 2007. UM mailbox policies are required when you enable users for Unified Messaging, as these policies control the association between UM mailbox and UM dial plan. You can also use UM mailbox policy to apply a common set of policies or security settings (such as PIN policies, dialing restrictions, etc) to a collection of UM-enabled mailboxes.

Manage UM policies

In the console, the UM Mailbox Policies tab of the Unified Messaging node under the Organization Configuration work center is the place to create and configure UM mailbox policies.

The PowerShell tasks for managing UM policies are <verb>-UMMailboxPolicy.

Apply an UM policy To a Mailbox

When you enable a mailbox for UM through the Enable Unified Messaging wizard, a UM policy is required. Below is the console GUI to associate a UM mailbox policy to a mailbox.

The PowerShell command line to assign a UM mailbox to a mailbox is:

Enable-UMMailbox <mailboxid> -UMMailboxPolicy "dp1 Default Policy" -Extensions 12345

Or if the mailbox is already UM-enabled:

Set-UMMailbox <mailboxid> -UMMailboxPolicy "dp1 Default Policy"

Managed folder mailbox policy

Managed folder mailbox policies are used for messaging records management (MRM), a.k.a e-mail lifecycle (ELC), in Exchange 2007. Managed folder mailbox policies collect managed folders into logical groupings. When a managed folder mailbox policy is applied to a mailbox, the managed folders and their settings linked to the mailbox policy are applied to the mailbox in a single step.

A blog post Records Management in Exchange Server 2007 and Outlook 2007 in 5 Easy Steps covered specifically how Exchange 2007 can help with MRM.

Manage Managed Folder Mailbox Policies

In the console, the Managed Folder Mailbox Policies tab of the Mailbox node under the Organization Configuration work center is the place to create and configure managed folder mailbox policies.

The PowerShell tasks for managing managed folder mailbox policies are <verb>-ManagedFolderMailboxPolicy.

The PowerShell command line to assign a managed folder mailbox policy to a mailbox is:

Set-Mailbox <mailboxid> -ManagedFolderMailboxPolicy "Inbox folder policy"

Policies in Exchange 2003 That Are Removed or Changed

System Policy

This has been removed. Refer to an earlier post Gone but not forgotten for a more detailed explanation.

Mailbox Manager Recipient Policy

This has been removed. The mailbox manager recipient policy is one kind of recipient policies in Exchange 2003, which is gone in Exchange 2007. This concept is replaced by managed default/custom folder, managed content settings and managed folder mailbox policy concepts in Exchange 2007, which is covered in the previous managed folder mailbox policy section of this post.

E-mail Address Recipient Policy

Changed. E-mail address recipient policy in Exchange 2003 has been separated into EAP and Accepted Domain concepts in Exchange 2007 which was covered in the E-mail Address Policy (EAP) section of this post.

- Jared (Ji-Chao) Zhang

Overview

Software Quality Metrics (SQM, also known as the Microsoft Customer Experience Improvement Program) is a set of anonymous data that can be sent back to Microsoft for the purposes of understanding what features of a product our customers are using. By examining this data, product teams can make decisions on where to fund future work.

In Exchange, the way SQM data is collected is through the Exchange Best Practices Analyzer Tool (ExBPA). You must explicitly opt in to the Microsoft Customer Experience Improvement Program in order for this data to be sent. Some examples of data we transmit: total number of mailboxes in an organization, total servers with the mailbox role installed, how many calls a unified messaging server has processed, etc.

This post describes how to opt in to SQM through ExBPA and how to run a health check to generate the data.

Opting in to the Microsoft Customer Experience Improvement Program

ExBPA is installed along with Exchange 2007. To run, go to the Toolbox section of the Exchange Management Console and select the Exchange Best Practices Analyzer. A run is typically done on a workstation rather than an Exchange server, to avoid ExBPA from interfering with the server's performance. Also, make sure the machine you are running on has Internet access so that SQM data can be transmitted back to Microsoft.

If this is the first time you have run ExBPA on a particular machine, the first screen you will see should look like this:

Note that SQM is neither opted in nor out by default. You will need to choose one before you can proceed with an ExBPA run. Click on the "Join the Microsoft Customer Experience Program" radio button to opt in. You should then click on "Check for updates now" to pull down the latest set of rules and data points.

If you have already run ExBPA at least once on a machine, you will not see the screen shown above when you first start. To bring it up, click on the "Updates and Customer Feedback" link at the bottom of the left panel. Make sure SQM is opted in as described above.

Running an ExBPA Health Check

Now that you have enabled SQM, you can go ahead and run a health check on your organization (there are lots of good reasons to run this even if you haven't enabled SQM – it will report on any configuration issues it finds with your deployment).

Running a health check is very straightforward. First, click on "Connect to Active Directory" on the left panel (or on the main panel if the Welcome screen is currently being shown). This will bring up a screen that looks like this:

You can either leave the default AD server name or set it to something explicit (you'd only likely do this if you were in a different domain than the Exchange organization, or if you knew that the particular server chosen was very busy and there was a better alternative). If your currently logged on credentials are sufficient to access the Exchange and AD servers, you can proceed immediately by clicking on "Connect to the Active Directory server." If not, click on "Show advanced login options" and enter new credentials (you can enter separate credentials for AD server access and for Exchange server access). After this, you can proceed as described above.

You will next see the Scan Options screen:

You should enter a meaningful label at the top, but everything else can be left defaulted. You can then click "Start Scanning" and it's off and running. An ExBPA scan may take anywhere from a few minutes to a few hours depending on the size of the organization and the network speed.

After the run completes, the SQM data will be automatically transmitted. Nothing more needs to be done. We would appreciate if you could take a few minutes to do this!

- Jon Avner

Although they are very similar, because the Edge Transport and Hub Transport servers were designed specifically for the role that they play, they have different default settings. For example, the Edge Transport role is configured by default to accept Internet mail, whereas the Hub Transport role is configured to be as secure as possible and does not accept mail from unauthenticated (un-trusted) sources. Because of this, we often get asked if there are options for the customer that cannot or chooses not to run an Edge server.

A brief word about putting an Exchange server directly on the Internet

Historically, Exchange servers should not be directly on the Internet – in no small part because Exchange needs direct access to the Active Directory. In the case of the Client Access Server protocols (HTTPS, IMAP, POP), the recommendation is for the server to sit behind a reverse proxy/port forwarding firewall like ISA that can detect and block attacks. In the case of SMTP, the suggested solution is Edge Transport role, because that has all the functionality of Exchange (unlike other active SMTP filtering solutions) but still has the isolation options of being completely disjoined from the rest of the forest. Whether you chose the Edge Transport or Hub Transport role to receive Internet mail, the server can and should be placed behind a firewall, though active SMTP filtering is not required.

For the customers with only one server, it is suggested to consider a hygiene service such as Exchange Hosted Services (EHS) or perhaps the ISP can offer such a service.

That said, a common configuration for a single Exchange server is to have Exchange sitting directly behind a NAT firewall or reverse proxy like ISA. There is obviously a certain amount of additional risk associated with this approach, but for many smaller customers, the risk is acceptable.

For more information on this topic and the various options available, see "How to Configure Connectors for Internet Mail Flow".

What features will I be missing by doing this?

The five main feature sets that will be missing are:

• Edge can be deployed in a perimeter network; specifically, it does not need to be domain joined (but can be), which provides greater security. Hub transport requires a connection to Active Directory.
• Isolation – in particular, the SMTP stream from the Internet tends to be full of spam – over 70% of traffic in most cases. By separating this from your internal traffic, you can insure that internal servers are not busy processing and filtering spam. Internal servers are then free to perform routing, compliance, and other mailbox to mailbox operations. This is particularly important if internal email is mission critical.
• Edge Transport rules agent – instead you get the Hub Transport rules agent. Hub Transport rules are largely for compliance whereas Edge Transport rules are largely for hygiene. For more information about this topic, see "Overview of Transport Rules".
• Attachment filter protocol agent – the hub transport rules do have some attachment options, but the ability to scan the incoming MIME stream for malicious attachment types and reject at the protocol layer is not one of those features; this agent is not installed or supported on hub at the present time, however, anti-virus products like Microsoft Forefront often provide this functionality.
• Address re-write agent – this agent generally is used by larger corporations that will have Edge servers and/or additional software that can perform this functionality.

Receive connector configuration

While there are seemingly limitless ways to configure your receive connectors, I am suggesting the route that involves the least number of steps and can be done completely within the Exchange Management Console. Go here for more information about receive connectors.

To find receive connectors in the Exchange Management Console, navigate to Server Configuration -> Hub Transport. Then select your server and you'll see the Receive Connectors tab below.

The "Default" receive connector on Hub is configured for other Exchange servers to authenticate, but it does not accept anonymous email by default. The easiest way to address this is to add the "Anonymous users" permissions group to this connector:

Note: In Exchange Server 2007 Beta 2, this step had to be performed from the Exchange Management Shell.

If you fail to do this step, people that send you email will probably get an NDR with the error "530 5.7.1 Client was not authenticated."

Accepted domains

By default, your new Exchange 2007 servers will only accept email destined to the Windows domain that the server was a member of. In order to accept email destined to your external SMTP domain, you will probably need to create a new accepted domain. This is done in the Exchange Management Console under Organization Configuration -> Hub Transport, then select Accepted Domains.

If you fail to perform this step, people who send email directly to you will probably get an NDR with the error "550 5.7.1 Unable to relay."

Send connector configuration

In order to send email, you need to configure a send connector. This is done in the Exchange Management Console under Organization Configuration -> Hub Transport, then select Send Connectors.

The simplest method is to create one of type "Internet":

If you've installed Exchange 2007 into an existing environment with 2003, then you probably already have a Send Connector (SMTP Connector) and you just need to verify the settings. If the connector is on your 2003 server, you can only view the settings from the Exchange 2007 Management Console. All changes will need to be made through from the Exchange 2003 System Manager (look for "SMTP Connectors"). For example, if you only have a connector on the 2003 machine, then all outbound mail will go through the 2003 server. If you have one on the 2003 and one on the 2007 server, then mail will go through the closest connector. If you delete the one on 2003 and have one on the 2007 server, then all outgoing mail will pass through the 2007 server.

In order for all outbound mail to pass through the connector, the address space of the connector should be * (type "smtp"):

The network tab allows you to specify whether you'll use a smart host (perhaps an SMTP server at your ISP) to relay your messages, or if you'll handle the delivery yourself (using DNS).

The source server specifies which Exchange server or servers in your organization will be responsible for sending Internet email.

Setting up an SPF record for your domain is also a good idea, especially if you relay messages off of your ISP.

Anti-spam configuration

Because Hub Transport servers only need to perform anti-spam functions when there is no Edge Transport server to perform this function, this is another feature that is not enabled by default. Adding this functionality to your Hub Transport servers is a pretty simple process. First, launch the Exchange Management Shell. In the Scripts folder that was created, you will find a PowerShell script to install the Anti-spam agents. After you run this command, you will need to restart your transport service, and restart the Exchange Management Console.

Once you complete these steps, you will see the Anti-spam tab enabled in the Exchange Management Console.

Please note that if you previously had any Exchange 2003 settings for anti-spam, you will need to migrate your settings over to Exchange 2007.

Useful customizations

Because your server is sitting directly on the Internet, you may want to change the advertised FQDN that is sent in HELO/EHLO commands in SMTP. The UI for both send and receive connectors allows you to configure this.

Because you will not be using Edge Server, you have no need for the Microsoft Exchange EdgeSync service. You can set this service to disabled to prevent it from starting and using system resources.

Final steps

The final step is to 1) make sure that your MX record is correct and 2) that your firewall is letting the connection inbound to port 25. I can't tell you exactly what to do, but usually the easiest method if you already have a mail server is to either reuse that server's IP, or update the firewall rule to point to the new Exchange 2007 server's internal IP.

Use the Mail Flow Analyzer to assist you with troubleshooting issues that may arise. Additionally, there are at least two web sites that can help you diagnose DNS and SMTP receive problems:

• http://www.checkdns.net
• http://www.dnsreport.com

- Scott Landry

The e-mail address recipient policy concept in Exchange 2003 is separated into two concepts in Exchange 2007: E-mail Address Policies (EAP) and Accepted Domains. This blog post covers the relationship of EAP and accepted domains in Exchange 2007 and how the functionality of e-mail address recipient policies in Exchange 2003 maps to EAP and Accepted Domains in Exchange 2007.

Relationship of EAP and Accepted Domains in Exchange 2007

EAP defines the e-mail proxy addresses that are stamped onto recipient objects. Accepted domains define the SMTP namespaces for which an Exchange organization routes e-mail. Any accepted domain added to the system can be linked to an EAP so that it will generate recipient e-mail addresses for this accepted domain. And every EAP must link to an existing accepted domain so that e-mails sent to e-mail addresses that are defined by the EAP can be routed by Exchange 2007 transport servers.

In Exchange 2007, authoritative and relay domains are managed together as accepted domains. In Exchange Management Console, the Accepted Domains tab of Hub Transport node under Organization Configuration work center is used to manage all accepted domains defined in the organization.

E-Mail Address Policy wizard provides the console GUI used to select an accepted domain for which a new e-mail address policy applies. Only accepted domains defined in the Exchange 2007 organization can be added to the list in the EAP.

PowerShell cmdlets can also be used to manage accepted domains and e-mail address policy.

E-Mail Address Recipient Policies in Exchange 2003

In Exchange 2003, there are two kinds of recipient policies: e-mail address recipient policies and mailbox manager recipient policies. Mailbox manager recipient policies are not the focus of this blog post and will not be discussed further. E-mail address recipient policies combined the concepts of EAP and accepted domains in Exchange 2007. Below is the ESM GUI to configure a domain to be stamped with recipient e-mail addresses. Notice that there is an option (highlighted with a red rectangle) to set this domain as an authoritative domain or not – the accepted-as-authoritative-domain equivalent in Exchange 2003.

There are three problems with this combined e-mail address recipient policy concept:

1. If a domain is specified for an e-mail address recipient policy but not set as an authoritative domain, e-mails sent to recipients with e-mail addresses defined by the policy will not be routed within the Exchange organization for this domain. This is an invalid scenario, but the ESM GUI doesn’t block this.
2. The authoritative domain concept is hidden under the e-mail address recipient policy GUI, which is not very discoverable.
3. Relay domains are managed through Connector GUI; a completely different location than authoritative domain management, which increases managing complexity. Below is the snapshot of managing relay domains through Connectors ESM GUI.

For these reasons, the e-mail address recipient policy concept in Exchange 2003 is separated into EAP and Accepted Domains for better discoverability and management in Exchange 2007.

- Jared Zhang

Summary

A cumulative security update has been recently released for Internet Explorer 6 for Microsoft Windows XP Service Pack 2 and Microsoft Windows Server 2003 Service Pack 1. This update changes the way in which Internet Explorer handles some Web pages that use ActiveX controls and Java applets. As we have seen some questions around this, we wanted to cover them here.

The below document describes the changes that this Update introduces, how it affects Outlook Web Access and how we can mitigate the effects of this change.

What has changed and why

A Cumulative security update for Internet Explorer (MS06-013) introduced a change in the way IE handles Web pages that use ActiveX controls and Java applets.

After you install this update, you cannot interact with ActiveX controls from certain Web pages until these controls are enabled. This change was deemed necessary for security reasons to avoid the remote code execution. Outlook Web Access is affected by this change as follows:

Symptoms related to Exchange

We see red X in the body of Outlook Web Access (OWA) email, when we use OWA with IE 7 (Windows Vista). The Red X error will not allow to compose a new message, reply to an email, or create a new task, note, journal entry, or an appointment. It may also not allow change any configuration in the Outlook Web Access options folder. The body of the message is grayed out, or has a Red X as below:

On a computer on which you have installed update 912945, you must first click one time in the compose frame in Outlook Web Access before you edit text. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

912945: (http://support.microsoft.com/kb/912945/) Internet Explorer ActiveX update

On a computer on which you have installed security update 912812 that is described in security bulletin MS06-013, you must first click one time in the compose frame in Outlook Web Access to activate the edit control.

Impact of the update when installed on a desktop

Installing the Update 912945 or 912812 on a computer which uses Internet Explorer 6 causes Internet Explorer to now prompt before the control is enabled and used.

Thus Internet Explorer 6 with this update installed will now prompt that you click one time on ActiveX control to enable the edit control.

Example Picture:

Impact on OWA

Since Outlook Web Access uses ActiveX controls heavily this could mean clicking to enable a control whenever we click on Compose a new e-mail message , Reply to an e-mail message, Create a new contact, or appointment to name a Few.

Example Picture:

Windows Vista

This also affects OWA when accessed from Windows Vista as Windows Vista no longer includes support for the ActiveX control that is used for HTML editing in Outlook Web Access.

ActiveX controls are unsafe for IE users who turn on the browser's ability to download and activate ActiveX controls within a web page. The problems occur when a user surfs to a non-trusted web page and that web page contains a malicious ActiveX control. This is a very common means of distributing spyware; the easiest way to avoid it is to not install ActiveX controls from non trusted sites. This is the reason why ActiveX control is eliminated from IE 7.

Solution

Exchange 2000/2003:

On an Exchange 2000/2003 server installing update 911829 on the Exchange server enables a new editor for Internet Explorer. The new editor uses an Internet Explorer "iframe" instead of an ActiveX control. Thus after you apply update 911829, you are not required to first click to enable a control in the compose frame of Outlook Web Access before you edit text.

In Case of other websites which use ActiveX:

If you are a Web site owner, you can rewrite your Web pages so that users are never presented with a tooltip or a dialog box.

The following MSDN link gives us how.

http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/activating_activex.asp

Compatibility Patch:

A compatibility patch that will disable the behavior of the Internet Explorer ActiveX update has also been released. (Update 917425) Note that this patch is temporary, and will only apply to KB 912812. This IE compatibility patch will not be available for future security updates. 

Pre - Internet Explorer 6

Since this update is currently released for Internet Explorer 6 only this would not cause any behavior change when a pre-Internet Explorer 6 browser is used.

Additional Reading

http://support.microsoft.com/kb/912945

http://support.microsoft.com/kb/911829

http://support.microsoft.com/kb/917425

While at issues surrounding Internet Explorer and OWA, you might want to also check our previous post on Exchange 2003 SP2 SMIME update released (KB 924334) - resolves compatibility with IE 7.

- Manoj Dhadwal

Exchange Server 2007 introduces a new mechanism for distributing Offline Address Books (OAB) that doesn't require Public Folders. It instead uses HTTP(S) and the Background Intelligent Transfer Service (BITS). There are several potential advantages of the new distribution mechanism including supporting more concurrent clients, reduced bandwidth usage, and more control over the distribution points. It is important to note that the new distribution mechanism requires Outlook 2007, but you can always choose to use both Public Folder Distribution and Web Based Distribution of OABs. That way, older clients can still access their OABs using Public Folders while Outlook 2007 clients can take advantage of the enhanced functionality.

The new web-based OAB distribution process depends on several components working together and without one of them will not function properly:

• OABGen – this service runs on the OAB Generation server to create the OAB. This must be an Exchange 2007 Mailbox server to support OAB Distribution
• Exchange File Distribution Service – this service runs on CAS servers and is responsible to getting the OAB content from the OABGen server.
• OAB Virtual Directory – This is an IIS virtual directory on a CAS server where the OAB is downloaded from.
• Autodiscover – Autodiscover runs on a CAS server and handles returning the correct OAB URL for a given client connection.

I think a few examples are in order to fully understand what is happening at a high level. The following diagram shows the topology which will be used for the examples. The assumption here is that all users have the same OAB and that OAB is distributed to all CAS servers.

Before a user even connects, the following happens:

1) OAB is generated on one of the mailbox servers in London

2) The Exchange File Distribution Service on each of the CAS Servers in London copies the new OAB Files from the OAB Generation Server in London

3) The Exchange File Distribution Service on the CAS server in Sao Paulo wakes up and copies the files over the slow link from the OAB Generation Server in London. This could take a while depending on the speed of the slow link. The new OAB is not made available until it is completely copied and verified

Note: Not all CAS servers will download the new OAB at the exact same time. There is a Poll Interval (default 8 hours) which starts the copying if there are new files. The first poll happens when the Exchange File Distribution Service starts, so the exact time a server polls will be different on each CAS server unless they all started up at the same time.

Once all of the CAS servers have the OAB, there are several user download scenarios:

User A:

4) Outlook Connects to the Autodiscover service to get the closest OAB distribution URL

5) Autodiscover returns the URL to one of the CAS servers in London

6) Outlook connects with BITS to the URL autodiscover provided and downloads the OAB

User B:

4) Outlook connects to the Autodiscover service to get the closes OAB Distribution URL

5) Autodiscover returns the URL to the CAS server in Sao Paulo

6) Outlook connects with BITS to the URL autodiscover provided and downloads the OAB

User B's mailbox resides in the London site since there are no mailbox servers in the Sao Paulo office, but his OAB will be downloaded from the closest CAS server.

User C:

4) Outlook connect to the Autodiscover service to get the closest OAB Distribution URL

5) Autodiscover returns the URL to one of the CAS servers in London

6) Autodiscover then finds a CAS server in the same site as the Mailbox Server in step 5

7) Outlook connects with BITS to the URL autodiscover provided and downloads the OAB

For any Internet user, the system has no idea where the closest CAS server is, so it defaults to a CAS server close to their mailbox server.

Each CAS server can handle a large number of concurrent connections since the download is happening via BITS and is being sent in small chunks at a time. Much of the bandwidth savings comes from only copying an OAB to a remote site once and then having clients at that site automatically download their OAB from there rather than using the site-link.

The OAB Virtual Directory supports direct connection as well as connections through ISA server. However, the BITS client does not support self-signed certificates so by default, OAB distribution points are created to use HTTP. You can enable SSL support if you provide a fully trusted certificate in IIS.

- Jim Edelen

Yesterday afternoon, I was trying to send a large video of my new born baby to my mom through Exchange Server 2007 Outlook Web Access (OWA). And when I tried to upload the video, OWA would not let me do so. Darn it - cannot even share my baby's first shower with my mother. And then I realized - hey, didn't I write some code to prevent such uploads?

Now, you might say that sending my baby's video does not exactly constitute the best use of company resources but I can think of a lot of Administrators that might want to have control over attachment size in OWA.

If you are an administrator of an Exchange Server of your organization, read on...

By default, Exchange 2007 OWA will let you send attachments of up to 30 MB in size. Depending on your situation, you might want to either increase or decrease this number as we have a mechanism by which you can change the default upload limits of file attachments in OWA.

For example: in order to send attachments which are 50 MB or larger:

1. You need to set the MaxRequestLength in web.config to a value larger than 50 MB. The MaxRequestLength in web.config is an ASP.NET setting that prevents requests larger than a certain length which was added to prevent DOS attacks. It is set to 30 MB by default and needs to be increased in order to send attachments larger than 30 MB. This could also be decreased to enforce a lower limit.

2. You need to increase the MaxSubmitMessageSize which is a readonly Mailbox property (MaxSubmitMessageSize = 0x666D0003) and this is where we are getting the 10 MB limit from.

This is read from the following places:

1. First read from Mailbox object of the user itself
2.  if not found as denoted by "unlimited", Transport Settings Container
3.  if not found as denoted by "unlimited", from Org Container (default read from Org Container)

In order to set the value, use the following tasks in the Exchange Management Shell:

1. set-transportconfig and then set MaxSendSize (this is in KBs) to 51200 for 50 MB attachments. This will set it for all users

Or

2. set-mailbox and set the MaxSendSize (this is in KBs) to 51200 for 50 MB attachments for a specific set of users.

Once you set either, you need to recycle store or not access the mailbox for about 15-20 minutes (to let store cache expire) in order for the size change to have affect. Also, the property is stored in AD and subject to replication delays.

One more thing that you need to be aware of (sorry, the list just goes on):

We have a Request timeout of 60 minutes for any attachment upload request or attachment download (in OWA Basic and Premium). So, if you are trying to upload a 50MB attachment over a 56Kbps link, you will time out and get a HttpWebException (e.g., the max upload is about 25 MB over a 56 Kbps link).

So, to summarize, there are two keys to send a large attachment:

1. Modify ASP.NET web.config settings.

2. Modify the MaxSendSize using either the set-TransportConfig (for all users) or Set-Mailbox for individual users.

And you need to

3. Make sure the total upload time will be less than 60 minutes (based on your size and the speed of your network link)

The web.config change is immediate but the MaxSendSize change takes time, due to caching policy (Mailbox cache, DSAccess delays, and replication delays).

Examples:

Web.Config change

By default, web.config under OWA Vdir (Microsoft\Exchange Server\ClientAccess\Owa) will have the following entry (by default, the max request size is approximately 30MB):

<system.web>

<httpRuntime maxRequestLength="30000" />

....

</system.web>

Change <httpRuntime maxRequestLength="30000" /> to <httpRuntime maxRequestLength="X" /> where X is the desired value in KBs. So, for 50MB, X will be approximately 50000.

Change per-user message size limit

Go to Exchange Management Shell, and type the following command:

Set-mailbox -id:"username" -MaxSendSize:50000

Where "username" is the mailbox identity. This will set the maximum message send limit to approximately 50 MB. You will need to restart store to see the effect immediately.

Change all-user message size limit

Go to Exchange Management Shell, and type the following command:

Set-transportconfig -MaxSendSize: 50000

This will set the maximum message send limit to approximately 50 MB. You will need to restart store to see the effect immediately.

- Raj Mukherjee

As many of you know, there will be a change next year in the transition dates for US daylight saving time. I won't go into all the gory details here, but if you want them follow this link http://www.microsoft.com/windows/timezone/dst2007.mspx This site will be updated to provide all the latest information about daylight saving time, including updates from Microsoft products affected by daylight saving time, as well as links to KB articles when they are available.

The Exchange team, along with Windows and Office have been giving this a lot of attention. We will be providing, free of charge, a solution for Exchange products in mainstream support. This solution will consist of changes in CDO to support these new dates as well as rebasing tool for calendar items that are already existent in users calendars. This rebasing tool is a server side tool. There will also be a client side tool available from Outlook. For products that are no longer under Mainstream support, these non-security updates will only be offered to customers that have an Extended Hotfix Agreement. For more information on the current support status of your Microsoft products and the Support Lifecycle Policy, please visit http://support.microsoft.com/lifecycle.

- Elizabeth Scott

After the success of Microsoft Exchange Server 2003, the Microsoft Exchange team was pondering what the next-generation Exchange Server should look like. We had several high-level goals, which we won't go into in this blog, but let's look at a few specific details that motivated us to redesign for Exchange 2007:

• Separation of server roles
  • Customers liked the idea of Exchange playing different server roles. For example, it was easier for administrators to maintain a Mailbox server role and a Transport server role separately. The separation was good for introducing new scenarios such as Unified Messaging and for building robust components.
• We wanted to create the first ever Microsoft Edge Transport server
  • Microsoft Exchange decided to introduce a new stand-alone server role in the perimeter network and to fulfill our customers' needs in that area. To achieve this, we had to design a unique gateway management model that isolates servers (active directory) in the perimeter network from the rest of the organization. It made sense to redesign instead of change Exchange 2003 behavior to achieve this goal.
• Efficient routing
  • For some time, we'd been thinking about how to change the underlying routing concept so that it's easy for customers to deploy Microsoft Exchange. The decision was made to move to an Active Directory-based routing concept instead of a unique Exchange routing group concept. Also, we wanted to figure out how to remove the link state concept to achieve robust server-to-server mail delivery. Redesigning helped give our architects the freedom to explore this area.
• A better extensibility model
  • With our customers' ever-growing need to extend the Microsoft Exchange platform, it was apparent that we needed to provide an agile and rock-solid extensibility layer. Redesign would empower agent developers
• Extraction from the Microsoft Windows code base
  • We didn't want our customers to have any protocol prerequisites, such as Internet Information Services (IIS), to installing Microsoft Exchange, and we knew that maintaining two SMTP code bases was expensive for us. The redesign helped Microsoft Exchange eliminate the IIS dependency from the SMTP architecture.
• In-house benefits
  • This redesign helped us achieve a much cleaner infrastructure to support new initiatives like the Trustworthy Messaging and Messaging Policy.
• Managed code for better security
  • As we made the redesign, the Microsoft Exchange team decided to take an additional step to use managed code. This provides better security against buffer overflow type issues and also enhances Microsoft Exchange developers' long-term productivity.

- Agnita Pandian

We get the following questions quite often:

What will be the difference between Standard and Enterprise versions of Exchange 2007?

What about CALs (Client Access Licenses)?

And the answers are on this page.

- Nino Bilic