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

A little while ago we posted about a little swag giveaway we wanted to do: see here and here for more details.

The wait is over. We know the suspense has been killing you!

Out of many excellent submissions (thank you!!) and with the help of highly sophisticated methods and complicated algorithms, the panel of judges (KC and Nino) produced their favorites. It was a close race!

Without further ado, the favorites were:

Grand Prize: Alex Zammit

First prize: Luke Edson

Second prize: Jeff Guillet

Honorable mention: Jeremy Reichman and Russ Kaufman

Congratulations! You will be receiving your swag packages in the mail!

• We chose Alex because of his continuous involvement in our Exchange newsgroups, where he helped others in multiple different cases. Additionally, he is keeping and updating a site where he shares different areas of the product with others. Great job!
• Luke was chosen because of his helpful replies on forums that he sent us links to. Looking around, he is definitely very active there!
• Jeff was chosen because of multiple helpful posts and great follow-up in our own Exchange newsgroups.
• Jeremy was chosen because of his active involvement in several different sites, covering a lot of Entourage questions, like this one for example.
• Russ was chosen because of work that he put into explaining and helping people with clustering and Exchange. Check this site for more info.

Thank you all for sending us your "proofs" - we had a good time checking them out. It is easy to see that Exchange community is quite active and helpful! Keep on helping!

- The Exchange Team

I wanted to draw some attention to this article as I think it is very cool as it shows how different analyzer tools have impacted you, our customers, and us in Support Services, when helping you.

Ed Beck wrote the article titled Exchange Analyzer Tools Success Stories, check it out! If you have any sort of feedback on those tools - we'll take it here too!

- Nino Bilic

As discussed in the earlier blog post introducing the new Exchange 2007 console, the Exchange Management Console GUI has been completely redesigned in Exchange 2007. While redesigning the Exchange Management Console for Exchange 2007, we used specific ground rules to help guide what features and settings should be exposed in the console and how the console itself should be built. These guidelines allowed us to ensure that we had designed a rich, functional tool that wasn't overwhelming and complex. It also ensured a console where additional feature GUI could be added to respond more effectively to customer requests.

Exchange 2007 GUI Console Goals and Ground Rules

To meet these goals, we developed the following ground rules and reasoning:

1. Rewrite our Exchange management console GUI to consume cmdlets directly. This means that the GUI shares business logic with the cmdlets (reuses the existing cmdlet business logic, really) and so we can easily add additional GUI in later service packs and releases simply by building on existing cmdlets.
   Note: In previous releases GUI elements had to use embeded business logic which translated to much more time and difficulty in adding GUI. These complications in adding GUI after the initial product release often led to configuration settings being exposed via registry keys or AD attributes that required KBs to be written to explain how to use them.
2. The most common features & settings used by most of our customers should always be exposed in the console.
   Note: In the past, Exchange 2003/2000, this hasn't been the case. For example, OWA administrators had to download a tool to manage very common settings.

Naturally, when moving from Exchange 2003 to the Exchange 2007 console using the above ground rules, there have been changes in what is exposed in the console. Those changes have led to some features being removed from the console GUI. The reasons for removing some specific GUI generally fall into one of the three following categories:

1. Feature was an advanced scenario, not commonly used by most customers and thus added to complexity and confusion (and clutter) in the GUI.
   Note: In previous versions of Exchange, features not visible in the GUI were frequently not available through any administrative interface. In Exchange 2007, we have a great mitigation for features not exposed in the console GUI - the Exchange management shell!! The shell provides rich error handling, validation, and discoverability for configuration settings - a feature not found in registry editor or ADSIEdit!
2. Feature was removed from Exchange 2007 entirely
3. Feature or setting was replaced by a better solution in Exchange 2007 - for instance it works out of the box without requiring the previously complex configuration.

Exchange 2007 GUI Result

Based on these guidelines, we did an evaluation of all GUI available in Exchange 2003 and also took into consideration any GUI required for new Exchange 2007 features. Then we made some hard choices on what belonged in the new GUI console for Exchange 2007 and where these should be placed. The surprising outcome was that only a handful of features are completely removed from the GUI, and there's actually more (quantity) GUI exposed in Exchange 2007 than there was in Exchange 2003.

Think of it a bit like cleaning out your garage. When you start out, it's a huge mess and there's no room anywhere to hold even the stuff you've already got. But by the time you've reorganized everything more efficiently, you find there's suddenly room to hold the car again!

The table below lists the various GUI features that were removed for Exchange 2007 RTM. Please have a look through the list and let us know your opinion on the decisions we made. In particular, we'd love to know if you think we missed anything critical from Exchange 2003 GUI or if the mitigations seem insufficient to you.

Did we get it right?

If you've made it all the way through that table, you're a trooper and we thank you! We've done lots of usability testing around the new Exchange 2007 console and the use of various Exchange 2007 features, but there's sure to be some folks who disagree with one or more of the items in the list above.

That's where you come in! Now that we have developed a much more flexible GUI architecture (ie - built on cmdlet business logic), it's far more possible than in previous versions of Exchange to correct problems in the GUI or to add in necessary GUI after the initial release of the product.

We'd love to hear from you if there are features you believe are missing from the GUI that should be there. It's our goal to keep the GUI simple and uncluttered - following the ground rules at the top of this blog post, but we definitely want to make sure we haven't overlooked some critical GUI features. Please let us know what you think!

- Evan Dodds and Amanda Langowski

There is a lot of emphasis on Exchange database backups. As a result most Exchange administrators plan regular backups with considerations for their specific environment. In the process of developing a backup solution, Exchange administrators have to answer multitude of questions: Shall I protect my databases with daily Full backups, or weekly Full complemented with daily Incrementals? Shall I use VSS technology with hardware clones? Shall I include multiple Storage Groups in a single backup set? How about the IO/CPU impact? Is there enough network bandwidth to complete backups within nightly backup window? Where shall I store backups? How often should I retire the backup media? How do I monitor backups? ...
 
Successful backups are all goodness and a must have, but do you know if your backups are good enough to restore, well at least good enough to bet your job on it?   One of the horror stories I remember hearing from PSS was an Exchange administrator thinking backups were succeeding daily came to realize the good backups were all overwritten by bad ones when excessive database corruptions finally took his database offline. There was no hope of restoring from backups, and repair was not an option either. Granted a good monitoring solution (and an administrator paying attention to monitoring reports) can go a long way, but unlike good wine backups don't get better with age. A restore process that was perfect six months ago can fail to work due to changes on the backup product, changes in configuration, changes in the process, or a simple change of personnel in charge of the restore.
 
Just like you schedule regular backups, you should also schedule regular testing of your restore procedures. I am not asking you to restore all your backups all the time, neither am I telling you to restore some of your backups some of the time, what I am advising is "to restore some of your backups all the time".  When it comes to being prepared for database failures, running weekly or biweekly restores to a Recovery Storage Group is a small step for an administrator but a giant step for your users' precious data.
 
Be prepared with backups, and don't be afraid to use them.

- Ayla Kol