You Had Me At EHLO...

What's new with Exchange 2010 languages support?

Exchange — Tue, 09 Feb 2010 13:30:00 GMT

With the launch of Exchange 2010, we have introduced a new way to manage the set of languages available for Exchange.

In previous versions of Exchange, you had one server language per DVD. In Exchange 2010, we have changed to a new language neutral design. This allows us to release all available languages in a single DVD. We can also add and update additional languages over the lifetime of the product. This model also allows us to easily update the translation quality over the lifetime of the product. We are no longer dependent on component updates or service pack deployments.

We provide this flexibility through the use of a language pack bundle. The Exchange 2010 RTM DVD contains our initial version of this bundle. Exchange Setup will install this bundle from the DVD, from a network share, or recommend you to download the most up to date version of the bundle if your server has internet access. Since Exchange 2010 RTM, we have released an updated build of the bundle, available from here. Our recommendation is that all customers deploy this updated bundle as it contains both additional client languages, as well as translation improvements for all the languages. An up to date list of supported languages can be found in Exchange 2010 Language Support. Going forward, we do expect to release updated language pack bundles to improve quality and add additional languages.

The language bundle is delivered as a single downloadable file which includes all localized resources for the server— including Exchange Management Console (EMC) and client (OWA & ECP) interfaces within Exchange. To get a localized experience in EMC, ECP and OWA, you need to install the language pack. Listed below are three scenarios that we would like to call out and provide guidance around them with regards to language pack installation.

Language pack bundle deployment as part of the initial server setup
This scenario applies to an environment where you are installing the language during the fresh setup of your server. We recommend you to install the Language pack in this scenario from the DVD. While the installation of the bundle is available from the usual graphical setup, commands line options are also available. For this scenario use:
Setup.com /mode:install /roles:.... [/LanguagePack:]
Language pack bundle deployment for the first time post initial server setup
This scenario applies to you, if you have set up your server first and now want to install the Language pack , we recommend you to download the latest Language pack from the download center and follow the steps therein. If you prefer to use the command line option, use :
Setup.com /mode:install /LanguagePack:
Language pack update
You are already using the language pack bundle, and now want to update it to the latest available. In this scenario, update the exiting bundle with the latest Language pack from the download center and follow the steps therein. In addition, you could also install it using the command line:
Setup.com /mode:upgrade [/LanguagePack:]

Note:
- Before installing the language pack bundle, ensure that your OS is installed in the language that you would like to use Exchange in.
- You should deploy the new or updated language pack bundle starting with your mailbox servers.
- After installing the Exchange language packs, restart the computer to complete the installation of the language packs.
- If there is no language pack bundle deployed, English will be the only language available for Client and Server, regardless of the OS Language.

-Kevin Allison

Troubleshooting Exchange 2010 Management Tools startup issues

Exchange — Thu, 04 Feb 2010 16:58:41 GMT

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

Triaging Exchange Performance issues related to Active Directory (AD) Performance (including Networking and DNS performance)

Exchange — Wed, 03 Feb 2010 15:03:13 GMT

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:

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
- 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

New Exchange 2010 Webcasts and Videos

Exchange — Mon, 01 Feb 2010 19:59:00 GMT

The new Exchange 2010 webcast series is live! Register to attend in-person via Live Meeting or download the recorded video or podcast. A full schedule of topics and presenters is below. Each webcast is 60min in length. Looking for something shorter? We also have a new series of "How Do I" videos dedicated to Exchange 2010 that can be found in the Exchange TechCenter. Keep up to date with all new content releases by joining the Exchange twitter feed (below).

Tweet!

As a member of the Exchange community - you can interact with our team through blogs, forums, and now a Twitter feed. Get all the latest Exchange news direct from the product team!

Webcast Series

TechNet Webcast: Introducing Exchange Server 2010
Presented by: Rand Morimoto
In a time when your organization requires its communication tools to be cost-effective and flexible, Microsoft Exchange Server 2010 enables you to achieve new levels of reliability and performance by delivering features that can simplify your administration, help protect your communications, and delight your users by meeting their demands for great business productivity. In this webcast we introduce you to Exchange Server 2010, as well as highlight and demonstrate key investments made in this latest release.
TechNet Webcast: Discover the New OWA: Outlook Web App
Presented by: Gary Danoys
The new Outlook Web App provides the most robust Web experience for accessing your Microsoft Exchange Server. With OWA 2010 users will get even more ways to communicate from the Web. From the new OWA IM and SMS Sync features to the incredible changes to the conversation view; new communications types and presentation methods abound to make users more productive. New features like MailTips, Side-by-side calendars, Delegate access, Delivery reports, and more are demonstrated. The new Exchange Control Panel (ECP) also makes end-user self-service features greatly enhanced meaning users can more easily manage their own issues. This webcasts focuses on the new end-user functions available in OWA 2010 as well as walks through the configuration of IM with Microsoft Office Communications Server 2007 R2 and helping IT pros troubleshoot common configuration errors in setting up OWA IM.
TechNet Webcast: Upgrade and Coexistence with Exchange Server 2007 and 2003
Presented by: Harold Wong
Walk through the process for introducing Exchange 2010 servers into an Exchange 2003/2007 organization. Learn the pre-requisites, steps required, and the impact to client access for MAPI, Outlook Anywhere, OWA, ActiveSync, and POP/IMAP clients after the upgrade has occurred.
TechNet Webcast: Information Protection and Control in Microsoft Exchange Server 2010
Presented by: Michael Smith
Worried about employees accidentally leaking valuable corporate e-mail? This webcast introduces new methods of information protection and control powered by Exchange Server 2010, including new transport rule for moderation, dynamic signatures and application of rights management. A discussion of the use of Active Directory Rights Management Service in parallel with Exchange is included, as well as an introduction to how these new features can be applied to real-world messaging control scenarios.
TechNet Webcast: Exchange Server 2010 High Availability
Presented by: Devin L. Ganger
Welcome to the future! The future of Exchange high availability, that is. In this webcast we reveal the changes and improvements to the built-in high availability platform in Exchange Server 2010. Exchange 2010 includes a unified solution for high availability and disaster recovery that is quick to deploy and easy to manage. Learn about all of the new features in Exchange 2010 that make it the most resilient, highly available version of Exchange ever.
TechNet Webcast: Getting the Most out of Exchange Server 2010: Performance and Scalability
Presented by: John Fullbright
Selecting the right server hardware for an Exchange 2010 deployment becomes much easier when you know the product team's scalability and performance guidelines. This webcast provides a look at the product team's guidance for the processor and memory requirements of each server role in Exchange 2010. A number of key performance enhancements from this release are discussed, and you also learn about how to use related tools like the Exchange Storage Calculator, Exchange Profile Analyzer, Loadgen, and Jetstress to take the guesswork out of server sizing.
TechNet Webcast: Deploying and Managing Microsoft Exchange Server 2010 Transport Servers
Presented by: David Elfassy
The transport server role in Exchange 2010 provides some exciting new management functionality to make mail flow issues easier to monitor and diagnose. This webcast shows you how you can best leverage this functionality including Direct Deliver, Shadow Redundancy, and transport SLA measurement and reporting. Learn how to plan for the most efficient transition -- whether you're moving from Exchange 2003 or 2007.
TechNet Webcast: Addressing E-mail Archiving and Retention
Presented by: Kamal Janardhan
As e-mail volume continues to grow, we recognize your user's desire for an infinite inbox and the IT Admin's goal to be able to preserve and discover these mailboxes in a cost-effective manner. To help address these needs, Exchange Server 2010 introduces integrated archiving along with message retention and multi-mailbox discovery capabilities. This webcast offers a technical deep dive and some demonstrations of the user and IT Pro archiving experience in Outlook and Outlook Web App, as well as Exchange Management Console and PowerShell. The session also highlights the message retention capabilities through Move and Delete Policies in Outlook, OWA and PowerShell, Hold Policy to preserve data for recovery in legal or accidental deletion scenarios, and e-Discovery with multi-mailbox search in the Exchange Control Panel.
TechNet Webcast: Exchange Server 2010 Management and Operations
Presented by: Oliver Moazzezi
Exchange Server 2010 includes new capabilities that make the operation of your Exchange environment more efficient. Learn how we've made the Exchange Management Console more powerful, extended the reach of PowerShell, made it easier to delegate management tasks, and built Web-based tools to make the job of managing Exchange easier than ever.
TechNet Webcast: Calendar Sharing and Federation in Microsoft Exchange Server 2010
Presented by: Joel Stidley
Federation is a key part of the architecture of Microsoft Exchange Server 2010, powering new organization-to-organization sharing scenarios. Attend this webcast to learn how to implement free/busy and full calendar sharing with your business partners using Exchange Server 2010.

How Do I videos

-Erin Briney

Released: Update Rollup 2 for Exchange Server 2007 Service Pack 2

Exchange — Fri, 29 Jan 2010 18:07:00 GMT

Exchange CXP team has released Update Rollup 2 for Exchange Server 2007 Service Pack 2 (KB 972076) to the download center.

In addition to bug fixes reported by customers we have added new rules to the Exchange Best Practices Analyzer to check the health of your system. Starting this rollup, customers who wish to deploy the new BPA health rules to a server with no internet connection can do so by downloading the installing the update rollup on the server. Until Exchange Server 2007 Service Pack 2, updates to the BPA rules were available only via the web which meant customers wanting to deploy the new health check rules to servers not connected to the internet would have had to copy over the XML files manually. In Exchange 2007 SP2, we implemented a work item which allows us to ship updates to the BPA health check rules via the rollup and as well as via the traditional web based channel. More on this via a blog post in the near future.

KBA 972076 lists all the fixes included in this rollup. Here are some of the product improvements and critical bug fixes we'd like to call out:

KB 972705: This one is for all the IT pros and anyone who has ever had to explain abnormal database size/log file growth in a short period of time. We have added three new registry entries to help speed up troubleshooting the issue:
- BytesLogWarningThreshold
- BytesLogErrorThreshold
- BytesLogCheckPeriodInMinutes
More information on the values to set in the above registry keys is documented in KB 972705.
KB 975404: Accepting meeting requests sent via an application using CDO like Blackberry devices sometimes results in rendering an embedded message attached to the meeting request inaccessible.
KB 976137: We have made a change to the behavior of the Unified Messaging Auto attendant when it plays the greeting for callers on a holiday. Currently when callers call on a holiday, they hear the non-business hours greeting followed by the holiday greeting. In this rollup we have made a change so that the callers calling on a holiday will only hear the holiday greeting. If your greetings are configured such that they would make sense to callers calling on a holiday only if they hear both the non-business hours greeting and the holiday greeting, then you need to re-configure them when you install this update rollup.
KB 971177: Another change in the UM Auto Attendants configuration in the Exchange Management Console. It is now aware if your time zone follows Daylight Saving Time.
KB 975165: In an environment using self-signed certificates and CAS-CAS proxying, Exchange Web Services requests proxied may start failing after the Availability Service has made a proxy request.
A bug where the OWA Virtual Directory cannot be accessed via the Exchange Management Console in an environment coexisting with Exchange 2010 if the Exchange 2007 server was upgraded from Exchange 2007 SP1 to SP2.

KB 972076 has more details about this release and a complete list of all fixes included in this rollup.

-Exchange

Interception and Redirection of Messages Using Transport Rules or Journaling

Exchange — Thu, 28 Jan 2010 17:10:00 GMT

When looking for Exchange controls to copy messages for regulatory compliance needs, you may have come across both Transport Rules and Journaling and wondered, "Which one best serves the needs of my organization?"

Both features have the capability to intercept and copy messages to another mailbox, but they differ in how they intercept messages and in what details are included in the copied message. Transport Rules can be employed to satisfy needs for message review and monitoring, while Journaling can be employed to meet the regulatory compliance needs for message archiving. The purpose of this article is to contrast these features' capabilities of message interception, and to help you identify which will best meet your particular compliance and control requirements. For a broader understanding of these two Exchange features, please reference the links provided below.

Transport Rules-based message interception

Transport rules are applied when messages are sent or received in your organization.

Transport Rule = Condition + Action + Exception

First, a criteria is evaluated such as who the sender or receiver of the message is, or the keywords in a message. If messages meet particular criteria (conditions and exceptions), then an action can be applied like 'block,' 'copy,' 'moderate,' or 'append a disclaimer to the message'. Transport Rules are used to enforce message control and protection policies.

The Transport Rules agent runs on the Exchange Hub Transport server, evaluating every message against the set of Transport Rules.

If your goal is to clandestinely copy certain messages to a supervisory mailbox for post-send review, one could use the "Blind carbon copy (Bcc)" action. For example:

Conditions	Apply rule to messages sent to users that are 'Outside the organization' and when the Subject field or message body contains 'Secret project code words'
Actions	Blind carbon copy(Bcc) the message to 'contentreview@contoso.com'
Exceptions	Except when the message is sent to a member of 'trustedpartner@contoso.com'

In this rule, external bound messages containing sensitive project key words are copied to a mailbox, where they will be reviewed periodically for policy violations, except for messages which are addressed to members of the trusted partner group.

If your goal in message interception is to have a supervisor review and approve the message before delivery, then you may want to use the moderation action (new in Exchange 2010). An example of how to configure a Transport Rule for moderation, using the Exchange Management Console (EMC):

Figure 1: Transport rule conditions

Figure 2: Transport rule actions

In the example rule above, members of the "Contractors" group are working on a sensitive project and corporate policy dictates that messages sent outside of the organization must be first approved by the user's manager before being delivered. The manager gets an approval request message for the intercepted message, and has the ability to approve or reject the message (via Outlook or OWA).

The advantage that Transport Rules presents is the rich set of conditions & exceptions to which one can scope the rule. One can create very specific rules to intercept messages based on recipients, senders, message content, and/or message properties. For additional details on Transport Rules see:

Journaling for compliance

The journaling feature was developed to meet the needs of enterprise class message archiving, often driven by legal and regulatory requirements, such as the Sarbanes Oxley Act, SEC Rule 17A-4, and other similar regulations. If an archive is required, then Exchange journaling can be used to create records of email communications, including BCC data, DL membership at the time of delivery, etc.. These records are then delivered via SMTP to the archive for de-duplication / discovery and production.

Similar to the Transport Rules agent, the Journaling agent also runs on Hub Transport servers (the Journaling agent runs after the Transport Rules agent), evaluating every message against the set of journal rules.

Journal rules are policies for intercepting and archiving messages to and from regulated users (or sets of users); the journal rule configuration allows one define the target user(s) and scope to global, internal, or external messages. For example:

Figure 3: Journal rule properties

In the example journal rule above, all messages sent to or from User01 will be journaled. The journal reports are sent to the Journal mailbox for archiving.

In the example journal report below, the message, "Sales Forecast," from Test User01 was intercepted by the journal rule. A copy of the original message is attached to the journal report, and message metadata (e.g. recipient details) is included in the journal report body:

Figure 4: A journal report includes message metadata and the original message as an attachment

Attaching a copy of the original message to the journal report ensures that the original headers and properties of the message are maintained, as opposed to a message copied by transport rules where some headers will be stripped and properties transformed on delivery. This is one significant difference between a message intercepted by Journaling and a message intercepted by Transport Rules. Other differences are provided in the next section below.

The other advantage that Journaling has over Transport Rules is in the message recipient meta-data provided in the journal report envelope. This lists all of the recipients in the SMTP envelope (P1 recipient list, RFC821), and how each recipient got on the message, including:

Distribution group expansion ("To: user01@contoso.com, Expanded: salesteam@contoso.com")
Forwarded recipients ("To: user03@contoso.com, Forwarded: user02@contoso.com")
BCC'd recipients ("Bcc: reporterdude@treyresearch.net")
Recipients added by Transport Rules or any other transport agent (not in the example above, but would be listed as "Recipient: someone@example.com"

Lastly, the journal report messages themselves are privileged messages, which will not be intercepted by transport rules, and can be configured such that they will never expire in a transport queue (e.g., will not NDR). Messages redirected or bcc'd by a Transport rule, on the other hand, are treated just like any other standard message in the system (e.g., can NDR if the target mailbox is unreachable).

For additional details on Journaling see:

Which feature should I use?

In most cases, this decision will probably pivot around how important it is for you to capture the meta-data around intercepted messages. In summary:

Transport Rules support redirecting or BCC'ing messages to another user or mailbox for moderation or review. This is not suitable for legal e-discovery due to missing metadata and the modified message contents (headers, etc). This best suited for internal surveillance or corporate policy enforcement, where reviewing the message body content is the primary need.
Journaling supports e-discovery archives and enables copying a full fidelity version of the message. The journal reports contain BCC, DL membership, etc. This is best suited for enterprise class archiving and regulatory compliance. If your organization wants to support e-discovery via a third party archive, you need to use Journaling.

Below is a chart of some typical requirements organizations have for message interception (be it for review or archiving), and how each feature meets those needs:

Requirement	Transport Rule (Blind carbon copy)	Journaling (Journal report)
Message ID: Is the original submitted message ID preserved?	Yes, the bcc'd message has the same message ID as the original.	Yes, in the journal report body and in the attached message.
Message Body: Is the message body preserved?	Yes, the message body is untouched by the bcc action.	Yes, in the attached message to the journal report.
Recipients in the SMTP Envelope: Is all of the recipient data in the SMTP envelope (aka, P1 recipient list, RFC 821) preserved?	No, the delivered message only has the recipients in the message body (aka., P2 recipient list, RFC 822).	Yes, in report body and in the attached message.
Recipients in the Message Body: Are the recipients in the message body (aka., P2 recipient list, RFC 822) preserved?	Yes, in the bcc'd message headers.	Yes, in the report headers and in the attached message.
DL Members: Is group expansion information included?	No.	Yes, in the report body.
BCC: If the sender addressed BCC recipients, is information about those BCC recipients captured?	No, all bcc recipient (P1 recipient list) information is stripped when delivered.	Yes, in the journal report body and in the attached message.
Transport Rule Recipient Changes: Are added recipients accounted for?	No, recipients added by transport rules after the bcc rule will not be accounted for in the bcc rule.	Yes, the Journaling agent will detect any change in recipients made by Transport Rules or other agent, and will re-evaluate the journal rules against these new recipients.
Moderation: Are moderation messages and events captured?	No, if the recipients on the message (e.g. moderated distribution groups) were first moderated, the transport rule for bcc would not capture the moderation activity.	Yes, the journaling rule would capture approved and rejected messages.
De-duplication: Are unnecessary duplicate messages prevented?	No, all duplicates will trigger the rule, potentially resulting multiple copies.	Yes, duplicate reports to the same journal target address are minimized.
IRM Decryption: Are IRM-protected messages decrypted in the delivered copy?	No, the bcc recipient will receive an encrypted message (and may not be able to read it).	Yes, the Journaling agent can provide both a decrypted copy and an encrypted copy of the message, attached to the journal report. *Requires configuring Journal Report Decryption
Loss prevention: Is there a way to ensure delivery of the copied message?	No, if the Bcc target mailbox is unreachable, the Bcc'd message will eventually time out in the queue and fail delivery.	Yes, on-premise deployments of Exchange, by default, will hold journal reports indefinitely in the queue until the journal mailbox is available again. Alternatively, a journaling NDR address can be configured (required for datacenter tenants), to which undeliverable journal reports will be sent.
Comprehensive: Are all message types evaluated?	No, the Transport Rules agent will not evaluate rules against system messages.	Yes, the Journaling agent will evaluate all messages, including system messages.

Both Transport Rules and Journaling are powerful tools for the Exchange admin to meet message policy enforcement needs and regulatory compliance needs of your organization - understanding your organization's real archiving and control needs is key to picking the right technology.

- Steve Clagg

Protecting Exchange 2010 DAG (Single Site) Using Data Protection Manager 2010

Exchange — Tue, 26 Jan 2010 16:38:00 GMT

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

Exchange 2010 Mailbox Server Role Requirements Calculator Updated to Version 3.5

Exchange — Fri, 22 Jan 2010 16:06:00 GMT

==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:

Launch two versions of the calculator.
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.
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.

	Datacenter 1	Datacenter 2
DAG1	Active	Passive
DAG2	Passive	Active

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

Making sense of Exchange Logs using ExLogAnalyzer

Exchange — Wed, 20 Jan 2010 19:21:24 GMT

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):

MailboxServer	Sender	Count
mbx01.contoso.com	support_person@contoso.com	162
mbx01.contoso.com	sales_person@contoso.com	124
mbx02.contoso.com	ceo@contoso.com	61

Sender Distribution by Submit (analysis yielding CSV):

SentMsgRange	Count	Percent	Percentile
1-5 msgs	23310	86.59%	86.59%
6-10 msgs	3078	11.43%	98.02%
11-20 msgs	497	1.85%	99.87%
21-30 msgs	28	0.10%	99.97%
31+ msgs	7	0.03%	100.00%

Distribution Group Expansion Analyzer (analysis yielding CSV):

Recipient	RecipCount	ExpandCount
info@contoso.com	1	2242
skiing@contoso.com	43	848
parents@contoso.com	223	203
all@contoso.com	2325	17

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

Restricting email to the Internet on a per user AND per domain basis

Exchange — Mon, 18 Jan 2010 14:39:27 GMT

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)

Announcing Additional Upgrade Scenarios for the Exchange Server 2010 Deployment Assistant

Exchange — Wed, 13 Jan 2010 23:03:47 GMT

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

Exchange 2010 Delivery Reports

Exchange — Wed, 13 Jan 2010 17:02:33 GMT

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

Raising diagnostic logging for Message Access might cause calendar issues with Exchange 2007 SP2

Exchange — Mon, 11 Jan 2010 15:04:57 GMT

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

Management Tool Interoperability

Exchange — Fri, 08 Jan 2010 15:30:00 GMT

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:

2003 Object	ESM on 2003	EMC on 2007	EMC on 2010
View Users, Contact, DDL	SUPPORTED	SUPPORTED	SUPPORTED
Manage Users, Contacts, DDL	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Provision (Create) mailboxes	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
View Mailboxes	SUPPORTED	SUPPORTED	SUPPORTED
Manage Mailboxes (Edit/Remove)	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Manage Mobile Devices	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Import MBX from PST and Export to 2007 (Open Issue)	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
View Disconnected MBXs	SUPPORTED	SUPPORTED	SUPPORTED
Connect Disconnected Mailbox	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Connect to Public Folder DB	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Manage Send As permissions	N/A	SUPPORTED	SUPPORTED
manage Full Access permissions	N/A	SUPPORTED	SUPPORTED
Enable/Disable UM	N/A	N/A	N/A
Manage Global Objects (Address Lists/GALs)	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
Provision (Create) OAB	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
View OAB	SUPPORTED	SUPPORTED	SUPPORTED
Manage EAP	N/A	N/A	N/A
Manage MRM Objects (Default folders, custom folders, mailbox policies)	N/A	N/A	N/A
View Transport Rules & Journal Rules	N/A	N/A	N/A
Manage remote domains, accepted domains, send connectors, Edge subscriptions	N/A	N/A	N/A
View UM Dial Plans,UM IP Gateways,UM Mailbox,UM Auto Attendants	N/A	N/A	N/A
Manage UM Dial Plans,UM IP Gateways,UM Mailbox,UM Auto Attendants	N/A	N/A	N/A
Manage Active Sync Mailbox Policies	N/A	N/A	N/A
View per-server objects (Servers, Virtual directories,POP3,IMAP4,Receive Connectors)	Servers, Virtual Directories, POP3,IMAP4	NOT SUPPORTED	NOT SUPPORTED
Manage Databases	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED
View Databases	SUPPORTED	NOT SUPPORTED	NOT SUPPORTED

2007 Object	ESM on 2003	EMC on 2007	EMC on 2010
View Users, Contact, DDL	SUPPORTED	SUPPORTED	SUPPORTED
Manage Users, Contacts, DDL	NOT SUPPORTED	SUPPORTED	SUPPORTED
Provision (Create) mailboxes	NOT SUPPORTED	SUPPORTED	NOT SUPPORTED
View Mailboxes	SUPPORTED	SUPPORTED	SUPPORTED
Manage Mailboxes (Edit/Remove)	NOT SUPPORTED	SUPPORTED	SUPPORTED
Manage Mobile Devices	NOT SUPPORTED	SUPPORTED	NOT SUPPORTED
Import MBX from PST and Export to 2007 (Open Issue)	NOT SUPPORTED	SUPPORTED	SUPPORTED
View Disconnected MBXs	SUPPORTED	SUPPORTED	SUPPORTED
Connect Disconnected Mailbox	NOT SUPPORTED	SUPPORTED	NOT SUPPORTED
Connect to Public Folder DB	NOT SUPPORTED	SUPPORTED	SUPPORTED
Manage Send As permissions	N/A	SUPPORTED	SUPPORTED
manage Full Access permissions	N/A	SUPPORTED	SUPPORTED
Enable/Disable UM	N/A	SUPPORTED	NOT SUPPORTED
Manage Global Objects (Address Lists/GALs)	NOT SUPPORTED	SUPPORTED	SUPPORTED
Provision (Create) OAB	SUPPORTED	SUPPORTED	NOT SUPPORTED
View OAB	SUPPORTED	SUPPORTED	SUPPORTED
Manage EAP	N/A	SUPPORTED	SUPPORTED
Manage MRM Objects (Default folders, custom folders, mailbox policies)	N/A	SUPPORTED	SUPPORTED
View Transport Rules & Journal Rules	N/A	SUPPORTED	NOT SUPPORTED
Manage remote domains, accepted domains, send connectors, Edge subscriptions	N/A	SUPPORTED	SUPPORTED
View UM Dial Plans,UM IP Gateways,UM Mailbox,UM Auto Attendants	N/A	SUPPORTED	SUPPORTED
Manage UM Dial Plans,UM IP Gateways,UM Mailbox,UM Auto Attendants	N/A	SUPPORTED	SUPPORTED
Manage Active Sync Mailbox Policies	N/A	SUPPORTED	SUPPORTED
View per-server objects (Servers, Virtual directories,POP3,IMAP4,Receive Connectors)	Default SMTP Virtual Server Directory Server Objects	SUPPORTED	NOT SUPPORTED
Manage Databases	NOT SUPPORTED	SUPPORTED	NOT SUPPORTED
View Databases	SUPPORTED	SUPPORTED	NOT SUPPORTED

2010 Object	ESM on 2003	EMC on 2007	EMC on 2010
View Users, Contact, DDL	SUPPORTED	SUPPORTED	SUPPORTED
Manage Users, Contacts, DDL	NOT SUPPORTED	NOT SUPPORTED	SUPPORTED
Provision (Create) mailboxes	NOT SUPPORTED	NOT SUPPORTED	SUPPORTED
View Mailboxes	SUPPORTED	SUPPORTED	SUPPORTED
Manage Mailboxes (Edit/Remove)	NOT SUPPORTED	NOT SUPPORTED	SUPPORTED
Manage Mobile Devices	NOT SUPPORTED	NOT SUPPORTED	SUPPORTED
Import MBX from PST and Export to 2007 (Open Issue)	NOT SUPPORTED	NOT SUPPORTED	SUPPORTED
View Disconnected MBXs	SUPPORTED	SUPPORTED	SUPPORTED
Connect Disconnected Mailbox	NOT SUPPORTED	NOT SUPPORTED	SUPPORTED
Connect to Public Folder DB	NOT SUPPORTED	NOT SUPPORTED	SUPPORTED
Manage Send As permissions	N/A	SUPPORTED	SUPPORTED
Manage Full Access permissions	N/A	NOT SUPPORTED	SUPPORTED
Enable/Disable UM	N/A	NOT SUPPORTED	SUPPORTED
Manage Global Objects (Address Lists/GALs)	NOT SUPPORTED	SUPPORTED	SUPPORTED
Provision (Create) OAB	NOT SUPPORTED	NOT SUPPORTED	SUPPORTED
View OAB	SUPPORTED	SUPPORTED	SUPPORTED
Manage EAP	N/A	SUPPORTED	SUPPORTED
Manage MRM Objects (Default folders, custom folders, mailbox policies)	N/A	MRM V2 components are not exposed in the EMC on 2007, only V1 components (managed folders, content settings, policy).	SUPPORTED
View Transport Rules & Journal Rules	N/A	NOT SUPPORTED	SUPPORTED
Manage remote domains, accepted domains, send connectors, Edge subscriptions	N/A	SUPPORTED	SUPPORTED
View UM Dial Plans,UM IP Gateways,UM Mailbox,UM Auto Attendants	N/A	SUPPORTED	SUPPORTED
Manage UM Dial Plans,UM IP Gateways,UM Mailbox,UM Auto Attendants	N/A	NOT SUPPORTED	SUPPORTED
Manage Active Sync Mailbox Policies	N/A	SUPPORTED	SUPPORTED
View per-server objects (Servers, Virtual directories,POP3,IMAP4,Receive Connectors)	Default SMTP Virtual Server Directory Server Objects	NOT SUPPORTED	SUPPORTED
Manage Databases	NOT SUPPORTED	NOT SUPPORTED	SUPPORTED
View Databases	NOT SUPPORTED	NOT SUPPORTED	SUPPORTED

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

On Address List Segregation with Exchange 2010...

Exchange — Thu, 07 Jan 2010 14:40:19 GMT

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