Quarantine Mailbox: Displaying original SCL, sender and recipients

In Exchange Server 2007, messages delivered to the quarantine mailbox show up as DSNs sent by the postmaster address of the default domain. In HOW TO: Expose original senders and recipients of quarantined messages, we modified the QTNE.cfg form for Microsoft Outlook to reveal original senders and recipients.

Although the original sender and recipient fields were added, the original SCL stamped on the quarantined message wasn't visible. The OriginalScl property was exposed in Exchange 2007 SP1, and is now included in the updated form in that post. Installing the updated form exposes the original SCL for messages in the quarantine mailbox, as seen in Figure 1.


Figure 1: The original SCL for messages in the quarantine mailbox can be displayed using the updated Outlook form

Where are mailbox last logon, client IP address, and other details in Exchange 2007?

In Exchange Server 2003/2000, expanding a Mailbox Database provides information about mailboxes in a database, last logon/logoff times and account(s) that logged on to mailboxes (see 'Displaying Client IP Address in Exchange System Manager' for details).


Figure 1: In Exchange 2003, the Logons node displays Store logon-related information. Click here to see a bigger screenshot.

In Exchange Server 2007, these details are not displayed in the EMC. These can be retrieved easily using the Exchange shell.

The Get-LogonStatistics cmdlet provides the following logon-related information.

AdapterSpeed :
ClientIPAddress :
ClientMode :
ClientName :
ClientVersion :
CodePage :
CurrentOpenAttachments :
CurrentOpenFolders :
CurrentOpenMessages :
FolderOperationCount :
FullMailboxDirectoryName :
FullUserDirectoryName :
HostAddress :
LastAccessTime :
Latency :
LocaleID :
LogonTime :
MACAddress :
MessagingOperationCount :
OtherOperationCount :
ProgressOperationCount :
RPCCallsSucceeded :
StreamOperationCount :
TableOperationCount :
TotalOperationCount :
TransferOperationCount :
UserName :
Windows2000Account :
ServerName :
StorageGroupName :
DatabaseName :
Identity :

The command can be constrained to a mailbox database (get-logonstatistics -Database "MyDatabase" | fl), a mailbox server (get-logonstatistics -Server "MyServer"), or a particular mailbox.

Mailbox information

In ESM, the Mailboxes node of a Mailbox Store displays mailbox-related information such as mailbox size, number of items, and last logon/logoff.


Figure 2: In Exchange 2003, the Mailboxes node displays mailbox-related information. Click here to see a bigger screenshot.

This information can be retrieved using the Get-MailboxStatistics cmdlet. It provides the following information related to a mailbox:

AssociatedItemCount :
DeletedItemCount :
DisconnectDate :
DisplayName :
ItemCount :
LastLoggedOnUserAccount :
LastLogoffTime :
LastLogonTime :
LegacyDN :
MailboxGuid :
ObjectClass :
StorageLimitStatus :
TotalDeletedItemSize :
TotalItemSize :
Database :
ServerName :
StorageGroupName :
DatabaseName :
Identity :

It can also be constrained to a -Database, -Server, or mailbox.

Now that we're dealing with the shell, besides these cmdlets' built-in filtering capabilities (Database, Server, or mailbox), you can use Powershell's where-object cmdlet to further filter the results based on the properties returned by each cmdlet. For example, to find out logon sessions from a particular IP address:

Get-LogonStatistics -Server "MyServer" | where {$_.ClientIPAddress -like "192.168.2.101"}

Controlling OOFs per domain and per mailbox

OOFs can be controlled per domain using Remote Domain settings. By default, setup creates the default Remote Domain for address space *. (As with Connector namespaces, * translates to all domains for which Exchange isn't authoritative/has an Accepted Domain for, and doesn't have an explicit Remote Domain for).


Figure 1: Remote Domains allow control of OOF messages to the internet or specific domains

The choices:
None: OOFs are disabled for the remote domain.
External: Allows only external OOFs to be sent to the remote domain. OOFs created using legacy Outlook clients and those sent by Exchange 2003/2000 servers will be not be allowed. If blocking OOFs to external domains in Exchange 2003/2000, this allows you to restrict legacy Outlook clients from sending OOFs, but allow Outlook 2007/Exchange 2007 users to send external OOFs.
ExternalLegacy: Allows external and legacy OOFs to be sent to the remote domain.
InternalLegacy: Allows internal and legacy OOFs to be sent to the remote domain.

Allowing Internal OOFs to Remote Domains

The InternalLegacy setting sends internal OOF messages to a Remote Domain. If verbiage or content of internal OOFs isn't something you want to share with the outside world, do not use this for Remote Domains.



The InternalLegacy option can be useful in distributed organizations with multiple address spaces and multiple email systems, or specific cases where you may want to share such information with a trusted organization.

Controlling OOFs per-mailbox

Besides the settings in Remote Domains, you can also control external OOFs per-mailbox. This is done using the Set-Mailbox cmdlet. The ExternalOofOptions parameter defaults to External. You can change it to InternalOnly to restrict a mailbox user from sending OOFs outside the organization:

Set-Mailbox foo@mydomain.com -ExternalOofOptions InternalOnly

Related:

• While you were out: Scheduling meetings and OOFs
  
• The hilarious lingo of Exchange folks
  
• Why is OOF an OOF and not an OOO?
  
• Legacy client and Out of Office (OOF) interoperability
  
• OOF integration with Exchange Server 2007 Unified Messaging (UM)

Released: New Whitepapers on Continuous Replication and Planning for Large Mailboxes

New whitepapers have been released today on TechNet.

Whitepaper: Continuous Replication Deep Dive
- written by Ross Smith IV and Scott Schnoll

This whitepaper discusses the different components of Continuous Replication— used by LCR, CCR and SCR, how replication works, backups and log file truncation, what happens during scheduled and unscheduled outages, and how Continuous Replication compares with other replication solutions.

The whitepaper is available here.

Whitepaper: Planning for Large Mailboxes with Exchange Server 2007
- written by Tom Di Nardo

This whitepaper discusses planning and operational issues faced when dealing with large mailboxes, including planning storage, long database backup and online/offline maintenance times.

The whitepaper is available here.

Modifying Display Templates and additional attributes

Recently got a question about customizing the GAL and my previous post that talks about it: "HOW TO: Modify Display Template to make default email address appear in Address Book/GAL".

The new Details Template Editor in Exchange 2007 (in EMC | Tools) makes it much easier to modify templates and give your GAL the kind of look you want (short of adding that 5 Mb. purple bitmap file as a background and an extra-large company logo perhaps... :). Screenshots and more information about Details Templates can be found in Managing Details Templates.

So, you're trying to customize the properties pages of your address lists and want to add an attribute such as ipPhone. You don't see the attribute you're looking for. Can you add additional attributes to the list? Or should you? Dave Goldman explains in Adding attributes to the Exchange details templates.

Updated: Mailbox Server Role Storage Calculator v14.7

An updated version of the Mailbox Server Role Storage Calculator (let's just call it Storage Calculator or StorageCalc? :) has been released. More details about v14.7 in Ross' post on the team blog: Updates to the Mailbox Server Role Storage Requirements Calculator.

Released: MAPI Client and CDO 1.2.1 for Exchange 2007

The Exchange Server 2007 base package does not include MAPI client libraries and CDO components that can be used by applications. MAPI and CDO are used to programmatically connect to Exchange Stores. These have been released as a web download.

Download ExchangeMapiCdo.MSI from microsoft.com.

While you were out: Scheduling meetings and OOFs

Although it's been an accepted (and expected) practice to setup OOF auto-responses while you are out of office, I haven't been a big fan of OOFs in the past. My reasons:

1. I often forget to turn off OOFs once I'm back in the office, or forget to set these up in the first place— setting up OOFs isn't exactly a priority for many when leaving for a business trip or a vacation.
2. At times I don't want to provide the same information to external senders that I provide to internal ones.
3. I don't want to broadcast to the whole world about being out of office.
4. I hate to respond to spammers (or phishers and identity thieves) and confirm my email address with a nice little OOF response that may also have more personal details about me, including contact information.

Exchange Server 2007 and Outlook 2007/OWA have help for folks like me.

Schedule OOFs: You can beat the last minute OOF blues by scheduling OOF start and stop times using the Out Of Office Assistant in Outlook 2007 [Tools -> Out of Office Assistant] or OWA [Options -> Out of Office Assistant].
Different internal and external OOF responses: You can also setup different OOF messages for internal and external recipients.
Restrict external OOFs: You can restrict OOFs to internal senders or your Contacts only.


Figure 1: The Out of Office Assistant allows you to schedule OOFs, create different OOF messages for internal and external senders, and restrict external OOFs to your Contacts

However, OOF auto-responses are sent out exactly once per sender - the very first time the sender sends you a message.

When planning to be out of office, it's a great idea to setup a Calendar appointment for yourself and mark the status as out of office instead of busy.


Figure 2: When planning to be out of office, create an appointment on your Calendar and set the status to out of office

When another user tries to schedule a meeting with you during the period you're out of office, your Free/Busy information does not show your OOF status. Setting up the OOF appointment in your Calendar allows meeting organizers to instantly identify whether you're just busy or actually out of the office during the period.


Figure 3: Meeting organizers can instantly determine your out of office status

Related posts:
- The hilarious lingo of Exchange folks
- Why is OOF an OOF and not an OOO?
- Legacy client and Out of Office (OOF) interoperability
- OOF integration with Exchange Server 2007 Unified Messaging (UM)

How to forward mail to an external email address

In Exchange Server 2003, mail for a recipient can be forwarded to an alternate recipient by modifying the recipient's Delivery Options in ADUC | recipient -> properties | Exchange General tab.

If you need to forward mail to an external email address, you cannot simply type the address in Delivery Options. A (mail-enabled) Contact needs to be created in AD first, and Delivery Options modified to point to the Contact.

Exchange Server 2007: In Exchange Server 2007, these tasks remain the same. However, instead of using ADUC to accomplish them, you use the EMC or the shell (aka "EMS"). The new term for a Contact is MailContact.

 To create a MailContact using the Exchange Management Console:

1. Expand Recipeint Configuration | Mail Contact
2. In the Action pane, click New Mail Contact
3. To create a new Contact object, leave the default (New Contact) selected | click Next
4. Type First name, Last name
5. Click Edit to add the external email address
6. Click New to complete creation of new MailContact

To create a new MailContact using the Exchange Management Shell:

New-MailContact -Name "Foo User" -ExternalEmailAddress "foo@externaldomain.com

Next, we set the recipient's Delivery Options to deliver to the alternate recipient.

 To forward mail for a recipient to the MailContact using the Exchange Management Console:

1. Expand Recipeint Configuration | Mailbox | select mailbox | properties | Mail Flow Settings tab | Delivery Options
2. Under Forwarding address, select the Forward to checkbox
3. Click Browse to select the MailContact

Figure 1: Modifying Delivery Options to forward email to an alternate recipient

4. Optional: If a copy of the message needs to be delivered to both the external recipient and the original recipient's mailbox, select the Deliver message to both forwarding address and mailbox
5. Click OK to close Delivery Options properties
6. Click OK to close recipient's properties

Using the Exchange Management Shell:

Set-Mailbox "Joe Adams" -ForwardingAddress "foo@externaldomain.com"

To deliver a copy to the mailbox (in addition to the external email address - equivalent of step 4 above):

Set-Mailbox "Joe Adams" -ForwardingAddress "foo@externaldomain.com" -DeliverToMailboxAndForward $true

To get a list of mailboxes with forwarding enabled:

Get-Mailbox | where {$_.ForwardingAddress -ne $null} | ft name,forwardingaddress

Automatic forwarding and Remote Domains

Remote Domains are a bunch of settings, such as message formats, character sets, and OOFs, for messages sent to particular remote domains. The default Remote Domain setting applies to address space * - that is, all remote domains for which an explicit Remote Domain setting does not exist.


Figure 2: The Allow automatic forward setting for remote domains impacts client-side automatic forwarding, and is disabled by default.

However, this setting only applies to client-side forwarding. For instance, if a user creates a rule in Microsoft Outlook to automatically forward mail to an external email address, the default setting does not allow it. To enable automatic client-side forwarding of mail to external addresses, select the Allow automatic forward checkbox in a remote domain's properties | Format of original message sent as attachment to journal report tab (Yes, the tab is mislabeled. It is the "Message Formats" tab... :).

Server-side forwarding setup by an administrator is not impacted by this setting.

DST 2007: December 2007 cumulative time zone update for Microsoft Windows operating systems

The last time we took a look at the timezone changes was when the August 2007 cumulative time zone update was released (Read previous post: "DST 2007: August 2007 Cumulative Timezone Update for Windows operating systems"). The August 2007 update included new timezone data for Caucasus Standard Time, Armenian Standard Time, New Zealand Standard Time, GTB Standard Time, and Jordan Standard Time. Some updates were minor - such as changing the display name of a time zone.

In December, Microsoft released another time zone update - KB 942763: December 2007 cumulative time zone update for Microsoft Windows operating systems. Changes:
- Arabic Standard Time: Adjusts DST start and end dates for Baghdad time zone
- Australia: Central Australia, Eastern Australia and Tasmania Standard Time - these start and end on the same day.
- Egypt Standard Time: Adjusts DST start and end dates for Cairo time zone
- Israel Standard Time: Adjusts DST start and end dates for Jerusalem
- South America: E. South America Standard Time, Central Brazilian Standard Time - Adjusts DST start dates and end dates for the Brasilia time zone and for the Manaus time zone
- Venezuela Standard Time: Adds a new time zone for the Caracas time zone

Updates in the above list reflect the latest time zone changes made around the world after the Aug. 2007 Cumulative Timezone Update was released. If you've already applied the previous updates affecting your locale, and rebased appointments, the latest update will not change anything for you.

Also note, this is a cumulative update. It includes all previous timezone updates.

Related posts:
- DST 2007 Rollup Post

HOW TO: List mailboxes with Full Mailbox Access permission assigned

In "HOW TO: Grant Full Mailbox Access permission", we saw how to assign and view mailbox permissions, including Full Mailbox Access. Here's how you can get a list of mailboxes with explicitly-assigned (i.e. not inherited) Full Mailbox Access permissions.

Instead of running this against all mailboxes in the Organization, it makes sense to filter it against a sub-set of mailboxes.

Filtering mailboxes returned by Get-Mailbox

Mailboxes returned by the Get-Mailbox command can be filtered using -Server, -Database, -RecipientTypeDetails, and -OrganizationalUnit parameters. Note, the -Filter parameter can also be used and allows granular filtering of mailboxes that are returned, based on a number of filterable properties.

In this example, we use the -Server parameter to filter mailboxes on a particular server, and pipe it to the Get-MailboxPermission command:

Get-Mailbox -Server "e12postcard" | Get-MailboxPermission

This produces a long list of permissions - inherited and assigned explicitly to the mailbox(es).

Let's filter the above to reveal only the explicitly assigned permissions:

Get-Mailbox -Server "e12postcard" | Get-MailboxPermission | where { $_.IsInherited -eq $false }

The output shows all explicitly-assigned permissions, including the permissions assigned to the mailbox owner (NT AUTHORITY\SELF). Not quite what we want! Let's filter that out:

Get-Mailbox -Server "e12postcard" | Get-MailboxPermission | where { ($_.IsInherited -eq $false) -and -not ($_.User -like "NT AUTHORITY\SELF") }

Now we have a list of all mailboxes with explicitly assigned permissions.

We can filter this further to list only the ones that have Full Mailbox Access permission assigned:

Get-Mailbox -Server "e12postcard" | Get-MailboxPermission | where { ($_.AccessRights -eq "FullAccess") -and ($_.IsInherited -eq $false) -and -not ($_.User -like "NT AUTHORITY\SELF") }

Similarly, you can filter users that have other mailbox permissions assigned, such as SendAs, DeleteItem, ReadPermission, ChangePermission, ChangeOwner, or ExternalAccount.

Related Posts:
- HOW TO: Grant Full Mailbox Access permission
- HOW TO: Assign SendAs right using Exchange shell

Recipient Policies: Can separate policies for Email Addresses and Mailbox Manager Settings be applied?

Exchange Server 2003/2000's Recipient Policies can have settings to generate email addresses for recipients, and Mailbox Manager settings to manage mailbox content. (The Exchange Server 2007 equivalents are 1. Accepted Domains + Email Address Policies to generate email addresses, and 2. Managed Folder Mailbox Policies (with default or custom Managed Folders + Managed Content Settings) to manage mailbox content).

When creating these policies, one can either use a single policy with both types of settings, or use separate Recipient Policies for both purposes - one to generate email addresses for recipients, and other(s) with Mailbox Manager settings to manage mailbox content. The latter approach (separate policies) is more common.

Modifying an existing Recipient Policy to add Mailbox Manager settings

 An existing Recipient Policy can be modified to add/remove Mailbox Manager or Email Address settings by right-clicking the policy and selecting Change property pages.



 From the Property Pages dialog box, select the appropriate settings to be included in the Recipient Policy.

Can multiple Recipient Policies be applied to a recipient?
Yes, you can use separate policies to generate email addresses and manage mailbox content.

Scenario1: Single policy with Email Addresses and Mailbox Manager settings applied. Recipient Joe Adams is not managed by policies (in ADUC -> Joe's account properties | E-mail Addresses tab, Automatically update e-mail addresses based on recipient policy is unchecked). None of the settings - Email Addresses or Mailbox Manager, get applied to that user.

Scenario 2: Two separate Recipient Policies are applied - one with Email Addresses and the other with Mailbox Manager settings. Recipient Joe Adams is not managed by Recipient Policies. The policy with Email Address settings does not get applied to Joe. The second policy with Mailbox Manager settings does get applied.

Given the above scenarios, if you want Mailbox Manager settings to be applied to all mailbox-enabled users, including those that are not managed by Recipient Policies, it makes sense to use two separate policies for Email Addresses and Mailbox Manager settings respectively.

Exchange Server 2007 avoids these scenarios completely. The functionality of generating email addresses - Accepted Domains + Email Address Policies, is separate from the functionality of managing mailbox content, which is available through Managed Folder Mailbox Policies.

Related Posts:
1. Applying Mailbox Manager policies to a sub-folder
2. Exchange Server 2007: Why aren't Managed Content Settngs applied?
3. Applying Managed Folder Policy to more than one user
4. Managed Folders: How to apply different Managed Content Settings to Default Folders
5. Restricting Messaging Records Management to a particular message type

Disabled mailboxes: Can they really receive email?

Some truths you live with for a lifetime, like Outlook users cannot send email using an alternate email address (with Outlook in MAPI mode - read previous post: "HOW TO: Send as alternate email address"). Others change as Microsoft Exchange evolves, either through new versions of Exchange server, or service packs and hotfixes.

Disabled mailboxes cannot receive email. Or rather, could not receive email. This has been true all this while, and hasn't changed in Exchange 2000, Exchange Server 2003, including SP1 and SP2.

The reason is described in Microsoft KBA 319047 - "You receive a non-delivery report when you send a message to a disabled account".

In addition to not being able to receive email, administrators face a few other operational issues when managing disabled mailboxes:

- A common scenario: An employee leaves. You disable the account, as part of a standard operating procedure followed in most organizations. You assign his/her manager/co-worker/replacement permissions to access the mailbox. If the mailbox is disabled, they can't access it!
- A disabled mailbox needs to be be enabled first before it can be moved (KBA 278966: "You cannot move or log on to an Exchange resource mailbox")
- The Application Event Log is flooded with annoying Event ID 9548s, informing you that the disabled account does not have a msExchMasterAccountSID attribute populated - something most Exchange administrators have probably gnashed their teeth at a few times a day.

Workarounds exist to populate the msExchMasterAccountSID attribute with the well-known SELF SID (KBA 322890 "How to associate an external account with an existing Exchange 2000 mailbox"), but not something you want to do on a regular interval after every account, or a bunch of them, are disabled.

The hotfix mentioned in KBA 903158: "A hotfix is available to modify the way that Exchange Server 2003 handles a disabled Active Directory user account that is associated with an Exchange Server 2003 mailbox" changes that behavior. It makes the Store act as if a disabled account with a null/empty msExchMasterAccountSID attribute actually has the SELF SID.

All the above actions (and more) complete successfully for disabled accounts. Yes, disabled accounts receive email if you have this hotfix applied - or any subsequent hotfix that updates Store.exe to version 6.5.7234.3 or later.

But what if I don't want disabled accounts to receive email? To prevent disabled accounts from receiving any email, setup Delivery Restrictions (in ADUC | user -> properties | Exchange General tab) to:


Figure 1: Setting Delivery Restrictions on a recipient to prevent receiving mail

1. Receive mail from authenticated users only: With Recipient Filtering enabled, this will drop internet mail at the gateway or the first Exchange server that receives inbound internet mail
2.Receive mail only from: a particular Distribution Group (use a Distribution Group with no members).

Bulk mailbox creation revisited: Adding Active Directory attributes

The instructions in Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell allow you to quickly create mailboxes in bulk using the New-Mailbox command.

Continuing from where we left off in that post, another scenario is being able to add Active Directory attributes to the new user object created by New-Mailbox. Note, the New-Mailbox command can populate only a limited set of AD attributes for an object - those related to Exchange. These are listed in the documentation for New-Mailbox.

To add AD attributes, the logical choice would be to use the New-User command to create the user, and mailbox-enable it by using Enable-Mailbox. This would work great, except for the fact that the New-User command doesn't exist! The key thing to remember is - Exchange provides only the commands necessary to create Exchange recipients. So you have commands like New-Mailbox, New-MailUser, New-MailContact, New-PublicFolder/New-MailPublicFolder, and New-DistributionGroup. However, there are no AD-equivalents like New-User, New-Contact (to create a Contact that's not mail-enabled), New-SecurityGroup or New-Group.

PowerShell and Active Directory

Active Directory isn't really PowerShell-enabled, as other components of Windows - like the file system, registry, etc., and Exchange Server 2007 are. There are no AD-related commands (Cmdlet? Shell folks, was it really necessary to introduce another word to the jargon - one that uses the entire word "command"? Perhaps something shorter would've been nicer if you wanted to have a unique word... :-) You can use the Directory Services provider, but that essentially leaves you in VBScript mode, with some PowerShell goodness! A little easier, but not natively shell, as you are used to with Exchange commands.

Quest adds these much-needed commands through its free add-on Management Shell for AD. Download it here. Quest has named them so they're differentiated from future commands that will be available natively in PowerShell. For the time being, the quirkiness of typing commands with a Q - as in New-QADUser instead of New-ADUser or New-User - is something we will have to live with, until AD is PowerShell-enabled.

Kudos to the folks at Quest for making these available for free.

Also take a look at PowerShell Community Extensions - it has an Active Directory provider that lets you navigate AD like a file system.

If you already have a user created, you can use the Set-User command to populate its AD-related attributes.

To accomplish what we want to do here (thanks to Evan Dodds for the input), we use the New-Mailbox command, and pipe the output to Set-User to populate AD attributes. In the following example, we add the Phone attribute, besides using the Alias, Name and UserPrincipalName attributes used to create the mailbox.

Add the Phone column in our CSV/spreadsheet, so it looks like the following:

Alias,Name,UPN,Phone
User_One,User One,userone@yourUPNsuffix.com,650.555.1121
User_Two,User Two,usertwo@yourUPNsuffix.com,650.656,2221
User_Three,User Three,userthree@yourUPNsuffix.com,650.797.3321

Now we modify the script/commands from the previous post:

$password=Read-Host "Enter Password" -AsSecureString

Import-CSV "c:\CreateRecipients.csv" foreach {new-mailbox -alias $_.alias -name $_.name -UserPrincipalName $_.UPN -database "Mailbox Database" -org "Users" -Password $password | set-user -phone $_.phone}

The above command(s) create the user account as part of New-Mailbox. When we pipe that to Set-User, we still have a reference to that object, and can use Set-User to populate the AD attribute Phone. (Changes made to the command from previous post highlighted.)

Related Posts:
- Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell
- Exchange Server 2007: Bulk mailbox-enabling users using Exchange Shell

Restricting Messaging Records Management to a particular message type

One of the frequently asked questions related to Exchange Server 2007's Messaging Records Management is: how do I purge only specific type of items from a particular default or custom Managed Folder, or the entire mailbox? For instance, in many scenarios its acceptable to purge messages from a particular folder or the entire mailbox after a certain number of days, but you don't want to touch users' Contacts, Notes, Calendar items, etc.

I've hinted at how to accomplish this in a previous post (read "Managed Folders: How to apply different Managed Content Settings to Default Folders") as a sidebar item. This post directly addresses such questions and scenarios.

Let's say you want to purge items that are older than a certain number of days from the entire mailbox, without touching particular type of items.

To accomplish this:

Create a new Managed Default Folder called "EntireMailbox-Purge365Days" (or pick a name that describes this better... ). In the Default folder type drop-down, select All other folders in the mailbox

All other folders in the mailbox, and default folders

If the Entire Mailbox Managed Folder, or any other instance of a Managed Folder created using All other folders in the mailbox is used in a Managed Folder Mailbox Policy, it applies to the entire mailbox (including all Default Folders and any Custom Folders created by Exchange or by the mailbox user), except any default or custom Managed Folders included in the same Managed Folder Mailbox Policy.

Scenario 1: A policy that includes a Default Folder of type All other folders in the mailbox (including the pre-canned Entire Mailbox Default Folder) applied to a user, no other Default Folders are included in that policy. The policy applies to the entire mailbox, including all Default and Custom folders.


Figure 2: A Managed Folder Mailbox Policy applied to Entire Mailbox also impacts any custom folders created by the mailbox user that are not explicitly included in the policy.

However, if you have restricted the message type to "E-mail", the policy will only take action on email items in those folders.

Scenario 2: A policy that includes a Default Folder of type All other folders in the mailbox (including the pre-canned Entire Mailbox Default Folder) is applied to a user, policy also includes other Default Folders such as Deleted Items, Inbox, etc.
The result: The Managed Content Settings for the "entire mailbox" Default Folder applies to all Default and Custom Folders, but not to the ones you explicitly linked to the same policy.

Create new Managed Content Settings for the new folder. Under message type, select "E-mail".



You cannot select multiple message types - the only choices are selecting All Mailbox Content, or a specific message type. If you want to apply settings for different message types, create additional Managed Content Settings for the Default Folder and select other message type like Faxes, RSS Items, Missed Calls, etc. - one message type per Managed Content Settings.

Add this new Managed Default Folder to an existing Managed Folder Mailbox Policy, or create a new policy.

Apply the policy to appropriate users if not already applied. (Read previous post "Applying Managed Folder Policy to more than one user")

Ensure the Managed Folder Assistant is scheduled to run. (Read previous post "Exchange Server 2007: Why aren't Managed Content Settngs applied?")

 Related posts:
- Managed Folders: How to apply different Managed Content Settings to Default Folders
- Applying Managed Folder Policy to more than one user
- Exchange Server 2007: Why aren't Managed Content Settngs applied?

Managed Folders: How to apply different Managed Content Settings to Default Folders

Exchange Server 2007's Managed Folders come in two flavors: 1) Managed Default Folders 2) Managed Custom Folders. Default folders are the ones created by default in user mailboxes, like Inbox, Sent Items, Deleted Items, etc. Custom Folders are the result of a much-requested feature by Exchange folks over the years: Can I create a folder called "Project Blah" in all mailboxes?

The Managed Default Folders tab (under Organization Configuration | Mailbox) displays a single entry for a default folder of a particular type, e.g. Deleted Items.



You create Managed Content Settings for a default folder like Deleted Items to permanently delete items in the folder after 30 days.



Next, you want to create another setting for your executives with a higher retention period of 300 days for the Deleted Items folder. If you try to create another Managed Content Settings for the same Default Managed Folder, you get the following error.

Managed Folders and Managed Content Settings

If Exchange only allows you to associate one Managed Content Settings with one Managed Folder, I've often wondered, why not allow specifying content retention settings in the Properties of that folder? Why have a Managed Folder AND a Managed Content Settings for that folder as separate objects?

This is to allow different Managed Content Settings for different types of items in a Managed Folder. For example, for the Deleted Items folder, you can create a Managed Content Setting to permanently delete messages after 30 days, but retain other types of items like faxes or Contacts for a little longer, let's say 60 days.

Note: You cannot change the Message Type selected in Managed Content Settings after it is created. To select a different Message Type, delete the Managed Content Settings object and recreate it with the correct/intended Message Type selected.

To create a new Managed Content Settings for a default folder, Deleted Items in this case, we need to create another default folder.

1. In the Exchange console, select Organization Configuration | Mailbox | Managed Default Folders.
2. From the Action pane on the right, click on the New Managed Default Folder link.
3. In the New Managed Default Folder page, enter a name for the new default folder instance. Note, unlike Managed Custom Folders, the default folders like Deleted Items, Inbox, Sent Items, Drafts, etc. already exist in a mailbox. What we're doing here is simply creating an instance/representation of a default folder, to be able to associate Managed Content Settings with it.



4. From the Default Folder Type drop-down, select the correct default folder type - for this example we select Deleted Items.
5. [Optional] Type a comment in the text box titled Display the following comment when the folder is viewed in Outlook.
6. Click New | click Finish on the Completion page.

Now you have another instance of the Deleted Items folder. You can create Managed Content Settings for it, and add it to a Managed Folder Mailbox Policy.



For more information on applying Managed Folder Mailbox Policy, read previous post "Applying Managed Folder Policy to more than one user".

 Related posts:
- Applying Managed Folder Policy to more than one user
- Exchange Server 2007: Why aren't Managed Content Settngs applied?
- Restricting Messaging Records Management to a particular message type

Exchange Server 2007: Setting Message Size Limits

In a previous post, we looked at how the maximum recipients per message settings are treated differently by Exchange Server 2007 and Exchange Server 2003/2000 when sending to Distribution Groups (read previous post "Distribution Groups and maximum recipients per message").

Another commonly asked question is about message size limits and the inability to send messages that are apparently within the maximum sizes configured. Let's take a look at the message size settings in different places.

Organizational limits: These apply to all Exchange servers in the Organization. You can set these using the Set-TransportConfig command from the Exchange shell:

Set-TransportConfig -MaxReceiveSize 40MB -MaxSendSize 40MB

In SP1, you can also set it using the Exchange console by going to Organization Configuration | Hub Transport | Global Settings tab | Transport Settings | properties.

Receive Connector limit: Unlike Exchange Server 2003/2007's SMTP virtual servers, ReceiveConnectors are only used to receive messages. The maximum message size limit can be different on different Receive Connectors on a Hub Transport or Edge Transport server. To modify the maximum message size on a Receive Connector using the Exchange console, select Server Configuration | Hub Transport | select a HT server | Receive Connectors -> select a connector | Properties | General tab.



To set ReceiveConnector limit using the shell:

Set-ReceiveConnector "CONNECTOR NAME" -MaxMessageSize 40Mb

Send Connector limit: Send Connectors are used for sending outbound messages to the internet or particular address spaces (domains). Edge Transport servers also have a Send Connector to send inbound messages to Hub Transport servers in an AD Site. To modify the maximum message size on Send Connectors, select Organization Configuration | Hub Transport | Send Connectors -> select connector | Properties | General tab.



To set SendConnector limit using the shell:

Set-SendConnector "CONNECTOR NAME" -MaxMessageSize 40Mb

Mailbox limit: Individual recipients like mailboxes can have their own limits to bypass the Organizational limits. To set these using the Exhange console: Recipients | Mailbox -> select mailbox | properties | Mail Flow Settings tab | Message Size Restrictions.



Note: Setting these higher on the recipient bypasses the maximum sizes on Organization configuration for internal messages, but not for messages sent to or received from an external sender or recipient.

Sender and Recipient Size Limits: Consider the sender's MaxSendSize and the internal recipient's MaxReceiveSize when troubleshooting message size issues.

If the sender's size limits allow sending a large message, but the recipient's limits do not allow receiving a message of that size, you get a NDR with the following text (note the enhanced status code informing you exactly why the message was rejected):
#550 5.2.3 RESOLVER.RST.RecipSizeLimit; message too large for this recipient ##

If the recipient is allowed to receive a large message, but the sender isn't allowed to send a message of that size, you get the following NDR:
#550 5.2.3 RESOLVER.RST.SendSizeLimit; message too large for this sender ##

To set these using the Exchange shell:

Set-Mailbox "Joe Adams" -MaxSendSize 20Mb -MaxReceiveSize 20Mb

Distribution Groups and Contacts (MailContacts) only have maximum receive size in the Exchange console, but both MaxReceiveSize and MaxSendSize properties can be set for them using the Exchange shell.

Global Settings: Besides the above, another set of message size limits can impact Exchange Server 2007 recipients, but are often overlooked when troubleshooting. These are the ones in Exchange Server 2003 Global Settings | Message Delivery -> Properties.




- If you have these configured to a specific value before you upgrade the Organization to Exchange Server 2007, these are left untouched.
- If you have these set to "No Limit" before the Exchange Server 2007 upgrade, these are reset to the Exchange Server 2007 defaults.
- In case Exchange Server 2007's Organization settings (the ones you can set using Set-TransportConfig) conflict with these legacy Global Settings, the lower of the two sizes are used.

The problem is, these are neither visible in the EMC, nor using any of the Exchange shell commands.

If you still have an Exchange Server 2003 server in the Org, you can use ESM to modify these. Alternatively, you can use ADSIEdit to browse to the Configuration container | Services | Microsoft Exchange | YourOrgName | Global Settings | Message Delivery -> Properties, and modify the following attributes as required:
1. delivContentLength -> corresponds to MaxReceiveSize parameter in Set-TransportConfig command.
2. SubmissionContentLength -> corresponds to MaxSendSize parameter in Set-TransportConfig command.
Note: The maximum value for both of the above is 2097151 KB, slightly under 2 Gb.
3. msExchRecipLimit -> corresponds to MaxRecipientEnvelopeLimit parameter in Set-TransportConfig command.

Set these to be the same as the equivalent Organization settings in Exchange Server 2007.

Exchange Server 2007 SP1 makes managing Global Settings easier.

If Global Settings have numeric values (i.e. aren't set to "No Limit"), using Set-TransportConfig to change maxReceiveSize, maxSendSize or maxRecipientEnvelopeLimit also changes the corresponding Global Settings.

Active Directory SiteLink limit: In Exchange Server 2007 SP1, you can also set maximum message size limit on AD Site Links. Exchange Server 2007 uses the AD Site topology to determine the least cost paths. If the message size to be delivered to a remote AD Site exceeds the limit on the AD Site Link, message delivery will fail. By default, the MaxMessageSize on AD Site Links is set to unlimited. This can be changed using the following command:

Set-ADSiteLink "SITE LINK NAME" -MaxMessageSize 20Mb

Routing Group Connector Limit: Routing Group Connectors are used in co-existence scenarios to transfer messages between Exchange Server 2003/2000 Routing Groups and the Exchange Server 2007 Routing Group (yes, there is one under the hood.. ). Messages exchanged between these Routing Groups should be below the message size limits of their respective RGCs. The default is set to unlimited. To set the MaxMessageSize on a Routing Group Connector:

Set-RoutingGroupConnector "CONNECTOR NAME" -MaxMessageSize 20Mb

Content conversion and message size limits

One source of confusion in previous versions of Exchange Server, as far as the message size limits are concerned, is that created by the content conversion process. Content conversion happens when Exchange converts an internet/MIME message into MAPI/Exchange format, and vice versa. Content conversion generally increases the message size - roughly by 30%. If you set a maximum message size of 10Mb., and wonder why a 9 Mb. attachment didn't make it through, consider the content conversion overhead, as also message headers (which are computed along with the DATA portion of the message to calculate the message size), and any actions taken by Transport Rules.

How does Exchange Server 2007 handle such messages? When a message enters the Exchange Server 2007 Org, it gets stamped with an X-MS-Exchange-Organization-OriginalSize header, which indicates the original size of the message before conversion. When considering message size limits, if the message has since ballooned to a larger size due to content conversion, added headers, etc. - the lower of the original message size and the current (converted) message size is considered, eliminating some of the confusion seen with message sizes in previous versions.

Using the Exchange shell to track failed message delivery

You can use the Exchange shell to track messages that could not be delivered because of message size issues. The RecipientStatus field in Message Tracking logs is used to store the SMTP response and enhanced status codes. The Message Tracking EventID we're looking for is FAIL. (Read previous post on message tracking: "Exchange Server 2007: Message Tracking from the command line")

To track messages that failed because of recipient's MaxReceiveSize:

Get-MessageTrackingLog -EventID FAIL | where {$_.RecipientStatus -like "*RecipSizeLimit*"}

To track messages that failed because of the sender's MaxSendSize:

Get-MessageTrackingLog -EventID FAIL | where {$_.RecipientStatus -like "*SendSizeLimit*"}

Distribution Groups and maximum recipients per message

In Exchange Server 2003, you can restrict maximum number of recipients per message in the following places:
1. Global Settngs (Message Delivery -> properties | Defaults)


Figure 1: Max recipients in Global Settings | Message Delivery -> properties | Defaults tab

2. SMTP Virtual Server -> properties | Messages
3. ADUC -> recipient -> properties | Exchange General tab | Delivery Options | Recipient Limits.

How does this work when sending to a Distribution Group?
In Exchange Server 2003, the max recipients restriction is enforced after the Categorizer has expanded Distribution Groups - a Distribution Group with 100 members is counted as 100 recipients. Distribution Group expansion stops when the maximum number of recipients is reached, resulting in a partial delivery.

This behavior has been changed in Exchange Server 2007 - the maximum recipients restriction is enforced before a Distribution Group is expanded. A Distribution Group is considered a single recipient, regardless of the number of members it has.

An interesting effect of the Exchange Server 2003 behavior in this regard: If a Distribution Group member has Delivery Restrictions set to receive from certain senders only, or to not receive messages sent by certain senders - the recipient is not counted in the total number of recipients post Distribution Group-expansion.

Consider this scenario:
- Maximum Recipients (in Global Settings): 100.
- Distribution Group members: 105
- No NDRs: Distribution Group is configured not to send Delivery Reports
- 5 members have De