Geek Out With Perry: New Video Series and Blog

It's been over two months since I posted here! No, I'm not taking a break, at least not an intentional one, and hopefully will get back to posting regularly soon. Meanwhile, check out the posts on the Exchange team blog.

And if you've been monitoring the team blog, you must have come across (and read with interest, I hope) the Top 10 Exchange Storage Myths post and the Large Mailbox Vision whitepaper posted on the Microsoft site. Yes, 'tis the season of large and very large (and low cost) mailboxes, and with features such as Exchange 2010's Personal Archive, the multitude of performance improvements and continuous lowering of disk I/O requirements in Exchange 2007 and 2010, coupled with Outlook's perf improvements (Outlook 2007 SP2 and Outlook 2010), we're seeing Exchange mailboxes get a lot larger! Interestingly, 2 Gb+ is now the norm in many organizations, and 10 Gb mailboxes on their way to the "not unusual" territory!

I myself crossed the 5 Gb. limit on my own mailbox, hosted on Exchange 2010 RTM server. Glad to say it's working very well with Outlook 2010 and OWA, and I'm allowing myself to get a little sloppier as far as filing messages in folders goes. Exchange Search (and Windows Search — used by Outlook when accessing Exchange Server in cached mode) continue to provide great search capability.

Exchange GM Perry Clarke, one of Exchange's thought leaders, has started blogging, and you'll find many of his thoughts around ever-increasing mailbox size and storage trends very interesting. Check out the new video series — Geeking Out With Perry, and Perry's first blog post— Getting the conversation started.

Perry— welcome to the blogosphere! I look forward to future episodes from the video series, and more blog posts.

Outlook Spy 2.15 is Outlook 2010-compatible

Didn't notice earlier— one of my favorite Outlook/Exchange tools is now compatible with Outlook 2010. Outlook Spy is primarily a tool for Outlook/Exchange developers, but Exchange administrators also find it useful. It allows you to look under the hood of mailboxes and messages. Created by Dmitry Streblechenko, an Outlook MVP, Outlook Spy has been on my list of "must have Exchange tools" for as long as I can remember. Released in November 2009, the latest version of Outlook Spy (v2.15) adds Outlook 2010 compatibility.

You can download Outlook Spy 2.15 from Dmitry's web site. Registration for a single user license is $49.99. It's been worth every penny and more for me.

I also like the free MFCMapi tool on Codeplex - Microsoft's open source community site where you'll find a lot of useful tools and apps along with the source code. MFCMapi is a compact executable (760-873K) and doesn't require installation. It was created by Microsoft's Stephen Griffin. It's available in both 32-bit and 64-bit versions.

Bulk mailbox creation: Import passwords from a file

Automating bulk mailbox creation required fairly advanced scripting skills in Exchange 2003/2000. Thanks to the Exchange Management Shell (aka "the shell") in Exchange 2010 and 2007, this task is greatly simplified. It doesn't require any advanced scripting skills and it can be accomplished by relative newcomers to Exchange Server with very little knowledge of the shell.

Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell shows you how to create bulk mailboxes using user data imported from a CSV file. A related post— Bulk mailbox creation revisited: Adding Active Directory attributes shows you how additional Active Directory attributes not included in the New-Mailbox/Set-Mailbox cmdlets can be populated.

When creating mailboxes using the New-Mailbox cmdlet, Exchange Shell requires the password to be of type System.Security.SecureString, derived from the SecureString class in the dot net framework. In the example in Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell, we use the same password for all accounts. We also prompt the admin to enter that password using the Read-Host cmdlet, as shown below:

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

When the admin running the command or script enters the password, powershell masks the password by displaying a * for each character entered.

One frequently asked question when discussing bulk mailbox creation is: how do I import passwords from a text file? Of course, saving passwords in a text file isn't very secure, but there may be cases where you need to do this temporarily— particularly when you want to create mailboxes/user accounts in bulk and don't want to assign the same password to all accounts. When doing so, it's recommend to set the account to change password on next logon. There may also be other scenarios where you need to import passwords from a text file, so I'll leave the security aspect of this up to you.

The first step to importing passwords from the text file is to add it as an additional column or field in the file. For example:

Alias,Name,UPN,Password
User_One,User One,[email protected],P@ssw0rd1
User_Two,User Two,[email protected],P@ssw0rd2
User_Three,User Three,[email protected],P@ssw0rd3

If you try to use the same command as shown in the previous post, and simply add the parameter -password and the value $_.password in the code block, it'll fail.

Import-CSV CreateRecipients.csv | foreach {new-mailbox -alias $_.alias -name $_.name -userPrincipalName $_.UPN -database "Mailbox Database" -org Users -Password $_.password}
Cannot process argument transformation on parameter 'Password'. Cannot convert the "P@ssw0rd1" value of type "System.String" to type "System.Security.SecureString".
+ CategoryInfo : InvalidData: (:) [New-Mailbox], ParameterBindin...mationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,New-Mailbox

Converting a string to a SecureString
To use the password field imported from the CSV file, you must first convert it to a SecureString. You can convert a string to a SecureString using the ConvertTo-SecureString cmdlet. When using the ConvertTo-SecureString cmdlet, you must specify that the source string is provided as cleartext by using the AsPlainText switch (not to be confused with the plaintext message format). The cmdlet also requires that you specify the Force switch to confirm you really want to do this— yes, you've just provided your consent to convert a plaintext string to a SecureString!

The modified command looks something like this:

Import-CSV CreateRecipients.csv | foreach {New-Mailbox -Alias $_.alias -Name $_.name -UserPrincipalName $_.UPN -Database "Mailbox Database" -Org Users -Password (ConvertTo-SecureString $_.password -AsPlainText -Force)}

To enforce a password change on next logon, add the ResetPasswordOnNextLogon parameter to the command:

Import-CSV CreateRecipients.csv | foreach {New-Mailbox -Alias $_.alias -Name $_.name -UserPrincipalName $_.UPN -Database "Mailbox Database" -Org Users -Password (ConvertTo-SecureString $_.password -AsPlainText -Force) -ResetPasswordOnNextLogon $true}

Managed Folders: Why aren't Calendar items expired?

You're testing Exchange 2007's Messaging Records Management (MRM) features to implement your organization's messaging retention policies.

You create a new Managed Folder for Calendar items, and then create a Managed Content Setting for it to expire Calendar items in 1 year. Next, you create a Managed Folder Mailbox Policy and add the Managed Folder to the Policy. You apply the policy to a test mailbox.

Testing the Managed Folder Policy
You open the test mailbox, create a single-instance appointment that starts and ends on some date more than a year ago.

To test the new Managed Folder Policy, you manually run the Managed Folder Assistant against your test mailbox:

Start-ManagedFolderAssistant -Mailbox "Joe Adams"

You expect the meeting, which (starts and) ends at some date more than a year ago, to be expired and the RetentionAction specified in the Managed Content Setting to be applied. It doesn't.

Calculating Retention Age for Calendar items

You can tell the MFA when to start counting an item's retention age from, by specifying it in the Content Settings for a Managed Folder. It can be based on:
1) When the item was delivered to a mailbox or
2) When the item was moved to a folder


Figure 1: Configuring retention period in Managed Content Settings

Calendar items such as meetings and appointments, and Tasks, are treated differently since these items have an end date. You could create a meeting for a future event, or create a recurring meeting that takes place at a certain interval (daily/weekly/monthly/yearly) during a certain period, or indefinitely. Therefore, the end date of these items needs to be considered when expiring them. Recurring meetings will expire based on the end date of the last occurrence. Meetings with no end date do not expire.


Figure 2: Recurring meetings can be scheduled to occur daily, weekly, monthly, or yearly for a long period, or indefinitely. When expiring such items, the MFA considers the end date.

If these items are deleted, and thus end up in the Deleted Items folder, the end date is no longer a factor. The Managed Folder Assistant expires Calendar items in the Deleted Items folder based on the message-received date. If the received-date cannot be determined, the message-creation date is used.

More details about retention age for different types of items in "How Retention Periods Are Calculated for Items in Managed Folders".

You locate an older PST and copy a Calendar item which occurs in roughly the same timeframe as the one you just created. When you run the MFA, the copied item with an end date from more than a year ago is expired!

When processing a mailbox, the MFA queries for Calendar items where the creation date is older than the expiration date. If you create a test item for a past date, as we did in this case, it does not get processed by the MFA until the creation date is older than the AgeLimitForRetention.


Figure 3: Calendar items created for a past date will have a creation time that is later than the meeting/appointment end time

Of course, you're not likely to run into this issue except in test scenarios. Real-world meetings do not get created in the past. The creation date is guaranteed to be equal to or older than the end date of the meeting..

SCRIPT: List Delegates With Send On Behalf Access

Send On Behalf access allows a user to send mail on behalf of the mailbox owner.


Figure 1: Send On Behalf access can be assigned from ADUC | recipient properties | Exchange General | Delivery Options, or by the mailbox owner using Microsoft Outlook

Here's a script that lists all users with delegates.

File: listDelegates.zip

Related posts and links:

• Understanding Exchange Server 2003 Mailbox Access Delegation
  
• List users with email forwarding enabled
  
• HOW TO: Export all email addresses from a domain
  
• SCRIPT: Show mailbox limits
  
• SCRIPT: Reset Mailbox Limits
  

Start Managed Folder Assistant for a single mailbox

When testing Managed Folder Mailbox Policy settings in Exchange 2007, you may need to frequently run the Managed Folder Assistant (MFA)) to process a mailbox on-demand, so you can check the mailbox content and MRM logs. However, every time you run Start-ManagedFolderAssistant, the MFA processes all mailboxes on all Mailbox Databases on the server.

Of course, you can avoid all the agony by instructing the Managed Folder Assistant to process only the specified mailbox:

Start-ManagedFolderAssistant -Mailbox "Foo"

Processing a single mailbox results in the MFA completing its job quickly and makes parsing the MRM log easier— the MFA only logs events related to the specified mailbox.

The -Mailbox parameter does not take multiple mailboxes as input. To process more than 1 mailbox, you will need to use the Get-Mailbox cmdlet (or Get-User piped to Get-Mailbox, depending on the property you want to filter on) and pipe a filtered list of mailboxes to Start-ManagedFolderAssistant. For example, the following command will result in the MFA processing all mailboxes from the department:

Get-User -Filter {department -eq "Sales" -and RecipientType -eq "UserMailbox"} | Get-Mailbox | Start-ManagedFolderAssistant

Or maybe you want to have the MFA process all mailboxes with a particular policy applied. Note, the Filter requires the distinguishedName of the policy:

$policy = (Get-ManagedFolderMailboxPolicy "MRMPolicy-VPs").distinguishedName; Get-Mailbox -Filter {ManagedFolderMailboxPolicy -eq $policy} | Start-ManagedFolderAssistant

Troubleshooting Exchange Server Antispam: Disable Outlook Junk Mail

When troubleshooting antispam issues, particularly false positives (legitimate email incorrectly tagged as spam), frequently you run into scenarios where Exchange Server antispam features seem to be working correctly but you still see messages being delivered to the Junk Mail folder instead of the Inbox.

For instance, you whitelist a sender or sender domain, or add the sending IP address to the IP Allow List. You find message(s) from the whitelisted sender, domain or IP address still being delivered to the Junk Mail folder. You open the message and check the antispam headers - as expected, Exchange has stamped the message with a SCL of -1.

When troubleshooting Exchange antispam issues, it's best to turn off Microsoft Outlook's own antispam filtering. This is something Outlook does in addition to Exchange's server-side antispam agents. By default, Outlook's Junk E-mail Filter is turned on and set to Low.

To disable Junk Mail filtering in Outlook 2007:
1. Go to Tools menu | Options | Preferences tab | under E-mail section -> click the Junk Mail button.
2. In Junk E-mail Options, on the Options tab, select No Automatic Filtering...


Figure 1: Disable Outlook's own Junk E-mail Filtering when troubleshooting Exchange server antispam features

Related posts and links:

• About the Junk E-mail Filter
  

Resource Mailbox Calendar Settings: Configuring resource mailboxes using OWA

Have you been using the Set-MailboxCalendarSettings cmdlet to configure scheduling settings for resource mailboxes? Wish there was a graphical interface to configure these settings?

[PS] C:\>get-mailboxcalendarsettings cf-oahu | fl

AutomateProcessing : AutoAccept
AllowConflicts : False
BookingWindowInDays : 180
MaximumDurationInMinutes : 1440
AllowRecurringMeetings : True
EnforceSchedulingHorizon : True
ScheduleOnlyDuringWorkHours : False
ConflictPercentageAllowed : 0
MaximumConflictInstances : 0
ForwardRequestsToDelegates : True
DeleteAttachments : True
DeleteComments : True
RemovePrivateProperty : True
DeleteSubject : True
DisableReminders : True
AddOrganizerToSubject : True
DeleteNonCalendarItems : True
TentativePendingApproval : True
EnableResponseDetails : True
OrganizerInfo : True
ResourceDelegates : {}
RequestOutOfPolicy :
AllRequestOutOfPolicy : False
BookInPolicy :
AllBookInPolicy : True
RequestInPolicy :
AllRequestInPolicy : False
AddAdditionalResponse : False
AdditionalResponse :
RemoveOldMeetingMessages : True
AddNewRequestsTentatively : True
ProcessExternalMeetingMessages : False
DefaultReminderTime : 15
RemoveForwardedMeetingNotifications : False
Identity : MDomain.com/Conference Rooms/CF-Oahu

Output of Get-MailboxCalendarSettings cmdlet

Christian Schindler, MCT, MCA (Messaging), from Austria points out the little known fact that you can use OWA to configure calendar settings for resource mailboxes. Note, the user accounts for resource mailboxes are disabled by default. You would need to enable the account in ADUC before you try to logon using OWA.

An alternative to enabling resource mailboxes

If you want to avoid enabling resource mailbox accounts, here's an alternative. You can assign yourself (or any other account) FullAccess permission on the resource mailbox(es) you want to configure. Use the following command:

Get-Mailbox -Filter {RecipientTypeDetails -eq "RoomMailbox"} | Add-MailboxPermission -User "YourAccount" -AccessRights FullAccess

With the permission assigned, you can log on to OWA using your account, and open the resource mailboxes using OWA 2007's ability to open additional mailboxes, as shown in the following screenshot.

If you look at Options in OWA when logged in as an ordinary mailbox user (that is, not logged on to a resource mailbox), you see Calendar Options.

If you log on to a resource mailbox using OWA, you also see Resource Settings as one of the options.


Figure 1: The Resource Settings option is available in OWA when logged on to a resource mailbox. Full size screenshot here.

Not only does this allow you to configure the settings for automated processing of meeting requests, there's also a rich text editor for creating a custom response message.


Figure 2: The Resource Settings option also has a rich text editor for creating a custom HTML response message.

Related posts and links:

• HOW TO: Convert a user mailbox to a resource mailbox
  
• Cmdlet help: Set-MailboxCalendarSettings
  
• Managing Resource Scheduling
  
• How to Enable or Disable Automatic Booking on a Resource Mailbox
  
• How to Enable Explicit Logons in Outlook Web Access

Configuring Deleted Item Retention

After a user empties the Deleted Items folder, although these items disappear from the view of the mailbox, they are not completely deleted. They are retained till the Deleted Item Retention period expires in what's fondly referred to as the Dumpster— not to be confused with the Transport Dumpster maintained by Hub Transport servers.

Deleted Item Retention (DIR) can be configured on the Mailbox Database. It is set to 14 days by default. The other related parameters that can be configured on the MDB include deleted mailbox retention period and the option to not purge deleted items until the MDB has been backed up.


Figure 1: Deleted Item Retention settings for a Mailbox Database


Configuring Deleted Item Retention per-mailbox
Individual mailboxes can be configured with a different Deleted Item Retention period, which bypasses the limit set on the Mailbox Database. To configure the individual DIR settings for a mailbox using the Exchange console:
1. In Recipient Configuration | Mailbox | select recipient --> Properties | Mailbox Settings tab | double-click Storage Quotas

2. In the Storage Quotas property page, uncheck Use mailbox database defaults


3. In the Keep deleted items for days field, enter a new value

4. Optional: Check Do not permanently delete items until you back up the database

Why is it a good idea to not purge the dumpster till the Store has been backed up?
If not checked, items in the Dumpster will expire after the Deleted Items Retention period, and be permanently lost! If the Dumpster is purged before a backup takes place, the item is lost forever, with no way to recover it. Retention Policies in many organizations require that all messages or mailbox items should be recoverable.

5. Click OK to close the Storage Quotas property page | click OK to close mailbox properties.

Modifying the Deleted Item Retention period for a mailbox using the Exchange shell
The DIR period can be set by populating the RetainDeletedItemsFor property using the Set-Mailbox cmdlet. Using the shell's ability to pipe objects (output from one cmdlet to be processed by another cmdlet), you can use Get-Mailbox with the -Filter property and get the desired set of mailboxes to apply the new DIR period in bulk. You can also use a number of other properties to filter mailboxes based on the OU, Mailbox Database, Storage Group, etc. For example:

Get-Mailbox -OrganizationUnit "San Francisco" | Set-Mailbox -RetainDeletedItemsFor 20.00:00:00

(See Applying Managed Folder Policy to more than one user for more examples. The list of filterable properties that can be used in the -Filter parameter: Exchange 2007 RTM | SP1).

However, simply setting the RetainDeletedItemsFor property does not apply the new retention period to mailboxes. Remember the checkbox in the console for Use mailbox database defaults? How do we uncheck that using the shell?

Let's get all *Deleted* properties of a mailbox:

Get-Mailbox "My Mailbox" | ft *Deleted* -AutoSize

What you get back is:


The value modified by the checkbox in the console shows up in the DeletedItemFlags column in the Get-Mailbox output. It can have three values:
1) DatabaseDefault when the checkbox is selected
2) RetainForCustomPeriod when it's not
3) RetainUntilBackupOrCustomPeriod— a third value, if you've also selected the option not to purge the Dumpster before the Store's backed up.

At this point, I wouldn't blame you if you instinctively proceed to use the Set-Mailbox cmdlet to flip the DeletedItemFlags property from DatabaseDefault to RetainForCustomPeriod. However, this doesn't work.

What Get-Mailbox actually displays as the DeletedItemFlags is a calculated property— properties which are calculated and displayed for ease of administration, but aren't actual properties that can be modified using the corresponding Set-Whatever cmdlet.

The property we need to modify is called UseDatabaseRetentionDefaults. It's a boolean property— valid values can be $true or $false.

When setting a custom/non-default Deleted Item Retention period on mailboxes, we should set the UseDatabaseRetentionDefaults property to $false:

Set-Mailbox "My Mailbox" -RetainDeletedItemsFor 20.00:00:00 -UseDatabaseRetentionDefaults $false

The Get-Mailbox output after this is done:


If you also set RetainDeletedItemsUntilBackup to $true:


Getting Dumpster Statistics
To get the total number and size of deleted items in the dumpster for a mailbox, use the Get-MailboxStatistics cmdlet:

Get-MailboxStatistics [email protected] | Select *Deleted*

The output:

DeletedItemCount TotalDeletedItemSize
---------------- --------------------
752                16020237B

Doesn't the output from the above command include the Deleted Items folder?
No. To get the statistics for the Deleted Items folder, use:

Get-MailboxFolderStatistics [email protected] | where {$_.FolderPath -like "/Deleted Items"}

The output:

Date : 9/16/2008 7:15:49 PM
Name : Deleted Items
Identity : [email protected]\Deleted Items
FolderPath : /Deleted Items
FolderId : LgAAAAAaFeUR2TeSRpY38Ihx7YFNAQCK6B+B4tC8RbU9t9FmHnW4AAAAABIcAAAB
FolderType : DeletedItems
ItemsInFolder : 361
FolderSize : 6214440B
ItemsInFolderAndSubfolders : 361
FolderAndSubfolderSize : 6214440B
OldestItemReceivedDate :
NewestItemReceivedDate :
ManagedFolder : DI30days

Related posts and links:

• Configuring Deleted Mailbox and Deleted Item Retention
  
• How to Configure Deleted Item Retention for a Mailbox Database
  
• How to Configure Deleted Item Retention for a User
  
• How to Recover a Deleted Item

Troubleshooting Exchange Performance: Performance Analysis of Logs (PAL) tool

Interested in monitoring and troubleshooting Exchange Server performance? Check out the Performance Analysis of Logs (PAL) tool on CodePlex.

PAL creates some great reports that provide a better analysis of Exchange performance data than actually looking at perfmon counters all day. Mike Lagase has more details in his blog post "Performance Troubleshooting using the PAL tool".

Related posts:

• Monitoring Exchange Server 2007 Performance: Perfmon counters and thresholds
  
• Fixed: Outlook 2007 Performance issues with large mailboxes
  
• Perfmon counters show up as numbers?
  
• Troubleshooting IMF: Important performance counter
  

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. The reasons are not hard to guess. These details are retrieved by querying the mailbox database. In Exchange 2003, these were displayed when you selected the mailbox database, resulting in a single mailbox database being queried. In Exchange 2007, mailboxes are displayed when you select Recipient Configuration -> Mailboxes, and depending on the selected scope/filter, the console displays mailboxes from the entire organization. Querying all mailbox databases on different servers in a distributed organization can become very slow, generate a lot of extra network traffic— terribly inefficient.

Instead, why not allow the administrator to query for these details when they're actually required? The shell provides you the flexibility to only get the fields you want, only for the mailboxes you want, making it much more efficient. If you manage smaller Exchange deployments and love your GUI management tools, you may not fall in love with the idea. (But that debate's already settled, and you're going to have to learn some bit of Exchange shell to be able to manage Exchange 2007 and later. The good news is, it's cooler, easy-to-use, well-documented by now, and comes with plenty of help!).

Logon Statistics
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 [email protected] -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 "[email protected]

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 "[email protected]"

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

Set-Mailbox "Joe Adams" -ForwardingAddress "[email protected]" -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.

List users with SendAs permission assigned
The following code lists mailboxes with the SendAs permission assigned. Unlike FullAccess mailbox permission, SendAs is an Active Directory permission.

Get-Mailbox -ResultSize unlimited | Get-ADPermissions | Where {$_.ExtendedRights -like "Send-As" -and $_.User -notlike "NT AUTHORIT\SELF" -and $_.Deny -eq $false} | ft Identity,User,IsInherited -AutoSize

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,[email protected],650.555.1121
User_Two,User Two,[email protected],650.656,2221
User_Three,User Three,[email protected],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, such as Inbox, Sent Items, and Deleted Items. 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?

Exchange setup creates a set of default folders of each type e.g. Deleted Items. These are visible in Organization Configuration | Mailbox | Managed Default Folders tab, or by using the Get-ManagedFolder cmdlet.


Figure 1: Exchange setup creates a set of managed default folders of each type.

To apply message retention settings for items in a managed folder, you must create Managed Content Settings for it. For example, you can create a Managed Content Setting to retain items in the Deleted Items folder for 30 days, and permanently delete items older than 30 days.


Figure 2: You can create additional Managed Default Folders of type Deleted Items.

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.


Figure 3: You cannot create an additional Managed Content Settings for the same message class for the same folder.

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.

Create another Managed Default Folder
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. In the Action pane, click 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.
   
   
   Figure 4: Creating a new Managed Default Folder of type Deleted Items.
   
   
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. The comment will be displayed in Outlook 2007 when the user selects this folder.
   
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.


Figure 6: Another instance of the Deleted Items default folder.

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 SMTP Virtual Servers in Exchange Server 2003/2000, Exchange 2007's Receive Connectors 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 Exchange console: Recipients | Mailbox -> select mailbox | properties | Mail Flow Settings tab | Message Size Restrictions.

Do individual size limits bypass the Organization size limit?

Setting higher message size limits on an Exchange recipient bypasses the maximum message sizes in the Exchange Organization configuration, albeit only for internal messages, not for messages sent to or received from unauthenticated sources.

Troubleshooting 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 it's often overlooked when troubleshooting. This is the one 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 Organization, you can use ESM to modify these limits. 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*"}