In this blog post, we will be highlighting some of the most common errors that may be seen when attempting to open the Exchange Management tools (Exchange Management Console and Exchange Management Shell).

To start off, you first need to be aware that in Exchange 2010, all management is done via Remote PowerShell, even when opening the Management Tools on an Exchange server. Where this differs from Exchange 2007 is that there is now a much larger dependency on IIS, as Remote PowerShell requests are sent via the HTTP protocol and use IIS as the mechanism for connections. IIS works with the WinRM (Windows Remote Management) service, and the WSMan (Web Services for Management) protocol to initiate the connection.

When you click on the Exchange Management Shell shortcut, a Remote PowerShell session is opened. Instead of simply loading the Exchange snap-in (as we did with Exchange 2007), PowerShell connects using IIS to the closest Exchange 2010 server via WinRM. WinRM then performs authentication checks, creates the remote session and presents to you the cmdlets that you have access to via RBAC (Role Based Access Control).

Since all Remote PowerShell connections go through IIS, we have identified some of the most common errors that may be exhibited when attempting to open the Exchange Management tools along with the most common causes of those errors and how to address these issues. We have attempted to list these in order of frequency.

Issue:

Connecting to remote server failed with the following error message: The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic.

Possible causes:

1. Remote PowerShell uses Kerberos to authenticate the user connecting. IIS implements this Kerberos authentication method via a native module. In IIS Manager, if you go to the PowerShell Virtual Directory and then look at the Modules, you should see Kerbauth listed as a Native Module, with the dll location pointing to C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dll. If the Kerbauth module shows up as a Managed module instead of Native, or if the Kerbauth module has been loaded on the Default Web Site level (instead of, or in addition to, the PowerShell virtual directory), you can experience this issue. To correct this, make sure that the Kerbauth module is not enabled on the Default Web Site, but is only enabled on the PowerShell virtual directory. The entry type of "Local" indicates that the Kerbauth module was enabled directly on this level, and not inherited from a parent.

2. If the WSMan module entry is missing from the global modules section of the C:\Windows\System32\Inetsrv\config\ApplicationHost.config file, as follows:

<globalModules>
           <add name="WSMan" image="C:\Windows\system32\wsmscv.dll" />

This will result in the WSMan module displaying as a Managed module on the PowerShell virtual directory.

To correct this, make sure that the WSMan module has been registered (but not enabled) at the Server level, and has been enabled on the PowerShell virtual directory.

3. If the user that is attempting to connect is not Remote PowerShell enabled. To check if a user is enabled for Remote PowerShell, you need to open the Exchange Management Shell with an account that has been enabled, and run the following query.

(Get-User <username>).RemotePowershellEnabled

This will return a True or False. If the output shows False, the user is not enabled for Remote PowerShell. To enable the user, run the following command.

Set-User <username> -RemotePowerShellEnabled $True

Issue:

Connecting to the remote server failed with the following error message: The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. For more information, see the about_Remote_Troubleshooting Help topic.

Possible Causes:

1. The http binding has been removed from the Default Web Site. A common scenario for this is if you are running multiple web sites, and attempting to set up a redirect to https://mail.company.com/owa by requiring SSL on the Default Web Site, and creating another web site to do the redirect back to the SSL-enabled website.

Remote PowerShell requires port 80 to be available on the Default Web Site. If you want to set up an automatic redirect to /owa and redirect http requests to https, you should follow the instructions located at http://technet.microsoft.com/en-us/library/aa998359(EXCHG.80).aspx and follow the directions under the section "For a Configuration in Which SSL is Required on the Default Web Site or on the OWA Virtual Directory in IIS 7.0".

2. The http binding on the Default Web Site has been modified, and the Hostname field configured. To correct this issue, you need to clear out the Hostname field under the port 80 bindings on the Default Web Site.

Issue:

Connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'.

In addition, you may see the following warning event in the System log:

Source: Microsoft-Windows-WinRM
EventID: 10113
Level: Warning
Description: Request processing failed because the WinRM service cannot load data or event source: DLL="%ExchangeInstallPath%Bin\Microsoft.Exchange.AuthorizationPlugin.dll"

Possible Causes

1. The ExchangeInstallPath variable may be missing. To check this, go to the System Properties, Environment variables, and look under the System variables. You should see a variable of ExchangeInstallPath with a value pointing to C:\Program Files\Microsoft\Exchange Server\V14\.

2. The Path of the Powershell virtual directory has been modified. The PowerShell virtual directory must point to the \Program Files\Microsoft\Exchange Server\v14\ClientAccess\PowerShell directory or you will encounter problems.

Issue:

Connecting to remote server failed with the following error message: The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL. For more information, see the about_Remote_Troubleshooting Help topic.

Possible Causes:

1. Make sure the MSExchangePowerShellAppPool is running. If it is, try recycling the Application Pool and check for errors or warnings in the Event logs.

2. Make sure that the user that is trying to connect is Remote PowerShell Enabled (see the first error for details on how to check this).

3. Make sure WinRM is properly configured on the server.

a. Run WinRM Quick Config on the server and ensure that both tests pass and no actions are required. If any actions are required, answer Yes to the prompt to allow the WinRM configuration changes to be made.

b. Run WinRM enumerate winrm/config/listener and ensure that a listener is present for the HTTP protocol on port 5985 listening on all addresses.

Issue:

Connecting to remote server failed with the following error message: The WinRM client received an HTTP status code of 403 from the remote WS-Management service.

Possible Causes:

1. The "Require SSL" option has been enabled on the PowerShell Virtual Directory. To resolve this, remove the "Require SSL" option from this Virtual Directory. The Exchange Management Tools connect over port 80, not 443, so if Require SSL is set, when a connection is attempted on port 80, IIS will return a 403 error indicating SSL is required.

- Ben Winzenz, Solange Trombini

In many organizations the skill sets that administer Exchange, Active Directory (AD), Domain Naming System (DNS), and the network infrastructure are often segregated. Since Exchange is heavily dependent on communication with AD and that communication must traverse the network, the ability for the Exchange Administrator to have a basic understanding of how each of these components can be troubleshot is useful. Furthermore, often times the DNS, network, and AD administrators are not familiar with how Exchange is dependent on their services and thus are not fully prepared to help an Exchange administrator isolate production issues. As such, by the end of this it is hoped that there will be enough information to allow the Exchange, DNS, network, and AD administrators to each collect the data necessary to identify the majority of the issues.

There is some required reading that is necessary in order to understand much of the content that follows. Rather than reiterate all of the pre-requisite knowledge here, reviewing the following content might be helpful:

• Ruling Out Active Directory-Bound Problems
• Monitoring Without System Center Operations Manager: Exchange 2007 Help
  • Most specifically - Monitoring Common Counters: Exchange 2007 Help
• Why you need Active Directory for Exchange Server 2007
• Measuring AD Performance
• Understanding and Troubleshooting Directory Access
• Exchange Server 2003 and Active Directory
• Mike Lagase : New ADAccess Performance counters included with Exchange 2007 SP2
• Performance Tuning Guidelines for Windows Server 2003
• Performance Tuning Guidelines for Windows Server 2008
• Microsoft® Windows ServerT 2003 Resource Kit

To start with, an understanding of what the performance counters "LDAP Read Time" and "LDAP Search Time" track is very useful (as identified in Ruling Out Active Directory-Bound Problems and Monitoring Common Counters: Exchange 2007 Help). One knows that once these counters approach or exceed the recommended thresholds, troubleshooting outside of Exchange needs to begin. Therefore, the question, "What are the potential contributors to high values for these counters?" is thus raised. Since these counters are installed with Exchange and are tracked within the DSAccess /ADAccess components, depending on the version of Exchange, there are a number of dependencies that Exchange does not have visibility into that the troubleshooter needs to be cognizant of when evaluating where the source of the delay is incurred. In order to provide a clearer picture of what needs to be considered, below is a walkthrough of a somewhat simplified list of events that happens after the clock starts ticking (reference How Active Directory Searches Work for greater detail):

1. WLDAP32.DLL receives the request from one of the Exchange processes. It has to locate a Global Catalog (GC) first.

2. DNS query traverses the network. Unresponsiveness or degraded responsiveness from DNS servers will degrade the overall performance of the query.

3. WLDAP32.DLL submits the query to the GC.

4. If not already started, a Transmission Control Protocol (TCP) session is established, the Lightweight Directory Access Protocol (LDAP) query traverses the wire.
Note: since TCP requires a 3 stage handshake before the session and in turn windowing can work, multiply network latencies by 3 to figure out how much time it takes just to establish the session (thus that 10 ms latency becomes 30 ms delay even before the Exchange server submits the query).

5. The TCP data transmitted up the networking stack to LSASS.exe listening on the LDAP ports.

6. The query is processed by the GC and searches through the database to return the results.

7. The data is sent out the Network Interface Card (NIC) on the GC.

8. The query is received via WLDAP32.DLL from the GC.

a. If there are multiple pages all pages need to be returned and stored in a data structure within DSAccess / ADAccess. Each of these requires traversal of the network and resubmission of the query.

b. If there are a large quantity of values in the requested attribute (think group memberships), these all need to be retrieved and returned. This results in multiple queries to the GC. This may require steps 1 - 5 to recur.

As can be seen from the above set of steps a lot of the performance delays are heavily dependent on network latency and network performance. In fact the only portion of that number that is actually impacted by the GC performance itself is step 5. As such, in addition to troubleshooting any potential performance issues on the GC, it is highly advantageous to collect network trace data when issues do occur, preferably from both sides of the conversation.

Summary of Data needed to troubleshoot

Exchange Server - Having this data from both sides is important for comparison purposes (i.e. is the processor spike on the DC correlating with the degraded performance in Exchange)

• Performance Counters specified in the referenced articles:
  • Exchange 2007/2010 - Monitoring Common Counters: Exchange 2007 Help
  • Exchange 2000/Exchange 2003 - Ruling Out Active Directory-Bound Problems
    Note: For Exchange 2003 add in MSExchangeDSAccess Domain Controllers\LDAP Search Time(All Instances) and MSExchangeDSAccess Domain Controllers\LDAP Read Time\(All Instances) so that the DC to be troubleshot can be identified.
• Network Trace from the Exchange server side

Note: To ease collection of the Exchange performance data reference "Mike Lagase : Perfwiz replacement for Exchange 2007"

AD Server -

• Performance Data -
  • Windows 2008/2008 R2 - Monitoring Common Counters: Exchange 2007 Help recommends starting the built in Data Collector Set "Reliability and Performance\Reports\System\Active Directory Diagnostics" and use the data collector set.
    Reference: Performance Logs and Alerts
  • Windows 2003
    • At a minimum, the counters specified in Ruling Out Active Directory-Bound Problems
    • SPA - Select the Active Directory report.
• Network Trace from the affected DC side.

DNS Server - not all organizations use Microsoft DNS servers, but for the purposes of this article the assumption that a Microsoft DNS server is in use.

• Network Trace from the DNS server
• Performance Data
  • Windows 2008/2008 R2 - start the built in Data Collector Set "Reliability and Performance\Reports\System\System Performance" and use the data collector set.
  • Windows 2003 - SPA Select the System Overview report
  • Performance counters - All DNS related counters.

How to triage where troubleshooting needs to happen

• Network Infrastructure issues -
  • Use the network trace to determine if the DNS server is responding in a timely fashion. Keeping in mind that Microsoft recommends the entire conversation happen in less than 50 ms in general, if the DNS servers are taking more of that 50 ms than the actual LDAP search, this could be problematic. Timely is also subjective to whatever is normal for the environment and base lining is helpful here. In general if the DNS server is on the same segment and performing properly, 1 to 2 ms or less is reasonable. Of course as always, it is recommended that the environment be base lined so that the expected performance is known.
  • Use the network trace to determine if the TCP session with the GC is being established in a timely fashion.
    Again, keeping in mind that there is a 50 ms performance threshold, if the TCP session establishment is taking more time than the actual LDAP search takes to complete, this could be problematic. Also, timely is also subjective to whatever is normal for the environment and base lining is helpful hear. In general, if the GCs are on the same segments and both the network and the GC are performing properly, sessions established in 1 to 2 ms or less is reasonable. Of course as always, it is recommended that the environment be base lined so that the expected performance is known.
• AD Issues - Often AD infrastructures are large and the AD admins cannot determine which of the many GCs is in use by the affected Exchange server, thus the responsibility of pointing the AD support team to the right box to troubleshoot falls on the Exchange admin.
  • Use the network trace to find out which GC is having a large delay between the LDAP Request and LDAP Response packets.
  • Use the performance counters to narrow down to the box that is performing poorly.
    • Exchange 2007/2010 - MSExchange ADAccess Domain Controllers\LDAP Search Time and MSExchange ADAccess Domain Controllers\LDAP Read Time check the specific instances for values exceeding the recommended thresholds. This will report the specific GC (and underlying network path) that is not responding to Exchange as quickly as desired.
      Note: On Exchange 2007 SP2 and newer systems, the "MSExchange ADAccess Local Site Domain Controllers" can also be used in the same manner.
    • Exchange 2003 - MSExchangeDSAccess Domain Controllers\LDAP Search Time and MSExchangeDSAccess Domain Controllers\LDAP Read Time, check the specific instances for values exceeding the recommended thresholds. This will report the specific GC (and underlying network path) that is not responding to Exchange as quickly as desired.
    • Exchange 2000 - performance counters similar to the above did not exist. The only way to determine which GC is responding slowly is to analyze a network trace as described previously.

Next, identify bottlenecks within the GC (note: for the most part these basics apply to troubleshooting DNS performance as well):

While there are a large variety of potential issues, there are some basic things that can be eliminated before advanced troubleshooting need take place. The below guidance are the most basic remediation suggestions for the largest variety of these types of issues. Essentially this comes down to, "Ok, so the issue is identified, now what do I do?"

Since there is plenty of published information on how to isolate disk, processor, and/or network issues, please reference the excellent articles linked at the beginning for the recommended thresholds. Also, check out Performance Analysis of Logs (PAL), which automates the analysis of the performance data collected to help determine where the system is bottlenecking.

Disk bound - Once the issue is isolated to being disk bound, there are essentially two options, add memory or allow for increased disk IO (i.e. add spindles for direct attached storage).

• Adding memory is not quite as cut and dry as just throwing in some sticks of RAM.
  • 32-bit systems - It makes sense to avoid rehashing the entire discussion of 32-bit OS architecture especially since 32-bit architecture is on its way out. Reference this support article for some useful info. Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server
  • 64-bit systems - Generally the easiest thing to do is to put enough RAM in the box to load the entire database (minus white space) in memory. As of this writing, even for the largest enterprises (16 GB to 32 GB databases), this is becoming quite inexpensive or easy to justify. If the box has enough memory to load the entire database already and disk IO is the issue, troubleshoot why the database is not being loaded. A couple tip:
    • Measure Process\Virtual Bytes\lsass to see if it is about (within 10%/20%) of the size of the database (minus white space) or larger. If it isn't, troubleshoot why lsass isn't growing.
      Ensure that other applications aren't consuming large amounts of memory and preventing LSASS from growing like it wants to.
• Increasing disk-throughput.
  • If RAM cannot be added (or additional RAM will provide no benefit) due to the limits of the 32-bit OS architecture migrate to 64-bit. If migrating to 64-bit is not an option, the only option left is to add more disk throughput. Assuming that the storage is local and not SAN attached, it essentially means add more spindles (talk to the SAN guys if the AD database is stored on the SAN).
  • Reducing disk IO to the database volume is another option. Look at options such as turning off backups and AV scans during production hours, move SYSVOL and/or the database logs to separate spindles. Just follow standard storage performance tuning recommendations. Also, IOs to the disk can be reduced by reducing the demand on the boxes either by adding more DCs to the environment or reducing client demand. SPA and Performance Logs and Alerts will help track down what else is using the volume.

Processor bound:

• Ensure that LSASS is the process using the CPU, if not eliminate the problematic process.
• If LSASS is running hot, then use SPA (Windows 2003) or Performance Logs and Alerts (Windows 2008 and up) to identify where the CPU is being consumed within LSASS.
• If everything looks normal then the only option remaining is to add more processors to the box or more boxes to the infrastructure if there is high processor load across multiple systems.
  Note: In large infrastructures with multiple DCs and multiple Exchange servers, adding more hardware only makes sense if all of the boxes are experiencing high CPU utilization (close to or exceeding the thresholds in Ruling Out Active Directory-Bound Problems). If most or all of the boxes in the Exchange site are not experiencing high CPU utilization then there is probably a system specific reason for high CPU time. Look for hardcoded applications, improperly balanced load due to tuning LDAP Weights and Priorities (Check out Why you need Active Directory for Exchange Server 2007 for details on how this works), or anything else which may indicate why on GC is being singled out compared to the rest. Fix that issue before adding more hardware.

Network:

• If the outbound queue length is > 0 sustained the easy fixes are:
  • Update the NIC drivers to the latest versions if possible
  • Disable the Scalable Networking pack features (SNP) on Windows 2003 base servers- An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers. Check the network card settings to see if your driver can enable or disable certain SNP offloading features. Depending on the driver, if you disable these settings at the OS level, there is a possibility that they can still be enabled directly on the network card settings.
  • If the DCs are running Windows 2003 and the Exchange Servers are running on Windows 2008, then apply the Scalable Networking Pack rollup on the DCs to ensure that known compatibility issues do not occur. Also be aware of a known Windows 2008 TCP/IP setting issue in http://support.microsoft.com/kb/967224 that can affect overall network connectivity and performance.
  • Ensure that the NIC speed/duplex settings are properly set. MS recommendations, as of this writing, recommend both the GC and switch be set to 100/Full for 100 Mb segments and Auto/Auto for GigE segments. Check the Network Interface\Current Bandwidth performance counter to ensure that network card auto-negotiation is not changing the speeds the network card. This value should remain consistent at one value throughout the lifetime of the server being online.
  • Disable the load balancing/fault tolerance features of the NIC driver suite.
• Ensure that Network Interface\Packets Outbound Errors performance counters remains at 0 all the time. Any increases in this value can indicate intermittent connectivity issues on the server.
• If the network connection is using more 60% to 80% of the maximum bandwidth, the only solutions are to upgrade the available bandwidth (100Mb > GigE) or distribute the load across multiple servers/network connections.

Identifying the source of the GC load

The possibility exists that, despite the DC being either disk or processor bound, that the load is unnecessary. To determine this, the load on the box must be analyzed in greater detail than just the performance can provide. To that end, there are two main strategies for identifying the load on the box, both of which can be used concurrently. How to analyze this data is somewhat out of scope of this article, but the below bullets contain links to useful articles on how to use this data:

• Enable diagnostic logging on the DC by setting the "15 Field Engineering" registry value in order to identify expensive queries that return greater than 1,000 objects.
  • For more details on how to use this reference:
    • Logging LDAP searches: AD and ADAM > ActiveDir.org
    • Creating More Efficient Microsoft Active Directory-Enabled Applications
  • Pros
    • Shows the expensive or inefficient LDAP queries
    • The data is easy to get to since it is stored in the DS log
    • Data collection and alerting can be automated using SCOM.
  • Cons
    • Can overwrite the logs quickly, but the irony here is that if it is flushing the logs quickly, there is probably a lot of expensive queries that need to be remediated.
    • Doesn't actually track the processor impact of the query.
    • Only reports on LDAP queries.
• Use SPA (note this functionality exists natively in Windows 2008 and is entitled Performance Logs and Alerts which is part of Windows Reliability and Performance Monitor)
  • More details
    • Brad Rutkowski's Blog : Great tool for Windows 2003: Server Performance Advisor (SPA)
    • Download details: Microsoft ® Windows Server T 2003 Performance Advisor
    • Brad Rutkowski's Blog : Interacting with Data Collector Sets via Powershell
    • tonymurray : Troubleshooting LDAP issues with Server Performance Advisor (SPA)
    • Tracking LDAP Searches with Windows Server 2008 Reliability and Performance Monitor > ActiveDir.org
  • Pros
    • Shows everything that is going on, whether it is authentication, LDAP queries, network traffic, or disk IO.
    • Data collection can be triggered using SCOM when certain thresholds are hit.
  • Cons
    • On busy DCs the logging can quickly grow to unmanageable levels (busy being hundreds of LDAP queries and authentications per second). Think on the order of 100+ MB per minute. But this isn't too bad as usually a 5 to 10 minute data collection during a production issue will get the data necessary to identify what is occurring.
    • Requires the installation of a tool set (Windows 2003 only)

Conclusion

Data collection is key! Getting the right data when the problem occurs is absolutely critical to the restoring the health of the environment. Furthermore, as Exchange is the product suffering when its dependencies are not responding adequately, it falls on the Exchange administrator to do the leg work collecting the right data from the perspective of Exchange, and then isolating where the network, DNS, and AD administrators might need to look and start collecting data. Without this information, the network, DNS, and AD admins will be looking for a needle in a haystack and it is highly unlikely that they will find anything of use. Thus, once the Exchange admin has isolated the dependencies of concern, using the information provided here, it will be much easier to collect the data necessary from those systems to remediate any issues.

Thanks to Rod Fournier and Mike Lagase for their endless suggestions for improvement of this blog post.

- Ken Brumfield

Our friends over in the Data Protection Manager product group recently posted this article on how you can protect your Exchange 2010 high availability architecture using the next version of Data Protection Manager.  To find out more about DPM 2010, head over to the DPM blog.

- Ross Smith IV

==Version 3.5 Updates==

Version 3.5 introduces the following fixes:

• Improved the text on the input tab with regards to the number of database copy instances you would like for both HA and lagged copies.
• Fixes an issue where in a high availability architecture the calculator may size the solution based on activating more database copies during a second server failure event than the total number of database copies deployed on the server.

==Version 3.4 Updates==

Version 3.4 corrects a memory and CPU utilization issue where you deploy a site resilient architecture with multiple mailbox servers and a single database copy in the primary datacenter.  Specifically, the calculator would determine the active database copy configuration after a single server failure and then size the CPU and memory requirements.  However, since there is only a single database copy in the primary datacenter, the solution cannot survive with all copies hosted in the primary datacenter.  Therefore, the copies need to be activated in the secondary datacenter.  Version 3.4 corrects this scenario by ensuring there are at least 2 database copies in the primary datacenter in order  to calculate the active database count after a single server failure.

==Version 3.2 Updates==

It's been a while since we discussed the Exchange 2010 Mailbox Server Role Requirements Calculator. Well I am pleased to say that today we are launching version 3.2 of the calculator.

This version includes the following improvements and new features:

• Added processor core guidance for Hub Transport and Client Access server roles.
• Added the ability to define a custom number of databases that you would like to implement in the solution.
• Added support for 2-node site resilient Database Availability Groups.
• Added 1 and 6 processor cores as selectable options.
• Improved breakdown of the activation scenarios in a site resilient solution.
• Improved breakout of the role requirements section.
• The Storage Design tab now indicates that when you select a custom RAID configuration that the calculator ignores RAID-5 and RAID-6 for 5.xK and 7.2K spindles due to performance concerns.
• Updated processor utilization results to show the processor utilization even if it is above the recommended threshold.
• Made conditional formatting improvements throughout the calculator to warn you when you have a configuration that will not work.
• Improved various cell comments.

This version also corrects the following bugs:

• Fixed LUN Requirements tables to accurately reflect space requirements when database copies are deployed as each server may not host all database copies.
• Fixed conditions that resulted in -1 lagged copies.
• Improved the active database copies after first/second server failure calculations:
  • We now calculate and expose the worst case scenario (the server that has to host the most active databases) is used in sizing memory and CPU.
  • We now ensure that the secondary datacenter calculations only consider double server failures when there are 3+ HA copies located in the secondary datacenter.
• Removed maximum memory stipulation in the minimum ESE cache memory calculation.

Hey where is Active/Active?

And for those that I know will ask, this version of the calculator does not include the Active/Active user distribution site resiliency scenario. For those that need that scenario, what I recommend is the following:

1. Launch two versions of the calculator.
2. Populate the first version for the first DAG in your design. This DAG (DAG1) will utilize Datacenter 1 as its primary location (and thus its user population is based out of Datacenter 1). It has site resiliency by having servers and database copies located in Datacenter 2 that can be activated in the event Datacenter 1 is lost.
3. Populate the second version for the second DAG in your design. This DAG (DAG2) will utilize Datacenter 2 as its primary location (and thus its user population is based out of Datacenter 2). It has site resiliency by having servers and database copies located in Datacenter 1 that can be activated in the event Datacenter 2 is lost.

By implementing the architecture in this way, you can ensure that for the majority of scenarios except loss of datacenter, the users remain operational in their primary datacenter location.

Conclusion

Hopefully you will find this calculator invaluable in helping to determine your mailbox server role requirements for Exchange 2010 mailbox servers. If you have any questions or suggestions, please email strgcalc AT microsoft DOT com.

For the explanation of different tabs and how the calculator works, go here. Yup, we updated that too!

Finally, to get the new calculator - go here.

- Ross Smith IV

Early 2008 we have posted a blog entry with a VB script that generates some pre-canned reports that are based on message tracking logs. The script has proven to be useful in understanding Microsoft's Exchange work load and guide some design decision for Exchange 2010. This script was developed by Todd Luttinen, Principal Program Manager at Microsoft.

During the development of Exchange 2010, we needed to extended our log analysis beyond just message tracking and to answer a variety of questions that assist with design decisions. This exposed a bottle neck with having a single script that has all the parsing and analyzers bundled together.

This resulted in the creation of ExLogAnalyzer by Victor Boctor, Principal Architect at Microsoft. ExLogAnalyzer was developed in C# with the following goals:

• Separation of syntax and semantics.
• Multi-Server support (process log files that span multiple servers). Log events across servers are processed in chronological order.
• Multi-Log Type support (process / cross reference logs of different log types to produce a single report). Log events across log types are processed in chronological order.
• Provide an extensibility model to support rapid development and distribution of extensions (to support new log types) and analyzers (to encapsulate reporting logic).
• Ability for the community to develop their own analyzers or even extensions.
• Support for Exchange 2007 / 2010 log types.

The main shift in this model, compared to the previous script, is that ExLogAnalyzer is built as a framework that can be used to analyze Exchange as well as possibly any other log format. New log types are supported via plugins called "extensions". Extensions are responsible for doing all the parsing and converting of log lines into events, where each event triggers a method and passes all the pre-parsed information as the event arguments. The specific reports are also implemented as plugins known as "analyzers", where each analyzer handles the events it is interested in and does the appropriate accounting and report generation (typically in CSV format). Implementing each analyzer in isolation (rather than one script that answers multiple questions) makes it much simpler to develop, understand and distribute such analyzers. Such extensions and analyzers can also be easily shared given the plugin model. The following simple diagram summarizes the architecture of this tool:

The ExLogAnalyzer is now released to the community with the following extensions / analyzers available out of the box:

• Message Tracking Log
• MsgTrkTopSendersByDeliverLogAnalyzer - Generates the top 1000 senders based on mailbox deliveries. Messages to the internet are not counted.
• MsgTrkTopSendersBySubmitLogAnalyzer - Provides an analysis of the sender load distribution based on number of messages sent from their mailboxes.
• MsgTrkTopRecipientLogAnalyzer - Generates the top 1000 recipients based on mailbox deliveries. Messages to the internet are not counted.
• MsgTrkMessageSizeDistributionLogAnalyzer - Provides an understanding of the message size distribution.
• MsgTrkRecipientNotFoundLogAnalyzer - Discover and summarize recipients for which "Recipient Not Found" error was generated.
• MsgTrkMailflowVisualizerLogAnalyzer - Generates a directed graph showing the server being analyzed and all the inbound / outbound mail flow paths.
• MsgTrkComponentLatencyPercentileLogAnalyzer (E14) - Analyzes the latencies of the different components and determines the latencies experienced by the specified percentiles of messages.
• MsgTrkDuplicateDeliveryLogAnalyzer - Analyzes the sources for duplicate deliveries to Store. Note that end users don't see such duplicates.
• MsgTrkEventFrequencyLogAnalyzer - Provides an understanding of the distribution of the event + source combinations.
• MsgTrkEventTimeDistributionLogAnalyzer - Provides an understanding of the event distribution over time with a per hour resolution.
• MsgTrkExpandLogAnalyzer - Analyzes the distribution list expansion load on the system.
• MsgTrkReceiveLogAnalyzer - Analyzes the distribution of the sources for the messages received by a server or a set of servers.
• Smtp Receive Log
• SmtpReceiveWorkLoadLogAnalyzer - Analyzes the SMTP receive work load over time while tracking tarpitting, client time outs, etc.
• SmtpReceiveDelayedAckLogAnalyzer (E14) - Analysis of delayed ack performance over time. This report provides an overview of the redundancy that is achieved for legacy systems via delayed ack.
• SmtpReceiveFormatterLogAnalyzer - Re-writes the logs with each session in a separate file, it also reformats the log so that the common session information is included in the header, hence, making the session details more readable.
• SmtpReceiveSeparatorLogAnalyzer - Re-writes the logs with each session in a separate file while maintaining the exact log format.
• SmtpReceiveSessionIndexLogAnalyzer - Provides a summary of all sessions processed within the provided logs.
• Connectivity Log
• ConnectivityWorkLoadLogAnalyzer - An analyzer that samples the connections over time. This analyzer generates a CSV file per source (e.g. SMTP or MAPI).
• ConnectivityStatsLogAnalyzer - An analyzer that provides the frequency of sessions, failed and DNS failures per source + destination combination.
• ConnectivityFormatterLogAnalyzer - Re-writes the sessions as a file per session, moved all the common session information to the header to make the sessions more readable.

Sample Reports

Following are some samples to provide a feel of the outputs of some of these analyzers.

Mail Flow Visualizer (demonstrated possible visualization using directed graphs):

Message Size Distribution:

SmtpReceiveFormatterLog (log re-writing for splitting sessions and making them more readable):

# Session Id: 08CBDCECE3DDF231
# Start Time (local): 2009-07-28T11:07:46.922
# End Time (local): 2009-07-28T11:07:46.953
# Start Time (UTC): 2009-07-28T18:07:46.922Z
# End Time (UTC): 2009-07-28T18:07:46.953Z
# Disconnect Type: Local
# Connector Id: MyServer\MyServer_CrossForest
# Local End Point: 157.54.7.153:25
# Remote End Point: 157.54.71.39:4183

0000000,+,,
0000000,*,None,Set Session Permissions
0000000,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAuthenticationFlag SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender BypassAntiSpam BypassMessageSizeLimit SMTPAcceptEXCH50 AcceptRoutingHeaders AcceptForestHeaders AcceptOrganizationHeaders SMTPAcceptXShadow,Set Session Permissions
0000000,>,220 MyServer E14 Cross Forest,
0000000,<,EHLO otherhost.otherforest.microsoft.com,
0000000,>,250-MyServer.redmond.corp.contoso.com Hello [157.54.71.39],
0000000,>,250-SIZE 10485760,
0000000,>,250-PIPELINING,
0000000,>,250-DSN,
0000000,>,250-ENHANCEDSTATUSCODES,
0000000,>,250-AUTH,
0000000,>,250-8BITMIME,
0000000,>,250-BINARYMIME,
0000000,>,250-CHUNKING,
0000000,>,250-XEXCH50,
0000000,>,250 XSHADOW,
0000000,<,XSHADOW 3333YTkxYjEtYzE1OC00NDcxLWI4OTktMDA2NDI5YmVmZWRlQFRLNUVYMTRNTFRXNjUxLndpbmdyb3VwLndpbmRlcGxveS5udGRldi5taWNyb3NvZnQuY39t,
0000000,>,250 q7rdaFIdKk3NNRTbjRsjrQ==,
0000000,<,MAIL FROM:<sender@contoso.com> SIZE=25477 XSHADOW=70136df4-c89b-4700-9654-b642c4eb78bb,
0000000,*,08CBDCECE3DDF231;2009-07-28T18:07:46.922Z;1,receiving message
0000000,<,RCPT TO:<receiver@contoso.com> ORCPT=rfc822;receiver2@contoso.com,
0000000,>,250 2.1.0 Sender OK,
0000000,>,250 2.1.5 Recipient OK,
0000000,<,XEXCH50 1136 2,
0000000,>,354 Send binary data,
0000015,>,250 2.0.0 XEXCH50 OK,
0000015,<,BDAT 25477 LAST,
0000031,>,250 2.6.0 <DB82FD8C490D4F43ACE766C04B23A7050F0F12@someserver.otherforest.contoso.com> [InternalId=16796908] Queued mail for delivery,
0000031,<,XQDISCARD 50,
0000031,>,251 OK, no discard events,
0000031,<,QUIT,
0000031,>,221 2.0.0 Service closing transmission channel,
0000031,-,,Local

Top Senders by Submit (analysis yielding CSV - full report has top 1000):

Sender Distribution by Submit (analysis yielding CSV):

Distribution Group Expansion Analyzer (analysis yielding CSV):

Getting started

• Download ExLogAnalyzer from here.
• Checkout the Power Point slide deck included in the download for more details about ExLogAnalyzer.
• Use ExLogAnalyzer and its distributed sample analyzers to analyze your logs.
• Develop your own analyzers. Visual Studio and Visual C# Express Edition are the recommended tools. However, you can use Notepad or your favorite editor, given that ExLogAnalyzer detects and compiles the analyzer CSharp files at runtime.
• Provide us with feedback about ExLogAnalyzer, sample analyzers or the development process.
• Share your analyzers or ideas for useful new analyzers with the Exchange community.

- Victor Boctor

You requested it... and we delivered it in Exchange 2010!

One of the most requested items in exchange 2007 was something like this...

...we have 5-12 external domains that we need to allow some users to send to, but prevent sending to all other domains...

Or like this...

...we need a way to allow everyone to send to the internet but restrict members of 'contract workers group' to just certain domains. 

This blog post is meant to show how easy it now is to accomplish this oft heard request in Exchange 2010. Transport rules, introduced with Exchange 2007, provided a lot of new options for administration of mail resulting in even more requests for additional functionality. The rules now have new predicates and actions extending the possibilities of what can be done.

In particular, the predicates for address matching that were previously only available on the Edge role are now available for Hub role as well!

For more information about the new predicate and actions see the following links below:

Exchange 2010 Transport Rule Predicates:
http://technet.microsoft.com/en-us/library/dd638183.aspx

Exchange 2010 Transport Rule Actions:
http://technet.microsoft.com/en-us/library/aa998315.aspx

So I will use the 2nd "request" above to demonstrate how to create a rule in 2010 to accomplish it.

For our example, the rule will restrict "Active Directory Mail enabled users" who have their 'Department' defined as 'Temp Employees' from sending mail to the internet, except they must be allowed to send to 2 external domains called: 'partnerdomain.com' and 'fourthcoffee.com'. Additionally, to reduce Helpdesk calls, you want to send an NDR when they violate the rule. For demonstration purposes I will use 2 Conditions, one Action and one Exception.

Creating a new rule

1. Conditions

a. First condition:

"Sent to users that are inside or outside the Organization, or partners"

Screenshot #1 above, set the dropdown to Outside the Organization option

b. Second condition:

"When the sender's properties match text patterns".

Now note the new options with this in the 3rd screenshot below allowing selection of Active Directory properties on the user object!

Here we will be using the 'Title' property to match the rule to a sender.

2. Actions

"Send rejection message to sender with enhanced status code". The text you add here is displayed in the "Diagnostic information for administrators:" section of the NDR and can say whatever you wish.  Originally I started out with "You may only send internet mail to @fourthcoffee.com and partnerdomain.com".

While the NDR provides the information, it is somewhat 'hidden' to be practical for your typical user, so I will create a customized DSN. At this point, all we need to do is specify the text and enhanced status code for our administrators.  The new text will be "Diagnostic information for System Administrators" and we specified a specific and unique error code 5.7.122 that is easy for administrators to associate with this rule, should troubleshooting be necessary.

3. Exceptions

"Except when a recipient's address matches text patterns". This is where we add domains that these senders are allowed to send mail to on the "Specify text patterns" dialog box.

And finally, this is the customized NDR that senders receive when violating the rule we created. This test was to two recipients where one is an allowed domain, Janer@fourthcoffee.com, and another is not an allowed domain: mthomas@e2k3.dom.

Notice how the NDR was only generated for the rejected recipient.  All other recipients were allowed through.

For more information:

- Understanding Transport Rules
http://technet.microsoft.com/en-us/library/dd351127.aspx

- Understanding How Transport Rules Are Applied
http://technet.microsoft.com/en-us/library/bb124703(EXCHG.140).aspx

- Create a Custom DSN
http://technet.microsoft.com/en-us/library/aa996803.aspx

- Associating a DSN Message with a Transport Rule
http://technet.microsoft.com/en-us/library/bb123506(EXCHG.80).aspx

- Dave Forrest
(Contributions by Scott Landry, Stephen Gilbert and Steve Clagg)

In November, we launched the Exchange Server 2010 Deployment Assistant. In the initial version of the Deployment Assistant, content was available for customers upgrading from Exchange 2003. We are happy to announce that today we've released content for the following scenarios to http://technet.microsoft.com/exdeploy2010:

• Upgrading from Exchange Server 2007
• Upgrading from a mixed Exchange Server 2003/2007
• New Exchange Server 2010 installation

The Deployment Assistant allows you to create Exchange 2010 deployment instructions that are customized to your environment. The Deployment Assistant asks a small set of questions, and based on your answers, it provides a set of instructions that are designed to get you up and running on Exchange 2010. Instead of reading dozens of topics in the Exchange 2010 library, you simply answer a few questions, and the Deployment Assistant gives you customized content to install Exchange 2010.

The feedback on our initial release was very positive. We would love your feedback on these new scenarios, as well. Feel free to leave a comment here, or send an email to edafdbk@microsoft.com via the 'Feedback' link located in the header of every page of the Deployment Assistant. Send us your 'success stories' after using this tool! We'd love to hear about them, too!

-- Katie Kivett
Microsoft Exchange Deployment Assistant PM

The Delivery Reports feature which was introduced in Exchange 2010 enables both Information Workers, and administrators to view delivery status of messages and discover answers to questions such as: why a message was not delivered, where a message is now, who received a message, why a message was delivered to a particular folder, etc. While an earlier post introduced the Delivery Reports feature and provided an overview of its functionality, this post will dive a bit further into their architecture and how administrators can use them.

From an admin perspective the Delivery Reports feature was designed to assist in quickly and easily answering questions users may have around why a message they were supposed to receive (or a message they sent) was not delivered. Unlike previous versions of Exchange which forced administrators to manually examine the Message Tracking logs on multiple servers when troubleshooting missing (or delayed) messages, Message tracking logs in Exchange 2010 are automatically index and by using the Delivery Reports feature admins can quickly view a report which displays the Message Tracking events from all servers a message passed through. There are a number of ways Admins can access the Delivery Reports feature, namely: EMC (from the Toolbox), ECP (from Options -> Reporting), or via PowerShell Tasks.

Using ECP to track a message as an Administrator

Delivery Reports in ECP

If a user complains that a message they sent was not delivered the following steps can be used to track the message:

1. Under "Mailbox to search", select the user's mailbox of the user who reported the issue.

2. Select "Search for messages sent to:", and select the users who were supposed to receive the message. (Hint: If the message was sent to someone an internet recipient you can SMTP addresses under "Message Recipients" )

3. To reduce the number of results, you can also optionally specify keywords for the subject by entering in "Search for these words in the subject line"

4. Click "Search"

5. A list of messages will appear in the Search Results pane. To view the Delivery Report details for a specific message simply double-click on it.

If a user complains that they did not receive a message they were supposed to the following steps can be used to track the message:

1. Under "Mailbox to search", select the user's mailbox of the user who reported the issue.

2. Select "Search for messages received from:", and select the user who sent the message. (Hint: If the message came from an internet sender you can enter their SMTP addresses under "Message Recipients" )

3. To reduce the number of results, you can also optionally specify keywords for the subject by entering in "Search for these words in the subject line"

4. Click "Search"

5. A list of messages will appear in the Search Results pane. To view the Delivery Report details for a specific message simply double-click on it.

Delivery Reports Architecture

The following diagram provides a high-level overview of the architecture for the Delivery Reports feature (a.k.a. tracking). Please click for full size version:

In the above example a user uses ECP to track a message which was sent from a user on Mailbox Server 1 to a recipient on Mailbox Server 2.

1. ECP Calls the Search-MessageTrackingReport task and specifies the parameters of the search.

2. The Search-MessageTrackingReport task finds the senders Mailbox Server.

3. The Log Search Service running on Mailbox Server 1 is queried with the search parameters to determine where the message was sent to next.

Note: The Log Search Service, which provides Delivery Reports with a query-able interface to data in the Message Tracking logs, generally loads about two weeks' worth of data (though this number may vary depending on server configuration, mailflow, etc ).

4. As the message went from Mailbox Server 1 to Hub Server 1, tracking follows the path and queries the Log Search Service on Hub Server 1 to determine what happened to the message next

5. Tracking then discovers that the message went across a boundary (Premise/ Forest/ Site).

6. Tracking makes an EWS request to CAS Server 2 in the remote premise/forest/site.

7. CAS Server 2 Queries the Log Search Service on Hub Server 2

8. The message is followed to Mailbox Server 2

9. Delivery Status information is retrieved and returned to CAS 2

10. CAS 2 returns the delivery status information to CAS 1

11. The task merges all of the results and returns them to the user through ECP.

Tip: Configure the Message Tracking files sizes for each server in such a way that the log data will be persisted for about the same length of time on each server, as tracking depends on the log information being available at each hop.

- Naveen Chand

There is potential for calendar related problems when new diagnostic logging for Message Access, which is available in Exchange Server 2007 Service Pack 2 (SP2) is raised from its default setting of Lowest. 

A Knowledge Base article and a fix are in the works at this time and will be available soon.

Important - some calendar items may remain broken even after applying the update. This post addresses scenarios where those lingering symptoms remain.

What the users may see

Symptoms before applying the pending update:

• Access to recurring appointments (which have attachments for the instances) is broken - Outlook in online mode receives an "Item cannot be opened" error.
• Sending an embedded message in cached mode results in the attachment being stripped.
• Availability is not shown for some users.

The following symptoms may persist, even after applying the update or manually setting the Message Access diagnostic level back to Lowest:

• Certain users show no availability information from Outlook or OWA scheduling assistant.  Also, event id 4009 for MSExchange Availability is logged on servers with the CAS role

Exception returned:

Microsoft.Exchange.Data.Storage.ObjectNotFoundException: Cannot open embedded message.

• Delegates viewing calendars receive the error:

Cannot read on instance of this recurring appointment. Close any open appointments and try again, or recreate the appointment

• Messages are sent to ActiveSync devices with the following text:

Microsoft Exchange was unable to send the following items to your mobile device. These items have not been deleted. You should be able to access them using either Outlook or Outlook Web Access.

• When accessing Calendar from OWA, the day, week or month viewing will fail with the error:

The item that you attempted to access no longer exists.

We have determined these symptoms are primarily due to calendar items affected between the time logging was increased and when the pending update or workaround is implemented. Recurring calendar items with no end date that have had an occurrence modified seem most susceptible.  A quick method to find these visually is to look for the circling arrows with a line through it.

Does this apply to you?

Before the release of the pending update, if any Exchange Server 2007 SP2 server with the Mailbox role has the following new event log level raised from Lowest, this applies to you.

MSExchangeIS\9000 Private\Message Access

How to check your Organization for the problem

You can determine if your MBX servers are at risk by looking in the following places:

1) The new GUI introduced in SP2 - in the Exchange Management Console under Server Configuration, Mailbox, select the server and choose Manage Diagnostic Logging Properties...

2) In the registry for each MBX server [Lowest = 0]

3) Run the following Exchange CMDlet to find all Exchange 2007 MBX servers and this specific diagnostic logging level for Message Access:

Get-MailboxServer | foreach {Get-EventLogLevel -id ($_.name + "\MSExchangeIS\9000 Private\Message Access")}

How to correct the problem

If any MBX server is found to have logging above the default before the pending update is applied, you should reset it to Lowest manually.  Note which MBX servers are configured with the non-default level and then run this CMDlet to ensure they are all set to "Lowest"

Then either remount the databases or restart the Information Store service.

Get-MailboxServer | foreach {Set-EventLogLevel -id ($_.name + "\MSExchangeIS\9000 Private\Message Access") -Level "Lowest"}

A sample PowerShell script is available here to track down calendar items contributing to the symptoms that persist after applying the workaround detailed above.  This script will identify the day containing problem appointments and can be run against a specific mailbox or all Exchange 2007 mailboxes.  The requirements for running the script are detailed in the script comments. The sample script uses the $true argument to enumerate all Exchange 2007 mailboxes and user42@contoso.com to initialize the Autodiscover portion of the Web Services object:

[PS] C:\Powershell\scripts> .\Find-BadCalendarItems.ps1 user42@contoso.com $true
Checking mailbox: user01@contoso.com
Checking mailbox: user02@contoso.com
...
Checking mailbox: user42@contoso.com
Checking mailbox: repro01@contoso.com
Failed: 11/30/2009 - 12/30/2009

Error: Mailbox logon failed., inner exception: Cannot open embedded message.

Day failed: 12/2/2009
Checking mailbox: repro02@contoso.com
Failed : 11/30/2009 - 12/30/2009

Error: Mailbox logon failed., inner exception: Cannot open embedded message.

Day failed: 12/23/2009
Checking mailbox: user43@contoso.com
Checking mailbox: lastuser@contoso.com
Problems found:
repro01@contoso.com: 12/2/2009
repro02@contoso.com: 12/23/2009
Done!

Now that 12/23/2009 has been identified as the problem date for user repro02@contoso.com, you can use Outlook to find any recurring calendar items with no end date that have had an occurrence modified on that day. Copy that occurrence [either to a temporary Calendar folder or even to a different time that day] then delete just that occurrence. Moving the copy back or manually recreating the instance will resolve the symptom for that user.

- Austin McCollum, Bill Long, Jon Runyon, Kris Waters

It is common for Exchange organizations to include different versions of Exchange. Interoperability scenarios present challenges to administrators for maintaining the different tool sets required to manage different versions of recipient and configuration objects in the organization. It is important to understand the implications of using Exchange 2010 management tools in these situations. Some of this information may change in the future.

Exchange Object Versions

Exchange management tools generally take some action against objects that are stored in the Active Directory (AD) directory. These objects can be recipient objects (Mailbox enabled accounts, mail enabled accounts, mail contacts, etc...) or they can be Exchange configuration objects (Exchange servers, mailbox databases, connectors, etc...)

Exchange uses a property that tags an object as "belonging" to one specific version of Exchange. The property in AD is msExchangeVersion. To quickly check the Exchange version of an object, from the Exchange Management Shell, use the "Get" cmdlet for that object type, and issue a command like the following which gets the ExchangeVersion property value for a mailbox enabled user:

[PS] C:\> Get-Mailbox user1 | Format-List ExchangeVersion
ExchangeVersion : 0.10 (14.0.100.0)

In this example, the version is 14.0.100. This is the version of Exchange that was used to create this recipient object. For a management tool to be able to manage this object, it must be for version 14.0.100 or higher.

All Exchange objects are stamped with an ExchangeVersion value, and it is in this way that management tool interoperability is controlled.

Exchange 2003 Interoperability

The Exchange System Manager (ESM) is the primary management interface for Exchange 2003. The ESM does not have a direct interface for managing recipient objects, instead relying on the Active Directory Users and Computers (ADUC) to be installed on the same machine to expose property pages for recipient objects. The following limitations apply to management tool interoperability:

• Exchange 2010 management tools can be used to view Exchange 2003 recipient objects, but not the other way around.
• The ESM cannot be used to manage any configuration objects for Exchange 2010.
• The Exchange 2010 management tools can be used to view certain Exchange 2003 configuration objects, but not make any modifications.

Exchange 2007 Interoperability

Both Exchange 2007 and Exchange 2010 use their own versions of EMC and EMS. Interoperability limitations between Exchange 2007 and Exchange 2010 management tools can be more difficult to understand because of the similarity between the tools.

The following matrix will help to determine what can be done from each tool.

EMC Management Tool Interoperability:

Additional Scenarios

Move Mailbox

• Exchange Server 2007 EMC cannot move an Exchange Server 2007 mailbox to an Exchange Server 2010 server, or move an Exchange Server 2010 mailbox to an Exchange Server 2010/Exchange Server 2007 server.
• Exchange Server 2010 EMC can move an Exchange Server 2010/Exchange Server 2007 mailbox to an Exchange Server 2010/Exchange Server 2007 server.
• When an Exchange Server 2007 mailbox is moved to an Exchange Server 2010 sever, the mailbox is upgraded to Exchange Server 2010 version. After the version upgrade, the mailbox should still work with the associated policies (ActiveSync, OWA, UM, etc) that are in a down-version. (Open Issue)
• When moved back to an Exchange Server 2007 server from an Exchange Server 2010 server, the mailbox is downgraded to Exchange Server 2007.

Move OAB

• Exchange Server 2010 EMC can move an Exchange Server 2007/Exchange 2003 OAB to an Exchange Server 2010/Exchange Server 2007/Exchange 2003 server.
• Exchange Server 2010 EMC can move an Exchange Server 2010 OAB to an Exchange Server 2007/Exchange 2003 server.

Send Connector Source/Send Server

• Exchange Server 2007 EMC can set either an Exchange Server 2007 or Exchange Server 2010 transport server as the source server of a send connector.
• Exchange Server 2010 EMC can set either an Exchange Server 2010 or Exchange Server 2007 transport server as the source server of a send connector.

Queue Viewer

• Exchange Server 2007 Queue Viewer snap-in cannot connect to an Exchange Server 2010 server to view Exchange Server 2010 queues or messages.
• Exchange Server 2010 Queue Viewer snap-in cannot connect to an Exchange Server 2007 server to view Exchange Server 2007 queues or messages.

The limitations that are imposed in the EMC can be translated to limitations that also exist in EMS when using the same underlying PowerShell commands. For example, when viewing the properties for a mailbox in EMC, the Get-Mailbox command is used in the background to populate the property information. If a change is made, the Set-Mailbox command is used to make the change to the mailbox object. In some situations it may be possible to view information for an object that was created with one tool version, but not make any changes.

The limitations depend on specific conditions and can be related to the configuration management levels exposed in EMC: Organization Configuration, Server Configuration and Recipient Configuration.

Organization Configuration

Organization objects are global in nature and can be managed using both versions of management tools with some specific exceptions.

Exchange 2010 mailbox and public folder databases only appear under the Organization Configuration node in the Exchange 2010 EMC. Exchange 2007 mailbox and public folder databases appear under the Server Configuration node in Exchange 2007 EMC.

Messaging Records Management features for Exchange 2010 (MRM v2) only appear under the Organization Configuration node in the Exchange 2010 EMC. MRM v1 features appear in both versions and can be managed from both tools.

Server Configuration

Server management is very clear cut in EMC interoperability scenarios. Exchange 2007 servers do not appear in the result pane of the Exchange 2010 EMC and vice versa.

EMS commands for server configuration can be used from either version of EMS as long as the cmdlet does not depend on a specific configuration object version on the target. A message is generated and no changes are made if the cmdlet is not compatible.

Recipient Configuration

Recipient Objects that are created with Exchange 2007 management tools can be managed using both tool sets. Recipient Objects that are created using Exchange 2010 management tools can only be managed using Exchange 2010 management tools. Exchange 2007 SP2 management tools have logic to validate actions based on object type. When attempting to manage an Exchange 2007 object, an informational message is seen similar to this:

After clicking the OK button the properties are not activated for change but can be viewed. A similar message is generated with trying to modify an Exchange 2010 recipient object using an Exchange 2007 EMS command as shown in the following example where Set-Mailbox is used in Exchange 2007 EMS to attempt a change to an Exchange 2010 mailbox:

[PS] C:\>set-mailbox user2 -CustomAttribute1 "some value"
Set-Mailbox : Object is read only because it was created by a future version of Exchange: 0.10 (14.0.100.0). Current supported version is 0.1 (8.0.535.0).
At line:1 char:12
+ set-mailbox <<<< user2 -CustomAttribute1 "some value"
+ CategoryInfo : NotSpecified: (0:Int32) [Set-Mailbox], InvalidADObjectOperationException + FullyQualifiedErrorId : 855E94FC,Microsoft.Exchange.Management.RecipientTasks.SetMailbox

Using Get-Mailbox in this instance works as expected because the command only retrieves information but does not make any changes.

Side-by-Side Management Tools

Exchange 2010 and Exchange 2007 Service Pack 2 (SP2) make it possible to deploy the different versions of Exchange Management Shell (EMS) and Exchange Management Console (EMC) from both products on the same workstation in a configuration called Side-by-Side Deployment. Both sets of management tools are then available from the Programs menu as shown:

Both versions of EMC and EMS can be opened and used independently from the other version. The following shot shows both versions of EMC open on the same machine. Alternatively, the snap-in for Exchange 2007 EMC and Exchange 2010 EMC can both be added to the same console.

Prerequisites for Side-by-Side Deployment

The following Windows operating systems are supported for the Exchange Management Tool role:

• Windows Vista SP2 x64 bit
• Windows 2008 SP2 x64 bit

The prerequisites for installing Exchange 2007 and Exchange 2010 Management tools in a side-by-side deployment are:

• .Net Framework 3.5 and 3.5 SP1
• Windows Remote Management v2.0
• Windows PowerShell v2.0
• Windows Installer version 4.5 is required to install Exchange 2007 SP2 on Vista SP2, but is not required on Windows Server 2008 SP2 because it is already included.
• Internet Information Services (IIS) features IIS 6 Metabase Compatibility (Web-Metabase) and IIS 6 Management Console (Web-Lgcy-Mgmt-Console).

Both sets of management tools use similarly named files. To limit confusion between file sets, the Exchange 2007 files and Exchange 2010 files are stored in different locations. The Exchange 2007 files by default are stored in folders directly under the Program Files\Microsoft\Exchange Server directory while the Exchange 2010 files are stored in the V14 folder in the same directory as shown:

- Charlotte Raymundo, Jonathan Runyon, Nagesh Mahadev

We have started getting more and more questions (as well as some support cases) around Address List Segregation with Exchange 2010. Some of our customers have also assumed that the existing Exchange 2007 documentation on the subject would just apply to Exchange 2010 also and have tried to configure this, usually with bad results.

Dave Goldman - one of people who worked on the Exchange 2007 document - has just posted a blog post detailing the status of the existing document and it's use with Exchange 2010. In short: DON'T DO IT. There is a new document in works for Exchange 2010 and we will definitely let you know when it releases, but trying to apply Exchange 2007 document to Exchange 2010 leads to Bad Things.

You can see Dave's blog post here.

- Nino Bilic

I am delighted to announce that on March 1st 2010 we will be delivering the first session of the Microsoft Certified Master program for Exchange Server 2010.

We delivered our very last 2007 based rotation back in October. Over the programs lifetime we have delivered the course 26 times, trained over 300 people overall, and about 230 people or so have gained at least one certification (MCM 2003/7 and MCA 2003/7 are those in play). These people are some of the best and most experienced Exchange experts in the world. Most of them go on to do great things, work with some great customers and do amazing work. You can read about some of their experiences over at our blog and pick up some tips on how to do well on the program if you ever decide to attend.

For the March delivery I actually still have a few seats, and because the 2010 pre-req exams only just came out, I'm accepting the 2007 exams instead. Remember though, those exams aren't going to prepare you for MCM, but they are a start. If you've already got your hands onto 2010, and you really will need to have worked with it to do well, and you have a great knowledge of 2007 and even 2003, then you could be just what I'm looking for.

Another piece of great news is that we are now accepting Premier Hours as a form of payment. Premier hours are something our Premier Support customers buy at the beginning of each year, and use up when they raise support cases, or take advantage of our other service offerings. Well the good news is, if you have a bunch of hours and nothing to spend them on.. you can use them to pay for MCM! Please ask your TAM about it, and if they don't know about it yet, don't be too hard on them, it's only just come about and they are still reading through their holiday season email backlog most likely!

So if you think you have what it takes, and really do want to be one of the first people in the world to be able to use the MCM 2010 title, then you need to sign up, and do it now.

Go to http://www.microsoft.com/learning/en/us/certification/master.aspx - read about it, read the blog, get signed up, and if you have any questions, email me or post a comment here.

-- Greg Taylor