Released: Update Rollup 2 for Exchange Server 2007 SP1

Exchange Server 2007 SP1 Update Rollup 2 has been released.

Description of the roll-up can be found in KB 948016. Besides all the fixes from Update Rollup 1 (for SP1), this rollup includes fixes for the following issues:

• - 940462 The public folder store may take several minutes to mount on an Exchange 2007 server
• - 944153 Exchange Server 2007 does not have Transport Neutral Encapsulation Format (TNEF) capabilities for POP and IMAP protocols
• - 945917 You receive an error message when you try to access the Outlook Web Access global address list in an Exchange Server 2007 environment
• - 947346 Exchange Server 2007 mailbox users cannot retrieve the free/busy information for Exchange Server 2003 mailbox users in a large Exchange Server organization that has more than 100 administrative groups
• - 947360 Error message occurs, and users cannot access the free/busy information after you use the Import-Mailbox cmdlet to import data to a mailbox in Exchange Server 2007 Service Pack 1
• - 947391 The contents of .pst files are not imported into Exchange Server 2007 mailboxes when you use the Import-Mailbox cmdlet
• - 947451 A recipient sees unexpected text in the top of an e-mail message that you send in Exchange Server 2007
• - 947458 The Edgetransport.exe process may crash on an Edge server that is running Exchange Server 2007 Service Pack 1
• - 947551 The Edgetransport.exe process may crash intermittently on an Exchange Server 2007 Service Pack 1 Edge server
• - 947577 If you try to connect a mobile device to a mailbox server through a server that is running Exchange Server 2007, the mobile device may be unable to connect
• - 947646 Event ID 12011 is logged every time that the MSExchangeTransport service starts after you install Exchange Server 2007 Service Pack 1 on a computer that is running the German version of Windows Server 2003
• - 948047 An event ID 1080 message is logged in the System log every three seconds after you run the Set-ExchangeServer command to set the static domain controllers on an Exchange 2007 cluster node
• - 948297 The OOF template may be delivered as an attachment in an Exchange 2007 environment when you use the "Reply with Template" option in Microsoft Outlook
• - 948332 Failover takes a long time to finish in an Exchange Server 2007 cluster continuous replication environment
• - 948374 The EdgeTransport.exe process crashes intermittently, and event ID 1033 is logged in Exchange Server 2007
• - 948666 When you try to migrate a mailbox from Exchange Server 2003 to Exchange Server 2007, the Exchange Management Shell may stop responding
• - 948830 The MSExchangeSyncAppPool application pool crashes on a server that hosts an Exchange Server 2007 Client Access Server role
• - 948831 A user may be unable to synchronize with an Exchange Server mailbox from a mobile device when a Client Access server has been upgraded to Exchange Server 2007 Service Pack 1
• - 948844 An exception occurs, and event IDs 4999 and 5000 are logged when you modify the Outlook Web Access user interface
• - 949186 When you try to run the Restore-mailbox cmdlet on a server that is running Exchange Server 2007, you receive an error message
• - 949193 The address rewrite agent does not rewrite the address for Out of Office (OOF) messages in Exchange Server 2007
• - 949463 An exception error is generated after you run a Set-AttachmentfilterListConfig command together with the ExceptionConnectors option on an Exchange 2007 SP1-based server
• - 949541 You cannot log on to Outlook Web Access Light, and an error message occurs in Exchange Server 2007
• - 949703 Error message in Outlook when you click the signature icon of a signed e-mail message that an Exchange Server 2007-based Edge server receives: "The digital signature is invalid"
• - 949726 After you install Exchange Server 2007 Service Pack 1, the Set-ExcecutionPolicy task causes an error message, and event ID 103 is logged
• - 949772 If you run the "isinteg -dump" command against a dismounted store on a server that is running Exchange Server 2007, the Store.exe process stops unexpectedly
• - 950123 Error message after you apply Update Rollup 1 for Exchange Server 2007 Service Pack 1 in a Japanese environment: "Public Folder Management Console is not an allowed Snap-in"

HOW TO: Remove Public Folders

This is a fairly common question - you're trying to remove the Public Folder store on an Exchange 2007 server and get an error that some Public Folder replicas still exist. You're certain you've removed all Public Folder replicas from that server. What next?

Here's a little procedure documented in How to Delete Multiple Public Folders from Your Organization that takes care of this.

Remove all Public Folder replicas from the server using the following command:

Get-PublicFolder -Server "SERVER NAME" "\" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server "SERVER NAME" -Recurse -ErrorAction:SilentlyContinue

Next, remove all System Folders using the following command:

Get-PublicFolder -Server "SERVER NAME" "\Non_Ipm_Subtree" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server "SERVER NAME" -Recurse -ErrorAction:SilentlyContinue

To verify all Public Folders have been deleted:

Get-PublicFolderStatistics -Server "SERVER NAME" | fl

At times the replica clean-up may take a little while. If you still see replicas after running this command, run it again in 10-15 minutes.

Note: This procedure should be performed only if you're removing the last (or only) Public Folder Store from an Exchange Organization. If there are other servers in the Organization that also host Public Folders, using this procedure removes the folders from the Public Folder hierarchy.

Removing Public Folder replicas using MoveAllReplicas.ps1

If Public Folders are hosted on more than one server, use the MoveAllReplicas.ps1 script to remove replicas from a server, as illustrated in KB 927464: How to remove Exchange 2007 from a computer.

The MoveAllReplicas.ps1 script resides in the Scripts folder in the path where Exchange Server 2007 is installed. It's an easy-to-use script that takes 2 parameters— the source and target server names. The source server is the server you're trying to remove the Public Folder replicas from. The target server can be any other server in the Organization that hosts Public Folders— presumably a server that's in the same location to avoid replicating PFs over WAN links.

MoveAllReplicas.ps1 -Server "SOURCE SERVER NAME" –NewServer "TARGET SERVER NAME"

Once this is done, it may take some time for Public Folders to replicate to the target server, and for these to be removed from the source server. To verify there are no replicas on the source server, you can use the Get-PublicFolderStatistics command.

Errata: Edge Subscription and Synchronization white paper

The white paper on Edge Subscription and Synchronization has the following error:

Under Recipient Information:

Distribution groups are not replicated to ADAM.

Distribution Groups are in fact replicated to ADAM using EdgeSync. In Exchange Server 2007 SP1, Distribution Group membership (the member attribute) is also replicated.

On Windows Server 2008, ADAM is replaced by Active Directory Lightweight Directory Services (AD LDS).

Note that new Distribution Groups created in Exchange Server 2007 are set to receive mail only from authenticated senders by default— preventing them from receiving internet mail. Any Exchange recipients set to receive mail only from authenticated senders are not replicated by EdgeSync.

Related Posts:
- Configuring firewalls and name resolution for Edge Transport servers
- New Distribution Groups do not receive internet email by default

Standby Continuous Replication (SCR): Replay and Truncation Lag

Standby Continuous Replication (SCR) is a new High Availability feature in Exchange Server 2007 SP1. It uses Continuous Replication (also used by LCR and CCR) to replicate Storage Groups from a clustered or non-clustered mailbox server, known as a SCR source, to a clustered or non-clustered mailbox server, known as a SCR target.

SCR is managed using the Exchange shell - no management features exist in the EMC to configure or manage it.

Unlike LCR and CCR, which are designed to have a single copy of a Storage Group (consisting of an Exchange Store EDB + transaction logs & system files), SCR is designed to have many-to-one and one-to-many "replication relationships". (A SCR relationship or partnership - not formally defined terms, but simply used to explain the concept here - is SCR replication of a particular Storage Group from a SCR source server to a particular SCR target server).

A Storage Group from one SCR source can be replicated to multiple SCR target servers, and Storage Groups from one or more SCR source mailbox servers can be replicated to a single SCR target mailbox server.

By default, the Replication Service delays replaying 50 transaction logs to the SCR replica Database. Additionally, you can configure the following parameters to control how SCR replicas behave:
ReplayLagTime: specifies how long the Replication Service waits before replaying replicated transaction logs to the replica Database (EDB) on the target. Default:1 day
TruncationLagTime sets a lag time for truncating log files on that replica. Provided the other requirements are met for log file truncation on the SCR replica, log files are not truncated till ReplayLagTime + TruncationLagTime has elapsed. Default:0.

Why do I need the delay?

Replay lag gives you the protection of having a copy of your database from back in time. This back-in-time copy can be used to recover from logical corruption, pilot errors etc.

Additionally, if there is no delay, in the case of a lossy failover of the SCR source to a LCR or CCR replica, the (new source) Database will be behind its SCR target(s), requiring reseeding. Not something one would want to do for large Databases over WAN links (or even locally within the same datacenter). Delaying the last 50 transaction logs from being replayed to the SCR target avoids the need to reseed.

However, a large number of transaction logs not replayed to the Database means increased storage requirements for the SCR target, and also an increase in the time it takes to activate it in case of failure of the SCR source. Before it can be brought online, all the logs will need to be replayed.

To avoid this, you can set the ReplayLagTime to 0 (from the default of 1 day). Note, the replay will still lag behind by 50 transaction logs - a hard-coded limit enforced by SCR that cannot be changed. The TruncationLagTime can be set higher, so logs are replayed but not truncated. You can then take VSS snapshots of the target for the point-in-time copies.

Once setup using the Enable-StorageGroupCopy command, the ReplayLagTime and TruncationLagTime cannot be changed without disabling and re-enabling that SCR relationship for the Storage Group.

How can I see ReplayLagTime and TruncationLagTime? The following command shows the SCR targets a Storage Group is being replicated to:

Get-StorageGroup "SG Name" | fl

However, neither the above command, nor Get-StorageGroupCopyStatus show the lag times.

The parameters are returned as an array when you use the former (Get-StorageGroup) - only the name of the SCR target is displayed in the StandbyMachine property.

To see the lag times:

$sg = Get-StorageGroup "MyServer\MyStorageGroupName"
$sg.StandbyMachines

Here's what it looks like:


Figure 1: Displaying the Replay and Truncation lag time

Can I change ReplayLagTime and TruncationLagTime without reseeding the Database? You need to disable replication and re-enable it to add or modify the lag times. :

Disable-StorageGroupCopy "Storage Group Name" -StandbyMachine "SCR Target Server"

When disabling SCR, you get prompted to delete all files in the replica folder on the SCR target. Skip that. Reseeding is not required if you do not delete the files:

WARNING: Storage group "DFMAILMAN.e12labs.com\dfmailman-sg1" has standby continuous replication (SCR) disabled. Manually delete all SCR target files from "C:\Exchange Server\Mailbox\First Storage Group" and "C:\Exchange Server\Mailbox\First Storage Group\Mailbox Database.edb" on server "mirror".

Now, let's enable SCR with the replay and truncation lag times:

Enable-StorageGroupCopy "Storage Group Name" -StandbyMachine "SCR Target Server" -ReplayLagTime 1.00:00:00 -TruncationLagTime 2.00:00:00

Once replication is enabled again, make sure to test replication status using:

Get-StorageGroupCopyStatus "SG Name" -StandbyMachine "SCR Target Server"

Routing outbound mail using a particular IP address

A question that frequently and inevitably pops up when discussing Exchange transport is that of being able to route outbound mail using a particular IP address. The Exchange Server 2003/2000 transport architecture was confusing for many newcomers— the difference between an SMTP Virtual Server and an SMTP Connector being the main cause of this confusion. This is further exacerbated by the fact that SMTP Connectors use SMTP Virtual Servers as bridgeheads.


Figure 1: In Exchange Server 2003/2000, the IP address binding in SMTP Virtual Server properties is only for inbound connections

I've often quoted Scott Landry's post on the team blog— SMTP Virtual Server Myths Exposed. Myth #4 in Scott's post:

Myth 4: Virtual Server IP Address Will Be Used For Outgoing Connections

The last source of misunderstanding is the socket which will be used to open an SMTP connection. This may seem confusing and somewhat contradictory of my first point, but SMTP simply tells the Windows network stack to provide SMTP with a socket. It does not provide a source IP address to use, and as such, you will notice that the source IP address assigned by Windows will be based on the Windows routing table, not taking into consideration the IP of the SMTP VSI that is delivering the message. A common observation of this is that on a cluster server we are using the physical machine IP as our source IP, not any of the virtual IP addresses.

Exchange Server 2007, with its shiny new transport stack (freshly divorced from IIS' SMTP service), makes this quite clear. Receive Connectors, somewhat comparable to the SMTP Virtual Server in previous versions, are for receiving inbound mail. Send Connectors are for sending outbound mail.

When creating or modifying a Send Connector using the shell, you can specify the SourceIPAddress parameter to configure it to use a particular IP address for outbound mail. The IP address can be any IP address bound to a NIC on the Edge Transport server that is configured as a source server on the Send Connector. To modify an existing Send Connector, using the following command:

Set-SendConnector "ToInternet" -SourceIPAddress 1.2.3.4

However, as noted in the documentation, this only works on Edge Transport servers. Hub Transport servers ignore the SourceIPAddress parameter.

HOW TO: Delegate recipient administration for an OU

Exchange Server 2007 allows easier delegation of administration responsibilities, based on the following predefined administration roles:
1) Exchange Organization Administrator
2) Exchange Server Administrator
3) Exchange Recipient Administrator
4) Exchange Public Folder Administrator and
5) Exchange View Only Administrator.


Figure 1: Exchange Server 2007 allows delegation of administrative responsibilities

The delegation wizard in the EMC allows you to delegate the Recipient Administrator role for the entire Organization, but doesn't allow more granular delegation at the Domain or OU level.

More about the Exchange Recipient Administrator role

Security principals that have the Exchange Recipient Administrator role delegated get membership of the Exchange View Only Administrators role. Additionally, they are assigned:
- Read access to all the Domain Users containers in AD (in domains where Setup /DomainPrep has been run)
- Write access to all the Exchange-specific attributes in those domains

When delegating the Exchange Recipient Administrator role using the Exchange console or the Add-ExchangeAdministrator command in the Exchange shell, all you're doing is adding the security principal (user/group) to Exchange Recipient Administrators, a (Universal) Security Group in the Microsoft Exchange Security container in AD.

For more details about Exchange Server 2007 permissions, refer to "Configuring Permissions in Exchange Server 2007".

Here's how you can delegate recipient administration for an OU.
Exchange Organization: E12Labs
Domain: E12Labs.com (DC=E12Labs,DC=com)
OU: San Francisco (OU=San Francisco,DC=E12Labs,DC=com)
User: foo (Best Practice: Assign permissions to Security Groups)

Allow generic read permission for objects in the OU:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights GenericRead

Allow ReadProperty and WriteProperty permissions on Exchange-related attributes for objects in the OU

Add-ADPermission –Identity "ou=San Francisco,dc=E12Labs,dc=com" –User "E12Labs\foo" -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail

Property Sets in Active Directory

Exchange-Information and Exchange-Personal-Information are property sets - a number of related properties grouped together. Assigning permissions on a property set results in a single ACE in DACLS, making them much smaller and faster to process.

Exchange Server 2003 adds Exchange attributes to the Public Information and Private Information property sets that exist in Active Directory.

Exchange Server 2007 does not rely on these existing AD property sets, but creates 2 of its own. If deploying in an existing Exchange 2003 Forest, Exchange Server 2007 removes the Exchange properties added to the AD property sets and adds them to the new Exchange 2007 property sets. The Exchange-Information property set has 105 properties. Exchange-Personal-Information has 7. More information about the Exchange Server 2007 property sets and which properties are included in them can be found in "Property Sets in Exchange 2007".

Allow creation and management of Dynamic Distribution Groups in the OU
Exchange Server 2007 RTM:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights GenericAll –InheritanceType Descendents -InheritedObjectType msExchDynamicDistributionList

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

Exchange Server 2007 SP1:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

Allow permission to access RUS:

Add-ADPermission -Identity "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" -User "E12labs\foo" -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents

Allow permission to update Address Lists and Email Address Policies:

Add-ADPermission –Identity "CN=Address Lists Container,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" –User "E12Labs\foo" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

Add-ADPermission –Identity "CN=Recipient Policies,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" –User "E12Labs\foo" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

In addition to these Active Directory permissions, recipient administrators also need Exchange View Only Administrator permission on the Exchange Organization. Use the following command to assign it:

Add-ExchangeAdministrator "E12Labs\foo" -Role ViewOnlyAdmin

A script for SP1: If you're on Exchange Server 2007 SP1, a script written by Ross Smith IV makes delegating recipient administration permissions on an OU a simple task accomplished quickly (No, it's not for Exchange Server 2007 RTM). The script - ConfigureSplitPerms.ps1, resides in the \Scripts folder in the Exchange Server install path. Usage:

.\ConfigureSplitPerms.ps1 -user "MyDomain\foo" -identity "OU=San Francisco,DC=ExchangeLabs,DC=net"

Released: Exchange Server 2007 Update Rollup 6

Exchange Server 2007 Update Rollup 6 is now publicly available. This update is for Exchange Server 2007 RTM - you do not need to install it on servers running Exchange Server 2007 SP1.

Description of the rollup can be found in KB 942846.

In keeping with the new servicing model for Exchange server (read previous post " Changes to hotfix/patching model for Exchange Server 2007"), rollups are cumulative. They include all the fixes included in previous rollups (Exchange Server 2007 Rollups 1-5 in this case). Update Rollup 6 includes fixes for the following issues:

• - 942814 The account test process is failed when you try to configure an Outlook 2007 client to connect to an Exchange Server 2007 mailbox by using a POP3 connection or an IMAP4 connection
• - 943163 The Test-OwaConnectivity cmdlet and the Test-ActiveSyncConnectivity cmdlet do not run successfully on a computer that is running Exchange Server 2007
• - 943394 Some e-mail messages become stuck in the submission queue in Exchange Server 2007
• - 945428 An e-mail message is in disorder and is unreadable in a Exchange Server 2007 environment
• - 945141 IMAP4 clients may experience latencies or slowness when the clients are running against Exchange Server 2007-based servers
• - 945046 You receive an NDR message when you send an e-mail message by using a Exchange Server 2007 Edge server
• - 941805 Error message when you try to schedule a yearly recurring appointment on the 31st day of certain months: "The recurrence date is invalid"
• - 944451 Only the entries in the MailSubmission log are returned when you run the Get-MessageTrackingLog cmdlet against an Exchange 2007 server that hosts both the Hub Transport role and the Mailbox role
• - 944333 The store event sink does not run as expected in an Exchange Server 2007 environment
• - 942374 Legacy free/busy information no longer appears for appointments that are booked against a mailbox in Exchange Server 2007
• - 940053 Error message when a user tries to access a mailbox and download e-mail messages by using a DAV e-mail client program: "HTTP 500 - Internal server error"
• - 941655 The Store.exe process stops responding, and event ID 9659 is logged on an Exchange 2007 server
• - 942424 On an Exchange Server 2007-based computer, the Microsoft Exchange Information Store service stops unexpectedly when you start the service or when you mount a database store
• - 941851 An HTML e-mail message appears garbled in Outlook when you send the message to an Exchange 2007 user
• - 935894 Web beacons and HTML forms in e-mail message attachments are blocked regardless of the FilterWebBeaconsAndHtmlForms parameter setting for the Outlook Web Access virtual directory in Exchange 2007
• - 943264 The IMAP service returns an untagged EXISTS response before the EXPUNGE command in Exchange 2007
• - 943149 You cannot type the Polish character "?" in the Subject box, in the To box, or in the Cc box when you compose an e-mail message in Outlook Web Access for Exchange 2007
• - 943371 Event IDs 8206, 8213, and 8199 are logged in an Exchange 2007 environment
• - 942647 The display name of an e-mail address is not encoded correctly according to RFC 2047 when you use extended characters in Exchange 2007
• - 943479 Some source mailboxes are merged into one target mailbox after you use a Move-Mailbox cmdlet to migrate the mailboxes from an Exchange 2003 organization to an Exchange 2007 organization
• - 944321 The Edgetransport.exe process may stop unexpectedly on an Exchange Server 2007-based edge server
• - 938957 The GetItem operation in Exchange Web Service obtains duplicate strings in Exchange 2007
• - 942418 The Subject line of a delegate e-mail message is corrupted in Outlook 2007
• - 925252 The Store.exe process uses almost 100 percent of CPU resources, and the size of the public folder store increases quickly in Exchange 2007

Exchange Server 2007 Rollup History

At 24 new fixes, this is the biggest rollup of them all. Here's what the previous rollups fixed:

Rollup 1 (4/18/2007): This is a minor rollup with 3 issues fixed - 932487, 929756, 930572
Rollup 2 (5/8/2007): Released within 3 weeks of the previous Rollup, it fixes a security issue mentioned in Microsoft Security Bulletin MS07-026 - Vulnerabilities in Microsoft Exchange Could Allow Remote Code Execution (931832)
Rollup 3 (6/28/2007): 14 issues fixed - 931328, 930468, 931842, 932207, 932515, 934887, 936337, 932905, 934402, 935412, 934259, 932605, 932661, and 935202
Rollup 4 (8/23/2007): 11 issues fixed - 930463, 937656, 936300, 932561, 937861, 938359, 940052, 933314, 939560, 938698, and 936716
Rollup 5 (10/25/2007): 14 issues fixed - 940051, 940058, 936734, 938130, 940080, 940632, 940757, 940764, 941104, 940259, 941774, 940710, 940329 and 941552
Rollup 6 (2/21/2008): 24 issues fixed, as listed in the above section.

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.

Exchange Server 2007 SP1: The most obscure (but relevant) changes

Recently I was asked by a fellow MCT (and now Exchange MVP) to list 3 most obscure (but relevant) changes in Exchange Server 2007 SP1. The first thing that came to mind was the change made to Back Pressure settings.

Back Pressure stops inbound mailflow on transport servers if system resources fall below a certain level. In Exchange Server 2007 RTM, the threshold for free disk space was 4 Gigs - if you had less, Back Pressure (yes, there have been jokes about the name of this feature... ) stops inbound mailflow and throws a 452 4.3.1 Insufficient system resources error on mail submission. Read previous post Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources for my experience with this.

In SP1, the threshold has been reduced to a much more realistic level of 500 Mb. I can probably live with that.

I later posted about turning Back Pressure off - not necessarily something I recommend in production. However, in test environments (particularly in virtual server environments with disks created to be the smallest size possible to allow installation of Windows Server and Exchange... ) this generally makes sense.

Related posts:
- Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources
- Exchange Server 2007: How to turn off the Back Pressure feature on transport servers

HOW TO: List mailboxes with Full Mailbox Access permission assigned

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

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

Filtering mailboxes returned by Get-Mailbox

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

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

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

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

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

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

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

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

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

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

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

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

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

Exchange Server 2007: Renewing the self-signed certificate

Exchange Server 2007 issues itself a self-signed certificate for use with services like SMTP, IMAP, POP, IIS and UM. The certificate is issued for a period of one year.

The self-signed certificate meets an important need - securing communication for Exchange services by default. Nevertheless, one should treat these self-signed certificates as temporary. It's not recommended to use these for any client communication on an ongoing basis. For most deployments, you will end up procuring a certificate from a trusted 3rd-party CA (or perhaps an internal CA in organizations with PKI deployed).

However, should you decide to leave the self-signed certificate(s) on some servers and continue to use them, these need to be renewed - just as you would renew certificates from 3rd-party or in-house CAs.

 To renew the certificate for server e12postcard.e12labs.com, a server with CAS and HT roles installed:

Get-ExchangeCertificate -domain "e12postcard.e12labs.com" | fl

Note the services the certificate is enabled for (by default: POP, IMAP, IIS, SMTP on CAS + HT servers). Copy the thumbprint of the certificate.

Get a new certificate with a new expiration date:

Get-ExchangeCertificate -thumbprint "C5DD5B60949267AD624618D8492C4C5281FDD10F" | New-ExchangeCertificate

If the existing certificate is being used for SMTP, you will get the following prompt:

Confirm
Overwrite existing default SMTP certificate,
'C5DD5B60949267AD624618D8492C4C5281FDD10F' (expires 8/22/2008 7:20:34 AM), with certificate '3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E' (expires 1/28/2009 7:37:31 AM)?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

Type y to continue. A new certificate is generated.

Thumbprint   Services   Subject
----------   --------   -------
3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E   .....   CN=E12Postcard

The new certificate is generated and enabled. Examine the new certificate:

Get-ExchangeCertificate -thumbprint "3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E" | fl

 The old certificate is enabled for IIS, POP, IMAP and SMTP. The new certificate generated using the above command is enabled only for POP, IMAP and SMTP - IIS is missing.

To enable the certificate for IIS:

Enable-ExchangeCertificate -thumbprint "3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E" -services IIS

This enables the certificate for IIS (in addition to any other services it may already be enabled for - it adds to existing values of the services property).

 Test services are working with the new certificate. If it works as expected, the old certificate can be removed:

Remove-ExchangeCertificate -thumbprint "C5DD5B60949267AD624618D8492C4C5281FDD10F"

Related posts:
- Outlook Anywhere and Exchange's Self-Signed Certificate
- Which name should I use as Common Name for my UC certificate?
- DigiCert: A Certificate Authority with excellent customer service

Assigning SCL to messages scanned by 3rd-party antispam filters

Here's a problem I had a hard time resolving on Exchange Server 2003. Exchange Server 2007's Transport Rules resolve this within minutes.

Pretend you're taking a Microsoft exam:
Scenario: "You are the Exchange administrator for your organization... ".

Exchange has the Content Filter Agent (CFA), and the Edge Transport Server role designed to be a non-domain-joined mail gateway, located in perimeter networks. However, the Unix/Linux/Security folks in your organization don't trust Exchange to do the filtering (or act as the mail gateway). They insist on using open source anti-spam software, such as SpamAssasin (yes Eric, I remember CRM114 - the Controllable Regex Mutilator... and all the cool stuff you can command it to do. Just to set the record straight, I was suitably impressed back then, and continue to be so till this day.. :) on the non-Exchange SMTP gateways. After tweaking it for a number of weeks, they are able to make it work the way they want it to, or are close to it. It's implementation time!

Their solution is to insert an X-header in messages that looks like this:

X-Spam-Status:yes

That's it. Their job ends there.

As the Exchange team/administrator, your job is to ensure messages with that header end up in users' Junk Mail folder.

Exchange Server 2003 did not provide any way, out-of-the-box, to be able to inspect message headers and stamp SCL. To add some contextual fun - back then, our "solution" was a doc that showed the end-users how to create an Outlook rule to move such messages to Junk Mail. Only if Exchange/Windows admins could code... I can hear you think.

 Creating a Transport Rule: Exchange Server 2007's Transport Rules functionality allows you to accomplish this easily. Here's how:
1. Fire up EMC | Organization Config | Hub Transport | Transport Rules tab
2. Click on New Transport Rule in the Action pane
3. Give the new rule a name, add a comment if you wish
4. In the Conditions page, select the condition when a message header contains specific words
5. In the Step 2 edit box, click on the message header link

6. Type X-Spam-Status | click OK
7. In the edit box, click on the specific words link
8. Type yes | click OK | click Next
9. In the Actions page, select the action set the spam confidence level to value
10. In the rule description, click on the 0 link and add a value that's above your SCLJunkThreshold | click Next
11. On the Exceptions page, click Next if you do not want any exceptions to this rule
12. Click New | click Finish to close the wizard

Or you can use the following commands:

$condition = Get-TransportRulePredicate HeaderContains
$condition.MessageHeader = "X-Spam-Status"
$condition.words = @("yes")
$action = Get-TransportRuleAction SetSCL
$action.SCLValue = 5
new-TransportRule "Stamp SCL" -condition @($condition) -action @($action)

 Disabling the Content Filter agent: Since you have a 3rd-party filtering solution running on your non-Exchange SMTP host(s), you can disable the Content Filter Agent. Messages exceeding SCLJunkThreshold will still be moved to Junk Mail folder.

Disable-TransportAgent "Content Filter Agent"

Alternatively, you can leave the CFA enabled, but disable the Delete, Reject and Quarantine actions.

Set-ContentFilterConfig -SCLDeleteEnabled $false -SCLRejectEnabled $false -SCLQuarantineEnabled $false

Send a test message with the X-header X-Spam-Status:yes. The message has the SCL value set by the Transport Rule. If it is above the SCLJunkThreshold, it should be delivered to the Junk Mail folder.

Why this doesn't work with Delete, Reject or Quarantine thresholds enabled?

The Content Filter Agent fires on the EndOfData SMTP event. On Hub Transport servers, the Transport Rules Agent fires on the OnRoutedMessage event. If the CFA is left enabled, along with any of the above actions, messages may get deleted, rejected or quarantined. The Transport Rules Agent never gets to see deleted and rejected messages at all.

What about quarantined messages?

It's understandable if the message is already deleted or rejected - there's nothing left for the Transport Rule agent to act on! However, why doesn't the agent act on quarantined messages? With Pipeline Tracing turned on, I spent some precious cycles trying to unravel the mystery, with little success. As it turned out (thanks to helpful Exchange team folks for pointing out... ), I was overlooking the obvious - Quarantined messages are wrapped in an NDR "envelope". If you've ever logged into the quarantine mailbox and looked at quarantined messages, you know what these look like. (Related post: "HOW TO: Expose original senders and recipients of quarantined messages") The Transport Rules Agent does not see the original message headers, including our X-Spam-Status header. As a result, the rule never fires.

Life on the Edge

If using an Edge Transport server in the mix, things change. The Edge Rule agent fires on the EndOfData event, unlike Hub Transport servers. When two transport agents fire on the same SMTP event, you can set the priorities of each accordingly so one fires before the other. This is described in "How to Make the SCL Value Available to Edge Transport Rules" in Exchange Server 2007 documentation.

However, it's a lot simpler to just disable the Content Filter Agent. This meets the requirements of this scenario, where anti-spam filtering is done by 3rd-party anti-spam filters and Exchange isn't required to do any filtering at all.

SMTP Connector Myth: Messages are always routed over SMTP Connectors with more specific address spaces

An Exchange Server message routing myth forever being propagated (including by me):

If 2 SMTP Connectors (or Send Connectors in case of Exchange Server 2007) exist, one with a more specific address space, like exchangepedia.com, and one for a more generic address space like *, messages are always routed over the Connector with the more specific address space.

Now, generally that rule of thumb works for most purposes, until you consider restrictions on Connectors. These include:
Connector Scope: (Entire) Organization, or the Routing Group (to which the Connector belongs or is homed to)
Message Size restrictions: To prevent messages over a certain size from being routed over a Connector
Delivery Restrictions: To allow/prevent messages from particular senders from being routed over a Connector (Exchange Server 2003/2000)


Figure 1: Content Restrictions on a SMTP Connector, including message size limit

Scenario:
You want to prevent users from sending messages over 100 Kb to exchangepedia.com.
- Connector1 for address space exchangepedia.com, message size restriction of 100Kb.
- Connector2 for address space *, no message size restrictions.
Result:
- Messages for exchangepedia.com recipients with a message size that is under the 100kb limit are routed over Connector1.
- Messages for exchangepedia.com recipients with a message size of over 100kb are routed over Connector2 with the generic address space of *. Connector1 with more specific address space of exchangepedia.com is never considered.

If you want to limit messages sent to exchangepedia.com to only 100kb, you cannot do it using the configuration in the above scenario.

From Exchange Server 2007 documentation:
Routing to External Domains -> Selecting the Routing Path to an External Recipient):

If more than one Send connector is configured to have an address space that meets the routing requirements for an external recipient, Exchange 2007 routing will select a single connector through which to route the message. The selected connector must meet the message size constraints. After Exchange 2007 has eliminated all connectors that have prohibitive message size restrictions, routing applies the following criteria to determine to which connector it will route:

From the list of all Send connectors and foreign connectors that are configured in the Exchange organization, it narrows the list to connectors that satisfy all the following criteria:

- In the scope for the local server
- Enabled
- With an address space that matches the recipient's e-mail domain

From the resulting list, select the connector with the most specific address space match. No matching connectors may be found.

Maybe an Exchange Server 2007 change, you wonder. Not quiet - Exchange Server 2003 behaves similarly.

From Exchange Server 2003 documentation:
Exchange Server 2003 Message Routing -> Routing Path Selection Process

It determines all connectors to the message destination in the organization topology, and then analyzes message characteristics and connector restrictions to exclude all those connectors that must not be used to transfer the message.

In a nutshell: Connector selection happens after restrictions are checked.

Which Connector? Determining the Send Connector used in Exchange Server 2007 is quiet easy - if using different fqdns on a Send Connector, you can simply check the Received headers; or you can look at the SMTP logs (read previous post "Exchange Server 2007: Logging SMTP Protocol Activity"). In Exchange Server 2003, you can bump up the diagnostics logging on MSExchangeTransport -> Routing Engine/Service. Exchange logs Event ID 984, which provides details about message routing, including the Connector selected.

In the following screenshots, we see 2 different SMTP Connectors being selected for 2 messages to the same destination - the smaller message uses the Connector with the specific address space - exchangepedia.com, which routes the message to a smarthost. The larger message that exceeds that Connector's message size limit is routed using the Connector for address space *, which routes the message using DNS to lookup the MX record(s) for exchangepedia.com.


Figure 2: With Diagnostics Logging enabled, Exchange Server 2003 logs Event ID 984, which shows Connector selected (for a small message under 100kb in this case). The message is delivered to the Smarthost specified in the Connector.


Figure 3: Event ID 984 shows the Connector for generic address space * selected for a larger message (over 100kb in this case). Message is delivered using DNS lookup.

Unintended consequences? The implications aren't pretty, specially when you consider scenarios where one uses a SMTP Connector for a particular address space to enforce TLS (perhaps one of the biggest reasons why messages should never be routed over a Connector with a generic address space if a Connector for a specific address space exists). If I enforce message size restrictions on my Connector with TLS enabled, larger messages can and will be transmitted using the generic Connector that does not use TLS. Now we have the larger message(s) traveling over potentially unsecured SMTP sessions.

What about Delivery Restrictions? For Exchange Server 2003, the same is true for Delivery Restrictions. If the Connector for exchangepedia.com has Delivery Restrictions to prevent Joe Adams from sending messages to Exchangepedia, the message routes over the generic Connector for * - effectively flushing such restrictions down the tube. Restrictions on Connectors with more generic address space are a different story - if Joe has Delivery Restrictions on the * Connector, he cannot send internet mail.

The first task of the Routing Engine/transport should be to check if Connectors with more specific address spaces are available. If it finds any, there is no reason to exclude these from the routing decision. Any restrictions on that Connector exist for a purpose - to restrict message sizes, or to prevent certain users from sending to particular domains using Delivery Restrictions. By excluding Connectors with restrictions from the routing calculation, we're saying routing the message is more important than enforcing those restrictions. As a result, by routing the message over generic Connectors, other requirements for mail delivery to that address space, such as those mentioned above and other available Connector settings, may not be applied.

Related Posts:
- HOW TO: Prevent a user from sending and receiving internet mail
- Exchange Server 2007: Setting Message Size Limits
- Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain

Keeping tabs on Antispam filters: A few handy scripts in Exchange Server 2007

One of the more useful improvements in Exchange Server 2007 is the abundance of logging for different features and components (read previous post "Exchange Server 2007: How many logs hath thee?"). In particular, the antispam agent logs fill an important gap in monitoring, reporting and troubleshooting message flow as it relates to antispam agents (read previous post "Exchange Server 2007: Managing And Filtering Anti-Spam Agent Logs"). As a messaging/Exchange administrator, you want to be able to pin point what the antispam agents have been up to, and determine if particular messsages, or sending hosts, domains or email addresses have been blocked by any of the antispam agents. The antispam agent logs and the get-agentlog command allow you to do this quickly and efficiently.

In addition to the the get-agentlog command, Exchange Server 2007 also ships with a number of canned scripts that help you keep tabs on what the agents are doing. These scripts are found in the \Exchange Server\Scripts directory, where \Exchange Server is the path of the Exchange Server 2007 installation. Note, no documentation or support is available for these scripts - they are meant to be examples you can use to write your own scripts. Let's take a peek in the directory and see what we find.

Commandline parameters used by antispam scripts

Most of the following scripts take the same (optional) parameters.
-top n: Where n is the number of results to display. If not specified, the script defaults to (top) 10.
-StartDate: Start date/time
-EndDate: End date/time
-location: path of agent log files. If no path is specified, the agent works against the default agent log file location.

1. Get-AntispamFilteringReport.ps1: Takes one of the following values as a mandatory parameter: 1) connections 2) commands 3) messagesrejected 4) messagesdeleted 5) messagesquarantined, and displays statistics for each agent.
2. Get-AntispamSCLHistogram.ps1: Provides a breakdown of number of messages stamped with each SCL value.
3. Get-AntispamTopBlockedSenderDomains.ps1: Lists top ten sender domains from which mail was blocked.
4. Get-AntispamTopBlockedSenderIPs.ps1: Lists the top ten IP addresses blocked by antispam agents, and number of messages blocked from each.
5. Get-AntispamTopBlockedSenders.ps1: Lists the top ten blocked senders (SMTP email addresses) and number of messages blocked from each. The script can report on P1 (i.e. address in message envelope in the MAIL header) or P2 addresses (from headers in message body like FROM). Specify the option as a commandline argument (optional parameters -top n, -StartDate, and EndDate used in this example):

.\Get-AntispamTopBlockedSenders.ps1 P1 -top 20 -StartDate "12/1/2007" -EndDate "12/10/2007"

Replace the P1 in the above command with P2 to report on P2 senders.
6. Get-AntispamTopRBLProviders.ps1: Lists the top ten RBLs (aka "IP Block List Providers") and messages blocked by each (read previous post: "Exchange Server 2007: How are RBLs performing?").
7. Get-AntispamTopRecipients.ps1: Lists the top ten recipient addresses that receive spam. The addresses may or may not exist in your Organization - the reporting is based on actions taken by antispam agents on incoming messages. Recipient Filtering with Recipient Validation (dropping messages for recipients that do not exist in AD/GAL) is a great way to drop a large number of messages.

The following scripts are not used for reporting:
8. Reset-AntispamUpdates.ps1: Uninstalls any antispam updates and reinstalls the original "out-of-box" antispam data.
9. Install-AntispamAgents.ps1: By default, antispam agents are not installed on the Hub Transport server role (read previous post: "HOW TO: Install anti-spam agents on Hub Transport server"). This script installs them if you need to.
10. Uninstall-AntispamAgents.ps1: Uninstalls antispam agents.

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