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 Delivery Restrictions set to receive mail from certain senders only.
- Post-Categorization, the expanded number of recipients is 100, within the limits on Global Settings.
- No NDRs for recipient with Delivery Restrictions: If the Distribution Group is set to not send delivery reports (or to send them only to the group owner), you never find out about the recipient who did not get the message, because no NDRs are received.
- Turning on NDRs on the Distribution Group: If NDRs are turned on for the Distribution Group, you get the following NDRs for recipients with Delivery Restrictions

The following recipient(s) could not be reached:

George Foresman on 8/24/2007 2:52 PM
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<letter.exchangelabs.net>

- If Delivery Restrictions are removed from the recipients who had these configured, they are now counted in total number of recipients. Now you get a NDR with the following text:

The following recipient(s) could not be reached:

DL_Finance on 8/24/2007 2:49 PM
The e-mail system limits the number of recipients that can be addressed in a single message. Send the message multiple times to fewer recipients.
<letter.exchangelabs.net>

Lessons learnt:

• In Exchange Server 2003 the maximum number of recipients in Global Settings should be set higher than the maximum number of recipients in the largest Distribution Group.


• If you want to prevent certain senders from sending to large Distribution Groups like "All Company", you can configure max number of recipients per message for them individually in ADUC -> recipient properties.


• In Exchange Server 2007, Distribution Groups are considered a single recipient when enforcing max recipient limits, avoiding partial delivery.


• In either case, it's a good idea to limit who can send to large Distribution Groups by implementing Delivery Restrictions on such groups.


• Turning off Delivery Reports for Distribution Groups leaves senders and group owners completely unaware of incidents like members not getting messages due to a low max recipients setting or if some Distribution Group members have Delivery Restrictions. Use your judgment when turning off NDRs - it makes sense to at least send NDRs to group owners for all but the most trafficked Distribution Groups.
  

New Exchange Server 2007 mailbox stamped as legacy mailbox

If you use the Exchange Server 2003/2000 extensions to Active Directory Users & Computers (ADUC) console to create mailboxes residing on Exchange Server 2007 servers, these mailboxes get stamped as legacy mailboxes.

Exchange Server 2007 mailboxes should be created using the Exchange (2007) console or shell.

To remove the legacy tag from mailboxes created using ADUC, use the following command:

Set-Mailbox "John Doe" -ApplyMandatoryProperties

This is documented in KB 931747: A mailbox that is located on an Exchange Server 2007 server may be identified as a legacy mailbox in Exchange Server 2007.

To get a list of legacy mailboxes:

Get-Mailbox | where {$_.RecipientTypeDetails -eq "legacymailbox"}

Note, not all legacy mailboxes reside on Exchange Server 2007 servers, so it's not a good idea to use the ApplyMandatoryProperties command to all of these. Mailboxes residing on Exchange Server 2003/2000 servers are also legacy mailboxes, and you may see some mailboxes moved from Exchange Server 2003/2000 servers carry this tag as well.

HOW TO: Forward mail to a Public Folder

When trying to forward inbound mail for a recipient to a Public Folder using the Exchange console (Recipient ->Properties | Mail Flow Settings | Delivery Options | Forward to: ), the Recipient Picker GUI does not display mail-enabled Public Folders.

This can be done from the shell using the following command:

Set-Mailbox "Foo" -ForwardingAddress "TestPF@mydomain.com"

The above command forwards mail to the Public Folder, without delivering a copy to the original recipient. To have a copy delivered to the recipient and forward it to a Public Folder, set the DeliverToMailboxAndForward property to true:

Set-Mailbox "Foo" -ForwardingAddress "TestPF@mydomain.com" -DeliverToMailboxAndForward $true

Once this is done, Delivery Options in the console does display mail being forwarded to the Public Folder.



Note, you can post to a Public Folder from Microsoft Outlook, but it should be mail-enabled to get an email address and receive (internet/smtp) email. To mail-enable a Public Folder, use the following command:

Enable-MailPublicFolder "\TestPF"

To find out how to add/remove email addresses and change the default email address for a public folder, read previous post "HOW TO: Add Email Addresses To Public Folders".

Move mailbox issue: disconnected mailbox remains on source mailbox Store

This came up earlier today in a newsgroup post. You move a mailbox from one mailbox Store to a mailbox Store on another server - either between two Exchange Server 2003/2000 servers, or between an Exchange Server 2003/2000 and an Exchange Server 2007 server. The mailbox moves successfully, the user can access it on the server it is moved to.

However, the mailbox is not purged from the source mailbox Store. It has a small size, and Exchange System Manager reports the number of items as 0. The mailbox is disconnected - it has a red x icon super-imposed, but ESM does not allow you to purge it or connect it to another user.

Running the mailbox cleanup agent on the Store does not change anything.

To be able to purge the mailbox from the target Store, try to move the mailbox back to that (original) Store. Move Mailbox will notify you that the mailbox already exists on the destination Store, and prompt you to purge it. Choose the option to purge.


The hotfix mentioned in KBA 940012 resolves this issue.

HOW TO: Prevent a user from sending and receiving internet mail

An often heard requirement is that of preventing one or a few users from sending/receiving internet mail.

Outbound internet mail: On Exchange Server 2003/2000, this was accomplished using Delivery Restrictions on SMTP Connector(s) for address space *.

Exchange Server 2007 doesn't have a similar way of implementing Delivery Restrictions, but it provides the convenience of inspecting messages in the transport pipeline and taking actions on those, using Transport Rules. To create a Transport Rule to prevent users from receiving internet mail:

Create a Distribution Group - let's call it "DG-NoInternetMail". Add the recipients you want to prevent from sending internet email as members of the group.

Create a Transport Rule [Flash demo]
1) Fire up Exchange console | Organization Configuration | Hub Transport | Transport Rules tab | click New Transport Rule
2) Enter a name for the rule - e.g. Rule-NoInternetMail
3) On the Conditions page, select "From a member of a distribution list"
4) In the rule description, click the link for distribution list (underlined)
5) Click Add | Select the distribution list "DG-NoInternetMail"
6) Under Conditions, select a second condition "Sent to users inside or outside the organization"
7) In the rule description, click Inside (underlined) | change scope to Outside
8) Click Next
9) On the Actions page, select "send bounce message to sender with enhanced status code"
10) If you want to modify the text of the bounced message (optional): In the description, click "Delivery not authorized, message refused" | enter new message text
11) Click Next | verify the rule conditions and action in the summary
12) Click New | click Finish

Inbound internet mail: In Exchange Server 2003/2000, you can prevent a recipient from receiving internet mail by requiring authentication to be able to send to the recipient. Internet senders are not authenticated. There are other ways to prevent inbound mail for certain users - like using Recipient Filtering, or generating an invalid email address from a non-existent domain, e.g. foo@nonexistentdomain.corp.

Exchange Server 2007 recipients can be set up to require sender authentication to receive email.

Using the Exchange console:
- Recipient Configuration -> select recipient -> recipient properties | Mail Flow Settings tab | Message Delivery Restrictions | Properties
- check "require that senders are authenticated"

Using the shell:

Set-Mailbox "Foo User" -RequireSenderAuthenticationEnabled $true

Additionally, either of the other 2 alternatives mentioned above for Exchange Server 2003/2000 can be used to prevent users from receiving internet email.

Setting delivery restriction based on group membership: Rather than setting up each recipient to receive inbound mail from authenticated senders only, you can get membership of the above distribution group and pipe it into the Set-Mailbox command:

Get-DistributionGroup "DG-NoInternetMail" | Set-Mailbox -RequireSenderAuthenticationEnabled $true

Use OWA/Outlook to test sending internet mail from a user who is a member of the distribution group.

HOW TO: Grant Full Mailbox Access permission

Follow-up to previous post titled "HOW TO: Assign SendAs right using Exchange shell" - the ability to assign SendAs and ReceiveAs permissions is preserved in AD Users & Computers, but the ability to grant Full Mailbox Access permission isn't available. Full Mailbox Access is a mailbox permission (without getting into a debate about what's a permission and what's a right, the term is used interchangeably here). In Exchange Server 2003/2000, mailbox permissions can be controlled from the Exchange Advanced tab | Mailbox Rights, as seen in the following screenshot.


Figure 1: In Exchange Server 2003/2000, mailbox permissions can be managed from ADUC

Since Exchange Server 2007 does not use ADUC for recipient management, this can't be done using ADUC.

The shell is your friend when it comes to assigning Full Mailbox Access and other mailbox permissions. You can use the Add-MailboxPermission command from the shell to assign it.

In the following example, we assign Full Mailbox Access permission on Joe Adams' mailbox to another user (janea):

Add-MailboxPermission "Joe Adams" -AccessRights FullAccess -user "janea"

Besides FullAccess, the following mailbox permissions can be granted using Add-MailboxPermission: 1) SendAs 2) ExternalAccount 3) DeleteItem 4) ReadPermission 5) ChangePermission 6) ChangeOwner

Viewing permissions using Get-MailboxPermission

To view permissions on a mailbox, use the Get-MailboxPermission command:

Get-MailboxPermission "Joe Adams"

To view explicitly assigned permissions (i.e. permissions that are not inherited):

Get-MailboxPermission "Joe Adams" | where {$_.IsInherited -eq $false}

To view all security principals with Full Access permission on a mailbox:

Get-MailboxPermission "Joe Adams" | where {$_.AccessRights -like "*FullAccess*"}

Managing Full Mailbox Access using the EMC in Exchange Server 2007 SP1

Exchange Server 2007 SP1 adds management of Full Mailbox Access permission to the EMC.
1. From Recipient Configuration | Mailbox | select mailbox.
2. In the Action pane (or by right-clicking the mailbox), click Manage Full Mailbox Access...


Figure 2: Exchange Server 2007 SP1 allows management of Full Mailbox Access permission from the EMC

HOW TO: Create Address Lists for Equipment Mailboxes

Exchange Server 2007 lets you create room and equipment mailboxes. Having these designated as resource mailboxes - either room or equipment - has its advantages as these get setup for resource booking without having to go through the cumbersome process of logging into such mailboxes and configuring calendar settings for each so they can be booked as resources.

Whereas an "All Rooms" Address List is created by default, equipment mailboxes are not listed in it, and there's no separate Address List for equipment. (Thanks to the person who asked this question in this morning's Exchange Q&A chat on TechNet!)

Additional Address Lists can be created easily for such equipment mailboxes.

To create an "All Equipment" Address List, use the following command in Exchange shell:

New-AddressList -name "All Equipment" -RecipientFilter {RecipientType -eq "UserMailbox" -and RecipientTypeDetails -eq "EquipmentMailbox"}

To view the mailboxes that get picked up by the above filter, use the following commands:

$AllEquipment = Get-AddressList "All Equipment"
Get-Recipient -filter $AllEquipment.RecipientFilter

You can also create more granular Address Lists, for example one for all projectors.

For this example, we follow a naming convention for naming equipment mailboxes for projectors, so it has a particular string like PROJ. In this case, our mailboxes follow a naming convention that results in projector mailboxes names like EQP-PROJ-InFocus1. You are free to make your own naming convention choices, this is just an example. Now we can use the following command to create an "All Projectors" Address List:

New-AddressList "All Projectors" -RecipientFilter {RecipientType -eq "UserMailbox" -and "RecipientTypeDetails -eq "EquipmentMailbox" -and name -like "*PROJ*"}

Now we have separate Address Lists for equipment resources, and also one for all projectors. This allows users to easily locate these resources using Address Lists when scheduling meetings.

Displaying Client IP Address in Exchange System Manager

In Exchange Server 2003, Exchange System Manager's Logons view for a Mailbox Store (expand Storage Group | Mailbox Store | Logons) displays client logon-related details.

The default view displays 1. User name 2. Windows 2000 Account 3. Logon Time 4. Last Access Time 5. Client Version. It does not display the client IP address from which users are logged on.

To display the IP address, add the Client IP Address column:

1. Expand the mailbox store | right-click Logons | View | Add/Remove Columns



2. Add Client IP Address



Besides the Client IP Address and other defaults mentioned above, the following logon-related fields are available:
1. Adapter Speed
2. Client Mode (Cached or not)
3. Client Name
4. Code Page
5. Folder Ops
6. Full Mailbox Directory Name
7. Full User Directory Name
8. Host Address
9. Latency
10. Locale ID
11. MAC Address
12. Messaging Ops
13. Open Attachments
14. Open Folders
15. Open Messages
16. Other Ops
17. Progress Ops
18. RPC Calls Succeeded
19. Stream Ops
20. Table Ops
21. Total Ops
22. Transfer Ops

For the scripting geeks amongst us, these properties are exposed by the Exchange_Logon WMI class.

New-Mailbox Parameters

When creating a new mailbox using the New Mailbox wizard in the Exchange console, you are required to enter a number of parameters. The Completion page/dialog box in the wizard shows the shell command used under the hood to create the mailbox. This functionality is quite useful in understanding the commands used by such wizards, and the syntax that can be used in the shell to accompl