We've just finished our 6 part series of webcasts on six key topics that developers need to know about as they start planning for moving their applications to Exchange 2010.  Those webcasts are now available as on-demand webcasts below, check them out today!  If you'd like a bit more human contact than these webcasts, then come join us at TechEd in Germany or Exchange Connections in Las Vegas next week; or the Microsoft Professional Developers Conference in LA November 17-19^th where we'll have great Exchange 2010 Web Services sessions and program managers from the Exchange Web Services team there to answer your questions and get your applications Exchange 2010-ready.

View the webcast now- Exchange Server 2010 Development (Part 1 of 6): Migrating Applications to Exchange Web Services

View the webcast now - Exchange Server 2010 Development (Part 2 of 6): A Deep Dive into Using Autodiscover Service in Exchange Web Services

View the webcast now - Exchange Server 2010 Development (Part 3 of 6): A Deep Dive into Impersonation and Delegation in Exchange Web Services

View the webcase now - Exchange Server 2010 Development (Part 4 of 6): A Deep Dive into Exchange Web Services Notifications (Push/Pull)

View the webcast now - Exchange Server 2010 Development (Part 5 of 6): A Deep Dive into the Exchange Web Services Managed API

View the webcast now - Exchange Server 2010 Development (Part 6 of 6): Best Practices for Building Scalable Exchange Server Applications

- Jason Henderson

I had a chance to go on the road and talk to a few of our Exchange 2010 early adopter customers. My first stop was in Clearfield, Utah where I met up with the folks at Lifetime Products. Lifetime Products is an early adopter of E2010, and appreciates the concept of a unified Inbox-and related cost savings. 

Check out the video:

CIO Magazine also thinks Lifetime Product's story is pretty compelling. Check it out here.

It was great chatting with the folks at Lifetime. As you heard, they are really excited about all the new features in Exchange 2010. I'll be back soon with more great customer videos.

-- Crystal Flores

We always talk about listening to customers and sometimes this is written off by many as 'marketing speak'.  In fact, we do take feedback seriously and no input is more important to our engineering processes than your voice.

Earlier this year we made a decision in one direction, and due to the feedback we have received on this blog and elsewhere, we have reconsidered.  In the coming calendar year we will issue an update for Exchange 2007 enabling full support of Windows Server 2008 R2.  We heard from many customers that this was important for streamlining their operations and reducing administrative challenges, so we have changed course and will add R2 support.  We are still working through the specifics and will let you know once we have more to share on the timing of this update.

So, keep the feedback coming.  We are listening.

Kevin Allison
GM Exchange Customer Experience

The management experience given by Exchange 2010 through PowerShell has been moved all the way from Local to Remote. This will mean that enterprise Admins will have to adjust their regular scripts to connect to Remote PowerShell instead of creating a local session.

Here are some examples on how can this be achieved and the differences that may have to be done in order to create the connection and run the cmdlets.

Using programmatic API

The programmatic API is the simplest method that will allow you to make a remote connection requiring only the Uri for the connection and a set of suitable credentials that need to be provided through a method.

SCredential credential = new PSCredential(username, password);

Note: The password here must be of type SecureString.

After you just need to create the connection Information that will allow the creation of the runspace.

// Set the connection Info
    WSManConnectionInfo connectionInfo = new WSManConnectionInfo(
      new Uri(liveIdconnectionUri),
      http://schemas.microsoft.com/powershell/Microsoft.Exchange,
      credential);

    connectionInfo.AuthenticationMechanism = AuthenticationMechanism.Basic;

// create a runspace on a remote path
// the returned instance must be of type RemoteRunspace

Runspace runspace = System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace(connectionInfo);

From here it is just you only need to create a PowerShell instance and fill it with your cmdlets and then invoke it through the run space we've just created. Here is a simple example with get-mailbox.

PowerShell powershell = PowerShell.Create();
      PSCommand command = new PSCommand();
      command.AddCommand("Get-Mailbox");
      command.AddParameter("Identity", mailboxName);
      powershell.Commands = command;
      try
      {
          // open the remote runspace
          runspace.Open();
          // associate the runspace with powershell
          powershell.Runspace = runspace;
          // invoke the powershell to obtain the results
          return powershell.Invoke();
      }
      finally
      {
          // dispose the runspace and enable garbage collection
          runspace.Dispose();
          runspace = null;
          // Finally dispose the powershell and set all variables to null to free
          // up any resources.
          powershell.Dispose();
          powershell = null;
      }

Using Programmatic API and Certificate Thumbprint

This uses the exact same syntax than the Programmatic API except that we would need to connect to a Uri that is has a Certificate Thumbprint enabled when we create the WSMAN connection in this syntax.

WSManConnectionInfo connectionInfo = new WSManConnectionInfo(
              "E75C847ADF7B355DAAC2C6D1A4EDD8284A0C0FDC",
              new Uri(certconnectionUri),
              "http://schemas.microsoft.com/powershell/Microsoft.Exchange");

Remote Request using a local run space (Scripting the remote class)

This is the best to create scripts and run your cmdlets using remote PowerShell. For this case, we have to script in the code a call to create a New-PSSession using our credential, the connection Uri and method of authentication. This is basically using the cmdlet:

New-PSSession -ConnectionUri Microsoft.Exchange -ConnectionUri $Uri -Credential $LiveCred -Authentication Basic

To do this, we have to create the Run space in which we will run the cmdlet and then create a PowerShell instance to add the cmdlet.

Runspace runspace = System.Management.Automation.Runspaces.RunspaceFactory.CreateRunspace();
        PowerShell powershell = PowerShell.Create();
        PSCommand command = new PSCommand();
        command.AddCommand("New-PSSession");
        command.AddParameter("ConfigurationName", "Microsoft.Exchange");
        command.AddParameter("ConnectionUri", new Uri(liveIdconnectionUri));
        command.AddParameter("Credential", cred);
        command.AddParameter("Authentication", "Basic");
        powershell.Commands = command;

Now invoke this cmdlet and set it as a variable on the local Run Space that will be used to do the remote calls.

try
     {
         // open the remote runspace
         runspace.Open();
         // associate the runspace with powershell
         powershell.Runspace = runspace;
         // invoke the powershell to obtain the results
         Collection<RemoteRunspaceInfo> result = powershell.Invoke<RemoteRunspaceInfo>();
         foreach (ErrorRecord current in powershell.Streams.Error)
         Console.WriteLine("The following Error happen when opening the remote Runspace: " + current.Exception.ToString() + " | InnerException: " + current.Exception.InnerException);
         if (result.Count != 1)
             throw new Exception("Unexpected number of Remote Runspace connections returned.");
         // Set the runspace as a local variable on the runspace
     powershell = PowerShell.Create();
     command = new PSCommand();
     command.AddCommand("Set-Variable");
     command.AddParameter("Name", "ra");
     command.AddParameter("Value", result[0]);
     powershell.Commands = command;
         powershell.Runspace = runspace;
         powershell.Invoke();

After we have done this, we can now do the remote calls that will be executed on the server side as script blocks.

         powershell = PowerShell.Create();
     command = new PSCommand();
     command.AddScript("Invoke-Command -ScriptBlock { Get-Mailbox -Identity:" + mailboxName + " } -     Session $ra");
     powershell.Commands = command;
     powershell.Runspace = runspace;
         return powershell.Invoke();
     }
     finally
     {
         // dispose the runspace and enable garbage collection
         runspace.Dispose();
         runspace = null;
         // Finally dispose the powershell and set all variables to null to free
         // up any resources.
         powershell.Dispose();
         powershell = null;
     }

- Mario Trigueros Solorio

Three weeks ago we announced that Exchange 2010 was code complete. As we get ready for launch, we're seeing some amazing results from our early adopter customers. Julia White, Director of Exchange Marketing, shares some of these early highlights on the Unified Communications Blog.

Check out her post and see how Exchange 2010 (and you) can do the work of 4 or 5 other servers - and do it better and more cost-effectively.

We've got a great webcast coming up next week to discuss recommendations for virtualizing Exchange server and the benefits of choosing Hyper-V + System Center as your virtualization solution. 

TechNet Webcast: Microsoft Virtualization Best Practices for Exchange Server (Level 300)

Wednesday, Nov. 4 at 10am Pacific time

Virtualizing business critical applications will deliver significant customer benefits including cost savings, enhanced business continuity and an agile and efficient management solution.  This session will focus on virtualizing Exchange using Microsoft solutions, and guidance for virtualizing Exchange for various Production scenarios. We will go into technical details with best practices.

This is an update to the blog post Next version of Exchange and Single Label Domain (SLD) policy under review.

In response to customer feedback, the Exchange team has updated their testing matrix and has determined that Exchange Server 2010 will be supported on Single Label Domains (SLD), Disjoint Namespaces, and Discontiguous Namespaces. This post contains a brief description of each of these scenarios and special considerations. If you intend to install Exchange 2010 into one of these environments you need to read the documentation about the applicable subject.

In adding support for these types of topologies, there is an underlying requirement for DNS to be properly installed and configured. Before proceeding with any deployment defined here, clients and servers must be able to reliably resolve DNS queries for a given resource in the appropriate namespace.

Single Label Domains

Single-label DNS names are DNS names that do not contain a suffix such as .com, .corp, .net, or .org. For example contoso would be an SLD while contoso.com, contoso.net, or contoso.local would not be an SLD.

Not a recommended configuration

While Exchange 2010 is supported with SLDs, the Exchange product team's view is that SLDs are not a recommended configuration, and may not be supported by future Exchange versions. Other Microsoft or third party applications that you want to run in your environment may not be supported on an SLD. This could have an adverse effect on your environment. While we will allow installation of Exchange 2010 in an SLD, we strongly recommend that you take steps to move your organization out of this configuration.

Disjoint Namespaces

A disjoint namespace scenario is one in which the primary DNS suffix of a computer does not match the DNS domain name where that computer resides. The computer with the primary DNS suffix that does not match is said to be disjoint. Another disjoint namespace scenario occurs if the NetBIOS domain name of a domain controller does not match the DNS domain name.

Exchange 2010 and Disjoint Namespaces

In Microsoft Exchange 2010, there are three supported scenarios for deploying Exchange in a domain that has a disjoint namespace. The supported scenarios are as follows:

• Scenario 1   The primary DNS suffix of the domain controller is not the same as the DNS domain name. Computers that are members of the domain can be either disjoint or not disjoint.
• Scenario 2   A member computer in an Active Directory domain is disjoint, even though the domain controller is not disjoint.
• Scenario 3   The NetBIOS domain name of the domain controller is not the same as the subdomain of the DNS domain name of that domain controller.

For more information on Exchange 2010 and disjoint namespaces see Understanding Disjoint Namespace Scenarios.

Special Considerations

• In Exchange 2010 you may need to configure the DNS suffix search list to include multiple DNS suffixes if you have a disjoint namespace. For more information please see Configure the DNS Suffix Search List for a Disjoint Namespace.
• It is a requirement that msds-allowedDNSSuffixes be configured within the Active Directory environment for all namespaces used within the forest. For instructions on configuring this, please see the Tech Net article "The computer's primary DNS suffix does not match the FQDN of the domain where it resides."

Discontiguous Namespaces

A discontiguous namespace, also referred to as non-contiguous namespace, is one in which the domains in a forest are not defined hierarchically. If the domains in a forest have discontiguous DNS names, they form separate domain trees within the forest. An Active Directory forest can have one or more domain trees. An example of a multi-tree forest would be a forest containing the domains, contoso.com and fabrikam.net. Note: contoso.com and contoso.net in the same forest would be an invalid configuration. This is because they would both be using a NetBIOS name of contoso in their respective domains. In the case of discontiguous DNS namespaces, each domain must still register a unique legacy NetBIOS domain name.

Special Considerations

For discontiguous namespaces, DNS must be configured such that Exchange servers are able to resolve all domain names in the environment. It is also a requirement that msds-allowedDNSSuffixes be configured within the Active Directory environment for all namespaces used within the forest. For instructions on configuring this, please see the Tech Net article "Understanding DNS Client Settings."

Exchange 2010 System Requirements

For more information on Exchange 2010 System Requirements please see the Tech Net article "Exchange 2010 System Requirements"

- Ed Beck

This post applies to Exchange 2010.

By default, PowerShell has 7 Cmdlets loaded in the remote session for "import-session *" scenario which leads to about 30 MB of memory spike. Any additional Exchange help files that are loaded will cause additional spike. We will see this spike when users would call get-help on our Cmdlets, PowerShell is just preempting the spike.

In order to correct and prevent these spikes there is a manual configuration that can be done as part of the steps during an Exchange Server deployment. This configuration is not part of Exchange setup because the file belongs to PowerShell. In this particular case the change can be made using a simple script that will go into the PowerShell directory and make the necessary change to the ComandInfo object type removing the HelpUri property from it.

Running from ConfigurrePowerShell.cmd:

$path = "$pshome\types.ps1xml"
$xmlDoc = New-Object System.Xml.XmlDocument
$xmlDoc.Load($path)
$nodeList = $xmlDoc.GetElementsByTagName("Type")
$ShouldUpdateTypeFile = $false

foreach ($node in $nodeList)
{
  if ($node.Name -eq "System.Management.Automation.CommandInfo")
  {
    foreach ($child in $node.Members.ChildNodes)
    {
      if ($child.Name -eq "HelpUri")
      {
        $removedChild = $node.Members.RemoveChild($child)
        $ShouldUpdateTypeFile = $true
      }
    }
  }
}

if($ShouldUpdateTypeFile)
{
  $xmlDoc.Save($path)
}

This short script will iterate through the nodes of the types.ps1xml file removing the HelpUri property saving around 40Mb of memory by not loading all the help content for cmdlets in the beginning of the session. Note that this will have no bad effects, in other words you will still be able to use get-help.

- Mario Trigueros Solorio

We sometimes hear customers talking about putting Exchange 2007 or Exchange 2010 Client Access Servers (CAS) into the Perimeter network (sometimes referred to as the "DMZ" - Demilitarized Zone). A Perimeter network is a network zone many companies deploy between the Internet and their intranet as defense-in-depth. The idea behind a perimeter network is to add additional steps to what a hacker would have to do to get access to any intranet resources. To add as strong defense-in-depth as possible, you want to put only servers you trust to withstand Internet attacks in the perimeter, and then you should assume they can be broken into anyway.

With Exchange 2000/2003, it was supported and there was documentation explaining how to put an Exchange 2000/2003 Front-End (FE) server into the perimeter network, with a firewall between the FE and the Exchange Back-End (BE) servers it accessed. This leads some customers who upgrade from E2000/E2003 to expect the same deployment pattern with E2007/E2010.

As you start planning for deploying an E2007/E2010 CAS server in the perimeter network, you quickly notice that there is no documentation for how to do this though. You will probably even find the TechNet documentation which explains this is explicitly not supported by Microsoft. Microsoft doesn't test or support any topologies which put firewalls between a CAS and a Mailbox (MBX) server. The only Exchange 2007/2010 role which is supported for deployment in a perimeter network, and with a firewall server separating it from other Exchange server it talks to, is the Edge role. This is true for Exchange servers talking to one another within and between AD Sites.

The fact that there is no support for using firewalls between Exchange servers (except for the Edge role) sometimes causes confusion for how to use the Windows OS firewall on Exchange. It is supported to have the Windows OS firewall turned on for Exchange servers. In fact, we strongly recommend you leave the Windows OS firewall turned on as a defense-in-depth measure. Exchange 2010 setup is smart enough to configure the Windows OS firewall so it'll let through all Exchange traffic appropriately (for Exchange 2007 you need to run the Security Configuration Wizard and apply the Exchange 2007 role based template).

When discussing the fact that it is not supported to put CAS in the perimeter network, the next question is obviously "why?". If this was supported and documented for E2000/E2003 FE, why not for E2007/E2010 CAS?

The most important reason why customers wanted to install Exchange FE servers in the perimeter network was to block any unauthenticated traffic from reaching servers on the intranet. This is a good practice, but as you'll see below doing this with Exchange FE/CAS servers is no longer the best way to accomplish this goal.

It is important to understand that the CAS role in Exchange 2007 is significantly different from the FE server in E2000/E2003.

· The E2000/E2003 FE servers were there to authenticate users and proxy traffic to the BE server where the traffic was actually interpreted and responded to. For example, the FE servers in E2000/E2003 don't do any Outlook Web Access (OWA) rendering. That all takes place on the BE servers.

· The E2007/E2010 CAS role on the other hand contains all middle-tier logic and rendering code for processes like OWA, Exchange ActiveSync (EAS), Exchange Web Services (EWS), and more.

In the same timeframe as E2007 was available, enough customers had also started using reverse proxies (e.g. Internet Security and Acceleration server (ISA) 2000 FP1, 2004 or 2006) with functionality like pre-authentication. This meant there was now a good way to do authentication of Exchange traffic before the traffic reached the Exchange servers. The role the E2000/E2003 FE server had played for defense-in-depth by pre-authenticating traffic before it reached servers which included a lot of Exchange business logic could now be better handled by these new reverse proxies. The reasons a reverse proxy like this does a better job than an Exchange FE or CAS server for this defense-in-depth role are:

· Exchange CAS servers require full access to all mailboxes in an AD Site, and significant access rights to the AD. That's a level of access privileged which you should avoid having in the perimeter network.

· The Exchange FE executed a little bit of Exchange business logic, and the Exchange CAS executes a lot of Exchange business logic. The more business logic you expose in the perimeter network, the more risk you're taking that something in that logic can be hacked. For servers you put in the perimeter network, you want to minimize the logic/code surface area they run and which is exposed to attack from the outside. Reverse Proxies are built with the primary purpose of withstanding Internet attacks like that. Although Exchange servers are also hardened from a security perspective, they run much more logic than a reverse proxy, which increases the risk.

· Reverse Proxies are built to be put in the perimeter network or at the edge of the network. They include many security features and flexibility for customers to determine the level of defense-in-depth which is right in any particular environment. Some of these defense-in-depth features are easy to just turn on (e.g. using pre-authentication while your reverse proxy is an AD domain member; or avoiding AD domain membership and limiting pre-authentication capabilities) whereas other defense-in-depth features take more work (e.g. using pre-authentication without domain membership by using RADIUS). But the important distinction between the reverse proxies and the CAS is that the reverse proxies have many more defense-in-depth features and deployment models available than Exchange CAS.

In addition to these reasons why a reverse proxy does a better job in the perimeter network than an Exchange FE/CAS does, there is also a problem with FE/CAS in the perimeter which goes away when using a reverse proxy there instead:

· Deploying an E2000/E2003 FE server in the Perimeter network was difficult. The port settings and other internal firewall configuration required was complicated and many customers ran into problems setting this up correctly. Different types of internal firewalls required different configuration and the symptoms experienced by Internet clients when something was misconfigured weren't always easy to diagnose. This complexity and the errors it caused was a problem for Exchange customers. The internal firewall configuration required when using a reverse proxy in the perimeter is much simpler. This is why we don't offer "CAS in the perimeter network" as a supported solution even for customers who want to take the security risks listed above: people accidentally end up shooting themselves in the foot when trying to configure things for a FE/CAS to work in a perimeter network.
If you are curious, the ports used between server roles by E2007 are listed in http://technet.microsoft.com/en-us/library/bb331973.aspx.

The best way to deploy Exchange CAS with respect to a perimeter network is to put a reverse proxy you trust in the perimeter, configure the firewall between the perimeter and the intranet to be as restrictive as possible and to host the CAS server on the intranet. This will get traffic inspection and other reverse proxy security filtering in place in the perimeter.
As extra defense, you can also configure pre-authentication to be done on the reverse proxy. This might not be possible for all Exchange protocols if you want to expose some advanced functionality like E2010 Federated Free/Busy and Calendar Sharing to the Internet. But you can configure the pre-authentication for as many clients and protocols as is supported by the reverse proxy and the scenarios you want to enable.

Regards,

Kristian Andaker and Jason Henderson

Today we released an updated version of the Exchange Remote Connectivity Analyzer. For those of you not familiar with this site, it is a Web-based tool that helps you troubleshoot connectivity issues. The tool simulates several client logon and mail flow scenarios. When a test fails, many of the errors have troubleshooting tips to assist you in correcting the problem. For more information, see our previous blog post here.

New/updated features

• Updated user interface
• New CAPTCHA implementation. (This is the hard to read words that make you prove you are a human)
• No more 'Beta' label
• Additional tests
  • Exchange Web Services - This allows you to perform connectivity testing for Exchange Web Services client such as Entourage. Developers can also use the Service Account Verification test to ensure things are configured and working properly for access with an alternate account or ExchangeImpersonation.
  • Outbound SMTP - Performs Reverse DNS testing, DNS RBL Checks, and SenderID validation against a provided "outbound" IP address
• Updated the Outlook Anywhere test logic to work with Exchange 2010
• Added a link in the footer to the Remote Connectivity Analyzer TechNet forum
• Added a password confirmation text box to ensure the proper password was entered before running a test. This will reduce the number of tests that fail simply due to a typo in the password.

Known Issues

• The Exchange ActiveSync tests allow you to "Ignore trusts for SSL". Checking this option only tells the tool to not fail if the certificate you are using is not in the list of Trusted Root Certificates... for example if you were using a certificate from your own Windows CA. This option does not allow the test to be completed over a non-SSL connection. That is, if you do not have a certificate and want to test whether Exchange ActiveSync works over port 80 - this tool cannot perform this validation. (Note: We will not be able to add this feature in the future). Note: Due to limitations in the RPC API, we are currently unable to ignore the trust requirement for SSL for the RPC over HTTP / Outlook Anywhere tests. We are looking into alternatives for future releases.

Thank you to everyone who sent feedback to us. The above list is a direct result of the comments you provided. Please keep the feedback coming. We also like to hear when the tool helps make you successful. The "Feedback" link is in the footer of each page on the site. This goes directly to Brad and me.

Link to tool: https://www.TestExchangeConnectivity.com

Here's a little video I created about the tool:

Enjoy!

- Shawn McGrath & Brad Hughes.

This is the final part of the three part series on Exchange 2007 search. Part 1 can be found here and part 2 is here. The following post outlines the search process for Exchange 2007.

Search Process

Search Methods for Exchange 2007

There are five basic ways to search mailbox data.

Three types of search Methods can be using when querying data directly against an Exchange 2007 Sever.

1. Exchange Search (New Content Indexing Feature) is used when a search request for Mailbox store data is requested. Outlook is in online mode and indexing is enabled on the store.
2. Store Search is the default search method that is used if Content Indexing is disabled on the Exchange Server. This is also the method used in previous versions of Exchange. Outlook is in online mode and indexing is disabled.

This blog post focuses on the first option - Exchange Search with Outlook 2007 in online mode and Exchange 2007 indexing is enabled. The difference between searching the Index with and without WDS installed on the Outlook 2007 client machine is covered in detail later in this section.

3. Outlook Online Search w. WDS - Outlook is online mode with WDS enabled to index the store.

This method is disabled in WDS by default beginning with WDS version 3.01 and not recommended because it causes performance issues on the Exchange 2007 server. It can be enabled or disabled on (a) an individual client machine or (b) by group policy. The Administration Guide for 3.01 and the Group Policy for Windows Search provide detailed information, while the 4.0 Administrator's Guide provides general information:

Windows Desktop Search 3.01 Administration Guide

http://www.microsoft.com/downloads/details.aspx?FamilyID=00645e54-70a8-4d05-906d-af8773cbc728&DisplayLang=en

Group Policy for Windows Search

http://technet.microsoft.com/en-us/library/cc732491.aspx

Note: The latest version of WDS is 4.0

Windows Search 4.0 Administrator's Guide

http://technet.microsoft.com/en-us/library/cc772446.aspx

For further information on why this method is disabled by default beginning with WDS 3.01 and the performance problems it causes if enabled, please see this reference:

905184  Exchange 2000 Server and Exchange Server 2003 performance may be affected when desktop search engine software is running on Outlook or other MAPI client computers

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

Two additional methods of search are available with Outlook 2007.

4. Outlook Cached Search - Outlook is in cached mode and Windows Desktop Search is not installed.

5. Outlook Cached Search w. WDS - Outlook in cached mode and Windows Desktop Search is installed, the local index files are used.

The Instant Search feature, new to Outlook 2007 and which is only available if Windows Desktop Search is installed on the client machine, gives the user the following functionality:

Hit Highlighting, which helps the user understand why an item was returned with their search results by highlighting the matching text.
Word Wheeling, automatically filters the items in the current view based on what the user types in, and continues to update as the search is modified, this is sometimes referred to as "Search as I type".
Query Builder, allows the user to use query syntax, explained in further detail later in this section.
All Folder Search, also examined in further detail later in this chapter this feature allows an Outlook user to search multiple folders in their Outlook profile, including multiple top-level folders.

Note: If you are accessing an Exchange 2007 Server with Outlook 2007 (without WDS) hit highlighting will still function.

Searching Mailbox Data - More Information

Locale and Language

In order to return consistent search results in environments of multiple locales, the following points must be true:

• The locale of the message must match the language the email was written
• Search queries are submitted in a single language
• The language of the search query must match the locale of the client computer as identified by the connection to the server

Searching Junk and Dumpster Items

All your mailbox folders are available for search in Outlook 2007 and OWA 2007, including the junk mail folder.  It is not currently possible to search your mailbox dumpster from Outlook or OWA.  For a dumpster workaround, see the section below on Cross Mailbox Search.

Cross Mailbox Search

An Exchange Administrator has the ability using the Exchange Management Shell to search across multiple mailboxes using the Export-Mailbox cmdlet. This cmdlet will search all mailbox items in multiple, or a single mailbox. What is interesting about this cmdlet is that a search of a single mailbox or across mailboxes will include the dumpster of a mailbox or multiple mailboxes. Deleted items are converted to regular messages and included in the search. Items that match your search are then exported to a specified pst or specified single target mailbox. You can use Cross Mailbox Search to search for text in the Subject or Body of the message. For additional information on how to perform a Cross Mailbox search, see the links below:

How To Use Exchange Search to Locate Messages for the Purposes of Review or Deletion:
http://technet.microsoft.com/en-us/library/aa997688.aspx

Exchange Server 2007 Cross Mailbox Search using Export-mailbox:
http://msexchangeteam.com/archive/2006/12/18/431934.aspx

Searching Attachments

With the use of installed IFilters Exchange Search indexes attachments. Depending on the client you are using to search, you may need to take additional steps to include attachments in the search.

• For OWA 2007, attachments in your search are included automatically
• For Outlook 2007, use Instant Search or Advanced Find
• For Outlook 2003, use Find or Advanced Find and select Subject Field & Message Body
• For Outlook 2002, use Advanced Find and select Subject Field & Message Body

Note that indexing is currently performed on embedded items for one level. If you have an email within an email, Exchange 2007 Search will index both items. If there is another email embedded in the second email, that email will not be indexed.

Another issue is that if you combine attachment keyword searching with another form of searching such as a keyword in an attachment (which gives hits) and a keyword in the TO: field (which gives hits), you will not get any hits if you combine these two parameters into one search because the attachment keywords and the TO: keywords are kept in different store tables. The only workaround currently is to do the searches separately and then compare the results for matching items.

Exchange Search vs. Store Search

When a user is in online mode in Outlook 2003 or Outlook 2007 and creates a search request within Outlook, the request is sent to the Exchange 2007 Server and serviced by one of two methods, Exchange Search or Exchange Store Search.  A table comparing the two methods is below, followed by an overview of the process of querying using Exchange Search.

The query processor checks on the status of the msftesql-Exchange and MSExchangeSearch services every 30 seconds and caches their status in Memory; if either is unavailable Exchange Store Search is used.  Note that if the catalog is unavailable, or the database is not enabled for full text search, then Exchange Store Search is used.  Note that Substring searching refers specifically to a substring anywhere within a word rather than simply Prefix searching which refers to a substring at the beginning of a word.

Exchange Search Process without WDS Installed

The following Exchange Search procedure assumes the Outlook online mode client is using the Advanced Find feature, or does not have Windows Desktop Search (WDS)/Instant Search, or any other local indexing application installed.

1. A client (Outlook or Web Client) creates search query, a search query contains the restriction and the scope, the "What" and "Where". 

a. The Exchange Server Query Processor inside the store takes the query and builds a request based on the restriction and scope. The restriction is evaluated and converted to a MAPI restriction tree, providing the parameters of the query. The scope is the folder list and sets the boundaries of the query. 

     i. During this query evaluation (if a Noise Word File has been implemented), the query processes common words called Noise Words are removed. "A", "and", "the", are all examples of noise words.

b. The query is now sent to MSSearch.

2. MSSearch creates a temporary folder called a Search Folder that will contain its results. MSSearch then reads the Index Catalogs and returns the Document ID's from the catalog that match the request.

a. The Search Folder is stored in a hidden folder hierarchy with a top level folder named Restrictions. These search folders are only temporary and the client does not directly access them.

3. The Query Processor then reads the Property Store to find the Entry ID's that match the Document ID's returned by MSSearch, these back links are then stored in the Search Folder.

4. A restricted view is then created based on the contents of the search folder. The information store then sends this view to the client. The client can now see all the items that match the restriction and scope of their query.

a. The search folder is deleted by the store when not used for a certain amount of time.

Exchange Search Process with WDS Installed

In order to perform Advanced Searching in online mode (against the Index, not against the Store), Windows Desktop Search (WDS) must be installed. That can be illustrated by using an advanced search example of Phrase Searching.

In our example (Outlook 2007 SP1 in online mode) phrase searching using Instant Search fails against Exchange 2007 SP1 with indexing enabled against mailboxes if WDS is not installed. Phrase searches use quotation marks. For example, if you do a phrase search using Instant Search for "One Two Three" you receive the same results if you search for One Two Three (without "").  The result you receive is that One and Two and Three all exist in the email, whether they are in the subject or the title of the email - all three terms have to be there to get hits, but One Two Three does not have to be in exact order.
By design in Exchange 2007 with Indexing enabled, Phrase Searching (i.e., using quotation marks to search for a phrase in the subject or body of a message) using Instant Search in Outlook 2007 online mode only works if Windows Desktop Search (WDS) is installed. This is by design in Outlook 2007 because the Semantic Analyzer Component of Windows Desktop Search (WDS) is required by Instant Search for advanced searching syntax (also called advanced search grammar or advanced searching language). This type of searching is officially known as Advanced Query Search or AQS that is only added to Instant Search from WDS.

Phrase and Keyword Searching
If you want to do phrase searching (using "") with Outlook 2007 Instant search in online mode with Exchange 2007, you must install Windows Desktop Search to go along with Outlook 2007. In summary, this is by design in Exchange 2007 and by design in Outlook 2007. This applies to all types of advanced queries against the Exchange 2007 index - WDS must be installed on the Outlook 2007 client in online mode.
When you install Outlook 2007, Outlook 2007 shows a prompt to have WDS installed
because Outlook 2007 would like to make use of the semantic analyzer component in WDS. Once WDS is installed, WDS enables Instant Search to perform AQS queries such as phrase searching (using ""), keyword searching and more. Online mode search works without WDS, but the AQS or Advanced Query Syntax such as using quotes for searching does not work. AQS is the query language for WDS and can be used to narrow the scope of your searches. For example, using AQS you can use keywords like sent:, from:, read:yes/no, NOT, AND, +, OR, to name a few. For a complete list of AQS search options, click on the following links:

Chapter 11: Searching Outlook Data
http://msdn.microsoft.com/en-us/library/cc513841.aspx

Advanced Query Syntax
http://msdn.microsoft.com/en-us/library/Bb266512(VS.85).aspx

Advanced Query Syntax
http://msdn.microsoft.com/en-us/library/aa965711.aspx

Advanced Query Syntax: What, Where, Why, and How
http://blogs.msdn.com/cheller/archive/2006/12/05/advanced-query-syntax-what-where-why-and-how.aspx

NOTE: Outlook 2007 without WDS installed will not support the Advance Query Syntax. This functionality is only provided with Windows Desktop Search.

Outlook 2007 with WDS installed supports Prefix and Exact Phrase Matching when double quotes are used around any word or words to specify an Exact Phase. 
Windows XP does not have Windows Desktop Search (WDS) installed by default. If you want to use the Advanced Query Search functions in Instant Search in Outlook 2007 online mode such as searching for phrases by using quotation marks, you will need to include Windows Desktop Search as a part of the Outlook 2007 install or add WDS after installing Outlook 2007.

WDS is installed by default on Windows Vista.  Therefore, Outlook 2007 installed on Windows Vista, in online mode, is able to utilize the Advanced Query Search functions by default.

OWA uses Basic Search instead of Advanced Search Query. Therefore, when using OWA to search the Exchange 2007 index on the server, it is by design that phrase searching and other advanced queries do not work. 

Prefix matching is the default for the Advanced Find feature in earlier versions of Outlook but this is not necessarily the case in Outlook 2007. The table below lists the different modes and searching features in Outlook 2007 and whether or not Prefix searching is supported. Note that the table below refers to Prefix matching specifically (the beginning of a word), rather than Substring searching (a string found anywhere in word). Note also that when Indexing is enabled and available and the mailbox has been crawled, Advanced Find in Online Mode uses Exchange Search when it searches for a property in a message that is indexed by Content Indexing, uses Store Search when it searches for a property in a message that is indexed by Content Indexing, and uses a combination of Exchange Search and Store Search for a complex search of a combination of properties in a message, one of which is indexed by Content Indexing and one of which is not indexed by Content Indexing.

Support Matrix for Prefix Matching

Further Information on WDS and Outlook 2007

Outlook 2007 is the first client version providing Instant Search in a pane which integrates Windows Desktop Search (WDS) into the Outlook interface. Instant Search makes it possible to easily search all mail folders in online mode and all personal folder files at the same time. Instant Search works in online mode against Exchange 2007 mailboxes. Instant Search also works in online mode against Exchange 2003 and Exchange 2000 mailboxes. For further information and to download WDS, see the following link:

Windows Desktop Search 4.0

http://www.microsoft.com/windows/products/winfamily/desktopsearch/choose/windowssearch4.mspx

Outlook 2007 with WDS installed allows you to return results for the selected folder (only) or All Folders. There is not an option for subfolder searching. However, this can always be performed through the Advanced Find feature.

Note that in previous versions of Outlook, WDS is not integrated into the Outlook interface. In Outlook 2003 and Outlook 2002, the Advanced Find dialog only allows you to search one mailbox folder plus its subfolders. You can choose to search the Mailbox top level folder and its subfolders and you can then search all items in the Mailbox in online mode. Or you can search one personal folder plus its subfolders at a time. However, you cannot search multiple top level folders or multiple .pst files (or a combination of folders and .pst files) at the same time. In Outlook 2003 and Outlook 2002, you must use the WDS interface by itself to be able to search all items in the mailbox and all items in personal folders at the same time.

Searching Exchange 2007 Public Folder Databases with Outlook 2007

Using Instant Search in Outlook 2007 or Advanced Find in Outlook 2007 or Outlook 2003, you can search Public folders only in cached mode and only your Public Folder Favorites and only when you check the Cached Exchange Mode Settings box which says Download Public Folder Favorites. You can also optionally mandate local cached indexing of public folder data on a per machine basis or by group policy. 

Indexing Exchange 2007 Public Folder Databases

Note that Exchange 2007 indexes only mailbox store databases. In Exchange 2000 and Exchange 2003, full-text indexing could also be implemented for the public store database. That functionality has been replaced with SharePoint 2007 SP1 server running on Windows 2003 to index Exchange Server 2007 SP1 public folders for Exchange 2007 SP1. For further information, see the following links:

942390 Description of the SharePoint Server 2007 issues that are fixed by the 2007 Microsoft Office servers Service Pack 1
http://support.microsoft.com/default.aspx?scid=kb;EN-US;942390

If the SharePoint 2007 server is on Windows 2008 64-bit, there is an issue that is fixed in SharePoint 2007 SP2 which will allow SharePoint 2007 on Windows 2008 to be able to index Exchange 2007 SP1 public folders. Note that it is required that you apply BOTH Windows SharePoint Services 3.0 Service Pack 2 and Microsoft Office SharePoint Server 2007 Service Pack 2 (64-bit versions):

KB Article Links

953338 Description of Windows SharePoint Services 3.0 SP2 and of Windows SharePoint Services 3.0 Language Pack SP2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;953338

953334 Description of 2007 Microsoft Office servers Service Pack 2 and of 2007 Microsoft Office servers Language Pack Service Pack 2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;953334

Download Links

Service Pack 2 for Windows SharePoint Services 3.0, x86 & x64
http://www.microsoft.com/downloads/details.aspx?FamilyId=79BADA82-C13F-44C1-BDC1-D0447337051B&displaylang=en

Service Pack 2 for Office SharePoint Server 2007, x86 & x64
http://www.microsoft.com/downloads/details.aspx?FamilyId=B7816D90-5FC6-4347-89B0-A80DEB27A082&displaylang=en

Summary

In summary, there are five basic ways to search Exchange 2007 mailbox data. This blog post focused on the first option - Exchange Search with Outlook 2007 in online mode with Exchange 2007 indexing enabled. Searching the Index with WDS installed on the Outlook 2007 client machine provides a new feature called Instant Search and includes the ability to do Advanced Query Searching. Also, using Instant Search that has WDS integrated into the Outlook 2007 interface allows you to search all mailbox folders in online mode and all .pst files simultaneously in a supported and reliable manner.  For performance reasons, indexing the mailbox store by WDS is disabled by default.

Search queries are performed in one language only, the language of the client performing the search. Cross Mailbox Search to a target mailbox or target .pst file is available through the Export-Mailbox command. Attachment searching, new to Exchange 2007, is only provided with the use of installed default Filters and additional Filters may be installed for other document types. In order to do attachment searching, you must be in online mode or use OWA. Instant Search automatically includes attachments and Advanced Find can search attachments in Outlook 2007, Outlook 2003, and Outlook 2002. OWA 2007 includes attachment searching automatically.

Exchange Search (default) is preferred over Store Search (only used when the Index Catalog is not present or not available). Exchange Search is much faster than Store Search, searches words and phrases instead of streams of bytes, searches attachments, and can search in various languages.

Searching Exchange 2007 Public Folder Databases with Outlook 2007 (and Outlook 2003) is only possible if you are in Cached Exchange Mode, and only on Public Folder Favorites, and only if you check the box which says Download Public Folder Favorites.

By design, Exchange 2007 only indexes mailbox store databases, while both previous versions Exchange 2003 and 2000 also indexed public folder databases. By design, the current method of indexing Exchange 2007 public folder databases is to use SharePoint 2007.

In Exchange 2007 SP1, SharePoint 2007 SP1 is used to index public folder databases. SharePoint 2007 SP1 servers can currently index public folder databases on Exchange 2007 SP1 servers. SharePoint 2007 SP2 servers running on Windows 2008 are expected to be able to index Exchange 2007 SP1 public folder databases.

Conclusions

Exchange 2007 full-text indexing is now a best practice for all Exchange 2007 mailbox databases due to the fact that searching is much faster, mail is immediately indexed when it arrives, the reduced catalog size, and both Search and Index are much less resource intensive than previous versions.

Crawling in Exchange 2007 is now performed automatically as new items arrive or a significant event such as a mailbox move to a database occurs rather than on a schedule as in previous versions. This means that the Catalog Index is always up-to-date within seconds of new items arrival. Exchange 2007 provides a Noise Word file capability per the language of the client.

Exchange 2007 Content Indexing for High Availability SCC servers is much like Clustered Servers content indexing for Exchange 2003 and Exchange 2000: there is one copy of the Catalog. For Exchange 2007 CCR servers, there are two copies of the mailbox database and each database has its own unique catalog which is only crawled at any one time on the active node.

There are five basic ways to search Exchange 2007 mailboxes, and this bulletin concentrates specifically on the new Features available for Outlook 2007 online mode clients with WDS installed against Exchange 2007 mailbox database with indexing enabled such as searching attachments and using Advanced Query Syntax. Indexing of Exchange 2007 public folder databases has been completely deprecated for Exchange 2007 and searching for Exchange 2007 public folder databases has been partially deprecated in Outlook 2007. The current method of indexing and searching for Exchange 2007 public folder databases is now using SharePoint 2007.

In conclusion, deploying Exchange 2007 together with Outlook 2007 and SharePoint 2007 gives advanced features, much faster and up-to-date indexing and searching than previous versions of full-text indexing for Exchange 2003 and Exchange 2000. Full-text indexing and the use of Exchange Search rather than Store Search are now recommended as a Best Practice for all Exchange 2007 mailbox databases.

Exchange 2007 Search Resources and Links

Technet

How to Diagnose Exchange Search Issues
http://technet.microsoft.com/en-us/library/bb123701(EXCHG.80).aspx?track=cc_exchange_sync

How to Disable or Enable Exchange Search
http://technet.microsoft.com/en-us/library/aa996416.aspx

How to Rebuild the Full-Text Index Catalog
http://technet.microsoft.com/en-us/library/aa995966(EXCHG.80).aspx

How To Use Exchange Search to Locate Messages for the Purposes of Review or Deletion
http://technet.microsoft.com/en-us/library/aa997688.aspx

Indexing Exchange Server 2007 Public Folders
http://blogs.msdn.com/enterprisesearch/archive/2008/06/06/indexing-exchange-server-2007-public-folders.aspx

Managing Exchange Search
http://technet.microsoft.com/en-us/library/aa998289.aspx

Understanding Client Throttling
http://technet.microsoft.com/en-us/library/cc540454.aspx

Understanding Exchange Search
http://technet.microsoft.com/en-us/library/bb232132(EXCHG.80).aspx

How To Use Exchange Search to Locate Messages for the Purposes of Review or Deletion
http://technet.microsoft.com/en-us/library/aa997688.aspx

Microsoft Exchange Team Blog and Team Wiki

Exchange Search FAQ
http://www.exchangeninjas.com/ExchangeSearchFAQ

Exchange Server 2007 Cross Mailbox Search using Export-mailbox
http://msexchangeteam.com/archive/2006/12/18/431934.aspx

The new Search in Exchange Server 2007
http://msexchangeteam.com/archive/2006/10/11/429163.aspx

KB Articles

944516  How to register Filter Pack IFilters with Exchange Server 2007
http://support.microsoft.com/default.aspx?scid=kb;EN-US;944516

945077 The Outlook Web Access search function does not work for some users in Exchange 2007
http://support.microsoft.com/default.aspx?scid=kb;EN-US;945077

Office Online

Can I remove the Instant Search pane?
http://office.microsoft.com/en-us/outlook/HA102388301033.aspx

Chapter 11: Searching Outlook Data
http://msdn.microsoft.com/en-us/library/cc513841.aspx

Create a Search Folder
http://office.microsoft.com/en-us/outlook/HA100389111033.aspx

Enable or disable Instant Search
http://office.microsoft.com/en-us/outlook/HA102378331033.aspx

Find a message or item by using Instant Search
http://office.microsoft.com/en-us/outlook/HA012305851033.aspx

Find and organize messages with Search Folders
http://office.microsoft.com/en-us/outlook/HA102341231033.aspx

Instant Search is not finding items
http://office.microsoft.com/en-us/outlook/HA101980851033.aspx

Learn to narrow your search criteria for better searches in Outlook
http://office.microsoft.com/en-us/outlook/HA102388311033.aspx

Reset indexing by rebuilding your Instant Search catalog
http://office.microsoft.com/en-us/outlook/HA102378321033.aspx

Turn off the prompt for installing Windows Desktop Search
http://office.microsoft.com/en-us/outlook/HA102429341033.aspx

Use Search Folders to gather messages marked as Important
http://office.microsoft.com/en-us/outlook/HA012305791033.aspx

Advanced Query Syntax

Chapter 11: Searching Outlook Data
http://msdn.microsoft.com/en-us/library/cc513841.aspx

Advanced Query Syntax
http://msdn.microsoft.com/en-us/library/aa965711.aspx

Advanced Query Syntax
http://msdn.microsoft.com/en-us/library/Bb266512(VS.85).aspx

Windows Search Advanced Query Syntax
http://www.microsoft.com/windows/products/winfamily/desktopsearch/technicalresources/advquery.mspx

New Mansions in Search - Advanced Query Syntax
http://blogs.msdn.com/jonasbar/archive/2007/01/31/new-mansions-in-search-advanced-query-syntax.aspx

Advanced Query Syntax: What, Where, Why, and How
http://blogs.msdn.com/cheller/archive/2006/12/05/advanced-query-syntax-what-where-why-and-how.aspx

Windows Desktop Search

Group Policy for Windows Search
http://technet.microsoft.com/en-us/library/cc732491.aspx

Windows Desktop Search 3.01 Administration Guide
http://www.microsoft.com/downloads/details.aspx?FamilyID=00645e54-70a8-4d05-906d-af8773cbc728&DisplayLang=en

Windows Search 4.0 Administrator's Guide
http://technet.microsoft.com/en-us/library/cc772446.aspx

Windows Search
http://msdn.microsoft.com/en-us/library/aa965362(VS.85).aspx

Windows Search 4.0
http://www.microsoft.com/windows/products/winfamily/desktopsearch/choose/windowssearch4.mspx

Windows Search: Technical Resources Overview
http://www.microsoft.com/windows/products/winfamily/desktopsearch/technicalresources.mspx

Description of Windows Desktop Search 3.01 and the Multilingual User Interface Pack for Windows Desktop Search 3.01
http://support.microsoft.com/kb/917013

-- Bob Want and Jack French

It was mentioned before that Exchange 2007 SP2 contained Exchange 2010 schema completely back ported to it, but if you check the LDF files that generate the schema you may notice that they are in fact different.

Back porting the schema was not a straight forward action code wise. In order to do it, we had to add some of the properties that were in a separated file in Exchange 2010 to all the *99.ldf files in Exchange 2007 SP2. This is why you may notice that there are differences in the files that generate the schemas in between the 2 versions.

However, this change has no impact on what happens when you install E2007 SP2. Schema versions are synchronized and after installing it, the schema in your environment will be that of Exchange 2010.

- Mario Trigueros Solorio

I wanted to take a moment to get out the latest information concerning Exchange Anti-Spam Filters for the different Exchange products that have been released. This definitely will not answer all the questions but it should help in clarifying things that you may notice changing over the next couple of weeks as we begin publishing Anti-spam Filter updates for Exchange Server 2010 product targeting the Standard CAL configuration.

Exchange Server 2003 Anti-spam Filter Updates

I previously discussed Demystifying Exchange Server 2003 SP2 IMF Updates in detail many moons ago. The IMF Updates for Exchange Server 2003 will only published on the third Wednesday of the month moving forward. Previously, it was being offered twice a month on the first and second Wednesday of the month.

Exchange Server 2007 Anti-spam Filter Updates

In preparation of releasing Anti-Spam updates for Exchange Server 2010 in the very near future, I would like to take a moment to remind that Enabling Forefront Security Anti-spam Updates is a good article to read for understanding how to enable Anti-Spam updates. There are other articles on the internet and this is the one that caught my attention. We should have updates to the instructions in the near future if it hasn't been done already to reflect how to configure Exchange Server 2010.

I would like to point out that for Exchange Server 2007, the publishing of Anti-Spam updates for the Standard CAL will still be once every two weeks and the Enterprise CAL updates will still be offered daily.

Exchange Server 2010 Anti-spam Filter Updates

For Exchange Server 2010, the Standard CAL spam definition updates will become available over the next couple of days and will be published twice a month from that point on. Exchange Server 2010 Enterprise CAL anti-spam definition updates will not be provided by Microsoft Update. They will be made available via Forefront Security for Exchange.

** WSUS Administrators **

For the WSUS administrators, you may notice the previous Product Classification "Exchange Server 2007 Anti-spam" is now "Exchange Server 2007 and Above Anti-spam". Over the next few weeks, you will see this name change again once more to "Microsoft Exchange Standard Anti-spam Updates" once the change is allowed to go live. We also published the first Exchange Server 2010 category and you should be seeing that listed with the other Product Classifications. These changes were done to make the above possible.

Thanks,

- Scott Roberts (Exchange)

By now, you've seen a few of our Spotlight on Exchange 2010 postings. If you have, hopefully you're excited about the great work that has been going on to make Exchange 2010 the best version of Exchange yet. So then the practical side of you kicks in and starts to wonder what it is going to take to start utilizing these new features when the time comes. Certainly, rolling out a new version of Exchange is rarely an endeavor to be entered into lightly.

In the interest of making certain that you can begin planning early and as informed as possible, I want to call out a requirement that we had to put in place for Transport server roles in order to deliver a quality product with cool new features. This requirement is often referred to as "version-based routing" or just "versioned routing."

What this requirement means

Simply put, this requirement means that Exchange 2010 Hub Transport servers and Exchange 2010 Mailbox servers will only communicate with each other. Also, it means that Exchange 2007 Hub Transport servers and Exchange 2007 mailbox servers will only communicate with each other. However, any version Hub is able to communicate (via SMTP) to any other Hub server. So, for a user on Exchange 2007 to be able to send to a user on Exchange 2010 in the same site, the mail must pass through both Hub servers.

For example:

Note that Exchange 2007 Service Pack 2 implements this restriction for Exchange 2007 Mail Submission and Exchange 2007 Mailbox Delivery. This is one reason that Service Pack 2 is required before deploying Exchange 2010 - and all servers must remain at Service Pack 2 to ensure that this feature continues to work properly. Also, note that (while out of scope of this posting) this same requirement applies to Client Access servers - Client Access server versions must match the version of the mailbox server that they are communicating with.

The mail routing between Exchange 2003 and Exchange 2010 has not changed from Exchange 2007. In Exchange 2010 we still rely on a Routing Group Connector (RGC) between the Exchange 2003 Routing Group and the Exchange 2007/2010 Routing Group. If you do not have Exchange 2007 today and would like to know more about routing considerations migrating from Exchange 2003, check out this post. Additionally, mail flow between AD sites (because it also uses SMTP) is not affected by version based routing.

Possible migration strategies

For a single all-in-one server deployment, the migration from 2007 to 2010 is relatively simple, just as it was from 2003 to 2007. Simply bring up the new server and migrate mailboxes. During that migration, mail will simply flow from one server to the other without impacting users - simply make sure that both servers have both roles.

For more complex migrations, in the interest of utilizing hardware effectively, you may consider using a swing server type method. That is, you have one spare server that you install Exchange 2010 onto. Once you move the mailboxes from 2007 to 2010, you can reclaim the hardware to repeat in other locations. For this reason, you want to incorporate this into your planning, and possibly consider a short co-existence period. Of course, as your users on 2007 are moved to 2010, you may consider appropriating hardware from being 2007 Hub servers to 2010 Hub servers.

A special note about redundancy/fault tolerance: Depending on the requirements and number of users, you also may consider making sure that you always have 2 hubs of both versions for redundancy. Of course if you have Exchange 2007 deployed with CCR clustering, then the Hub role cannot be installed on the same server. However, the replacement for CCR, Database Availability Group (DAG) does allow the Hub role to coexist with the mailbox role.

For those that have less hardware available, particularly if that hardware will be underutilized, virtualization is a great option for minimizing the number of physical servers that are required. Best of all, physical resources can be reallocated without having to rebuild an entire machine, although it requires that the environment was virtualized to begin with. For example, you could have two physical machines hosting both Exchange 2007 and Exchange 2010 Hub transport roles, providing you with redundancy for both versions, while not requiring additional hardware. Hyper-V is of course provided at no extra cost for those running Windows Server 2008 or later.

Why this requirement?

Essentially, as with most software development, this decision was about tradeoffs. But, first a little history...

If you're interested in these sort of things, you may be aware that as of Exchange 2007, transport no longer uses the now defunct Exchange file system driver to move messages in and out of the mailbox store. Instead we use a special managed internal RPC API that has some similarities to MAPI called Exchange Storage Objects (XSO). For many reasons, XSO is not a public API like Exchange Web Services or MAPI, but it is used by other roles that need to get messages in and out of the mailbox store.

If I still haven't lost you, you may also be aware of the huge value proposition we're delivering with the improvements to storage and the I/O requirements. In order to do that, and prepare for continuing storage improvements, some changes had to be made to the database schema. Accordingly, the XSO API had to be updated, and any code that utilized the old API had to also be updated.

Originally, the plan was to require that Exchange 2010 be in a separate AD site from the Exchange 2007 servers. Because that would have made deployment incredibly difficult, the Transport team took a feature to introduce the concept of "version based routing." This is also why Service Pack 2 is now required on Exchange 2007 servers.

Conclusion

Now that you understand the requirements introduced, you can plan accordingly to keep mail flowing smoothly during the migration to Exchange 2010. Feel free to let us know what you think - does this information help you plan better?

By the way, this will be more formally documented in these online help topics (depending on when you check, this may or may not be fully updated at the time of this posting):

• Upgrading from Exchange 2007 Transport
• Planning Roadmap for Upgrade and Coexistence - Exchange 2007

- Scott Landry

We are excited about the Exchange 2010 developer experience and we think you will be too.  Over the next two weeks we'll be doing six webcasts filled with information to help our partners and customers understand what Exchange 2010 means for them.  David, Chris and I just posted an introductory video on Channel 9 to give you an overview of why we're excited about Exchange 2010 and show off a cool application built on Exchange 2010 and the Exchange Web Services API.  Check out the video and then plan to attend the upcoming webcasts, where we will go much deeper into the technical details that you'll want to know as you think about moving your applications to Exchange 2010 and Exchange Web Services.

10/13/2009 - Exchange Server 2010 Development (Part 1 of 6): Migrating Applications to Exchange Web Services

10/14/2009 - Exchange Server 2010 Development (Part 2 of 6): A Deep Dive into Using Autodiscover Service in Exchange Web Services

10/15/2009 - Exchange Server 2010 Development (Part 3 of 6): A Deep Dive into Impersonation and Delegation in Exchange Web Services

10/20/2009 - Exchange Server 2010 Development (Part 4 of 6): A Deep Dive into Exchange Web Services Notifications (Push/Pull)

10/21/2009 - Exchange Server 2010 Development (Part 5 of 6): A Deep Dive into the Exchange Web Services Managed API

10/22/2009 - Exchange Server 2010 Development (Part 6 of 6): Best Practices for Building Scalable Exchange Server Applications

- Jason Henderson