You Had Me At EHLO...

Troubleshooting Move-Mailbox operations in Exchange 2007 that fail due to an attribute "Being Too Long"

Exchange — Thu, 09 Jul 2009 20:30:29 GMT

You may experience problems performing mailbox move operations if the number of characters on a given Exchange attribute is greater than the default values defined by /SchemaPrep. Most commonly this issue occurs because of an administrative and unsupported edit of the Schema to allow for more characters to be present on a given user attribute. Afterwards when the Mailbox-Move is attempted new Move-Mailbox prevalidation logic runs and ultimately fails the move if the user has a larger number of characters present on the object than that which was defined by /SchemaPrep for the attribute. This error will only manifest itself when the source or target of a mailbox move is an Exchange 2007 mail store. When the Mailbox Move fails the following error will be displayed in the Exchange Management Console:

<Attribute Name> is too long: maximum length is "x" and the actual length is "y"

The inspiration for this post came from a real issue I troubleshoot within Exchange Escalations Support. Throughout this post, I will be referencing and providing examples based upon Exchange Custom Attribute 2 (e.g. extensionAttribute2). However a failure could occur on any attribute that exceeds the upper limit set by /SchemaPrep which I will detail later in this post.

Primary Issue and Symptoms:

As previously noted, the primary symptom at play was that an Exchange Administrator was experiencing intermittent failures when utilizing the Exchange Management Console (EMC) or Exchange Management Shell (EMS) to perform Mailbox Moves. When the move failed an error similar to what is documented below would occur:

Error: Custom Attribute2 is too long: maximum length is 1024 and the actual length is "1358"

Additionally when running Get-Mailbox against the impacted user mailbox the administrator would receive an error about the object being corrupt:

Warning: Object domain.com/Users/TestUser has been corrupted and it is in an inconsistent state.
The following validation errors have occurred:

Warning: CustomAttribute2 is too long: maximum length is 1024 and the actual length is 1358.

Troubleshooting:

The error being referenced would suggest that the mailbox is failing to move due to a large number of characters being present on the aforementioned attribute (msExchAttribute2). The most logical place to begin troubleshooting would be to first determine whether or not a large number of characters are in fact present on the user object in the Active Directory. A number of techniques can be used to determine this:

LDP
ADSI Edit
Traditional Scripting
Exchange Management Console:
- In the Console Tree of the Exchange Management Console select the Mailbox node under Recipient Configuration.
- Depending on how large your organization is you may want to increase the number of recipients to display in the Actions pane.
- Select View and then Add/Remove columns.
- Select CustomAttribute2 select Add, then move it into the Displayed Columns list (you may want to move it to the second column in the list under Display Name), then click OK.
- The Mailboxes Node will load albeit with warnings. If you open the Warnings dialog, a list of all users in this state will be presented:

Windows PowerShell:

Note: If you save this script as a .ps1 file, once executed it will write to the console every user who has over 1024 characters on Extension Attribute 2. If you are receiving the error for a different attribute you can change the attribute as applicable (shell syntax courtesy of my friend and colleague Mike Hendrickson):

foreach ($mailbox in Get-Mailbox)
{
                if ($mailbox.CustomAttribute2.Length -gt "1024")
                {
                                Write-Host "Name: $($mailbox.Name)"
                                Write-Host "Length: $($mailbox.CustomAttribute2.Length)"
                                Write-Host ""
                }
}

Initially in my case I used LDP to "dump" the impacted user object and successfully determined that a large amount of characters were in fact present on extensionAttribute2. I then wanted to verify that the Exchange tools were calculating the value correctly. To do so, I used a very simple technique:

Within LDP, copy the complete contents of the attribute to the clip-board.
Open Notepad, disable word-wrap and add the Status Bar.
Copy the complete value into Notepad.
Calculate the total amount of characters.

To calculate the characters:

With Word-Wrap disabled a single line can only contain 1024 characters.
With the Status-Bar enabled you can get an exact character count for the last line by simply placing the cursor at the end of the last character (will be displayed in the status window).
To calculate, you simply multiple the number of complete lines by 1024 and add the value of characters from the last line.

So in my case, I had one complete line and an incomplete line that had 334 characters present.

1024 + 334 = 1358

This one test allowed me to deduce that yes this one object failing to move did have a lot of characters present on the documented attribute in the Active Directory, and that Exchange was in fact calculating the value accurately.

The next logical troubleshooting step would be to determine what the upper limits for this attribute are in the Active Directory Schema.

Verifying the Limits of Extension Attribute 2 in the Windows Schema:

In the Windows schema there is an object of type attributeSchemaClass for Exchange Extension Attribute 2. The actual display name of this object is: ms-Exch-Extension-Attribute-2.

This object (as well as all other Exchange related objects and classes) are created when /PrepareSchema (or in previous versions /forestprep) is ran. The minimum and maximum character values for objects are always defined by two specific attributes:

rangeLower: (being the minimum value)

rangeUpper: (being the maximum value)

I proceeded to take an LDP dump of the ms-Exch-Extension-Attribute-2 object out of the customer's schema (Note: the distinguishedName of this object would be something similar to CN=ms-Exch-Extension-Attribute-2,CN=Schema,CN=Configuration,DC=<DOMAIN>,DC=com').

What immediately became obvious is that the rangeUpper value for this object apparently supported 10240 characters:

Expanding base 'CN=ms-Exch-Extension-Attribute-2,CN=Schema,CN=Configuration,DC=<DOMAIN>,DC=com'...
Result <0>: (null)
Matched DNs:
Getting 1 entries:
>> Dn: CN=ms-Exch-Extension-Attribute-2,CN=Schema,CN=Configuration,DC=<DOMAIN<,DC=com
2> objectClass: top; attributeSchema;
1> cn: ms-Exch-Extension-Attribute-2;
1> distinguishedName: CN=ms-Exch-Extension-Attribute-2,CN=Schema,CN=Configuration,DC=<DOMAIN>,DC=com;
1> instanceType: 0x4 = ( IT_WRITE );
1> whenCreated: 04/03/2002 15:15:43 Pacific Standard Time Pacific Daylight Time;
1> whenChanged: 04/12/2009 17:20:51 Pacific Standard Time Pacific Daylight Time;
1> uSNCreated: 6732;
1> attributeID: 1.2.840.113556.1.2.424;
1> attributeSyntax: 2.5.5.12;
1> isSingleValued: TRUE;
1> rangeLower: 1;
1> rangeUpper: 10240;
1> mAPIID: 32814;
1> uSNChanged: 46036019;
1> showInAdvancedViewOnly: TRUE;
1> adminDisplayName: ms-Exch-Extension-Attribute-2;
1> adminDescription: ms-Exch-Extension-Attribute-2;
1> oMSyntax: 64;
1> searchFlags: 17;
1> lDAPDisplayName: extensionAttribute2;
1> name: ms-Exch-Extension-Attribute-2;
1> objectGUID: bc303dd3-f496-4c60-a5fa-8647a42dd063;
1> schemaIDGUID: bf967969-0de6-11d0-a285-00aa003049e2;
1> attributeSecurityGUID: 1f298a89-de98-47b8-b5cd-572ad53d267e;
1> isMemberOfPartialAttributeSet: TRUE;
1> objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=<DOMAIN>,DC=com;
-----------

So we can see here that the rangeLower value is set to 1 (which would be expected) and the rangeUpper value is set to 10240 (which would mean that the attribute itself can allow for 10240 individual characters). This large value explains why the failed object could have 1358 characters present on the AD object, but doesn't explain why the Mailbox Move operation would expect the value to be less than 1024.

At first glance this looks like a really...really big bug. Why would we allow you to store 10240 characters on an attribute but fail a mailbox-move because we expect the value to be less than 1024 characters?

But, under closer examination what struck me as curious was the relatively recent update to the object. In the LDP dump above you will notice that the whenChanged value for this object is: 04/12/2009 17:20:51 (early on in the call the customer had told me that they began deploying CAS servers in the environment nearly a year before hand). The whenChanged value in and of itself could be perfectly explainable (e.g. perhaps they decided to roll out SP1 which requires an upgrade of the Schema). On the other hand, perhaps a manual edit of the schema was performed to allow for this many characters.

At this point, I wanted to continue troubleshooting by performing two valid action items:

Compare the whenChanged value on another Exchange attribute (theoretically the whenChanged value "should be" nearly the same, as all Exchange objects should have been modified at roughly the same time (e.g. when /SchemaPrep was run)).
Verify the default value for ms-Exch-Extension-Attribute-2 as defined in the LDF files for Exchange 2007 /SchemaPrep.

Result of Troubleshooting Steps:

I took an LDP dump of ms-Exch-Extension-Attribute-1 and determined that its "whenChanged" value was much older than that contained on ms-Exch-Extension-Attribute-2. Immediately I began to suspect that an unsupported schema edit had been performed. Next I decided to review the LDF files.

To be clear, when /PrepareSchema is run a series of LDF files are imported to define classes and valid attributes for mail enabled objects. Amongst other things it will set the valid ranges on some of the attributes being added or modified within the schema. In Exchange 2007 there are 100 of these files stored on the installation media and are sequentially named schema0.ldf - schema99.ldf. These files can be opened and reviewed easily in notepad.

In my case, I got lucky because ms-Exch-Extension-Attribute-2 was defined in the first LDF file (schema0.ldf).

Note: If you are troubleshooting a different attribute and are having difficulty locating where this attribute is defined in the Schema LDF files, you may want to compile a master file (e.g. one comprised of all 100 LDF files) then simply search the file for the object you are looking for. This could save valuable time and insulate you from human error as you don't have to have all 100 files open (worst case scenario I suppose). For the record, it's supported to "look" in this fashion but not supported to update the schema in this way).

In my case, I found ms-Exch-Extension-Attribute-2 easily enough in schema0.ldf:

dn: CN=ms-Exch-Extension-Attribute-2,<SchemaContainerDN>
changetype: add
adminDescription: ms-Exch-Extension-Attribute-2
adminDisplayName: ms-Exch-Extension-Attribute-2
attributeID: 1.2.840.113556.1.2.424
attributeSyntax: 2.5.5.12
isMemberOfPartialAttributeSet: FALSE
isSingleValued: TRUE
lDAPDisplayName: extensionAttribute2
mapiId: 32814
name: ms-Exch-Extension-Attribute-2
oMSyntax: 64
objectCategory: CN=Attribute-Schema,<SchemaContainerDN>
objectClass: attributeSchema
rangeLower: 1
rangeUpper: 1024
schemaIdGuid:: aXmWv+YN0BGihQCqADBJ4g==
searchFlags: 0

Notice how rangeUpper = 1024.

So at this point it is pretty safe to assume that a Schema Administrator (the only type of user who can make such a change) went in and manually modified the rangeUpper value on this object. In this case it looks like a "0" was simply appended to 1024.

At this point, I was informed that there is a certain 3rd party tool out there that stores application specific user information on extensionAttribute2 and that the edit was necessary to allow the tool to work properly.

Are Schema Edits Supported?

Very simply, edits to the default Exchange schema have and never will be supported. The reason is that it is entirely possible that functionality could be added or removed that is dependent upon the values we expect to be present (as in this case). If you choose to go down this path your risks include but aren't necessarily limited to:

Your Active Directory and Exchange implementation not working as expected.
Being unsupported.

More Troubleshooting (a work-around):

The information contained within extensionAttribute2 on our failed users was simply string information. As we had a valid LDP dump for a user, I had the customer temporarily remove the entire string (although simply removing 335 characters would have allowed the move to complete) via ADSI Edit. Once done, we retried the move which completed successfully. After the move, we added the value back via ADSI Edit and verified that the 3rd party tool continued to function properly.

Conclusion:

Without going into a tremendous amount of detail here (there are many...many articles on the subject), Exchange 2007 now runs a series of pre-validation checks prior to actually performing a mailbox move. This was done in effort to try and reduce situations where partially provisioned accounts/mailboxes would exist as the result of a partially completed move (e.g. a failure where items may have been moved but some problem occurred in updating the AD, et cetera). Any administrator who has been tasked with this type of cleanup knows how tedious it can be. Thus, these checks were added as a precautionary measure to help alleviate this type of situation.

What's important to remember with respect to the scope of this sort of issue is to first know that these checks exist. The "technical stuff" is that within Move-Mailbox code there is a hard-coded validation lookup table. One of the checks it performs prior to allowing a move is to verify whether a user has more than 1024 characters on extensionAttribute2 (e.g. the value Exchange setup defined in the schema via /SchemaPrep). If the user does have something greater than 1024 characters, the pre-validation check fails the move procedure. This check is hard coded. That is to say, there is no LDAP call into the Active Directory to verify what the current allowable upper bounds are for the rangeUpper attribute in the Schema partition. So, although the edit was technically sound in theory, the mailbox move will continue to fail until it is less than 1024 characters.

Even though a "valid" work around was provided to the customer (yes... tedious, but administratively could be made much easier via shell exports and/or scripting), the best overall solution would have been for the vendor to create their own unique attributes that extended the user object class, defined the range and then wrote their values to an "intentional" attribute. Because these attributes would be unique to their application, they would never be checked in some sort of Exchange validation code.

Resources for Accomplishing This:

1. Extend the Schema:
http://technet.microsoft.com/en-us/magazine/2008.05.schema.aspx?pr=blog

2. Extend the User Class in the AD Schema:
http://www.windowsitpro.com/Web/Article/ArticleID/9738/9738.html

3. Contact the IANA to acquire valid OIDs:
http://msdn.microsoft.com/en-us/library/ms677621.aspx
http://pen.iana.org/pen/PenApplication.page

Prior to signing off, I have witnessed a lot of confusion concerning the acceptable values or "ranges" for Exchange Extension attributes. I wanted to provide you with a definitive list for all the Exchange Extension Attributes as well as their relevant values as defined in the SCHEMA*.ldf files. The short story (or as I like to say..."the Reader's Digest version") is that 1-10 can contain up to 1024 characters, whereas 11-15 support up to 2048 characters.

Schema Object Definitions and ranges as defined in the Exchange 2007 SCHEMA*.LDF files:

ms-Exch-Extension-Attribute-1 -- rangeUpper: 1024
ms-Exch-Extension-Attribute-2 -- rangeUpper: 1024
ms-Exch-Extension-Attribute-3 -- rangeUpper: 1024
ms-Exch-Extension-Attribute-4 -- rangeUpper: 1024
ms-Exch-Extension-Attribute-5 -- rangeUpper: 1024
ms-Exch-Extension-Attribute-6 -- rangeUpper: 1024
ms-Exch-Extension-Attribute-7 -- rangeUpper: 1024
ms-Exch-Extension-Attribute-8 -- rangeUpper: 1024
ms-Exch-Extension-Attribute-9 -- rangeUpper: 1024
ms-Exch-Extension-Attribute-10 -- rangeUpper: 1024
ms-Exch-Extension-Attribute-11 -- rangeUpper: 2048
ms-Exch-Extension-Attribute-12 -- rangeUpper: 2048
ms-Exch-Extension-Attribute-13 -- rangeUpper: 2048
ms-Exch-Extension-Attribute-14 -- rangeUpper: 2048
ms-Exch-Extension-Attribute-15 -- rangeUpper: 2048

I hope you found this article interesting/useful.

If you did, please leave some feedback.

Happy Trails.

- Eric Norberg

Share this post :

Large Message Processing in Exchange, Part 1: Prevention and Planning

Exchange — Tue, 07 Jul 2009 14:23:05 GMT

Already an expert on large messages? You'll still want to check out the updated "Best Practices" section below to harden your server against possible outages.

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.

Reasonable limits

It all begins with "reasonable" size limits. So the question everyone asks is "what is reasonable?" The answer is that your mileage will certainly vary with your hardware, drive space, number of users, availability requirements, etc. For Exchange 2007, the typical size limits we see are in the range of 10-30 MB. There are business cases where larger messages are required. However, not all hardware is equally equipped to handle it. Think about the following cases:

Maximum allowed msg size	Maximum allowed number of recipients per message	Typical messages per second	Possible worst case peak scenario
10MB	5000	10 msg/sec	500GB/sec
30MB	5000	10 msg/sec	1.5TB/sec
100MB	5000	10 msg/sec	5TB/sec

Do you have that kind of space available? Do you want to pay for it? Can your disks keep up with that amount of I/O? Hub transports? Mailbox databases? Transaction log files? Will your archiving and retention systems be able to keep up?

Ok, so obviously this is an extreme case - every message sent is not going to be as large as the maximum limit, and not every message is going to be sent to as many recipients as possible. But you can easily see that message size is an important piece of planning for server sizing and availability. You must plan for both the average case, but also consider the peak/worst case. Even if the same chart were done with averages instead of worst cases, you can imagine that even if just a few large messages make it out per day, the average size goes up considerably. Also, your server has to be able to handle those few per day in a reasonable amount of time. Remember that it is possible to provide limits for one set of users and still allow the occasional large message to be sent by more important folks, say company executives.

Furthermore, if the possibility exists that someone can send a DVD .ISO to everyone in the company, you can bet that it will happen at some point. Will your server(s) handle it gracefully? Or will business stop because of this incident?

Our capacity and planning tools will help you make the decision, although they are designed around the average case - don't forget to at least consider that raising message sizes will not only affect the average case, it will also raise the peak load case. For more discussion on this, see this post.

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.

Let's also take a look at the graph below (Message Size (MB) versus Version buckets). This graph charts the size of the message sent along with the corresponding Version Buckets Allocated while the message was transmitted. The yellow line shows the default medium threshold for Back pressure resource monitoring of 120, and the red line is the default High Threshold of 200. As the message increases, the version buckets allocated continue to increase as well. When the message size reaches approximately 100MB the version buckets allocated have done beyond the medium threshold value of 120. This will cause inbound anonymous SMTP traffic to temporarily be suspended (Internal Hub to Hub and Mailbox submissions will not be affected. This chart shows that Exchange 2007 has the ability for transport to support a single message as large as 150MB without causing internal mail flow disruption - but again, remember, this is an isolated single message going to a single recipient.

Please note that these measurements were taken in the absence of processing a high rate of other smaller messages and it was performed on a server configuration that was I/O constrained (single disk).

For more information about the impact of specific messages on hardware, check out this study.

And for information about the impact of large messages on your mailbox stores, see this post.

Size Limits

Although, you've probably seen this, let's quickly review the common places that size limits are set and discuss possible ways to harden your server(s):

Global/organizational size limits - these settings control the absolute maximum size message that can be submitted to store with Outlook, and accepted by the categorizer throughout the organization. Although it is "global" in scope, there can be exceptions to this limit.
Global/organizational MaxRecipientEnvelopeLimit - this controls how many recipients can be on a single message. It is probably a good idea to consider lowering this from the default value of 5000 once Exchange 2003 is no longer in your organization as Exchange 2003 calculates this after distribution groups are expanded. But Exchange 2007 and later will consider a DG as a single recipient. The nice thing here is that you can setup the larger DGs for broadcast emailing and restrict who is allowed to send to them. You could also lower the value if say you only had 2000 mailboxes in your organization - no need to keep the default value.
Connector limits (send, receive, foreign, routing group, AD site link) - these are useful for what can pass through a particular connector. For example, you may want to allow user SMTP submissions to be 15 MB, but only 10 MB for application servers, and only 5 MB for anonymous "Internet" email. You should always have a reasonable size limit on your Internet facing receive connector(s).

Yawn. You've seen this before, right? Well what about these limits you may not remember?

OWA - By default, OWA users can upload attachments of up to 30MB for submission. This value can be modified.
DAV clients like older versions of Entourage - KB 935848 talks about the issue. You can set the MaxRequestEntityAllowed value on the w3svc/1/ROOT/Exchange key in the metabase to a value similar to the maximum size posting you want to allow from DAV clients.
Public folders - Although public folder posts do not go through transport, they can be equally dangerous to the server. If someone posts a gigantic message, it could cause the public folder store to consume system resources and run out of space. In addition, if the folder is replicated, the problem can spread throughout the organization (replication messages are system messages and bypass most other checks). You can set limits for replication messages, but large single posts will bypass this limit. Contrary to popular belief, this setting is not an upper limit on replication message size - it's more like a lower limit. When we have multiple changes to pack up, we will keep packing each change into the same message until we reach at least the replication message size limit. After that, we send the message, and start packing additional changes into the next replication message. Let's say your replication message size limit is 300k. If you post 500 1k items in a folder, 300 of them will be packed into the first replication message, and then 200 will be packed into the next one and sent. If you post 500 1MB items, each individual item exceeds the message size limit, so that just means that we won't pack any additional changes into each replication message - each item will be sent in its own 1 MB replication message. If you post a 1 GB item, the same applies - you get a 1 GB replication message. We don't split up a large item between replication messages. The only way to control this is to set reasonable item size limits, particularly on replicated folders. You can set these at the database and folder level.

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 -

<add key="DatabaseMaxCacheSize" value="536870912" />

The version bucket thresholds should be as follows -

<add key="VersionBucketsHighThreshold" value="200" />
<add key="VersionBucketsMediumThreshold" value="120" />
<add key="VersionBucketsNormalThreshold" value="80" />

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.

- Scott Landry, Mohammad Nadeem and Bill Long

Share this post :

Spotlight on Exchange 2010: Voice Mail Preview - Part 1: Introduction

Exchange — Mon, 29 Jun 2009 15:35:00 GMT

Voice Mail Preview will literally transform the way that you look at voice messages in Exchange.

Exchange Unified Messaging (UM) makes it easy to manage your voice messages by delivering them in your Inbox. You can then use many types of Exchange mail client software to review your voice mail. Microsoft Outlook, Outlook Web Access (OWA), Outlook Mobile (and other clients connected via Exchange ActiveSync) and, of course Outlook Voice Access (the speech access interface in Exchange UM) are examples of the ways that you can now retrieve voice mail.

Figure 1. Exchange UM voice mail in the Inbox

If you're using a visual mail client such as Outlook to review your voice mail, it's great to see at a glance the message details (date/time, length) and the number or name of the sender. In Outlook and OWA, you can even add your own text in an Audio Notes field. This permits you to annotate the message so that you can see what it's about, should you return to it later. You can also search for the message by one or more words in the note, as you're used to doing for e-mail.

People who have used the Audio Notes feature since Exchange 2007 have surely sometimes wished that the annotations could be generated automatically.

In Exchange 2010, the Voice Mail Preview feature will do this, and more. By the time that a voice message arrives in your Inbox, UM can insert a Preview. This is machine-generated text that is derived from the voice recording. You can usually gain a good sense of the recorded content by looking at the Preview. Text in the Preview is indexed, so you can search for voice messages without Audio Notes. You can add additional information or make corrections through the Audio Notes field, if required.

Figure 2. Voice Mail Preview (sample message)

Figure 2 shows an example of an actual voice message with a Preview, which I received recently. Some of the text in the figure has been obscured to protect the identity of the caller. In this case, the caller was a telemarketer and I was able to glance at the message (which arrived while I was in a meeting and unable to play the audio) and decide that it was (how shall I put this?) not at all urgent.

In later articles in this series, I'll look at Voice Mail Preview in more detail, describing additional capabilities, how it works, and some limitations.

- Michael Wilson

Share this post :

Spotlight on Exchange 2010: Delivery Reports Part II (for Administrators)

Exchange — Fri, 26 Jun 2009 03:11:00 GMT

In my recent post Spotlight on Exchange 2010: Delivery Reports, I discussed Delivery Reports from an end-user perspective. In this post I'll review the different things administrators can do with message tracking. We'll discuss disclosure and privacy control settings and do a quick review on which roles have access to message tracking and how to grant access to a user or group of users.

Disclosure and privacy control

There are two settings that can be modified in the organizational configuration to change the level of disclosure of sensitive items in Delivery Reports: Read status reporting and subject logging.

Feature	Default Setting
Read Status Reporting	Disabled
Subject Logging	Enabled

Read Status Reporting

If this feature is enabled, a user requesting the Delivery Report for a particular message can see if that message was marked as read in the recipient's mailbox. Unlike read receipts, read status does not require a separate user action, if the message was marked as read at some moment by the email client, we report the status change and subsequent "mark-as-unread" activity won't affect the read status of the message.

Set-OrganizationConfig -ReadTrackingEnabled $true

Read status reporting is disabled by default, and can be enabled for every user in the organization by executing the following cmdlet in PowerShell:

After doing this, every Delivery Report shown to a user will include the read status of the message in the recipient's mailbox, for all the recipients in the organization, as we can see the following screen capture:

Keep in mind that if a message is marked as "Read", it means that the email client marked that message as read; both OWA and Outlook will, by default, mark messages as read if they are shown in the preview pane.

To give administrators more granular control over this feature once it is enabled in the organization, administrators can select individual users and disable read status reporting for messages in their mailboxes. This can be useful for users that handle sensitive information and the act of reading those messages should be kept hidden from others. For example, to disable the read status reporting for user Lubor Kollar from the Legal department, the administrator would execute the following PowerShell cmdlet:

Set-Mailbox "Lubor Kollar" -MessageTrackingReadStatusEnable $false

As we can see in the following Delivery Report, the read event is not being reported for the user:

Subject Logging

Administrators can also choose if the subject line for messages is stored in the message tracking logs for all emails sent or received within the organization. This is enabled by default, and can be disabled by the on-premise administrators. Disabling this feature is not an available option for datacenter administrators.

Before making the decision to disable this feature, administrators should consider the impact of the change to the end user's experience. Disabling subject logging will make it impossible to search for Delivery Reports using the subject field, so administrators should alert users that the subject field has to remain empty in all Delivery Report searches.

Get-TransportServer | Set-TransportServer -MessageTrackingLogSubjectLoggingEnabled $false
Get-MailboxServer | Set-MailboxServer -MessageTrackingLogSubjectLoggingEnabled $false

To suppress the logging of message subjects in the Message Tracking logs, on-premise administrators have to disable Subject Logging on each Mailbox Server and Transport server in the organization. For multi-role servers administrators would only have to disable this for either of the roles. Administrators can use the following PowerShell cmdlets to disable Subject Logging in all servers within the organization:

Administrative Roles

Currently users in the following security role groups can read Delivery Reports on behalf of other users:

Organization Management
View-Only Organization Management
Recipient Management
Records Management

New-ManagementRoleAssignment "Message Tracking - Help Desk" -Role "Message Tracking" -SecurityGroup "Help Desk"
Add-RoleGroupMember "Help Desk" -member msteele

To add Delivery Reports capabilities to the Help Desk role group and add the user Mark Steele as a member of the Help Desk group, execute the following PowerShell cmdlets:

So, the next time Mark Steele logs into ECP he will be able to use the "Select what to manage" dropdown to access the ECP Help Desk view for the organization; then by clicking on the "Reporting" tab he will access the administrator view of the Delivery Reports search pane, as shown on the screen shot below:

In the screenshot we can also see that the Administrator's view of the Delivery Reports search panel is somewhat different from the user view. In this view Administrators and Help Desk personnel can select a user mailbox using the "Mailbox to Search" field and make searches on behalf of that user in exactly the same manner that the selected user would.

- Alexis Delgado

Share this post :

Upcoming Microsoft Certified Master Dates Announced

Exchange — Wed, 24 Jun 2009 18:47:00 GMT

We've just announced the next 4 dates for the Microsoft Certified Master (MCM) Exchange Program over at our web site. There are two more Exchange 2007 deliveries planned, in September and November, and then we kick of the 2010 material in March and May 2010. Exciting times!

We are still offering a discount for the 2007 programs so if you want to take advantage of that, I suggest you hurry on over to the site and have a look. You can also take a look at our blog for lots of useful background info, stories from past attendees, advice for potential attendees and more.

I'll answer a question that I'm sure will come up: Should I take the 2007 course or wait for 2010? Well, the answer to that is here. Go take a look and leave a comment if you want to.

-- Greg Taylor

Spotlight on Exchange 2010: Call Answering Rules (Part I) - Creating your first Call Answering Rule

Exchange — Tue, 23 Jun 2009 02:04:00 GMT

One of the core functionalities provided by Exchange UM is call answering, i.e., to answer phone calls and record voice mails on your behalf. With the introduction of Call Answering Rules in Exchange UM 2010, you can dictate how incoming phone calls should be handled, thus enriching the call answering experience of your callers. In this article, we walk through the steps of creating a simple "default" call answering rule - one that is applied to all inbound phone calls.

I don't have any Call Answering Rule. So what?

Out-of-the-box, there are no Call Answering Rules created for you. All your callers will get the same default, call answering experience provided by UM 2007, i.e., callers will be prompted to leave you a voice message. Users who are satisfied with the default experience can continue to retain the same experience without the need to create any rule.

Creating a Default Call Answering Rule

As illustrated in Figure 1, the control for managing Call Answering Rules is located under ECP > Phone > Voice Mail tab. To create a new call answering rule, click on "New Rule".

Figure 1: Call Answering Rule Control

Anatomy of a Call Answering Rule

Each Call Answering Rule comprises two key aspects:

Conditions - what criteria must be met before the rule can be applied to an inbound call.
Actions - what options should be presented to the caller when all the conditions are met. These actions will be read to the caller over the phone and users can then pick an action using the phone keypad.

Figure 2 shows the form for creating a Call Answering Rule, which is divided into two columns. The right column displays the list of available conditions and actions you can use to build the rule. The left column displays the list of conditions and actions which have been added to the rule.

Figure 2: Call Answering Rule Form

Conditions

There are 4 classes of conditions supported by Call Answering Rules, including:

Caller ID
Time-of-the-day
Free/busy status
Automatic email reply is enabled/disabled

By using a combination of these conditions, you can create multiple Call Answering Rules and have them triggered for different phone calls. To create a default rule that will be applied to every call, you create a rule does not contain any condition. Since we are not adding any condition, I will not delve further into these conditions but leave them to my follow-up article.

Actions

There are 3 kinds of actions supported by Call Answering Rules, including:

Find-Me
Call Transfer
Leave a voice mail

Adding a Find-Me action

When a caller selects Find-Me action, UM will attempt to locate you on up to 2 different phone numbers, and then connect you to the caller. To add a Find-Me option, click on "Find me at the following numbers". In the Find-Me dialog and with reference to my example in Figure 3 :

You can optionally specify a context that will be read to the user. In my example, I have entered "important matters" to inform my callers that they should only select this action if they have important things to discuss.
You need to associate the Find-Me action with a number on the keypad. This is the key which the caller has to press to select this action. In my example, I have also specified "1" as the DTMF key to be used.
You also need to specify 1 to 2 phone numbers to be dialed. If 2 numbers are specified, they will be dialed in a sequential fashion, i.e., one after the other. Each phone number has an associated duration. This indicates how long UM should try dialing the phone number before moving on to the next number or revert back to the options menu.
Click on Apply to add the Find-Me option and close the dialog.

Figure 3: Find-Me Dialog

Adding a Call Transfer option

By configuring a Call Transfer action, you provide callers with the option to be transferred to someone else. To add a Call Transfer option, click on "Transfer the caller to..." link. In the Call Transfer dialog and with reference to my example in Figure 4.

You can optionally specify a context that will be read to the caller as part of this option. In my example, I have entered "Unified Messaging" to inform my callers that they can choose this option if they have questions around "Unified Messaging."
You need to associate the Find-Me action with a number on the keypad. I have specified "2" as the DTMF key to be used for this option.
You need to specify a transfer target for this option. This can be in the form of a phone number, or you can select an AD contact for the call transfer. When specifying the AD contact, UM will attempt to transfer the call to the UM extension of the AD contact. If the AD contact is not UM-enabled, the AD business phone number field will be used. In my example, I have selected my manager "Michael Wilson" as the transfer target.
Click on Apply to add the Call Transfer option and close the dialog.

Figure 4: Call Transfer Dialog

Adding Voice Mail action

By default, the Voice Mail option is automatically added to each Call Answering Rule. If you do not wish to offer this option, you can remove it by clicking:

To add the option back, simply click "Leave a Voice Message."

Saving the rule and trying it out

Prior to saying the rule, you need to give a meaningful name to the rule you've created. After which, you click on the SAVE button to create the rule. Next, you should test to see if the call answering rule is working as desired by trying to call your UM-enabled phone extension and wait for the call to be answered by UM.

Optional: Record a customized greeting

You can record a custom greeting for each rule. By default, UM will generate a default greeting based on the actions you have configured. To record a custom greeting, you can click on:

in the Call Answering Rule form and UM will call you up to record a greeting.

Note: In your recording, you should include any actions you have configured on the rule itself. UM will not list the actions if a custom greeting is present.

-Chun Yong Chua

Share this post :

White Paper: Comparing the Power Utilization of Native and Virtual Exchange Environments

Exchange — Fri, 19 Jun 2009 11:48:19 GMT

Is reducing or controlling the high cost of the power to run and cool computer hardware is a top priority for your organization? Are you considering server virtualization solutions to reduce your server footprint and the associated power and cooling costs?

Because the virtualization of Microsoft Exchange servers rarely results in a reduction of physical processors, there is some question as to whether there is significant hardware, power, cooling, or space savings from virtualizing correctly-sized Exchange Server 2007 server roles. The answer to this question can be found in a new White Paper we just released about a study that was done internally, entitled "Comparing the Power Utilization of Native and Virtual Exchange Environments." This study compared the power utilization of native and virtual Exchange server environments in a scenario in which the number of physical servers was reduced from eight to two, but the total number of logical processors and the amount of memory remained the same. It examined power utilization of native and virtual Exchange 2007 environments in a scenario where physical servers were reduced from 8 to 2 but the total number of logical processors remained constant at 32. There was no processor core consolidation, and storage power utilization was not included. In this scenario, there was a 50 percent reduction in server power utilization and a projected savings of 8,582 kWh/year.

For more details about the study and its conclusions, check out the White Paper, "Comparing the Power Utilization of Native and Virtual Exchange Environments."

Help us design our next Exchange TechCenter!

Exchange — Tue, 16 Jun 2009 17:41:00 GMT

Here at msexchangeteam.com, we've posted a few times about our Exchange TechCenter, see here and even here for a way-back post. We love the TechCenter, and all it brings to you, our customers. In fact, we are planning to move this blog even closer to the TechCenter as we move towards the Exchange 2010 product release. Combining everything about the TechCenter with the Exchange team blog is our idea of a match made in heaven.

As a preview to this, when we released the Exchange 2010 Beta, we also launched the Exchange 2010 Beta TechCenter. The Exchange 2010 Beta TechCenter is currently a separate site in addition to the Exchange Server 2007/2003 TechCenter. Check out our new layout:

This is the main Exchange 2007/2003 TechCenter design:

In conjunction with the Exchange Server 2010 Release To the Web (RTW), we'll integrate the Exchange 2010 beta website with the current (non-Exchange 2010 focused) TechCenter. However, we are currently designing this integrated TechCenter, and we are looking for your feedback during this process.

First a few things about the Exchange 2010 Beta TechCenter:

You might notice that we streamlined navigation to 4 main tabs: Home, Help, Blog, and Forums.

Help:
The "Library" tab in the current (non-Exchange 2010 focused) Exchange Server TechCenter was renamed to "Help" in the beta site. This tab name change is more than just an editorial change. For the first time, with Exchange Server 2010, accessing help via F1 from the Exchange Management Console (EMC), takes you directly to the contextually appropriate topic online in the TechNet Library vs. opening a.chm file-so the Library *is* the Help.
Blog and Forums:
We want to emphasize the priority for community in the design of the TechCenter so that you can connect with the Exchange team and each other. In this, we're making these key community resources more prominent.
Information you need:
We placed the most important beta content right on the TechCenter's main page (i.e system requirements, download and 2010 blog and forum posts) and provide another view into the latest blog and forum posts on Exchange Server 2010. These "content areas" are being updated on a continuous basis as more is developed.

Got Feedback?

So as we mentioned, this Exchange 2010 beta TechCenter will eventually be merged to become our main Exchange TechCenter as we get to our RTW release. We plan to keep the Community elements prominent on the next iteration. Speaking of community, we'd love your feedback not only on the beta TechCenter, but also on the following:

On the main page of the TEchCenters, we typically highlighted key video, webcast and whitepaper content. How much of this featured content should be Exchange 2010 content vs. Exchange 2007 content on the main page of the next release of the TechCenter?
Do the tools/resources on our actual Help content pages (here's an example page) give you access to what you need? (i.e. content ratings, link to more information, table of contents, etc)
Is there a particular content type or area that should be more prominent on the next version of the TechCenter?

We appreciate your feedback in helping shape the TechCenters and the Exchange Server 2010 Help experience to help get you the information you need to succeed. So please, let us know what you think!

Katie Kivett and Joey Masterson

Share this post :

Video: High Availability in Exchange Server 2010 - Part 4

Exchange — Sun, 14 Jun 2009 16:38:00 GMT

In Part 1 of my video blogcast series on High Availability in Exchange Server 2010, I introduced you to the concept of database mobility, and the features known as database availability groups (DAGs) and mailbox database copies.

In Part 2, I showed you how to create a DAG and how to add Mailbox servers to a DAG.

In Part 3, I showed you how to add a mailbox database copy, and I demonstrated Get-MailboxDatabaseCopyStatus and Test-ReplicationHealth.

In Part 4, the final part of this blogcast series, I perform a database switchover using the Exchange Management Console, and show you a switchover from an administrator's perspective. Then, I perform a second database switchover using the Exchange Management Shell, and show you a switchover from an Outlook Web Access user's perspective.

Please download the video and watch it full-screen. Part 4 is just under 4½ minutes. Click on the video thumbnail below to go to the video. There is a Download link where you can download the video (use Right-click, Save Target As...).

Part 4:

I hope you enjoyed this blogcast series. For more information see the High Availability and Site Resilience section of the Exchange Server 2010 (Beta) Help.

I'd also like to invite all of you to check out the Exchange Server 2010 forum and the Exchange Server 2010 Training Portal.

-- Scott Schnoll

Named Properties, Round 2: What lies Ahead

Exchange — Fri, 12 Jun 2009 03:07:00 GMT

In my last blog post on named properties, I detailed the history of named properties, how they are arranged, mapped, and how Exchange (since Exchange 2000) has created named property mappings for x-headers on inbound messages. Rollup 8 for Service Pack 1 contains the changes we made to restrict named property mapping further, and with Service Pack 2 on the horizon there are more changes in the waters. This post details what is changed in Service Pack 2, how that affects (or does not) you, and includes a request for feedback.

As mentioned before, Exchange 2007 creates named properties for x-headers during delivery. The RTM version of Exchange 2007 would NDR messages if the named property quota was reached, even if the property were only for an x-header. Service Pack 1 changed this behavior to only NDR the message if a non X-header named property could not be mapped (in other words, a property likely to contain critical data). Rollup 8 for Service pack 1 removes the ability of non-authenticated messages to consume named property IDs. Service Pack 2 goes even further.

Service Pack 2 is in line with Exchange2010 behavior - that is, no x-headers are ever promoted to individual properties if a client has not already requested (and mapped) them. Not even authenticated submissions can create new named property mappings. The x-headers are still stored in PR_TRANSPORT_HEADERS and still accessible to MAPI clients but they are not individual properties. This creates a problem for IMAP clients in particular:

Exchange2007 does not contain an STM file - it doesn't save the original mime content. Messages are converted to MAPI. IMAP has the ability to search based on header values, but if these are not promoted, the result is that the message is not contained in the results. If a client has previously mapped t he header in question (a MAPI client) then messages delivered after this will have the x-header promoted as an individual property.

So, the questions I ask are:

Do you own or run an application which requires a custom x-header to be promoted to a property but does NOT create the mapping?
Do you own or run an application which uses an IMAP header search for a custom x-header.

Things that aren't on the table:

Ability to remove named properties.
Ability to pre-register named properties.

We're aware that both of these would prove useful. Also, this is not a voting contest - we've seen how a vocal minority can skew results before. Just a heads up and if you have real world reasons for arguing for a particular request, let us know.

- Jason Nelson

Share this post :

Spotlight on Exchange 2010: E-mail Moderation

Exchange — Wed, 10 Jun 2009 23:38:00 GMT

Moderation in Exchange Server 2010

In past versions of Exchange server, the best way to control mail flow to a distribution group or mailbox was delivery restrictions. Delivery restrictions allow you to reject mail from certain individuals or groups (sometimes referred to as a blacklist), allow mail only from certain individuals or groups (or a whitelist), or a combination of both.

In Exchange Server 2010, moderation enables you to control messages sent to groups and individuals based on the human element: a moderator-not who sent it.

Moderation isn't limited to groups. Like delivery restrictions, you can also moderate mail sent to individual mailboxes or mail contacts, in the same way as mail sent to distribution groups. If you wanted to moderate mail from a mailbox/contact, you would have to set up a transport rule, where moderation is available as an action. For the rest of this post, I'll be talking about moderated groups/lists.

Sending mail to a moderated group

For end users, sending mail to a moderated group is the same as sending to any other group. If they are using Outlook Web Access or Outlook 2010, they will see a MailTip telling them they are sending mail to a moderated group.

Instead of expanding a message and sending it on to the members of a group, Exchange sends the mail to the Arbitration Mailbox. This mailbox is like a holding tank for messages that are under review by moderators. Upon receiving the message, the arbitration mailbox sends out approval request to each moderator. The original message is attached to the approval request and also shown in preview form in the approval request itself. Moderators have three options for a decision:

Approve
Reject
Reject with comments

These decisions are sent as messages back to the arbitration mailbox, where the decision is processed. Like mail to any other group, users are only notified if their message was not delivered (moderators can choose to include comments explaining why they rejected the message). If the message is approved, it is released from the arbitration mailbox for delivery to the group.

In both Outlook and Outlook Web Access, moderators see buttons at the top of their message for approving and rejecting messages (see an Outlook Web Access example below). In older versions of Outlook, moderators can make decisions with voting buttons.

Multiple moderators

For groups configured with multiple moderators, when one moderator makes a decision, a message is sent to all the other moderators notifying them of the decision. This notification is processed by the receiving mailbox, and when this notification arrives in a moderators mailbox, the approval request is disabled (no further decision can be made) and moved to the deleted items folder.

This keeps moderators' inboxes less cluttered, leaving only approval requests that still require a decision.

Enabling moderation for a group

To enable moderation for a group, you just need to enable moderation and specify who the moderators are. If you leave the list of moderators blank, the group owners will receive all the approval requests.

In ECP, group owners and administrators can configure moderation here:

Moderation can be similarly configured from EMC:

Moderation in a transport rule

For more customized scenarios, moderation is also available as an action with any transport rule. In the case of a rule where the condition is a match, the message is not delivered to any recipients until approved by moderator.

FAQ

Q: Are delivery restrictions still there in Exchange 2010?
A: Delivery restrictions haven't gone anywhere. In fact, you can use moderated groups and delivery restrictions together; delivery restrictions simply take precedence over moderation. If a sender passes delivery restrictions, then they will be moderated (unless they are on the bypass list for moderation).

Q: What if an email is sent to two groups: one moderated and one unmoderated?
A: The message will be sent to moderators for approval for delivery to the moderated group. It will be delivered to all members of the unmoderated group without moderator intervention. Any user that is a member of both groups would get the message immediately. They won't see a second message (upon approval to the moderated group) thanks to duplicate detection.

Q: What about nested moderated groups?
A: If one moderated group (the "child") is a member of another moderated group (the "parent"), the message must be approved for both the parent and the child groups.

If you set the BypassModerationEnabled flag to $true on the parent group, any messages sent to that group will bypass moderation by child groups. For some messages, you might not want moderators of child groups to be able to reject them (say, messages from executives sent to an org-wide group).

Q: What happens if two moderators make conflicting decisions at the same time?
A: In most cases, moderators will not be able to make a decision after one has already been made. However, if two moderators do manage to make decisions at the exact same time, whichever decision message makes it to the arbitration mailbox wins. The "losing" moderator(s) are then notified that their decision did not take effect.

Q: What versions of Exchange are required for moderation?
A: Moderation requires Exchange 2010 to be deployed on all Hub Transport Servers to work properly. Earlier versions of Exchange will ignore moderation and simply deliver any messages to moderated recipients.

- E.J. Dyksen

Share this post :

Spotlight on Exchange 2010: Delivery Reports

Exchange — Mon, 08 Jun 2009 18:42:00 GMT

Exchange 2010 provides an easy way to verify whether that very important message was delivered to every recipient with a new feature we call delivery reports.

Delivery Reports contains delivery information about messages you sent, such as:

Why didn't my message go through?
Where is my message now?
Who received my message?

And about messages you received:

Am I a member of any of the groups addressed in this message?
Why is this message in a folder and not in my inbox?

Delivery Reports can be accessed by users from Outlook Web Access or by clicking on the "Options" button and then going to "Organize E-mail".

Administrators can access Delivery Reports from the Exchange Control Panel on the "Reporting" tab, and if the Administrator has access to the Exchange Management Console, the "Toolbox" section contains a link to "Message Tracking" where they can search for Delivery Reports. The Message Tracking tool included in previous versions of Exchange has been renamed "Tracking Log Explorer".

What information is shown in Delivery Reports?

Event	Who sees it?
Email Submission from the Sender’s Mailbox	Users, Administrators, Helpdesk
Group Expansion	Users, Administrators, Helpdesk
Delivery Success	Users, Administrators, Helpdesk
Delivery Failure	Users, Administrators, Helpdesk
Inbox Rules	Recipients, Administrators, Helpdesk
Transport Rules	Administrators, Helpdesk
Message was read (if enabled)	Users, Administrators, Helpdesk
Hub Transfers	Administrators, Helpdesk
Transfer to External Servers	Users, Administrators, Helpdesk
Transfer to Older Versions	Users, Administrators, Helpdesk
Moderation	Users, Administrators, Helpdesk

Getting Delivery Reports for messages I sent

If you are interested in seeing the Delivery Report for a particular message in the Sent Items folder, right click on that message and then click on "Open Delivery Report"

This will open the Delivery Report included in the image bellow, where you can see that the message was sent to a group that contains 15 recipients and delivery was successful to all of them. You can also see which groups were expanded to make the delivery to a particular user. And your organization has Read Status reporting configured in your organization you would also see if the message was marked as read for a particular recipient.

If the message was addressed to a group, and you have the necessary permissions; the "Edit Groups" link will allow you to change the settings as well as remove yourself or others from the group.

Getting Delivery Reports for messages I received:

To track a message you received, you would go to the Inbox or any subfolder and access the Delivery Report by right-clicking on the message in the list view or on the top of the message and then clicking on "Open Delivery Report"

In this Delivery Report, you would see only information related to delivery into your mailbox. Delivery information for the other recipients of the message is not shown. You are able to see if any of your inbox rules moved the message to another folder and which groups were expanded so that the message was delivered to you.

Searching for Delivery Reports

If you want to get a delivery report for a message that you were expecting, or you simply can't find the message in your mailbox, you can also search for Delivery Reports. To do this you would have to log into Outlook Web Access, click on the "Options" Button and then click on "Organize E-mail". The "Delivery Reports" Tab is a search console to help you find a Delivery Report for messages you sent or messages that you received or expected to receive.

The "subject" filter can be used to refine any search, as a sender or as a recipient, and adding one or more words in the field can improve the search by reducing the number of results as well as the overall time the system takes to find the message you are looking for.

To search through all the messages you've sent, you can leave the "Search for messages I've sent to:" field empty, as shown in the screenshot:

If you want to search through the messages you've received, you have to specify the sender in the "Search for messages I've received from:" field:

As you can see from the image, the search results are listed in the bottom half of the search pane. You can double-click on any row or select one and click on the "Delivery Report" button to view the Delivery Report for that message.

Frequently asked questions:

Do I have to specify a sender when searching for messages I received?

Yes, we need to know who the sender is to get the tracking information. If you are looking for messages that you've sent you can choose if you specify a recipient or not.

Can I search for messages that were sent from users outside my organization?

Yes, you can search for messages sent by a particular user outside your organization that was addressed to a single user inside the organization. To do this you would have to provide the full SMTP address of the sender in the "Search for messages I've received from" field.

How long are Delivery Reports kept?

The Delivery Report tool uses the data stored in the message tracking logs; the default time for maintaining the indexes on those files is 2 weeks.

Can I see what a user did with the email I sent him?

If the administrators in your organization enable Read Status reporting you would be able to see if a message you sent have been marked as read by the recipient's client. More information on this will be given in a future post.

What information is presented to Administrators and Helpdesk?

Administrators can search for Delivery Reports on behalf of other users in the organization. The view presented to them will include some extra information, such as server names and addresses, to help troubleshoot delivery problems.

- Alexis Delgado

Share this post :

Video: High Availability in Exchange Server 2010 - Part 3

Exchange — Wed, 03 Jun 2009 22:04:18 GMT

In Part 2, I showed you how to create a DAG and how to add Mailbox servers to a DAG.

In Part 3, I show you how to add a mailbox database copy, and I demonstrate Get-MailboxDatabaseCopyStatus and Test-ReplicationHealth.

Please download the video and watch it full-screen. Part 3 is just under 3 minutes. Click on the video thumbnail below to go to the video. There is a Download link where you can download the video (use Right-click, Save Target As...).

Part 3:

Enjoy...and stay tuned for Part 4, coming soon!

-- Scott Schnoll

Troubleshooting Unified Messaging: New white paper

Exchange — Wed, 03 Jun 2009 19:55:00 GMT

Interested in learning the fundamentals of troubleshooting common Unified Messaging call flow issues?

We've just released a new white paper on troubleshooting Unified Messaging. In this white paper, we walk you through the flow of a simple call in UM and take a look at things that may go wrong at various points in the call flow. We provide tips for what you can do if you encounter one of these issues. You will also find information about some helpful troubleshooting tools and resources.

Whether you're new to using Unified Messaging or you'd like a quick review, this white paper has information that can help you keep your organization's Unified Messaging deployment running smoothly.

Head over to Technet to read Fundamentals of Troubleshooting Unified Messaging in Exchange 2007.

-Seema Rahman

Share this post :

Journaling Considerations in Mixed Environments

Exchange — Tue, 02 Jun 2009 00:35:00 GMT

Are you using Journaling in a mixed Exchange 2007 and Exchange 2003 environment? If yes, here are some mixed environment considerations you should be aware of.

A Brief Overview of Journaling

Exchange 2003 shipped with 3 different types of journaling:

Message-only Journaling: Sends just a copy of the email to the journal mailbox with all the P2 header information. This does not include BCC information, or members of a distribution group after the group is expanded.

BCC Journaling: Similar to message-only journaling, but captures BCC information as well.

Envelope Journaling: Captures all envelope (P1) header info, including BCC recipients, and expanded distribution group membership. A journal report is sent to the journal mailbox with the original message attached.

Regardless of the journaling method used, you would need to enable an entire mailbox database for journaling, resulting in mail to and from all mailboxes on the database being journaled.

Exchange 2003 servers transmit journaling metadata between them in a special binary large object (BLOB) using the XEXCH50 extension during an SMTP conversation.

Journaling in Exchange 2007

In Exchange 2007, message-only journaling and Bcc journaling are no longer supported because they do not capture all the information necessary in today’s compliance-focused environments. The only option is envelope journaling. Journaling comes in 2 flavors:

Standard Journaling: Also known as per-Mailbox Database (per-MDB) journaling.

Premium Journaling: Allows you to use Journal rules for more granular journaling.

Both Standard and Premium Journaling are performed in transport by the Journal agent. In deployments where you use 3rd-party archival solutions, you can journal directly to an external (to the Exchange organization) SMTP address using a Contact. This allows you to deliver journal reports directly to the 3rd-party archival solution, rather than having to store them in an Exchange mailbox first and setting up Outlook rules to forward them.

The EXCH50 SMTP extension has also been deprecated in favor of X-headers.

When a message is journaled, the X-Ms-Exchange-Organization-Processed-By-Journaling header is added to it to avoid duplication of journal reports by other Hub Transport servers which may handle the message. Journal reports are stamped with the X-Ms-Exchange-Organization-Journal-Report header, to identify them as such, thus allowing them to bypass message size limits.

However, these improvements come with some special considerations for such environments.

Location of Journaling Mailbox

In mixed environments, you must locate the journaling mailbox (the mailbox to which Journal reports are delivered, specified in the msExchMessageJournalRecipient attribute of the mailbox database) on an Exchange 2003 server. If the journaling mailbox is located on an Exchange 2007 server, email sent from Exchange 2003 users will not contain the journal report but rather only a copy of the original email message.

Why does this happen? When the sending Exchange 2003 server sees that either the recipient or the sender(s) has the journal recipient attribute populated for their mailbox database, it creates a pre-journal report. This is really just the beginning of the journal report (the metadata if you will). The actual creation of the journal report occurs on the Exchange server with the journal mailbox.

Due to the differences in the location of content conversion drivers in Exchange 2003 and Exchange 2007 (recall we moved the store driver to transport in exchange 2007 and due our conversion there or in Categorizer), Exchange 2007 Hub Transport expects a fully formed journal report. When we see the Exch50 blob with the exjournaldata info, we know the message has already been journaled and send it off to the journal mailbox as is.

To avoid this issue we recommend customers place their journal recipient mailbox on an Exchange 2003 server or utilize Journal rules.

Duplication of Journal Reports

If an Exchange 2007 mailbox sends an email to an Exchange 2003 mailbox and that email traverses 2 or more Hub Transport servers to get to the Exchange 2003 routing group, a duplicate journal report will be generated.

Recall from earlier that Exchange 2003 reads journaling information about an email such as journal recipient location from the Exch50 blob. Although in Exchange 2007 we no longer use this blob, we still create it for backward compatibility with Exchange 2003.

So consider when an email is submitted to a Hub Transport server, the journal agent fires and creates the journal report. However, since this HT sees that there is another Exchange 2007 HT in the routing path, it does not create the Exch50 blob. When the last hop HT gets the email, it sees that the next hop is to the legacy Exchange 2003 routing group, and creates the Exch50 blob. However, since the email has already been journaled (as evidenced by the x-header), the Exch50 blob does not contain the journal recipient list for Exchange 2003 to process, resulting in another journal report being created by the Exchange 2003 server.

If due to space considerations, duplicate journal reports are not desirable, you can use the –SubmissionServerOverrideList of the Set-MailboxServer cmdlet to force your mailbox server to use the Exchange 2007 server specified as the Bridgehead on the Routing Group Connector.

Journal Reports Stuck in Submission Queue

Another issue we have been seeing in mixed environments is journal reports sent from Exchange 2003 stuck in the submission queue on Exchange 2007 Hub Transport servers. This issue is currently bugged and there should be a fix out for it soon.

The reason? During S/TNEF to Base64 conversion, the size of a journal report message increases by the standard 33%. This may cause the journal report to exceed your organization’s message size limits. However, since this is a journal report, we will never NDR it and it will stay in the submission queue.

This is also a result of the different way in which Exchange 2003 sends out the journal report. In Exchange 2003, the journal report P2 FROM: header has the address of the original sender of the email, whereas in Exchange 2007 the journal report originates from “Microsoft Exchange“, which is a privileged sender and thus bypasses message size limits.

Duplication of Journal reports when an expansion server is specified

This is not really a mixed mode journaling issue, but rather something to be aware of and a good example of how the Journaling agent fires in Exchange 2007.

You create an Exchange2007 journal rule for a distribution group which has an Exchange 2007 Hub Transport server configured as the expansion server. When a user who is a member of the distribution group sends a message, it gets picked up by the submission service on a Hub Transport server in the same AD site as the Mailbox server. The Journaling agent on that server sees that the sender is a member of a journaled distribution group, and fires, creating a journal report. It then sees that the distribution group has another Hub Transport server configured as the expansion server, and forwards the message to that server for the distribution group to be expanded. The expansion server expands the distribution group, and the Journal agent fires again, creating another journal report for that message.

This is by design.

The Journaling agent fires on the OnSubmitted and OnRouted events in the transport pipeline. This ensures that if a transport agent or some other event (such as a distribution group expansion) modifies the envelope headers, these changes are captured in the journal report as well, maintaining compliance.

In conclusion, the changes in Journaling in Exchange 2007 bring with it many advantages over its predecessor, but like any move forward, co-existing with the past brings with it some special considerations.

-Tom Kern

Share this post :