Exchange PST Capture Tool released

Today the Exchange Team released the Microsoft Exchange PST Capture Tool (initial version 14.3.16.4). The tool can be used to discover and inject PST files in an Exchange 2010 Exchange Online mailbox or archive.

The tool was originally from Red Gate and known as PST Importer. It’s architecture consists of three components: the central service, agents for PST discovery, registration and collecting PST files and an administrative console

Courtesy: Red-gate

The online documentation can be found here.

Note that although it’s only supported for Exchange 2010 and Exchange Online, you can use it with Exchange 2007; it’s only untested (and probably unsupported) with that product.

You can read the official announcement here; you can download the tool and the agents here.

Exchange 2007 SP3 Update Rollup 6

Today the Exchange Team released Rollup 6 for Exchange Server 2007 Service Pack 3 (KB2608656). This update raises Exchange 2007 version number to 8.3.245.2.

Here’s the list of changes included in this rollup:

· 2289607 The week numbers displayed in OWA do not match the week numbers displayed in Outlook for English users and French users in an Exchange Server 2007 environment

· 2498852 “0×80041606″ error message when you perform a prefix search by using Outlook in online mode in an Exchange Server 2007 environment

· 2499841 An arrow icon does not appear after you change the email message subject by using OWA in an Exchange Server 2007 SP3 environment

· 2523695 A “System.ArgumentOutOfRangeException” exception occurs when you click the “Scheduling Assistant” tab in Exchange Server 2007 OWA

· 2545080 Users in a source forest cannot view the free/busy information of mailboxes in a target forest when the cross-forest Availability service is configured between two Exchange Server 2007 forests

· 2571391 Applications or services that depend on the Remote Registry service may stop working in an Exchange Server 2007 environment

· 2572010 The Microsoft Exchange Information Store service may crash after you run the Test-ExchangeSearch cmdlet in an Exchange Server 2007 environment

· 2575360 A new feature is available to automatically stop the Microsoft Exchange Information Store service when a time-out is detected in an Exchange Server 2007 SP3 environment

· 2591655 A journaling report remains in the submission queue when an email message is delivered successfully in an Exchange Server 2007 environment

· 2598980 The PidLidClipEnd property of a recurring meeting request has an incorrect value in an Exchange Server 2007 environment

· 2616427 An Outlook Anywhere client loses connection when a GC server restarts in an Exchange Server 2007 environment

· 2617784 Journal reports are expired or lost when the Microsoft Exchange Transport service is restarted in an Exchange Server 2007 environment

· 2626217 Certain changes to address lists may not be updated in an Exchange Server 2007 environment

· 2629790 The Exchange IMAP4 service may stop responding on an Exchange Server 2007 Client Access server when users access mailboxes that are hosted on Exchange Server 2003 servers

· 2633801 The SCOM 2007 SP1 server cannot alert certain issues in an Exchange Server 2007 organization

· 914533 The Microsoft Exchange Information Store service may stop responding on an Exchange Server 2007 server

· 976977 The scroll bar does not work in OWA when there are more than 22 all-day event calendar items in an Exchange Server 2007 user’s calendar

· 2641312 The update tracking information option does not work in an Exchange Server 2007 environment

· 2653334 The reseed process is unsuccessful on the SCR passive node when the circular logging feature is enabled in an Exchange Server 2007 environment

· 2656040 An Exchange Server 2007 Client Access server may respond slowly or stop responding when users try to synchronize the Exchange ActiveSync devices with their mailboxes

· 2658613 The “PidLidClipEnd” property of a no ending recurring meeting request is set to an incorrect value in an Exchange Server 2007 environment

Quick Note:

When running Forefront Protection for Exchange, make sure you disable Forefront before installing the rollup and re-enable it afterwards, otherwise the Information Store and Transport services may not start. You can disable Forefront using fscutility /disable and enable it using the fscutility /enable command.

Note that update rollups are cumulative, i.e. they contain fixes released in earlier update rollups for the same product level (RTM, SP). This means you don’t need to install previous update rollups during a fresh installation but can start with the latest rollup.

You can download Exchange 2007 SP3 Rollup 6 here.

Microsoft Office Filter Pack 2010 SP1

Right after launching Office 365, Microsoft released Service Pack 1 for Microsoft Office 2010 which includes Office 365 support besides the usual fixes. For those interested, Office 2010 SP1 can be downloaded here (x86) and here (x64). Related knowledgebase article including list of changes is KB2460049.

More interesting for Exchange folks is that there’s also an SP1 for the Microsoft Office Filter Pack 2010, which of course you install during Exchange setup as one of the prerequisites. As you probably know, the Filter Pack is used to index Office documents stored in Exchange databases to speed up queries.

You can download Service Pack 1 for Microsoft Office Filter Pack 2010 x64 Edition here. The related knowledgebase article is KB2460041

Few Poweshell commands

HUB Transport Server

+++++++++++++++++++++++++++++++++

Get-Queue -server ‘servername’ (Check Queue on a Hub Server)

get-messagetrackinglog -resultsize unlimited -EventID “RECEIVE” -Recipients “name@domain.com” -sender “name@mail.com” -Server “XXXYYYPP123” -Start “7/27/2010 12:00:00 AM” -End “7/29/2010 11:59:00 PM”

(To track the messages in a hub server, edit the query as needed)

Mailbox Server

+++++++++++++++++++++++++++++++++

Get-MailboxDatabase -server cmsname -status | select name,mounted (To check the status (Mounted) of all mailbox database in a server)

Get-MailboxDatabase -server cmsname -status | select Name,Server,*backup*,Mounted (To check the last Backup of all mailbox database in a server)

Dismount-Database CMSNAME\CMSNAME-SG01 (Dismount a single database)

Get-MailboxDatabase -server cmsname | Dismount-Database (Dismount all the mailbox database in a server)

Cluster

——-

Get-StorageGroupCopyStatus -server cmsname (To check the replication status of all storage group in a server)

Test-ReplicationHealth (To check the replication health of a cluster)

Suspend-MailboxDatabaseCopy -Identity CMSname\CMSname-SG01 -SuspendComment “Maintenance on 001” (Pause the replication of a storage group)

Resume-MailboxDatabaseCopy -Identity cmsname\CMSname-SG01 (Resume the replication of a storage group, which was paused)

Restore-StorageGroupCopy CMSNAME\CMSNAME-SG01 (Ignore the consistency state and make database mountable, possible of data loss)

Update-StorageGroupCopy CMSNAME\CMSNAME-SG01 -DeleteExistingFiles (Reseed the replication which was failed)

Move-ClusteredMailboxServer -Identity ‘CMSNAME’ -MoveComment ‘Install Forefront on A node’ -TargetMachine ‘nodeb’

Troubleshooting Cluster Servers

====================================================================================

1. Always use “Move-ClusteredMailboxServer” command to failover the server

2. Before failover the server, it is better to check whether the passive node is up to date.

Run “Get-StorageGroupCopyStatus” to see the target database is updated. The copy status should be Healthy and CopyQueueLength & ReplayQueueLength should be 0.

Do not failover the cluster if there is some value in CopyQueueLength or ReplayQueueLength unless it is really required. (Less value in CopyQueueLength & ReplayQueueLength is less data loss)

3. If the copy status failed first try “Resume-MailboxDatabaseCopy” then “Update-StorageGroupCopy” (Do not go for “Update-StorageGroupCopy” without seniours advise)

Mail queued up in Hub transport server – Back pressure

Overview

Although email is not always the best way to share files, the method is frequently used. As an administrator, you probably have to allow messages to be sent with attachments. Sometimes these attachments are relatively large. But you also have to balance this business requirement with making sure that your server hardware does not become overly utilized or that some users are denied service while others are processing super large messages.

In Customer Support Services we see a lot of critical server unresponsive type issues caused by someone trying to attach a really large file, say perhaps someone trying to share a DVD home video .ISO with their friends and coworkers.

Although we’ve attempted to harden Exchange out of the box, there are still a few things that you should consider doing to further limit the possibility of something like this happening.

Back Pressure

Exchange 2007 introduces a concept within Transport servers called Back Pressure. You can read all about it here. Suffice it to say, if your server becomes too busy, it will stop accepting new messages, and allow itself time to gracefully recover. It does this to protect itself from the extreme cases.

In short, Back Pressure is Exchange 2007’s way of monitoring available disk space, memory and uncommitted messages. When any of those resources exceed their corresponding thresholds for a sustained period the HUB server stops accepting anonymous submissions (medium threshold) or all submissions (high threshold). For example:

Event Type: Warning
Event Source: MSExchangeTransport
Event Category: ResourceManager
Event ID: 15004
Description:
Resource pressure increased from Medium to High.

Resource utilization of the following resources exceed the normal level:

Version buckets = 213 [High] [Normal=80 Medium=120 High=200]

Back pressure caused the following components to be disabled:
Inbound mail submission from Hub Transport servers
Inbound mail submission from the Internet
Mail submission from the Pickup directory
Mail submission from the Replay directory
Mail submission from Mailbox servers
Mail delivery to remote domains

With large messages, you have the possibility that a database transaction to commit the message into the database will take some time to complete. During that time, the database is tracking the commit with what is called version buckets or version store. So with large messages, you can guess that version buckets will often be the measure of how the mail queue database is keeping up. A few seconds of back pressure a few times per day is fine, but if your server(s) spend a lot of time in back pressure, then there’s the possibility that other messages aren’t being processed in a timely fashion.

Best Practices

An ounce of prevention is worth a pound of cure. So here are the best practices we recommend to protect your server(s) from large messages that might cause outages.

  • Install SP1 RU8. This rollup update contains an extremely important fix that should not be missed. KB 960775 is the fix that you need, particularly if you allow Outlook 2003 clients prior to SP3 to connect to your server. These clients will not ask for the maximum limits before synching and submitting a large message to the server. This can easily cause transaction log file growth and performance problems on the Mailbox server. But, worse, the store-generated DSN messages are then submitted to Transport and the problem can spread. This fix eliminates the possibility of Hub servers being affected. Regardless of this fix, it may still be a best practice to update your clients to SP3 and block legacy (unsupported) clients to limit the damage that can happen on the Mailbox server.
  • Run ExBPA. Although BPA does not know what’s reasonable for your organization, it can make sure that at least size limits are in place. ExBPA can check all of your servers quickly.
  • Set reasonable size limits for your organization based on planning. See above section for commonly missed size limits. You can use the detail output from the BPA to make certain the limits are where you think that they are.
  • Particularly if you’re supporting anything larger than the default 10MB message size, make sure that you’ve updated your edgetransport.exe.config file to the latest guidance for your version of Exchange. At the time of this publishing, the Exchange 2007 guidance when running the latest service pack is as follows:
  • The ESE cache size should be 512MB on any server with more than 4GB of RAM – An easy example:

    DatabaseMaxCacheSize” value=”536870912″ />

    For servers with 8GB of RAM or more, particularly if they are dedicated Hub role with transport dumpster enabled, you can set the value as high as 1GB:

    DatabaseMaxCacheSize” value=”1073741824″

    The version bucket thresholds should be as follows –

    DatabaseCheckPointDepthMax” value=”20971520″ /> to DatabaseCheckPointDepthMax” value=”536870912″

    The checkpoint depth should be approximately half of the DatabaseMaxCacheSize –
    QueueDatabaseLoggingBufferSize” value=”524288″ to QueueDatabaseLoggingBufferSize” value=”5242880″


    QueueDatabaseLoggingFileSize” value=”5242880″ /> to QueueDatabaseLoggingFileSize” value=”31457280″

  • Consider hardening and isolating Internet-facing receive connectors such that spam processing and virus scanning processes for inbound “unclean” message streams are not impacting the rest of mail flow. Set reasonable receive connector limits. This obviously transcends the large message discussion, but this is especially true if you allow larger messages.
  • Make sure that proper exclusions are set for file-based Antivirus software and that temporary locations are also located on drives with adequate space and speed. Temporary files can be created while converting large messages. Scanning these temporary files can cause problems – use proper Exchange Antivirus for protecting the messages and file-level scanning to protect the server(s).

Conclusion

Message size limits will protect your servers and make sure they stay happily running, but there is not any “one-size-fits-all” guidance. Nevertheless, setting reasonable message limits and following the best practices can save you a great deal of trouble.


Ref: http://msexchangeteam.com/archive/2009/07/07/451737.aspx


Upgrade from Exchange 2007 Transport

When upgrading from Microsoft Exchange Server 2007 to Exchange Server 2010, there will be a period of time where both versions coexist in production. You can plan an upgrade path from Exchange 2007 to Exchange 2010 using the information in this topic, which includes overview information, technical information about message flow in a coexistence environment, and considerations when operating in a mixed version environment.

Important: If you deploy Exchange 2010 as a new organization, you can’t later install Exchange 2007 in the Exchange 2010 organization. This isn’t a supported scenario. If you anticipate requiring Exchange 2007 functionality in your organization in the future, you must first install an Exchange 2007 organization and maintain at least one Exchange 2007 server.

The most important point in an Exchange 2010 and Exchange 2007 coexistence scenario is that every Mailbox server needs a Hub Transport server with a matching Exchange version in the same Active Directory site. Due to the changes made to the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can’t pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can’t communicate with Exchange 2010 Mailbox servers. Therefore, you need to maintain your Exchange 2007 Hub Transport servers in a specific Active Directory site until all Exchange 2007 Mailbox servers are removed from that site. For more details about how messages are routed in a coexistence environment, see “Message Routing Across Versions” later in this topic.

Note: In-place upgrades aren’t supported in Exchange 2010. You need to install new Exchange 2010 servers into your environment, and then phase out the Exchange 2007 servers. For the scope of this document, the phrase upgrade refers to generally upgrading the version of your Exchange deployment and not a specific server.

Upgrading your Exchange 2007 Hub Transport and Edge Transport servers should be part of your overall upgrade strategy. The recommended order is to upgrade your transport servers after your Client Access servers and before Unified Messaging and Mailbox servers. The Edge Transport servers need to be upgraded after the Hub Transport servers are upgraded.

Before you introduce Exchange 2010 Hub Transport or Edge Transport servers, make sure that all of your Exchange 2007 servers in that site are upgraded to Exchange 2007 Service Pack 2 (SP2). Exchange 2007 SP2 is required for Exchange 2010 and Exchange 2007 Hub Transport servers to coexist in a single Active Directory site. Exchange 2007 SP2 is also required so that the Microsoft Exchange EdgeSync service works across versions.

If you have Exchange 2007 deployed in multiple sites, you must upgrade your Internet-facing sites first. The order of upgrade for the remaining sites depends on your particular topology and your organization’s priorities.

The following process shows the recommended upgrade path for your transport servers in an Internet-facing site. (It is assumed that you are using Edge Transport servers with EdgeSync. If you are using a third-party smart host, you can omit steps 2-6.) The upgrade process is as follows:

  1. Introduce your first Exchange 2010 Hub Transport server to your site. As soon as the Exchange 2010 Hub Transport server is introduced to the site, it will take over edge synchronization. However, because the Edge Transport server is still running Exchange 2007 SP2, the Exchange 2010 Hub Transport server won’t perform incremental EdgeSync synchronization, but rather replicate full EdgeSync data, just like an Exchange 2007 Hub Transport server. For message delivery to the Internet, the Exchange 2010 Hub Transport server will go through the Exchange 2007 Hub Transport server, as shown in the following figure.
    Introducing Exchange 2010 Hub Transport server to existing Exchange 2007 site
    Transport server upgrade step 1
  2. Subscribe your Exchange 2007 Edge Transport server to your site again. This will add your Exchange 2010 Hub Transport server to the Edge Subscription as a source server, as shown in the following figure.
    Note:
    If you plan to add multiple Exchange 2010 Hub Transport servers to your Active Directory site, to save time, you can deploy all the new Hub Transport servers before subscribing your Edge Transport servers.
    Subscribing Exchange 2007 Edge Transport servers after introducing Exchange 2010 Hub Transport server
    Transport server upgrade step 2
  3. Introduce your first Exchange 2010 Edge Transport server to your perimeter network.
  4. Subscribe your Exchange 2010 Edge Transport server to your site. At this point, the Exchange 2010 Hub Transport server will start incremental updates to the Exchange 2010 Edge Transport server, as shown in the following figure.
    Subscribing Exchange 2010 Edge Transport server
    Transport server upgrade step 4
  5. Remove the Exchange 2007 Edge Subscription.
  6. Decommission your Exchange 2007 Edge Transport server, as shown in the following figure.
    Removing Exchange 2007 Edge Transport servers
    Transport server upgrade step 6
  7. After all of your mailboxes are on Exchange 2010 Mailbox servers, decommission your Exchange 2007 Hub Transport servers.

Message Routing Across Versions

Due to changes in the Exchange Server Object (XSO) model in Exchange 2010, Exchange 2010 Hub Transport servers can’t pick up messages from and deliver messages to Exchange 2007 Mailbox servers. Similarly Exchange 2007 Hub Transport servers can’t communicate with Exchange 2010 Mailbox servers. As a result, to have both Exchange 2010 and Exchange 2007 in the same Active Directory site, you must maintain both versions of Hub Transport servers in that site, as shown in the following figure. The versions of the servers in Site B aren’t shown in the figure, because the handling of intersite SMTP traffic is the same as it is in Exchange 2007. The Hub Transport server relays the messages to the Hub Transport server in the remote site for delivery.

Message flow between Exchange 2010 and Exchange 2007
Message flow with versioned routing

To enable message flow across versions, a feature called versioned routing is implemented in Exchange 2010. With versioned routing, the routing engine checks the version of a mailbox’s home server, along with its Active Directory site. If the version doesn’t match, the message is relayed to a Hub Transport server that has a matching version, as shown in the versioned routing workflow in the following figure. Routing is now dependent on both Active Directory sites and Exchange versions.

Versioned routing workflow
Versioned routing workflow

When an Exchange 2010 mailbox user sends a message to an Exchange 2007 mailbox user in the same site, the following occurs:

  1. The Exchange 2010 Mailbox server notifies the Exchange 2010 Hub Transport server of the new mail.
  2. The Exchange 2010 Hub Transport server picks up the message.
  3. The routing agent determines that the version of the Mailbox server that’s the home server of the destination mailbox doesn’t match its own version.
  4. The routing agent locates an Exchange 2007 Hub Transport server in the local site.
  5. The Exchange 2010 Hub Transport server relays the message to the Exchange 2007 Hub Transport server.
  6. The routing agent on the Exchange 2007 Hub Transport server determines that the target mailbox is on an Exchange 2007 Mailbox server in the local site.
  7. The Exchange 2007 Hub Transport server delivers the message to the Exchange 2007 Mailbox server.

Any messages sent from Exchange 2007 mailbox users to Exchange 2010 recipients follow a similar path.

Versioned routing was added to Exchange 2007 in SP2. To have both Exchange 2010 and Exchange 2007 coexist in the same Active Directory site, you must first upgrade your existing Exchange 2007 servers to SP2. When you have Exchange 2010 and Exchange 2007 SP2 in the same Active Directory site, each Hub Transport server handles messages for the Mailbox servers with matching versions. Versioned routing doesn’t change the way intrasite messages are routed.

Consider the following when you have Exchange 2010 and Exchange 2007 in the same site:

  • You can’t specify an incompatible Hub Transport server as the submission server override for a Mailbox server.
  • For a specific Mailbox server, if you don’t have a matching version Hub Transport server in the local site, any messages sent by users on that Mailbox server will remain on the Mailbox server.
  • For a specific Mailbox server, if you don’t have a matching version Hub Transport server in the local site, non-delivery reports (NDRs) will be issued for any messages sent to users on that Mailbox server.
  • Messages sent to mail-enabled public folders are handled the same way messages sent to mailboxes.

The edge synchronization process has been improved in Exchange 2010. In Exchange 2007, EdgeSync replicated all of the configuration and recipient information in its entirety. Especially in organizations with large number of recipients, this took a long time. Exchange 2010 introduces incremental updates for EdgeSync. When you first subscribe an Exchange 2010 Edge Transport server to a site, all the configuration information and recipient data is synchronized. In all subsequent updates, only the changes are replicated. Therefore, synchronization time and network utilization are substantially reduced.

Although Exchange 2007 Hub Transport servers can participate in EdgeSync with Exchange 2010 Edge Transport servers, incremental updates are only available between Exchange 2010 Hub Transport servers and Exchange 2010 Edge Transport servers. By default, when an Exchange 2010 Edge Transport server is subscribed to an Active Directory site that has Exchange 2010 Hub Transport servers, the Exchange 2010 Hub transport servers take over the EdgeSync process. You can fall back to Exchange 2007 Hub Transport servers by disabling the Microsoft Exchange EdgeSync service on the Exchange 2010 Hub Transport servers. However, when you do that, you go back to replicating all data with each EdgeSync update, instead of incremental updates.

If you already use transport rules or journaling in your Exchange 2007 organization, make sure that these features continue to function during the coexistence period, regardless of which Hub Transport server processes a specific message.

The following significant changes were made to transport and journaling rules in Exchange 2010, which have an impact when managing these features in a mixed environment:

  • Format changes Exchange 2010 transport rules support a series of new predicates and actions. To support these new predicates and actions, the format of how transport rules are stored in Active Directory has been modified. Exchange 2007 Hub Transport servers can’t process these new predicates and actions. For a complete list of predicates and actions available in Exchange 2010, see Transport Rule Predicates and Transport Rule Actions.
  • Storage location in Active Directory To prevent the Exchange 2007 Transport Rules agents from loading and attempting to process the rules created in Exchange 2010, the Exchange 2010 rules are stored in a separate Active Directory container. The same situation applies to journaling rules.

When installing Exchange 2010, if the Setup program detects the existence of Exchange 2007 transport rules, these legacy rules are automatically exported to a temporary location and subsequently imported to the Exchange 2010 transport rule container in Active Directory. This process happens automatically without any user interaction.

Note:
If there are any existing Exchange 2010 transport rules, Setup won’t migrate Exchange 2007 rules because the migration overwrites all existing Exchange 2010 transport rules.

Similarly, all Exchange 2007 journal rules are converted and copied to Exchange 2010 journal rules during setup.

The automatic import of rules to Exchange 2010 is only performed during initial setup. During the initial setup, the set of transport rules and journal rules for Exchange 2010 and Exchange 2007 will be synchronized. Going forward, if you make any changes to an existing rule, or create a rule, the rule will be changed in a single location based on the management tool you use. For example, in Exchange 2010, if you use the Exchange Management Shell to create a rule, only the Exchange 2010 rule container in Active Directory will be updated. Similarly if you use the Exchange Management Console (EMC) on an Exchange 2007 server to change an existing rule, only the Exchange 2007 version of that rule will be modified.

To ensure that your transport and journal rules remain consistent across versions, any changes you make must be made twice; once with Exchange 2010 management tools, and once with Exchange 2007 management tools.

In Exchange 2010, the internal and external DSN settings are configured for your entire Exchange organization. In Exchange 2007, these settings were configured on a per-server basis. As a result, these settings are stored in different configuration objects in Active Directory, and just like transport rules, need to be managed separately in a coexistence scenario.

Specifically, the following settings were moved from the Set-TransportServer cmdlet to the Set-TransportConfig cmdlet in Exchange 2010:

  • ExternalDelayDsnEnabled
  • ExternalDsnDefaultLanguage
  • ExternalDsnLanguageDetectionEnabled
  • ExternalDsnMaxMessageAttachSize
  • ExternalDsnReportingAuthority
  • ExternalDsnSendHtml
  • ExternalPostmasterAddress
  • InternalDelayDsnEnabled
  • InternalDsnDefaultLanguage
  • InternalDsnLanguageDetectionEnabled
  • InternalDsnMaxMessageAttachSize
  • InternalDsnReportingAuthority
  • InternalDsnSendHtml

If you need to change any of these settings in your organization, you must make the change once for the organization using the Set-TransportConfig cmdlet in the Exchange 2010 Shell and once for each Exchange 2007 Hub Transport server in the organization using the Set-TransportServer cmdlet in the Exchange 2007 Shell.

Message Tracking Across Versions

Exchange 2010 provides improved message tracking capabilities. End users, as well as administrators, can now track the messages they have sent using the Delivery Reports tool in Exchange Control Panel.

Delivery Reports enable end-to-end message tracking from a single location, providing detailed delivery information including when a message was marked as read. In Exchange 2010, a new message tracking remote procedure call (RPC) and Web service interface was implemented to support Delivery Reports. These interfaces don’t exist in Exchange 2007 and therefore the Delivery Reports feature doesn’t extend to the Exchange 2007 infrastructure in a coexistence scenario. However, it’s possible to use the message tracking tool in Exchange 2007 to track messages between versions.

The following table shows what to do when tracking messages in a mixed environment.

Tracking messages in a mixed environment

Sent from Sent to Tracking Tool

Exchange 2010 mailbox

Exchange 2010 mailbox

Use the Delivery Reports tool in Exchange Control Panel.

Exchange 2010 mailbox

Exchange 2007 mailbox

Use the Delivery Reports tool in Exchange Control Panel. The tool provides message tracking information to the point where the message is transferred to the Exchange 2007 server. No further tracking information will be available for that message.

Alternatively, you can use Tracking Log Explorer in Exchange 2010 or message tracking in Exchange 2007.

Exchange 2007 mailbox

Exchange 2007 or Exchange 2010 mailbox

Use Tracking Log Explorer in Exchange 2010 or message tracking in Exchange 2007.

For the most part, new transport features in Exchange 2010 only function within the realm of Exchange 2010. When to start using the new features depends on the needs of your organization. You can wait until the upgrade is complete, or start as soon as you introduce Exchange 2010 to your environment. To decide when to use the new features in a mixed environment, consider the following information.

Exchange 2010 introduces moderated recipients, so that messages sent to specific recipients can be subjected to an approval process. If you plan to use moderated recipients in a coexistence scenario, be aware of the following issues, which depend on the type of recipient:

  • Mailboxes You can only enable mailboxes on Exchange 2010 Mailbox servers for moderation. After you enable a mailbox for moderation, you must make sure that it isn’t moved back to an Exchange 2007 Mailbox server.
  • Distribution groups and dynamic distribution groups The messages to a moderated distribution group go through the approval process only when that distribution group is expanded on an Exchange 2010 Hub Transport server. Because the distribution group can be expanded on any server, we recommend waiting until all your Hub Transport servers are upgraded to Exchange 2010 before using moderated distribution groups.
  • Mail contacts and mail users Hub Transport servers route messages based on the external e-mail address specified for each mail user or mail contact. Because it isn’t possible to force messages for these recipient types to go through an Exchange 2010 Hub Transport server, you may not want to enable these recipient types for moderation in a mixed environment.

If you enable a recipient for moderation, make sure that the designated moderators use a client that can display the approve and reject options for an approval request. All moderators should use Microsoft Outlook 2010 or Microsoft Office Outlook Web App in Exchange 2010.

Shadow Redundancy

Exchange 2010 introduces shadow redundancy to provide redundancy for messages for the entire time they are in transit. The solution involves a technique similar to the transport dumpster. With shadow redundancy, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting successful delivery, the message is resubmitted for delivery to that next hop.

Shadow redundancy is enabled by default on Exchange 2010, and it ensures that messages are redundant only while being transferred between Exchange 2010 servers. After that message is transferred to an Exchange 2007 server, it’s no longer redundant. Therefore, to ensure that a message that originates on an Exchange 2010 server stays redundant until it’s delivered, make sure that it doesn’t get transferred to an Exchange 2007 server. For example, if you are using a hub site that has Exchange 2007 servers, messages between two spokes won’t be redundant even if they both have Exchange 2010 servers.

Exchange 2007 ActiveSync reporting

Increase in the number of mobile users using Exchange ActiveSync has grown rapidly over the years. iPhone and Windows mobile capturing market nowadays, its extremely important for exchange admins to monitor and report their usage real-time.
There have been instances where Exchange design solutions where implemented not knowing the exact impact of OWA and ActiveSync users and the load balancing CAS servers went unresponsive.

This article stresses on the importance and processes for a term well used in Exchange 2007 – Exchange ActiveSync reporting.

The best part is, we don’t have to install any tools or additional software’s for this, the Exchange 2007 power shell does the trick.

I am going to explain two cmd-lets in this article, one for all IIS logs in the W3SVC folder and one for a Single IIS log file. The process of extracting Exchange ActiveSync users with mobile devices is known as PARSING and this process was rather a hectic one in Exchange 2003.

Create a folder: C:\ActiveSync_reporting. Keep in mind that the IIS logs in a windows 2008 machine is stored in “C:\inetpub\logs\LogFiles”.

This is for all files in the logs folder:

Get-Childitem “C:\inetpub\logs\LogFiles\W3SVC1″ where-object {$_.lastwritetime -gt $DateToCompare} ForEach { Export-ActiveSyncLog -FileName $_.FullName -OutputPath “C:\ActiveSync_reporting” -OutputPrefix $_.Name.Replace(“.log”,”_”) -UseGMT:$true}

Output will be 6 files as shown:

Length Name
—————————
u_ex100411_Users.csv
u_ex100411_Servers.csv
u_ex100411 _Hourly.csv
u_ex100411_StatusCodes.csv
u_ex100411_PolicyCompliance.csv
u_ex100411_UserAgents.csv

u_ex100412_Users.csv
u_ex100412_Servers.csv
u_ex100412_Hourly.csv
u_ex100412_StatusCodes.csv
u_ex100412_PolicyCompliance.csv
u_ex100412_UserAgents.csv

If we need output for just a single IIS log:

Export-ActiveSyncLog -FileName “C:\inetpub\logs\LogFiles\W3SVC1\u_ex100410.log” -UseGMT:$true -OutputPath “C:\ActiveSync_reporting

Length Name
———————–
u_ex100410_Users.csv
u_ex100410_Servers.csv
u_ex100410_Hourly.csv
u_ex100410_StatusCodes.csv
u_ex100410_PolicyCompliance.csv
u_ex100410_UserAgents.csv

The most important file in the output is Users.csv which shows:

1. Username
2. Device ID
3. Device type
4. Hits on the CAS server

With the StatusCodes.csv, we can create a report based on http code status and find device-server communication health:

200 – Authentication pass
400 – Bad/invalid request
401 and 403 – Unauthorized/server refusing request
404 – File not found
449 – Retry
500 – Server error
503 – Service unavailable