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,userone@yourUPNsuffix.com,P@ssw0rd1
User_Two,User Two,usertwo@yourUPNsuffix.com,P@ssw0rd2
User_Three,User Three,userthree@yourUPNsuffix.com,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 User@MyDomain.com | 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 User@MyDomain.com | where {$_.FolderPath -like "/Deleted Items"}

The output:

Date : 9/16/2008 7:15:49 PM
Name : Deleted Items
Identity : User@MyDomain.com\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 foo@mydomain.com -ExternalOofOptions InternalOnly

Related:

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

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

New whitepapers have been released today on TechNet.

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

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

The whitepaper is available here.

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

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

The whitepaper is available here.

Modifying Display Templates and additional attributes

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

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

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

Updated: Mailbox Server Role Storage Calculator v14.7

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

Released: MAPI Client and CDO 1.2.1 for Exchange 2007

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

Download ExchangeMapiCdo.MSI from microsoft.com.

While you were out: Scheduling meetings and OOFs

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

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

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

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


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

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

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


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

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


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

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

How to forward mail to an external email address

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

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

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

 To create a MailContact using the Exchange Management Console:

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

To create a new MailContact using the Exchange Management Shell:

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

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

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

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

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

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

Using the Exchange Management Shell:

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

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

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

To get a list of mailboxes with forwarding enabled:

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

Automatic forwarding and Remote Domains

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


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

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

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

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

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

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

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

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

Related posts:
- DST 2007 Rollup Post

HOW TO: List mailboxes with Full Mailbox Access permission assigned

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

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

Filtering mailboxes returned by Get-Mailbox

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

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

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

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

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

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

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

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

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

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

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

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

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,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, 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*"}

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.

Let's filter the above list of legacy mailboxes to only the ones located on Exchange 2007 servers:

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

Apply mandatory properties:

Get-ExchangeServer | Where {$_.IsExchange2007OrLater} | Get-Mailbox | where {$_.RecipientTypeDetails -eq "legacymailbox"} | Set-Mailbox -ApplyMandatoryProperties

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-DistributionGroupMember "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 accomplish the same task. (As a side note, this display of commands is limited to wizards. If you add/modify a configuration setting directly, the commands used are not displayed).

When creating a new mailbox for a user Jim Murphy, the shell command used is displayed in the screenshot below.



Parameters used by the command displayed in the above screenshot:
1) Name: Jim Murphy
2) Alias: jmurphy
3) OrganizationalUnit: e12labs.com/users (Domain/Container or OU)
4) sAMAccountName: jmurphy
5) FirstName: Jim
6) Initials: '' (blank)
7) LastName: Murphy
8) Password: System.Security.Secure.String (hidden)
9) ResetPasswordOnNextLogon: $false
10) Database: distinguishedName of the mailbox database

The new-mailbox command creates a new user account in Active Directory, and a new mailbox in Exchange. Documentation for the new-mailbox command has an extensive list of all the parameters - required and optional.

However, a new mailbox can be created using far fewer parameters - as shown below:

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

The new-mailbox command does not accept a password if it is actually typed inline in the command, e.g. new-mailbox -password MyPassw0rd1.... The command in the above example results in the shell providing a prompt to securely enter a password, without making it visible in the shell. It is held in the variable $password. The variable can then be used in the new-mailbox command.

New-Mailbox -Password $password -Name "Jim Murphy" -UserPrincipalName jmurphy@e12labs.com -OrganizationalUnit Users -Database "Mailbox Database"

Note, not all the parameters used and displayed by the New Mailbox wizard are required. Some parameters, like alias are populated automatically by the shell. You can use the get-mailbox command to list all parameters for a mailbox, and determine which parameters were populated automatically.

get-mailbox "Jim Murphy" | fl

Applying Managed Folder Policy to more than one user

Scenario: You have a Managed Folder Mailbox Policy called Policy-DeletedItems90Days. The policy has Managed Content Settings to permanently delete items in the Deleted Items folder after 90 days.

You can easily apply this Managed Folder Mailbox Policy to a single user using the Exchange console, as shown in Figure 1.


Figure 1: Applying a Managed Folder Mailbox Policy to a user using the Exchange Management Console

A Managed Folder Mailbox Policy can also be applied to a mailbox using the following shell command:

Set-Mailbox "Foo User" -ManagedFolderMailboxPolicy "Policy-DeletedItems90Days"

How do we apply this to more than one user? By using the Get-Mailbox command to fetch a bunch of mailboxes - either all mailboxes in the Organization, or all mailboxes in a particular Organizational Unit (OU), or all (mailbox-enabled) users who are members of a particular distribution group, or other user parameters. The mailboxes returned can then be piped to the Set-Mailbox command.

To apply a Managed Folder Mailbox Policy to all (mailbox-enabled) users, we need to get a list of all mailboxes, and pipe it to the Set-Mailbox command:

Get-Mailbox -ResultSize unlimited | Set-Mailbox -ManagedFolderMailboxPolicy "Policy-DeletedItems90Days"

To apply the policy to all mailboxes in a particular OU, e.g. an OU called Sales - we restrict our Get-Mailbox query the OU:

Get-Mailbox -OrganizationalUnit "Sales" -ResultSize unlimited | Set-Mailbox -ManagedFolderMailboxPolicy "Policy-DeletedItems90Days"

Apply a Managed Folder policy to members of a Distribution Group

When applying the policy to members of a Distribution Group, remember that Distribution Group members can include recipients other than mailbox-enabled users (e.g. mail-enabled users, Contacts, other Distribution Groups, Public Folders, etc.). To apply the policy to all (mailbox-enabled) users who are members of a Distribution Group called DL-Sales, we will need to get members of the Distribution Group using the Get-DistributionGroup command, filter the result to get only mailbox-enabled users, and pipe it to the Set-Mailbox command:

Get-DistributionGroupMember "DL-Sales" -ResultSize unlimited | where {$_.RecipientType -eq "UserMailbox"} | Set-Mailbox -ManagedFolderMailboxPolicy "Policy-DeletedItems90Days"

One logical question after the last example - can I do this with Security Groups instead? You cannot get the group membership of a Security Group as easily as you can get the members of a Distribution Group. Unfortunately, the Exchange shell does not have any equivalent of Get-DistributionGroupMember command that will work for Security Groups, although it's possible to enumerate security group memberships using the ADSI provider. (You can search the web for shell scripts to enumerate security group members - Bharat)

Avoid the confirmation prompts when applying a Managed Folder policy
When applying a Managed Folder Mailbox Policy, you run into 2 prompts. The first one is the default confirmation prompt produced by Set-Mailbox. This is cmdlet saying, "Hey, something changed! Are you sure you want to do this?", and prompts you for a confirmation as shown below:

Confirm
Are you sure you want to perform this action?
Setting mailbox "exchangepedia.com/People/foo user1".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

You can avoid it by simply using -Confirm:$false in the command.

Next, you will run into the confirmation prompt produced when applying a Managed Folder Mailbox Policy. This is the cmdlet realizing, "Hey, this one's a serious change - you're applying a MF policy! Are you really, really sure? And btw, it'd be a good idea to block legacy Outlook clients!". The resulting prompt is shown below:

Confirm
When assigning a managed folder mailbox policy with managed custom folders to the mailbox "exchangepedia.com/People/foo user1", Outlook clients older than Outlook 2007 do not have all available client features and clients older than Outlook 2003 SP2 are not supported. You may use the "Set-CASMailbox" task to enable client version blocking. Are you sure you want to assign a managed folder mailbox policy to this mailbox?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

To override this one, you'll need to use the ManagedFolderMailboxPolicyAllowed switch. The command from the above example will thus look like this:

Get-Mailbox -ResultSize unlimited | Set-Mailbox -ManagedFolderMailboxPolicy "Policy-DeletedItems90Days" -ManagedFolderMailboxPolicyAllowed -Confirm:$false

A default Managed Folder policy for new users

A related frequently asked question— Can you have a default Managed Folder Mailbox Policy that's applied to new mailboxes automatically? There's no built-in way to specify a policy as the default policy for all users or new users at the time of account creation. However, you can use the Windows Scheduler to schedule a script or command to run on a schedule and apply the required policy to users.

For example:
Get-Mailbox -ResultSize Unlimited -Filter {ManagedFolderMailboxPolicy -eq $null} | Set-Mailbox -ManagedFolderMailboxPolicy MyPolicyName -ManagedFolderMailboxPolicyAllowed -Confirm:$true

Why not use LDAP filters?
That's fine, you say, but you really liked the Exchange 2003 way of applying a Recipient Policy, using LDAP filters. Using pretty much any attribute you chose to filter on. In Exchange 2007, there's no built-in way of using LDAP filters to apply a policy.

It's not such a great idea to apply message retention policies using an LDAP filter, or at least not in a manner similar to Exchange 2003.

For instance, if you're using a particular attribute to filter on, such as department, or group membership - simply changing the attribute or group membership could change when and how a mailbox user's messages are retained or purged. If you have multiple overlapping Recipient Policies, at times it's difficult to determine which policy is applicable to a user.

Exchange 2007 offers a simpler and deterministic behavior— by making the policy a user attribute. A policy explicitly associated with a user allows you to instantly determine which policy applies, with no ambiguity. It's also auditable, and reportable.

The automation is provided by PowerShell. Of course, you can simulate Exchange 2003's Recipient Policy behavior by using an OPATH filter with the Get-Mailbox cmdlet.

However, if you still need to use an LDAP filter, Nick Smith shows you how in Applying Managed Folder Mailbox Policies via LDAP Filters.

Related posts:
- Managed Folders: How to apply different Managed Content Settings to Default Folders
- Exchange Server 2007: Why aren't Managed Content Settngs applied?
- Restricting Messaging Records Management to a particular message type

HOW TO: Expose original senders and recipients of quarantined messages

The Content Filter Agent in Exchange Server 2007 allows you to quarantine messages above the SCLQuarantineThreshold. Messages so quarantined are delivered to a quarantine mailbox, specified in the Content Filter configuration. [Read previous post for more info, "Exchange 2007 Content Filter: How to move messages to users' Junk Mail folder"]

Messages arriving in the quarantine mailbox look like NDRs. They appear to be sent from the postmaster address of the default domain. As such, you can't easily see the original sender and recipient's addresses, as shown in the screenshot below:


Figure 1: By default, messages in the quarantine mailbox show the envelope sender— the postmaster address

"How to Recover Quarantined Messages from the Spam Quarantine Mailbox" in the Exchange Server 2007 documentation shows how to use a custom Outlook form to expose the original sender - the doc has code that can be copied to a text editor like Notepad and saved as a custom form (QTNE.CFG), which can be used in Outlook to expose the relevant MAPI property as a field that can be added to the view.

This exposes the original sender, but doesn't expose the original recipient of the message. To expose the recipient, you need to modify the form from the above link and add the relevant MAPI properties.

 Download the modified QTNE.CFG file
Download the modified form file and save it in the correct Forms folder for your locale.

For US English, the path is: \Program Files\Microsoft Office\Office12\Forms\1033. You can find out the locale ID (LCID) for your locale from KB 221435: List of supported locale identifiers in Word..

What was added in my Modified Quarantine Extension Form:
Under [Properties]

Property02=OriginalRecipient

After [Property.OriginalSender] section:

[Property.OriginalRecipient]
Type=30
NmidInteger=0x0E04
DisplayName=Original Recipient

 Install the form in Microsoft Outlook

1. Tools | Options | Other tab | Advanced Options | Custom Forms | Manage Forms | Install.
2. Navigate to the path where you saved the QTNE.CFG file, and select the file.


Figure 2: Installing the Modified Quarantine Extension form (QTNE.cfg) in Microsoft Outlook

3. Click OK a few times till all the dialog boxes are closed. The form is now installed.


 Add the fields
With the form installed in Outlook, it's time to make the fields show up!

1. In the Outlook messages pane, right-click the column heading on the top | select Custom.
2. In the Custom View dialog box, click Fields | from the "Select available fields from:" drop-down (which says "Frequently-used fields" by default), select Forms [screenshot].
3. Select the Modified Quarantine Extension Form | click Add
4. In the Show Fields dialog box, select Original Sender and Original Recipient | click Add.


Figure 3: Adding the Original Sender and Original Recipient fields to the view

5. Additionally, you can remove unnecessary fields and order the fields the way you want [screenshot of fields I have selected].

Once you're done, the Original Sender and Original Recipient fields are displayed as shown in the screenshot below:


Figure 4: The updated view after adding the Original Sender and Original Recipient columns

When the message list pane is expanded in Outlook, this is what it looks like.


Figure 5: Expanding the columns in the updated view

Exposing these fields makes managing the quarantine mailbox easier.

Update: Adding the Original SCL column
08/19/2008 7:39 PM

Exchange 2007 SP1 also exposes the original SCL. The Outlook form file (QTNE.cfg) can be updated by adding the following.

- In the [Properties] section:

Property03=OriginalSCL

- After the [Property.OriginalRecipient] section:

[Property.OriginalSCL]
Type=3
NmidPropset={41F28F13-83F4-4114-A584-EEDB5A6B0BFF}
NmidString=OriginalScl
DisplayName=Original SCL

You can download the updated QTNE.cfg form or manually updated your own file. Now you can add the Original SCL column.


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

The previous version of QTNE.cfg is still available.

HOW TO: Convert a user mailbox to a resource mailbox

When creating a new mailbox (or a mailbox-enabled user) in Exchange Server 2007, you have the option of creating a user mailbox or a resource mailbox - the latter for conference rooms, equipment like projectors, etc.

If you've already created a user mailbox instead, and want to convert it to a resource mailbox, use the following command:

Set-Mailbox "MailboxName" -Type Room

This sets up the mailbox as a room mailbox. The following changes take place (perhaps not an extensive list):
IsResource: True
UserAccountControl: Yes, Exchange Server 2007 resource mailboxes are disabled (displayed as "AccountDisabled" in the shell)
ExchangeUserAccountControl: AccountDisabled
LinkedMasterAccount: NT AUTHORITY\SELF
RecipientTypeDetails: RoomMailbox
AddressListMembership: In addition to the Default GAL and All Users address lists, the mailbox is made a member of All Rooms address list

AutomateProcessing in MailboxCalendarSettings is set to AutoUpdate. AutoUpdate sets up the mailbox to be processed by the Calendar Attendant. This processes meetings for users as they are received - even if the user is not logged on. Calendar items (meetings) are placed on the user's Calendar as tentative. As meeting updates are received, it marks the older instances as outdated.

The other choice here is AutoAccept, which sets it up for processing by the Resource Booking Attendant. It is similar to the Auto-Accept Agent for Exchange Server 2003 (a separate web download) - with a lot more configuration options, and without the XML configuration file required by AAA. To set up the mailbox for resource booking:

Set-MailboxCalendarSettings "MailboxName" -AutomateProcessing AutoAccept

There are plenty of configuration options one can use with Set-MailboxCalendarSettings command. Look at these in the documentation to figure out if you want to change any of the defaults.

To get a list of all resource mailboxes:

Get-Mailbox | where {$_.IsResource -eq "true"}

HOW TO: Send as alternate email address

This is one of the more frequently asked questions in different forums - how do I send as an alternate address?

You can use Exchange (2003/2007) Server's Recipient Pollicies (EmaiAddressPolicy in Exchange Server 2007), or the E-mail Addresses tab in AD Users & Computers, to add additional email addresses for recipients (e.g. mailbox-enabled or mail-enabled users, Distribution Groups, mail-enabled Public Folders, Contacts).

The email addresses are stored in recipients' proxyAddresses attribute in Active Directory. This allows recipients to receive inbound email on any email addresses in that attribute.

However, sending messages is a different story. For new messages, you can specify any of your email addresses (in the proxyAddresses attribute) - the address automatically gets resolved to your Display Name, and gets sent using the primary email address. This is the address displayed using (upper-case) SMTP: in the proxyAddresses attribute.

This behavior also manifests itself when replying to a message that was received on an address other than the primary email address.

There are workarounds to accomplish this, but they are as annoying as the problem itself.

1. Creating additional recipient(s):
- Create a new mailbox (you can also other recipient objects like Distribution Groups for this, but for this post I'll assume you're using a mailbox) for each address you want to use to send outgoing mail as.
- Ensure this address is set as the primary address of the new mailbox.
- Assign your primary account Send As permission on the new account(s)
- When sending a new message, or replying to a received message, manually populate the From: field in Outlook with the Display Name or SMTP address (or any other attribute that can resolve to the new account)

- Additionally, if using a mailbox-enabled account for this purpose, the additional mailbox can be opened by the user in Outlook, along with his/her primary mailbox.
- Alternatively, inbound mail can be redirected to the user's primary mailbox by modifying Delivery Options in the properties of new recipient(s) created for this purpose.

2. Using SMTP clients: SMTP clients like Outlook Express can be configured to send using the alternate email address. This is equally annoying - every time a message needs to be sent as an alternate address, you will need to fire up Outlook Express (or your SMTP client of choice) to send the message.

3. Using third-party tool - IvaSoft ChooseFrom: IvaSoft makes nifty utilities for Exchange/Outlook that allow you to accomplish tasks that Exchange/Outlook do not allow you to do natively. Their ChooseFrom utility can be used to choose from any address listed in the proxyAddresses attribute, without the pain of the workarounds mentioned above. It uses a transport event sink installed on Exchange server, and is licensed per server.

A separate version - ChooseFromOWA - enables this functionality from Outlook Web Access.

There's no solution to this issue in Exchange Server 2007/Outlook 2007 as well. IvaSoft has released ChooseFrom for Exchange Server 2007.

(As with most third-party software, install and test in a lab environment before you decide to install it on a production server.)

Exchange Server 2007: Why aren't Managed Content Settngs applied?

In Exchange Server 2007, Managed Folder Mailbox Policies are applied to mailboxes to control message retention. Conceptually, this is somewhat similar to Recipient Policy with Mailbox Manager settings in Exchange Server 2003, which is commonly used by administrators to accomplish tasks like emptying users' Deleted Items folders after a set period like 90 or 180 days.

(Messaging Records Management is an interesting topic, and a good candidate for a more elaborate article in the near future explaining how it works - Bharat)

Just as Exchange 2003's Mailbox Manager process runs on a schedule and applies the Mailbox Manager policies to mailboxes, Exchange 2007's Managed Folder Assistant (MFA) applies Managed Folder Policies. By default, it's set to "Never Run", as shown in the screen-shot below.


If you've just gone through the entire process of creating Managed Folder Policies, and are wondering why the mailboxes are not getting processed and why messages older than X number of days aren't getting purged, it's most likely because you haven't modified the above default and actually set a schedule for the MFA to run.

To schedule the MFA, start the EMC, expand Server Configuration | Mailbox | select the mailbox server | Properties | Messaging Records Management tab | click the Customize button, and select a time period.


In addition to being able to schedule the agent to run— preferably after-hours, just like you did with Exchange Server 2003's Mailbox Manager - you can also trigger it manually from the shell, using the following command:

Start-ManagedFolderAssistant

This triggers the agent to run immediately. You can specify which server(s) to start the agent on, by using the -Server SERVERNAME parameter:

Start-ManagedFolderAssistant -Server EXCHANGE1, EXCHANGE2

You can also specify which mailboxes to process by adding the -Mailbox "Mailbox Identity parameter (the identity of a user can be specified as an SMTP address, domain\username, or mailbox GUID), as described in the online docs:

Start-ManagedFolderAssistant -Mailbox foo@yourdomain.com

Note: You cannot use both the -Server and -Mailbox parameters together.

Related posts:
- Managed Folders: How to apply different Managed Content Settings to Default Folders
- Applying Managed Folder Policy to more than one user
- Restricting Messaging Records Management to a particular message type

DST 2007: Why we needed to rebase appointments

I thought I wouldn't need to post about DST 2007 issues after it kicked in on Sunday March 11th this year, but apparently that doesn't seem to be the case.

In a previous post (that I've referred to a number of times now) titled "DST 2007: Understanding what needs to be done and how to do it", I explained how computers keep time and how Outlook creates appointments.

While taking a break from the MVP Summit schedule earlier last week, I came across this eWeek article by Peter Galli titled "Time Change Brings 'Nightmare' Issues with Outlook, Calendars". The article quotes Robert Rosen, CIO of the National Institutes of Health's National Institute of Arthritis and Musculoskeletal and Skin Diseases. "Microsoft in particular requires operating system patches and then Outlook calendar modifications. That makes no sense. If they were storing in Coordinated Universal Time, the operating system patch should have fixed the calendars automatically".

After some reflection, I've gone from that line of thought, to a more logical explanation.

Rosen's line of thought, and mine to some extent when this thing started - if Outlook stores appointments in UTC, which is a universal time that shouldn't change, appointments should always be rendered at the correct time by merely telling the OS when DST starts and ends.

Here's why that line of though isn't correct: users don't book meetings using UTC. They do using their local time - let's say 4:30 PM Pacific time.

When saving the appointment, Outlook uses the time zone in effect on the day of the meeting to calculate the UTC Start Time and End Time. For the 4:30 PM appointment on March 12th, 2007, using the time zone in effect according to the older DST schedule, which would still be Pacific Standard Time or UTC -8:00, the UTC Stard and End times would be 12:30 - 1:00 AM on March 13th, 2007. Here's what the appointment looks like originally.
(Note: A recurring meeting is shown in the screenshot, with the CommonStart and CommonEnd properties so they can be captured on the same screen along with the time zone property - Bharat)


The operating system (OS) is told about this new DST schedule (by applying KB 931836 time zone update).

Now, the appointment Start and End time, though saved in UTC, end up being wrong! UTC 12:30 -1:00 AM on March 13th, 2007, turns out to be 5:30 - 6:00 PM Pacific time on March 12th, according to the new DST 2007 schedule.

Thus the need for "rebasing" those appointments occurring in the affected DST period, which actually adjusts the UTC start and end times of those meetings so they get rendered correctly (in local time) by Outlook. Here's what the 4:30 PM appointment on 3/12/2007 looks like after rebasing.


If users scheduled meetings using UTC to start with - a difficult task that would certainly impact the productivity and increase user frustration - meetings would always have a constant UTC time, irrespective of local time. (As a sidenote, this would have its own implications... but I'd rather not go into more details at this point, now that the DST 2007 change is behind us :-).

HOW TO: Add additional email addresses to a recipient

When adding new email addresses to a recipient using Exchange shell, remember that EmailAddresses property/proxyAddresses attribute is a multi-valued attribute. You can use the same syntax described in the previous post "HOW TO Update multi-valued attributes in PowerShell" to add one-off email addresses that are not created by EmailAddressPolicy.

$foo = get-mailbox User1
$foo.EmailAddresses +="sales@yourdomain.com","info@yourdomain.com"
$foo | set-mailbox

The above can also be easily accomplished using the console - Recipients | select a mailbox, Distribution Group or Contact | properties | E-mail Addresses tab | Add.

DST 2007: Is there an Outlook DST "patch"?

There seems to be some confusion about whether Outlook itself has a DST 2007 patch.

As noted in a previous post "DST 2007: Understanding what needs to be done and how to do it", there's the Outlook Calendar Update Tool - TzMove.exe ("Time Zone Data Update Tool for Microsoft Office Outlook" in Microsoft-speak). This is a tool to rebase existing appointments so they show up correctly on users' calendars after they've applied the time zone update to the operating system (KB 931836). As such, it's not really a patch.

Then there's the Outlook 2003 CDO patch (Outlook 2003 Post-SP2 hotfix) - KB 932962. This is the client-equivalent of the Exchange CDO patch (KB 926666 for Exchange Server 2003 SP2, KB 931978 for Exchange Server 2003 SP1), according to Microsoft's DST 2007 blog.

Do all Outlook users need this? No.

CDO is not installed by default on clients running Outlook, and isn't generally required.

However, some applications that use (client-side) CDO to access Outlook's Contacts and Calendar install this version of CDO on the client. If you're using one of those apps, for instance the contact-management app ACT, you should update the CDO component by applying KB 932962 on the client computer.

This updates CDO.DLL to version 6.5.7651.61 (and updates a few other files as well).

HOW TO: Assign SendAs right using Exchange shell

In Exchange Server 2007, recipients are managed from the Exchange console or shell. The Exchange console does not show security tab for a recipient.

You can still use AD Users & Computers console to modify permissions on a recipient, as the documentation suggests ["How to Grant Send As Permissions for a Mailbox"] - and in this case, assign the Send As permission. In ADUC | select recipient | Properties | Security tab.

You can use the Exchange shell to assign SendAs right (e.g. on a Distribution Group) to a user:

Add-AdPermission "Group Name" -user "User Name" -AccessRights
extendedright -ExtendedRights "send as"

Documentation for Add-ADPermission


11/29/2007:
Exchange Server 2007 SP1 includes a Manage Send As Permissions wizard, similar to the Full Mailbox Access wizard found in the RTM version.

1. In EMC, right-click a recipient | select Manage Send As Permission



2. In the Managed Send As Permission wizard, click the Add button to add the recipient which needs to be assigned Send As permission on the selected recipient

CNet News.com: IT pros battle clock and code in time change

A report from Erica Ogg at CNet News.com, aptly titled "IT pros battle clock and code in time change".

I'm trying to find the humor in all this, and this report provides it: "Microsoft acknowledges that the instructions for updating aren't exactly credit card-size." :)

Further: "BlackBerry Pearl user (user name not published here, in Erica's report linked below) said in an e-mail interview that when she received the patch from her carrier, she initially thought it was junk mail. Nonetheless, she installed the software." Yes, the kind of users we all have, and love to have! :)

Read the entire report on CNet News.com.

DST 2007: I rebased appointments and nothing moved!

It's natural to question what the rebasing tools did - after you rebased items, they didn't seem to move them! Appointments show up in their correct time slots.

Wasn't this what you wanted to see - appointments appear in their correct time slots? :)

I've covered this in a previous post titled "DST 2007: Understanding what needs to be done and how to do it", and I'll briefly explain what happens once again.

- User workstation has older DST 2006 time zone rules, all appointments created using those rules
- DST 2007, and the appointments we talk about are those occurring in the "extended" DST 2007 period, which as you may know by now is the period between March 11-April 1, because we're moving clocks forward by an hour 3 weeks earlier than usual, and between Oct. 28-Nov. 4 2007 - because we're moving clocks back by an hour a week later than usual. Let's refer to these as the affected appointments.

1. User workstation gets KB 931836: This updates the time zone definitions in the operating system's registry. It changes *when* the computer will switch to Daylight Savings Time, and when it'll switch back. Now, all those old appointments in the affected period appear an hour later. These are the appointments we need to rebase.
(Computers with old DST 2006 time zone, i.e. ones without KB 931836 update applied, will still show these at the correct times).

2. Appointments created while the KB 931836 time zone is applied (and occur during the affected period): These appointments will appear correctly. NO REBASING REQUIRED.

3. Appointments rebased using the Outlook Calendar Update Tool or the Exchange Calendar Update Tool. What this does - changes the Start and End times - which are in UTC/GMT (again, covered in previous post)

4. On computers with KB 931836 applied:
- Old appointments rebased, show up at the correct time
- If new appointments rebased wrongly, these show up one hour early

On computers without KB 931836 applied:
- Old appointments rebased, show up an hour early in Outlook
- New appointments (if) wrongly rebased, show up two hours early

Regardless of when rebasing is done, recurring items do not get rebased wrongly. These have the time zone embedded in the item which prevents them from being wrongly rebased by any of the rebasing tools.

Also note, appointments rebased once will not get rebased again when you run either tool.

DST 2007: Script to export Calendar items (before you rebase!)

MIIS (Microsoft Identity Integration Server) MVP Jason Sherry recently shared this script to export Calendar items, which should come in handy to export items from the affected "extended" DST period, before you start rebasing items.

In case something goes wrong during rebasing and appointments are off by an hour or two before or after their actual scheduled time, the output from this script should serve as a handy reference to determine the actual appointment times.

(Of course, as noted a few times earlier throughout my posts, adding the meeting time to the subject line of each meeting during this affected period should go *a long way* in "defending" yourself from any rebasing-related issues... however, the simplest solution is quite frequently the first one to be dismissed by many folks, including users and IT pros... - Bharat)


The script also has an option to disable Direct Booking of resource mailboxes while you rebase items. The account running this script should have Full Mailbox Access or Receive As permissions on mailboxes, (and just like requirements for the Exchange Calendar Update Tool - the account should not have Exchange Full Admin delegated to it, which creates a Deny ACE for Full Mailbox Access for the account).

The script uses MAPI, and like the rebasing tools - it should be run from a computer with Outlook installed.

Std. disclaimers from Jason: the script is a work in progress, please test in a non-production environment and use at your own risk.

Download ExportCalendar.vbs from here.

Download and read the documentation before you proceed.

DST 2007: Updating Front-End Servers

Another common question related to the DST updating process: do I need to do anything on my Front-End Exchange servers?

Front-End servers do need the Feb. 2007 Cumulative Time Zone Update (KB 931836), and the Exchange CDO patch (KB 926666 for Exchange Server 2003 SP2, KB 931978 for Exchange Server 2003 SP1).

When do we need to apply these? Preferably at the same time as the Back-End servers (during a scheduled maintenance window, the exact order shouldn't matter as much. Normally you apply any service packs or hotfixes to Front-End servers first).

Actual rebasing tools to modify Calendar items are run against mailboxes, so these can be said to be running against Back-End servers.

DST 2007: Heading into the weekend... list of relevant links

Some of us will probably be working on DST 2007 issues over the weekend.

Here's a list of some quick links to get you to relevant web pages for Microsoft KBAs, downloads, and BlackBerry DST 2007 resources.

(My list of DST 2007 posts can be accessed from the navbar link on the left side of this post - Bharat)

Windows OS Time Zone Updates:
1. 931836: February 2007 cumulative time zone update for Microsoft Windows operating systems, v6.5 date: 2/28/2007
Update 08/21/2007: KBA 931836 has been superseded by KBA 933360 August 2007 cumulative time zone update for Microsoft Windows operating systems. On 8/21/2007 this new KBA and the accompanying hotfix have been updated to include the following time zone changes:
Caucasus Standard Time: Display name changed, time zone changes removed
Armenian Standard Time: New time zone created
New Zealand Standard Time: DST start and end times changed because of new law passed in New Zealand after the Feb. 2007 Cumulative Timezone Update
GTB Standard Time: Display name for GTB Standard Time corrected to include Bucharest
Jordan Standard Time: Just like New Zealand, changes to DST start and end dates based on law passed after the Feb. 2007 Cumulative Time Zone Update was released.
2. 914387: How to configure daylight saving time for the United States in 2007 (For Windows 2000, WinXP RTM), v18.0 date: 2/28/2007

Exchange Server CDO Patches:
3. 926666: Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 2, v12.3 date: 3/2/2007
4. 931978: Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 1, v3.0 date: 2/20/2007

Rebasing Tools:
5. Microsoft Office Outlook Tool: Time Zone Data Update Tool for Microsoft Office Outlook
TZMOVE.EXE version 1.0 2/19/07 8.3 Mb
6. Microsoft Exchange Calendar Update Tool
v2.0 KB 930879, 2/21/2003, 253KB
7. 933146: Description of the hotfix package for the Time Zone Data Update tool for Microsoft Office Outlook, v1.1 date: 2/28/2007
8. DST Virtual Machine image v1.0 : Virtual Machine for Microsoft Exchange Calendar Update Tool (still v1.0 of the tool last time I checked - Bharat)
9. DST Update for Windows Mobile PocketPC

HOW TO Articles:
10. 930879: How to address daylight saving time by using the Exchange Calendar Update Tool
v17.0 date: 3/1/2007
11. 931667: How to address the daylight saving time changes in 2007 by using the Time Zone Data Update Tool for Microsoft Office Outlook, v9.0 date: 2/27/2007
12. Prepare Outlook calendar items for daylight saving time changes in 2007

Issues:
13. 932599: Information Store database does not mount with Event ID 9519 and 9518, v6.0 date: 2/28/2007
14. 930241: The Exchange 2003 database does not mount, and event IDs 9518 and 9519 are logged in the Application log – HOTFIX for same issue as KB 932599, v3.0 date: 2/23/2007
15. 912918: Users cannot send e-mail messages from a mobile device or from a shared mailbox in Exchange 2000 Server and in Exchange Server 2003, v13.0 date: 2/15/2007

Misc.:
16. Preparing for Daylight Saving Time changes in 2007, Last Reviewed: 2/26/2007
17. Exchange Server and Daylight Saving Time (DST) 2007 - Scott Schnoll

BlackBerry:
18. Daylight Saving Time 2007 resource page on BlackBerry.com
19. Updating your BlackBerry Environment to Support DST 2007 Changes (detailed PDF Doc on blackberry.com)
20. RIM "Set Send As" Permission tool
21. RIM's DST 2007 Query tool (queries BlackBerry database for hand-held device versions)

DST 2007: Clarification on using /ONLYCREATEDPREPATCH option

Update on the previous post titled "DST 2007: Hotfix for Outlook Calendar Update Tool", and the patched Outlook Calendar Update Tool (KB 933146) from PSS.

KB 933146 states:
We recommend that you do not use the /ONLYCREATEDPREPATCH command-line option with the Exchange Calendar Update Tool (MsExTmz.exe). The /ONLYCREATEDPREPATCH command-line option uses the local operating system as the basis for its logic. Therefore, all calendars would be rebased using the information from the computer where the Exchange Calendar Update Tool was run and probably would not apply to the user mailboxes that are being rebased.

However, you can use the /ONLYCREATEDPREPATCH option when rebasing items using the Exchange Calendar Update Tool (MsExTmz.exe).

An email clarification from PSS : When doing the above, you should ensure the computer that you're running the tool from has the Feb. 2007 Cumulative Time Zone Update (KB 931836) applied, or explicitly specify a UTC time. The tool will rebase Calendar items occurring in the affected extended DST period that were created before KB 931836 was applied to the computer (that you're running the tool from), or before the UTC time specified (if using it with the UTC time option).

Take aways from the above clarification:

- If using the former option (not specifying a UTC time), be aware that the tool will check the local computer's time zone and when the DST 2007 time zone update (KB 931836) was applied to that computer, not on the computer of the user whose mailbox is being processed.

- When using this option, depending on when the time zone update was applied to user workstations, all items may or may not get rebased correctly.

For instance,
i) If the time zone update was applied to a user workstation before you rebase Calendar items using MsExTmz.exe, and the user created new items after the time zone update was applied - those items will get rebased as well. Wrongly so in this case.
ii) If the user workstation does not have the time zone update, only items created before the time that the admin's computer got the time zone update will get rebased - leaving all appointments created after that time untouched.
iii) If specifying the UTC time with the option, appointments created before the time specified will get rebased, irrespective of whether they were created using the old time zone rules or the updated DST 2007 rules.

Where is TZMOVE.EXE?

Just installed the Outlook Calendar Update Tool and can't locate it in the Windows Start menu (All Programs, or in the Microsoft Office program group)?

After installation, the tool starts running and shows the start-up screen. If you've already run it once or chose to run it at a later time, here's where you'll find it on computers with Outlook 2003:
\Program Files\Microsoft Office\Office 12\Office Outlook Time Zone Data Update Tool

(On computers with Microsoft Office 2007 installed, you can also access the Outlook 2007 time zone tool from within Outlook | Tools | Options | Calendar Options | Time Zone | Change Calendar Time Zone)

DST 2007: Hotfix for Outlook Calendar Update Tool

As noted in previous post titled "DST 2007: Understanding what needs to be done and how to do it", Microsoft has released a hotfix for the Outlook Calendar Update Tool (aka "Time Zone Update tool for Microsoft Office Outlook").

This addresses some key issues mentioned in the previous post, and adds some new command line options:
1. Avoid rebasing single-instance items created after DST 2007 updates are applied to the OS: Again, as noted in my previous post, if users create appointments after the OS gets its DST 2007 time zone update but before existing items are rebased, such new single instance items also end up getting rebased - wrongly so. (The same does not apply to recurring items, which do not get rebased wrongly - as explained in the previous post - Bharat)

After this new hotfix is applied to the tool, it provides two options to avoid that:
- you can use the patched TZMOVE.EXE with /ONLYCREATEDPREPATCH option. The patched tool determines when the DST 2007 time zone update (KB 931836) is applied on the computer, and does not rebase any items created after that time.
- you can manually specify a time in UTC - the patched tool only rebases items created before that time. This is done using the /ONLYCREATEDPREPATCH switch with a UTC time (the cut-off time when the OS possibly would have received the DST 2007 time zone update) in the format yyyy-mm-ddThh:mm:ssZ, so it looks like the following:
TZMOVE.EXE /ONLYCREATEDPREPATCH:2007-03-01T18:00:00Z
(The above will rebase items created before 12:00 noon on March 1st, 2007. Since this uses the local computer's time zone, Microsoft recommends that you do not use this option when running the Exchange Calendar Update Tool).

2. Force rebasing of calendar items and suppressing meeting updates (that occur because rebasing changes the meeting times):
- Why do we need to force rebase appointments? Well, by default, the rebasing tool will only update meetings for which you (or rather, the account being used to run the tool) are the organizer. The force rebase actually forces updates of all appointments, regardless of who the organizer is.
- The options are /FORCEREBASESUPPRESSALLUPDATES - does not send meeting updates to anybody, or /FORCEREBASESUPPRESSEXCHANGEUPDATES - sends meeting updates only to invitees/attendees who are not in your Exchange Org.

3. Rebasing of Public Folder calendar items: You can now update Public Folders from the command line.

4. Rebasing of calendar items in folders other than the default Calendar folder, from the command line.

5. Do a what-if analysis!: The patched tool lets you use a new /REPORTINGMODE option, which simply logs any changes that would have been made if you ran the tool in Update mode. Now you can look at the Application log and determine if it would have picked up/rebased all the items that required rebasing, or if it would have missed anything.

More details in KB 933146.

DST 2007: Understanding what needs to be done and how to do it

As we head closer to March 11, which is when the extended Daylight Savings Time kicks in - 3 weeks earlier this time, thanks to the Energy Policy Act, here are answers to some more commonly asked questions.

This is not meant to be a comprehensive guide to DST 2007 (at least as of writing) - I have not covered details of how to run the Exchange Calendar Update Tool (MsExTmz.exe) in this post. The tool is covered quite well by Microsoft KnowledgeBase articles, in particular KB 930879: How to address daylight saving time by using the Exchange Calendar Update Tool, and posts on the Exchange team blog.

Microsoft has updated its guidance in the past few days, and the relevant Microsoft KB articles have been updated accordingly. Keep an eye on the date and versions of the KBAs you refer to. These now include a change log as well - thanks to the folks who thought of including this within the KBA for this time-sensitive issue.

In this post, I’ll talk about the relevant patches/updates and the tools made available by Microsoft. I’ll also take a look at how time works, how appointments are booked, what rebasing does, what specifically needs to be updated, and then go through the order of doing things. Needless to say, the exact order of doing things has many folks in different states of confusion, and as I write the guidance on that appears to have been locked in.

- Through the rest of this post, I will refer to calendar items as appointments - these can either be appointments created for yourself, or meetings where you invite others.
- I will also use the term Microsoft Outlook Calendar Update Tool to refer to the Time Zone Data Update tool for Microsoft Office Outlook, and once again request the marketing folks and product groups at Microsoft to coin names that are no longer than 2-3 words (4 words being the hard limit... :) - you could see the March 11 deadline for DST 2007 fly by you in the time it takes to say the Microsoft name for this tool.

1. KB 931836: February 2007 Cumulative Time Zone Update for Microsoft Windows operating systems:
What this does: Updates time zone information/rules in the Windows operating system. Windows stores time zone information in the registry. This updates those time zones, and tells the OS when the extended DST time will start and end in 2007 (amongst other things).
Operating Systems: Windows Server 2003, and Windows XP SP2.
What about Windows 2000 and Windows XP prior to SP2: These OSes are no longer in active support. Refer to KB 914387 - basically you'll have to hack the registry to update these OSes with DST 2007 time zone info.

2. Exchange Server CDO Patch: Exchange Servers have CDO installed. This is used by apps that use CDO - like OWA for instance, to perform functions like creating appointments. Third-party applications like RIM's BlackBerry Enterprise Server also use CDO. CDO has timezone information embedded in it. As such, it is important to update CDO on Exchange servers. There are 2 versions of the CDO patch available:
KB 926666: Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 2
KB 931978: Update for daylight saving time changes in 2007 for Exchange 2003 Service Pack 1
Note: Computers running Exchange System Management Tools also have CDO installed, as do app servers like RIM's BlackBerry Enterprise Server (BES). These need to be updated as well.

What about Exchange Server 2007? This is the latest version of Exchange, and it does not require any CDO updates. However, appointments in mailboxes on Exchange Server 2007 servers created using the old DST 2006 time zone rules will need to be rebased.

What about "legacy" Exchange versions, like Exchange 2000 for instance? These versions are not in active support as of now. You should contact your Microsoft Technical Account Manager (TAM)/rep to obtain any support or patches. Yes, there may be costs involved, and it's not the purpose of this post to delve into that, but I have commented about it in an earlier post. Apart from the CDO patch, appointments in mailboxes on these servers will also need to be rebased using either the Outlook or Exchange Calendar Update Tool.

3) The Tools: There are two tools made available by Microsoft.
i) Microsoft Outlook Calendar Update Tool/Time Zone Update Tool for Microsoft Outlook (TZMOVE.EXE): This is the tool that can be used by end-users to rebase their own appointments. We will get into rebasing in a moment.
Downloads: 1) Outlook Calendar Update Tool 2) Update: Hotfix for the Outlook Calendar Update Tool (KB 933146, Revision 1.1, Feb. 28, 2007). Allows force rebasing, rebasing Direct Booking resource mailboxes and Public Folders. Creates an item modification log.

ii) Microsoft Exchange Calendar Update Tool (MsExTmz.exe): This is the tool that can be run by administrators to rebase appointments for a bunch of mailboxes. It's important to note that you shouldn't install this tool on your Exchange servers, nor on computers running Exchange System Management Tools. It requires Outlook to be installed on the computer you run this from. The tool is a wrapper around the client tool TZMOVE.EXE - it calls TZMOVE and updates users' calendars as if they were running the client tool themselves, minus the UI that clients see which allows them to pick and choose which appointments to update.
Download: Microsoft Exchange Calendar Update Tool v2.0 (date: 2/21/2007, all of 253 Kb)

When you download the Exchange Calendar Update Tool, there's an automated configuration tool called MsExTmzCfg.exe that is also part of the package. What does this do? It walks you through the steps of extracting time zone information from mailboxes and creating the appropriate input files for the update tool to run. You can do without this one and configure everything manually, but this just makes it a lot easier, so it makes sense to use it.

How Time Works!

Now let's take a look at how time works, and the problem at hand.

- Time Zone definitions in registry: As noted earlier, time zone definitions, including details like when Daylight Savings Time (DST) will start and end, is stored in the registry.



- Coordinated Universal Time: Most time related stuff is done using what is known as Coordinated Universal Time or UTC. (No, the abbreviation is not CUT, and you can use any web search tools to find out why.... as a sidenote, this was formerly known as Greenwich Mean Time or GMT - both refer to the same time at longitude zero. The U.S. Naval Obeservatory site has more info on UT1, UTC and GMT. Not to veer too off-topic, UTC is not supposed to differ from UT1 by more than 0.9 seconds. For the purpose of this discussion, let's treat them as the same given the negligible difference.). Time servers that use protocols like Network Time Protocol (NTP) use this notion of a universal time that everyone and their computers can sync their clocks to.

- My Time Zone offset from UTC: Computers calculate local time as an offset to the UTC time, which can be trusted to be always accurate, regardless of what time zone you're in at the moment. UTC will remain the same.

If you remember setting up a Windows client or server OS, you may be familiar with the locale and time zone questions asked during setup. You can also view this by double-clicking the Windows clock and selecting the Time Zone tab. My time zone is Pacific Time, which during non-DST hours uses an offset of -8:00 from UTC. This means when the UTC time is 8:00 AM, my time is 8:00 AM - 8 hours = 12:00 AM (midnight).



Creating Appointments in Microsoft Outlook

When you create an appointment in Microsoft Outlook, it is created using UTC, which is calculated using the Time Zone information in the registry that would be in effect during that time (e.g. 4:30 PM PST = 4:30 + 8:00 time zone offset = 12:30 A.M. UTC). Before 2007, we have been used to seeing Windows update its time automatically when the time zone rules change - twice a year, as it will this year as well.

Recurring and Single-Instance Appointments: There are two types of appointments as far as Outlook is concerned - those that occur only once, also known as Single-Instance appointments, and those that occur regularly - let's say every week, starting from a particular date and ending on a particular date, called Recurring appointments. Versions of Microsoft Outlook prior to Outlook 2007 have handled these differently.

- Recurring Appointments save the time zone information within the appointment. This makes it much easier to figure out which time zone rules (DST 2006 or DST 2007 for instance) were used to create those appointments.
- Single Instance Appointments: These appointments, which only occur once, do not have any time zone information saved in them.

Additionally, it's important to note that as stated earlier, all time stuff works (or should work) based on UTC time. Both recurring and single-instance appointments are saved using UTC time.

The following screenshot shows MAPI properties of a recurring meeting that occurs at 4:30 PM PDT on March 12th. As you can see, the start and end times are UTC - 12:30 AM - 1:00 AM on March 13th! Single-instance meetings look somewhat similar - besides the recurrence, they don't have the TimeZone saved in the item as recurring meetings do.



How Outlook renders an appointment on your Calendar: When you view a Calendar in Microsoft Outlook, it looks at an appointment's Start and End times - and as the screenshot above shows, those are in UTC. It then looks up the time zone information from the registry of your computer, and determines your time zone's offset from UTC - let's say UTC -8:00, and renders the appointment at 4:30 PM on your Calendar. This allows folks from different time zones to schedule meetings with each other, and ensure those meetings show up at the correct local times in their time zone, not at 4:30 PM for everyone.

Dealing with DST: If the appointment were to occur at 2:00 PM during normal DST hours - which used to start on the first Sunday in April, Outlook would look up the DST rules in registry and be able to determine that. As a result, it would still show the appointment at 2:00 PM on that date - it would know that come first Sunday in April, the time zone offset from UTC would be -7:00 and not -8:00.

The good part is, we are used to dealing with this change every year, so it's not something unknown, like the Y2K bug. Further, it's not really a software bug as such - at some point the United States Congress decided it was a good idea to move the clock forward by one hour (i.e. UTC -7:00 for those in Pacific time zone, known as Pacific Daylight Time) three weeks ahead of time (and also move the clock backward by one hour - i.e. UTC -8:00 for Pacific time zone, known as Pacific Standard Time - a week later than usual), so we have more daylight and hopefully we'll end up using less energy. All well-intentioned stuff, I'm sure. What IT folks would have to go through to make this transition wasn't something that was on their minds at that point. :)

DST 2007: So, come March 11th, we will move our clocks forward by an hour. The Pacific Daylight Time, which would have otherwise started on April 1st this year, will start on March 11th instead. Similarly, it will end a week later - on November 4th this year, instead of October 28th. What are the implications of this?

1. Tell Windows operating sytems about this change occurring 3 weeks sooner and ending a week later. This is what the Feb. 2007 Cumulative Time Zone Update does, for Windows Server 2003, and for client operating systems like Windows XP SP2.

2. Rebasing Appointments: With the above in place, we should be OK, shouldn't we? Well, not really! This will work for all new appointments that we create using Outlook, but it does nothing for the existing appointments that we've already created using the DST 2006 rules, which assume DST will start on the first Sunday in April, as usual.

We will need to go back to all our appointments we created in our Calendars, and update them with this change. This process is called "rebasing".

In the above instance, (before rebasing) our appointment at 4:30 PM on 3/12 had a start time of 12:30 AM to 1:00 AM UTC on 3/13. Using DST 2006 rules, that would be rendered using UTC -8:00, and show up at 4:30 PM. However, after updating our computer's time zone for DST 2007, we would be at DST -7:00 on March 11, and the appointment would've been rendered at 5:30 PM instead. The following screenshot shows how rebasing the appointment adjusts the start and end times so it gets rendered correctly - the start and end times were changed to 11:30 PM on 3/12 and 12:00 AM (midnight) on 3/13 - UTC.



Let's take a look at what appointments will look like when created from a computer that has (old) DST 2006 rules, and how they will be rendered by Outlook once you do apply KB 931836 DST 2007 time zone update to the OS.


Click here to see the complete image if it's cut-off.

As you can see, appointments created on a computer with the old rules appear an hour behind on the computer with DST 2007 time zone rules.

After rebasing these appointments, here's how Outlook will render them:

Click here to see the complete image if it's cut-off.

The reverse is true if appointments are created by users with new DST 2007 rules, but are viewed by meeting invitees or the organizer on computers with old DST 2006 rules.

Let's walk through the rebasing process and the impact it has. We will use the Outlook Calendar Update Tool (TZMOVE.EXE) for this exercise - the Exchange Calendar Update Tool also calls this client tool to actually perform the updates.

1. Install TZMOVE.EXE on a computer with DST 2007 time zone update (KB 931836) applied


2. TZMOVE finds appointments.



Notes:
- Recurring meeting using new DST 2007 time zone at 12:00 PM does not get picked up by the tool - recurring meetings have time zone info embedded, the 12:00 PM meeting was created using the correct DST 2007 time zone.
- The old recurring meeting created using DST 2006 time zone does get picked up, and will get rebased.
- The single-instance meeting at 9:00 AM created using DST 2007 rules also gets picked up and rebased!

How long should you wait before applying the DST 2007 time zone update to all client computers and rebasing appointments. If you wait too long, here's what could happen - clients will inadvertently end up creating new appointments in the affected extended DST period using the new DST 2007 rules. When you rebase, these appointments get rebased as well. Here's what this could look like after rebasing:

Click here to see the complete image if it's cut-off.

Update: The Outlook Calendar Update Tool can be patched with a new hotfix (KB 933146) discussed earlier in this post. The patched tool can then detect when the OS was updated with DST 2007 time zone info and only rebases appointments after that time, using the /ONLYCREATEDPREPATCH command line parameter. Alternatively, only appointments created before a certain date & time - expressed in UTC - can be rebased, using the /ONLYCREATEDPREPATCH:(utc time here) command line parameter.

The take aways from this:

1) Once new time zone rules are applied on client computers, we will need to rebase the old appointments so they are rendered in the correct time slot by Outlook.
2) Any new appointments created on an updated computer (with DST 2007 rules) should not be rebased

3) To avoid #2, it's best to rebase appointments as soon as users get the DST 2007 time zone update applied on their computers (else they may create new appointments using new DST 2007 rules before rebasing is done, which may result in the newer appointments being rebased wrongly!)

4) As seen in the above examples, simply having users insert the correct time in the meeting subject makes these appointments stand out if they're off by an hour or two - if possible, have your users do this. It will be of great help in getting through this process.

5) Going a step forward, at least for important users like execs, have their assitants or the users themselves print out their calendars for this extended DST period (3 weeks from March 11 to April 1, hopefully you would have worked out the kinks by the time you get to the end of the DST period in the last week of October.

Which items will we rebase? Appointments created using old DST 2006 rules that occur during this "extended" DST period, which is the 3-week period prior to the first Sunday in April (i.e. March 11 - April 1), and the 1-week period between the last Sunday in October to the first Sunday in November (October 28th - November 4th).

Where do these items reside?
1) The default Calendar folder in user mailboxes on Exchange Server
2) Other "non-default" Calendar folders or sub-folders in user mailboxes
3) Perhaps in PST files, if users use them. Important to note that Exchange knows nothing about content in your PST files.
4) In Public Folders, if you have created any to store appointments.
5) Resource Mailboxes: Resource mailboxes are mailbox-enabled user accounts created for booking resources like conference rooms, projectors, et al. These are set up to be booked automatically when users invite them to meetings as resources. When rebasing appointments, if a resource is booked back-to-back, the rebased appointments will conflict with other appointments on the calendar through the rebasing process. It makes sense to configure them to accept these conflicts during the rebasing process.

There are two ways resource mailboxes can be setup:

- Direct Booking: If using Direct Booking, an admin logs into a resource mailbox using Microsoft Outlook, and sets it up to a) Accept meetings automatically and b) automatically decline conflicting meeting requests. During rebasing, we should configure resource mailboxes to not decline conflicting meeting requests, by unchecking the latter, as shown below:



The patched (with hotfix in KB 933146) Outlook Calendar Update Tool (TZMOVE.EXE) should be run using the /FORCEREBASESUPPRESSALLUPDATES command line parameter against resource mailboxes that are configured for Direct Booking. Once rebased, you can revert the resource mailbox configuration to decline conflicting meeting requests.

- Using the Auto-Accept Agent: The Auto-Accept Agent is an add-on server-side tool that Microsoft released as a web download after the release of Exchange Server 2003. Unlike using Direct Booking (as shown above), which uses the resource's Free/Busy information, the Auto-Accept Agent actually looks up the resource mailbox' Calendar to determine if a resource is available or not. It also has additional functionality like stripping attachments, dropping non-calendar items, amongst other things. The Auto-Accept Agent uses an xml file for configuration - AutoAccept.config.xml. By default, this resides in \Exhsrvr\Agents\AutoAccept.

The patched Outlook Calendar Update Tool (TZMOVE.EXE) should be run using the /FORCEREBASESUPPRESSALLUPDATES command line parameter against resource mailboxes that are registered with the Auto-Accept Agent.

3. Updating Exchange Servers: Next, we will need to go and update our Exchange Servers. They will need the new time zone update rules for Windows Server OS (KB 931836), and the Exchange CDO patch - depending on the version of Exchange Server you're on (KB 926666 for Exchange 2003 SP2, KB 931978 for Exchange 2003 SP1, and as stated earlier - patches for any previous versions of Exchange that may be in use in your organization, if you 've obtained them from Microsoft).

The Order!

Having talked about the issues, and I hope you understand them by now, let's take a look at the order of doing things. The guidance related to this has evolved and changed over the past few weeks and days. With that in mind, let's look at the order that Microsoft recommends we make these changes in, going by the recent guidance.


1. Update Windows Servers (update: including Exchange servers) and Windows client operating systems with the February 2007 Cumulative Time Zone Update (KB 931836 for Windows Server 2003 and Windows XP SP2).
2. Rebase Appointments
3. Exchange Servers: Apply the Exchange CDO patch to update the time zone embedded in the CDO components on Exchange servers (KB 926666 for Exchange Server 2003 SP2, KB 931978 for Exchange Server 2003 SP1)

Applying Mailbox Manager policies to a sub-folder

When you create a Recipient Policy to apply Mailbox Manager settings [for reference, read KBA 319188 "How to use recipient policies to control mailboxes in Exchange 2000 and Exchange 2003"], the policy properties include the default mailbox folders like Inbox, Sent Items, Deleted Items, et al. You can apply the policy to additional folders by clicking the Add button and adding a folder. However, applying a policy (e.g. to delete items older than a certain number of dates) to a particular folder does not apply this to a sub-folder. For instance, if you apply the policy to the default folder Inbox, it does not apply to any sub-folders of the Inbox folder.

I ended up testing this in response to a newsgroup question this morning. There's no relevant info in the online help or any KBA that I could find.

To apply Mailbox Manager policy to a sub-folder - in this case, a sub-folder called Spam in the default folder Inbox - click the Add button and type: Inbox/Spam.


Related Posts:
- Recipient Policies: Can separate policies for Email Addresses and Mailbox Manager Settings be applied?
- Exchange 2000/2003 Mailbox Manager and msExchMailboxManagerAgeLimit
- Exchange Server 2007: Why aren't Managed Content Settngs applied?

Exchange Server 2007: Cross-Mailbox Search Using Export-Mailbox

Exchange Server 2007 includes the much-required feature that allows you search for and export messages to another mailbox. You can search all mailboxes for messages with particular keywords and export those messages to a separate mailbox, which can then be accessed by compliance/legal folks who need access to such messages.

Another scenario where this feature comes in handy: being able to delete infected messages across all mailboxes.

The Export-Mailbox command exports messages with user-specified keywords in the message subject or body to a specified folder in a mailbox. Kumar Cunchala from the product team talks about how to do cross-mailbox searches on the team blog.

Before you ask, there's no support for exporting these messages to a PST file yet (Update: This was added in Exchange 2007 SP1). You could, of course, connect to the mailbox to which you export these messages and manually copy stuff to a PST using Outlook.

Update - HOW TO: Find an email address in Active Directory

An update to the earlier post on HOW TO: Find an email address in Active Directory (Note: Content from this post has been merged with the previous post, simply click on this link to see the roll-up post on finding email addresses), which shows how to find a recipient with a particular email address using ADUC's Saved Queries feature.


Using CSVDE/LDIFDE to find an email address: Saved Queries isn't available in the Windows 2000 version of ADUC. You can also use CSVDE or LDIFDE to export this information to a file, using the following command:

csvde -f outputfilename.csv -d "dc=domain,dc=com" -r "(&(mailnickname=*)(proxyAddresses=smtp:foo@domain.com))" -l name

Replace "dc=domain,dc=com" with your AD domain name and suffix, and foo@domain.com with the exact email address you're looking for.

To find all recipients who have an email address from a particular SMTP domain, you can use a wildcard, e.g.:

csvde -f outputfilename.csv -d "dc=domain,dc=com" -r "(&(mailnickname=*)(proxyAddresses=smtp:*@domain.com))" -l name

In the above example, only the name field is exported. All CSVDE/LDIFDE queries also return the object's distinguishedName. To add more fields to the list, insert a coma after name and type new field names separated by a coma: e.g.

name,displayName,sAMAccountName,proxyAddresses,homeMDB

Finding email addresses using the Exchange shell (Exchange 2010/2007): The Exchange Server 2007 shell makes it easier (once you familiarize yourself with shell basics). To get a list of all recipients with email addresses from a particular domain:

get-recipient | where {$_.emailaddresses -match "domain.com"} | select name,emailaddresses

To get a list of recipients with a particular email address:

get-recipient | where {$_.emailaddresses -match "foo@domain.com"} | select name,emailaddresses

Changes:
01/03/2007: Changed title, added Update to differentiate from previous post with same title
12/03/2007: Content from this post merged into the previous post HOW TO: Find an email address in Active Directory.

HOW TO: Modify Display Template to make default email address appear in Address Book/GAL

This was an interesting question posed in exchange.admin today, and it's been a long while since I made such changes so it took a while to figure this out.

When you go to a recipient's properties in GAL/Address Book in Outlook, the (default) email address - something you want to find quickly and many a times cut & paste somewhere - does not show up on the General tab. When you go to the E-mail Addresses tab, you see all the recipient's email addresses - these reside in the proxyAddresses attribute of the recipient. The default address appears with an uppercase SMTP:. However, you can't cut and paste anything from this tab.

To modify how these things appear, you need to modify the Display Templates. This topic in general isn't documented very well or as extensively. The Exchange Server 2003 Administration Guide has a little HOW TO procedure documented here.

So let's get this done!

Open Exchange System Manger | Recipients | Details Templates | English (or choose your locale here) | User [screenshot] | right-click | Properties.

Display templates contain a "Label" - which is the text displayed next to the field, and the actual field itself which displays the data. The location of these objects on the actual form that's displayed to the user is also shown as X and Y co-ordinates.

Locate the Alias field - the Label for this is called A&lias (X,Y = 189,30). The & tells the UI that the next character is to be used for the keyboard short-cut. Change this to E-&mail:

Next, locate the accompanying field at location X=259, Y=28 - it's an Edit field, and it shows the attribute ms-Exch-Mail-Nickname [screenshot]. You need to change this to the attribute "mail" - which is the default address of the recipient.

Here's what threw me off - the UI doesn't list the ldapDisplayNames of attributes! The ldapDisplayName mailNickname logically maps to the ms-Exch-Mail-Nickname attribute. But I could not find anything in the list that would logically map to the "mail" attribute.

I ended up using LDIFDE to dump the attribute with ldapDisplayName=mail - it is called E-mail-Addresses. Going by the name of the attribute, one would think this is for proxyAddresses - there's only one default email address that shows up in the "mail" attribute, and the attribute itself isn't multi-valued!

So, let's go ahead and complete this by selecting E-mail-addresses [screenshot] instead of ms-Exch-Mail-Nickname.

Once you're done, you can click on the "Test" button to see how it looks.

You would need to make this change to other recipient types - like Group, Public Folder, and Contact. Alternatively, in the templates where you do see extra space, you could perhaps add these as additional fields if you still want to show the Alias.

If your Exchange Org includes servers in different locales with different languages, you will need to make the above change(s) in the Display Templates for all of these.

Cached mode Outlook 2003 clients will see the change once the Offline Address Book is rebuilt - you can do this manually from ESM - right-click on the OAB - select "Rebuild". Go to the Outlook 2003 client and download the Address Book. Now select a recipient from the Address Book and go to properties | General tab. The Alias field is now replaced with E-mail [screenshot]

Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell

Bulk creation of mailboxes (and the accompanying user accounts) in Exchange Server 2003/2000 involved some elaborate scripting effort. This task can now be done fairly effortlessly, thanks to the Exchange Management Shell (EMS). The shell can very easily import/use CSV files saved from a spreadsheet or text editor and create the mailbox-enabled users. Here's how.

Create a spreadsheet (or you can use a standard text editor like Notepad to create a CSV file) with the following columns. You can add more fields if you wish:
Alias,Name,UPN

Add data for new accounts in following lines/rows. Here's what it'll look like:
Alias,Name,UPN
User_One,User One,userone@yourUPNsuffix.com
User_Two,User Two,usertwo@yourUPNsuffix.com
User_Three,User Three,userthree@yourUPNsuffix.com

Save the file as CSV - let's call it CreateRecipients.csv

Now fire up Exchange Management Shell and issue the following command:

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

This will prompt you for a password. The same password will be used as the initial password for all your mailbox-enabled users.

Next, issue the following command:

Import-CSV CreateRecipients.csv | foreach {new-mailbox -alias $_.alias -name $_.name -userPrincipalName $_.UPN -database "Mailbox Database" -org Users -Password $Password}

This will create the user accounts and mailboxes.

Here's how the shell interprets the above command:
Import-csv CreateRecipeints.csv gets data from the CSV file.

- The filename should be enclosed in quotes if you're providing the complete path with spaces, e.g. "c:\My Scripts\CreateRecipients.csv".
- If you're not running the command from the same directory (folder) where the CSV file is located, you will need to provide the complete path to the file.

- The | pipes the data from the CSV to the next command.
- foreach parses through each line in your CSV file, using the first row as a header. All the column headings/names get treated as field names.
- The new-mailbox command, as you may already know by now, creates a new mailbox-enabled user.
- For each variable, you either enter a value at the command line (for instance, we're using the value "Mailbox Database" for the Store), or you can pick up the value from your CSV file provided you have a column for it with a heading. For instance, for the -alias field, we use $_.alias - which tells the script to look for the column called alias in your CSV file and pick up the value from the current row or line.

If running the command on the same server where you want to create the mailboxes, you can simply use the Store name, e.g. "Mailbox Store". To create mailboxes on another server's Store(s), you can use either ServerName\Store, or ServerName\StorageGroup\Store, or even the GUID of the Store. How do you get those??? Use the Get-MailboxDatabase commandlet.

- The -org field stands for OU (or Container) you want to create the accounts in. If all the accounts you create from the CSV file will reside in the same container or OU, you can provide this at the command-line, as we did in the example above. Alternatively, you can include the OU/Container name in your spreadsheet/CSV file in a field - let's say OU - and modify your command to say: -org $_.OU
Note: Luckily you do not need to provide the distinguishedName of the OU or Container - simply the name of the OU or Container works.
- The -password field picks up the password from the variable called $password that we created earlier.

The new-mailbox command allows you to enter a lot of attributes for each mailbox-enabled user. These are documented here and also in the Exchange Server 2007 online help. For each attribute you want to populate, add it to your spreadsheet/CSV file.

Updates
July 9, 2007: To create new mailboxes with settings based on an existing mailbox, use the following commands:

$Template = Get-Mailbox "Template Mailbox"
Import-CSV CreateRecipients.csv | foreach {new-mailbox -alias $_.alias -name $_.name -userPrincipalName $_.UPN -database "Mailbox Database" -org Users -Password $Password -templateinstance $Template}

New Exchange fixes change permissions model, may disrupt Blackberry, Goodlink, and other services

A recent change in the Exchange permissions model may disrupt Blackberry, Goodlink and other services. Many folks may have already applied hotfixes that changed the behavior of "Send As" and "Full Mailbox Access" permissions. Here's a brief overview.

What: Separation of "Full Mailbox Access" and "Send As" permissions.

Why: Earlier, users with "Full Mailbox Access" permission on a mailbox were implicitly provided the "Send As" permission. This allowed them to send mail as that user. Services like Blackberry Enterprise Server and Goodlink commonly use Full Mailbox Access to be able to send mail as a user. This was a security issue for many customers and the permissions needed to be separated. With this change, users/services will now explicitly need "Send As" permission on a given user's mailbox to be able to send as that user.

Which versions: The above change was applied to the STORE.EXE file. You can tell by the version of STORE.EXE - if the version you have is equal to or later than the following, this change has already been made in your environment.
- Exchange 2000 SP3: version 6619.4 or later (first made available in hotfix KB 915358)
- Exchange 2003 SP1: version 7233.51 or later (first made available in hotfix KB 895949)
- Exchange 2003 SP2: version 7650.23 or later (first made available in hotfix KB 895949)

(Note About Today's Security Bulletin MS06-019: The security patch released today in Microsoft Security Bulletin MS06-019 also contains this fix for Exchange Server 2003 SP1. If you use Microsoft Update on your Exchange Servers, this will be applied as part of critical fixes. If you're on Exchange Server 2003 SP2, the SP2 version of the patch does not update Store.exe).

Do I need to do anything?: If your users or accounts used by services like Blackberry or Goodlink need to impersonate the user and use the "Full Mailbox Access" permission to do so, they will need to be assigned "Send As" permission explicitly.

Microsoft has included a script in KB 912918 that will dump all user accounts that have "Full Mailbox Access" permission. You can browse through the list and determine if any of those accounts need to impersonate users and therefore explicitly require "Send As" permission. You can then use the script to assign "Send As" permission to those accounts.

Are there any exceptions?: Yes, indeed. The following are exceptions where "Send As" permission is not required:
- the mailbox owner does not require "Send As" permission on its own mailbox
- Associated External Account - typically used in cross-Forest scenarios and while you're in mixed-mode with accounts in a NT 4.0 domain and Exchange in an AD Forest
- a delegate account that also has "Full Mailbox Access" permission

IMF: How to exclude recipients from IMF filtering

Microsoft recently released a hotfix for Intelligent Message Filter that adds functionality to exclude certain recipients from IMF filtering using an exclusive list, or only apply IMF to certain users using an inclusive list. The latter should be great for limited testing in a production environment.

You do need to call Microsoft PSS to get the hotfix mentioned in KBA 912587. This updates MSGFILTER.DLL to version 6.5.7650.22.

With the hotfix applied, you need to fire up regedit and
- create a new key called ContentFilter in HKLM\Software\Microsoft\Exchange.
- create a new DWORD value called CheckRecipients
- if you want to use an exclusive list - which means messages IMF will bypass (not scan) the message if ALL recipients in the message are on the list, modify CheckRecipients DWORD value you just created and type 2 in Value data
- Create a new Multi-String value called RecipList - and add names of recipients you want to exclude from IMF filtering.

Again, the emphasis is on all recipients - if there's a single recipient of a message not on the exclusion list, it will get scanned by IMF.

To do the opposite - create an inclusive list - change the value of CheckRecipients to 1, and add names of recipients who would like to get their messages filtered by IMF to the RecipList value.

It is not required to restart the server after you apply this hotfix.

Note: Calling PSS for required hotfixes that resolve particular issues is free. Just have the KBA number handy!

HOW TO: Reconnect a mailbox to another user

I've come across this question enough number of times that it makes sense to list the steps here and include a little Flash demo.

Scenario: UserA has a mailbox. User leaves the organization. UserB joins. You need to create a new user account for UserB, and have it connect to UserA's mailbox. (Or any situation similar to this where you want mailbox from one user to be assigned to another user. This is different from providing UserB the ability to open UserA's mailbox as an additional mailbox - which simply requires Full Access permission to UserA's mailbox.)

Delete the user's mailbox from AD Users & Computers. Right-click the user account | Exchange Tasks | Delete Mailbox. No need to worry about the data - we're not really deleting the mailbox, just disconnecting it from UserA.

Run the cleanup agent in Exchange System Manager. Expand the Store where the mailbox resides | right-click Mailboxes | click Run cleanup agent.

This marks all disconnected/orphaned mailboxes with a red cross icon superimposed, as shown in the screenshot below.



Now you can reconnect the disconnected mailbox to another user account that isn't (already) mailbox-enabled.
- Right-click the disconnected mailbox | click Reconnect.
-Type in the name of the user you want to reconnect it to, or click Find and look for the user.

More about disconnected mailboxes
Q. What happens to the disconnected mailboxes if they're not reconnected?
A. The mailbox clean-up agent runs and marks a mailbox as disconnected/deleted.
By default, the MDB is configured to retain deleted mailboxes till 30 days. This makes it easy to recover any mailboxes disconnected/deleted accidentally. If deleted mailbox retention is disabled, the mailbox is purged from the database.

An exception to this rule - if the MDB is configured to not purge deleted mailboxes till the store is backed up, the mailbox lives beyond the retention period, until a backup is completed successfully.

Related posts and links:

• Configuring Deleted Item Retention
  

HOW TO: Find an email address in Active Directory

Every once in a while you try to assign a particular address to a recipient in AD Users & Computers, only to be told someone already has that address! Email addresses need to be unique - two recipients cannot have the same email address.

Here are a few different ways to find out whether an email address is assigned, and the recipient it belongs to.

Resolve Recipient: Create a new message in Microsoft Outlook, enter the email address. Press CTRL-K. If the recipient is not hidden from Address Lists/GAL, the email address resolves to the Display Name.

Request Delivery Receipt: If the recipient is hidden from Address Lists, send a message to it with a Delivery Receipt requested.

ADUC Saved Query: In AD Users & Computers (on Windows Server 2003), right-click Saved Queries container | New | Query.
- Enter a name for the query, and click the Define Query button
- From the Find drop-down - select Custom Search | go to Advanced tab
- In the Enter LDAP Query text box, enter the query:

(proxyAddresses=smtp:postmaster@exchangepedia.com)

This returns recipients of all types - users, mail-enabled contacts, public folders, and groups that have the address postmaster@exchangepedia.com.

Click here to see a Flash demo. [Link updated]




 Using CSVDE/LDIFDE to find an email address: Saved Queries isn't available in the Windows 2000 version of ADUC. You can also use CSVDE or LDIFDE to export this information to a file, using the following command:

csvde -f outputfilename.csv -d "dc=domain,dc=com" -r "(&(mailnickname=*)(proxyAddresses=smtp:foo@domain.com))" -l name

Replace "dc=domain,dc=com" with your AD domain name and suffix, and foo@domain.com with the exact email address you're looking for.

To find all recipients who have an email address from a particular SMTP domain, you can use a wildcard, e.g.:

csvde -f outputfilename.csv -d "dc=domain,dc=com" -r "(&(mailnickname=*)(proxyAddresses=smtp:*@domain.com))" -l name

In the above example, only the name field is exported. All CSVDE/LDIFDE queries also return the object's distinguishedName. To add more fields to the list, insert a coma after name and type new field names separated by a coma: e.g.

name,displayName,sAMAccountName,proxyAddresses,homeMDB

 Finding email addresses using the Exchange shell (Exchange Server 2007): The Exchange Server 2007 shell makes it easier (once you familiarize yourself with shell basics). To get a list of all recipients with email addresses from a particular domain:

get-recipient | where {$_.emailaddresses -match "domain.com"} | select name,emailaddresses

To get a list of recipients with a particular email address:

get-recipient | where {$_.emailaddresses -match "foo@domain.com"} | select name,emailaddresses

Related Post(s):
1. Update - HOW TO: Find an email address in Active Directory
12/3/2007 - Content from the UPDATE post has been merged with this post to make it convenient for readers.
2. HOW TO: Export all email addresses from a domain

SCRIPT: Reset Mailbox Limits

I had posted a script that reports all users with their mailbox storage limits set individually on the user account properties in my earlier post titled "SCRIPT: Show mailbox limits".

I have just added another script to that post that will reset those mailboxes (with storage limits set individually). Once the script resets storage limits on the account, the account will get any mailbox storage limit policies.

File: ResetMailboxLimits.zip

Readme from the script:
This script will look for all user accounts that have their mailboxstorage size modified individually.
This includes accounts that have **any** following attributes:- Use mailbox store defaults is unchecked- Issue warning at (KB) is set- Prohibit send at (KB) is set- Prohibit send and receive at (KB) is set

Usage: resetmailboxlimits.vbe
Options:
/s:y will run script in silent mode (make sure you use the /f option to save output to a file if you're using silent mode
/f:[path to output file.txt] - will save output in a text file
/help
This example runs the script in silent mode and saves output in output.txt in c:\somedir

resetmailboxlimits.vbe /s /f:c:\somedir\output.txt

New user does not show up in GAL

Scenario: You’ve created a new user (or any Exchange recipient that should show up in Exchange Address Books/GAL), but the recipient does not show up in the GAL in Outlook.

Are you using Outlook 2003/2007 in Cached Mode?

If yes, login using Outlook Web Access and try to send the user an email. Does the name resolve?

If yes, it’s most likely related to the Offline Address Book (OAB) not being updated.

In Cached Mode, Outlook 2003/2007 clients use the Offline Address Book to lookup recipients. By default, Exchange generates the Offline Address Book once a day at 4:00 AM. New recipients do not show up in the OAB till Exchange updates it.


Figure 1: By default, Exchange updates OABs once a day at 4:00 AM

The options:
Rebuild the OAB
Exchange Server 2003:
- In ESM | Recipients | Offline Address Lists | right-click YourAddressListName | select Rebuild


Figure 2: Rebuilding the OAB

Exchange Server 2007:
In Exchange Server 2007, the OAB can be updated using the following command from the shell:

Update-OfflineAddressBook "Name of Address Book"

To update all OABs:

Get-OfflineAddressBook | Update-OfflineAddressBook

- On the client go to Outlook 2003/2007 | Tools | Send/Receive | Download Address Book….
- Uncheck Download changes since last Send/Receive
- Make sure Download Full Details is checked
- Click OK, wait for the download to complete (depending on your bandwidth and size of OAL, this may be close to instant, or it may take a few minutes)
- Check if the user appears in the GAL

Modify the OAB generation schedule: The OAB update interval can be modified to have Exchange update it more frequently, depending on your environment.

Alternatively, you can wait till after Exchange has updated the OAB.

Related Posts:

• Offline Address Book: Mystery of The Missing Recipients
  
• HOW TO: Modify Display Template to make default email address appear in Address Book/GAL
  
• Modifying Display Templates and additional attributes
  
• HOW TO: Hide Distribution Group membership
  
• HOW TO: Find an email address in Active Directory
  
• HOW TO: Export all email addresses from a domain

Updates:
- 01/03/2008: Added screenshots and Exchange Server 2007-specific info
- 10/02/2008: Typo corrected in command

SCRIPT: Show mailbox limits

At times the user's mailbox limits are adjusted to bypass the limits set on a store or all stores by a policy. This is done by unchecking 1) "Use mailbox store defaults" in user's properties --> Exchange General --> Storage Limits.

New values can be added for 2) "Issue warning at (KB):", 3) "Prohibit send at (KB):", and 4) "Prohibit send and receive at (KB):" fields.

The corresponding attributes in AD are:

1. mDBUseDefaults
   
2. mDBStorageQuota
   
3. mDBOverQuotaLimit
   
4. mDBHardQuotaLimit

Unchecking number 1 and not adding any values to 2, 3 & 4 result in user having a mailbox with no limits.

Here's a script that lists all mailboxes that have their limits changed to bypass store defaults (mDBUseDefaults=FALSE), and lists the 3 attributes above if present.

File: showMailboxLimits.zip

Usage:

showMailboxLimits.vbs /f:outputfilename.txt

adding a /s:y suppresses console output

Output produced is comma separated, can be opened in a spreadsheet.

Update:
1/17/2007: New script that shows mailbox quotas for all users, including those applied by the Store and any System Policies that may be applied to the Store:
" SCRIPT: Show mailbox quotas (including Store & Policy quotas)"

List users with email forwarding enabled

Here's a script written in response to a newsgroup post today on microsoft.public.exchange.admin.

Exchange Server allows you to forward inbound mail for one recipient to another recipient. You can forward messages to the alternate recipient, without delivering a copy to the original recipient (effectively redirecting inbound mail for the recipient), or deliver messages to both original and alternate recipients.


Figure 1: Exchange 2003 allows you to forward mail for one recipient to another recipient using Delivery Options

In Exchange 2003, this is accomplished using Delivery Options from ADUC | Exchange General tab. To forward to an external email address, create a (mail-enabled) Contact in AD.

In Exchange 2007, Delivery Options is found in the Mail Flow Settings tab in a recipient's properties in EMC.

Listing Users With Forwarding Enabled
Requirement: List users with email forwarding enabled.
Using Saved Queries: On Windows Server 2003, this can be easily accomplished using Saved Queries. Create a new query. From the Find drop-down, select Custom Search. In the Advanced tab, type the following LDAP query:
(&(mailNickname=*)(altRecipient=*))


Figure 2:You can view recipients with forwarding enabled using ADUC's Saved Queries feature

The other half of the requirement is to actually list the name of the user/mailbox being forwarded to. This is something ADUC can't do - there's no choice to add and display the altRecipient in a column next to each user.

The script will show all mailboxes setup to forward to an alternate recipient, the recipient being forwarded to (altRecipient), and also if messages are being delivered to both — the original recipient's mailbox and the alternate recipient.

File: ListForwardingEnabled.zip

In Exchange 2007, you can easily list this information using the shell:

Get-Mailbox -Filter {ForwardingAddress -ne $null} | ft Name,ForwardingAddress,DeliverToMailboxAndForward -Autosize

As reader Charles Howard points out in the comment (dt. Jan 29, 2009), the ForwardingAddress is output as the AD object (john smith domain.net\contacts\someguy) instead of the SMTP address. The following command can output the PrimarySMTPAddress of the recipient:

Get-Mailbox -Filter {ForwardingAddress -ne
$null} | foreach {$recipient = $_; $forwardingsmtp = (Get-Recipient $_.ForwardingAddress).PrimarySmtpAddress; Write-Host $recipient.Name, $forwardingsmtp, $recipient.DeliverToMailboxAndForward }

Updates:
- 11/25/2008: Added Exchange 2007 info and command
- 2/1/2009: Added command to output primary SMTP address of recipient being forwarded to.

HOW TO: Export all email addresses from a domain

Background: AD Users & Computers UI lets you list the mail column for each object, which displays the default (SMTP) email address for objects. You can export the list from ADUC as csv/txt. However, any additional email addresses in the proxyAddresses attribute are not exported.

There's no GUI to list/export all email addresses. Here's a script to do that - ListEmailAddresses.vbs.

File: ListEmailAddresses.zip

What does it exactly do?
- Queries Active Directory for Contacts & Groups
- Lists their email addresses
- Queries Users
- Lists enabled users' email addresses
- Lists disabled users' email addresses separately (was required for a certain project I did a long time back)
- Outputs to command line and also to a text file - c:\proxyaddresses.txt
- X.400 addresses are ignored

Updates:
08/07/2007: Download link updated to correct URL.

Unblock Outlook attachments

Ever found Outlook's long list of blocked attachments annoying? It's one thing to protect users from malicious code, but should someone who knows what they're doing be subjected to the same rules?

Now, there are ways of blocking/unblocking certain file types including registry hacks, group policies, et al. By far the most elegant and easy way for end users is a nifty little utility called Attachment Open written by Ken Slovak (MVP - Outlook).

It provides a COM add-in for Outlook. When you go to Tools | Options, you see an additional tab that lets you select particular (or all, if you really need to!) Level 1 file types and add them to the list of Level 2.
Level 1 file types are completely blocked by Outlook
Level2 file types are those that can be saved to the disk.

You can download it from http://www.slovaktech.com/attachmentoptions.htm

The utility is shareware. If you find it useful, you can donate 10 bucks by clicking a button - a small price to pay for those times when you really want to get to an attachment. :)

A good practice would be to move it back to Level1 (blocked) again after you're done accessing the attachment, unless you receive those file types very frequently and from trusted sources.

If you'd rather control this yourself through registry hacks, you need to add the extensions (followed by semi-colons after each extension - remember, if it's not formed correctly, Outlook will ignore the entire list!) to Level1Remove registry value in:
HKCU\Software\Microsoft\Office\VERSION_NO
\Outlook\Security

where VERSION_NO is:
9.0 - Outlook 2000
10.0 - Outlook 2002/XP
11.0 - Outlook 2003


List of attachments restricted by Outlook

Cannot Book Resource - Outlook thinks it's a recurring appointment

Issue: You try to reserve a conference room for a meeting, but get an error - XX Conference Room has declined your meeting because it is recurring. You must book each meeting separately with this resource". But it is a single instance meeting!

Cause: If several people have the resource's calendar open and make changes to it at more or less the same time, their client tries to update the Free/Busy info on the server at the same time. This corrupts the free/busy info.
(In general, clients should not be making changes directly to a resource's calendar.)

Resolution: Change some resource scheduling parameter for the resource from Outlook. For instance, uncheck "Decline conflicting meeting requests". This generates fresh free/busy info for the resource. You can then go back and check it again - the free/busy info will get refreshed yet again.

Source: Microsoft PSS

Seeing Double? (Default Email Folders)

Situation: Upgraded to Office 2003 Professional.
Outlook shows 2 of each default/system folder like Calendar, Contacts, Notes, Journal, Tasks, Junk E-mail, etc. (Not completely sure at what point this happened, but it happened within hours of Outlook 2003 upgrade, so that's the most likely suspect.)

Outlook thinks the new folders are the default, so new items get created in these folders. (For instance, when a meeting is accepted, it gets created in this new folder). The original "old" calendar has all previous meetings.

Tried to copy items from the old folders to the newly created ones - wouldn't work (for most folders).

Tried to delete the new folders - Outlook wouldn't allow it (default/system folders).

Solution:
1. Open the mailbox with MFCMAPI tool, login to mailbox, go to IPM Subtree, locate all new folders (mostly had 0 items in them) and delete.
2. Create new MAPI profile for user

Exchange 2000/2003 Mailbox Manager and msExchMailboxManagerAgeLimit.

Exchange 2000/2003 Mailbox Manager and msExchMailboxManagerAgeLimit.: "Mailbox manager policies may not process items as some administrators might expect. For example if you set up a mailbox manager policy to delete messages from the inbox after 30 days you may find that some of the messages are not deleted after the 30 day window has passed. In Exchange 2000/2003 in order for a message to be processed by a policy the age of the message must pass 3 criteria "

Moving mailboxes and corrupted Calendar

Moving mailboxes from an Exchange 2000 virtual server (EVS) to an Exchange Server 2003 EVS - can't seem to move 1 particular mailbox.

User has a history of corrupted Calendar folder/items - Oultook hangs immediately when choosing the Calendar folder from the folder list. (Lot of 8217s - KB327864: Meetings visible in Outlook may not be visible in OWA or non-MAPI clients).

Errors :
Event ID: 1008
Unable to move mailbox 'ABC'.
Error: The MAPI call failed.
MAPI or an unspecified service provider.
ID no: 80004005-0000-00000000

Event ID: 9172
Failed to copy messages to the destination mailbox store.
Error: The MAPI call failed.
MAPI or an unspecified service provider.
ID no: 80004005-0000-00000000

Event ID:8506
Unable to move mailbox ABC.
A problem occurred while getting the properties for a message.
Internal parent folder ID: e-21F33E; Message ID: 2-30B3DFA; Error code: 0x80004005.
Run ISINTEG to check for any problem in the database "Second Storage Group\Mailbox Store2 (SERVRENAME)".

Reference: KB264119. Suggests ISINTEG. Ran ISINTEG once. Didn't help. (Ran ESEUTIL /p as well... ). No dice. ISINTEG again 4 more times (with only one mailbox the store was already compacted to less than 500 Mb.). Tried mailbox move again to Store 1 in target server, worked. Moved to Store 2 in target server, worked again!