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"

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.

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

Reader Tip: Redirecting shell output to the clipboard

Exchangepedia reader Guamaniac has an interesting tip in the comments on "Exchange 2007 Content Filter: The Whitelist Is Here!":

Get-ContentFilterConfig should give you a list of all the content filter settings on that particular Transport server.

And I know this is the simplest of features in PowerShell, but I just love the fact that you can pipe output to the clipboard:

get-contentfilterconfig | clip

and then peruse in your favorite text editor!

I'm used to simply highlighting the output using the mouse (which adds it to the clipboard). You need to enable QuickEdit on the command prompt window to be able to use this cut-and-paste functionality..

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 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

Exchange shell: Using double quotes or single quotes in commands or scripts

Another frequently asked question about PowerShell/Exchange shell, and one that I myself had during the initial foray with the shell - what's the difference between using double quotes and single quotes in a shell command or script?

The biggest difference, and the only one I'm aware of, is the fact that using double quotes - e.g. "$mailboxes", expands the variable. (Note, if the variable has not been used/defined or doesn't have any value, you get no output.)

When using single quotes - e.g. '$mailboxes', it is treated as a string.

To see the difference in action:

$mailboxes = Get-Mailbox

Now that we have captured the value(s) of mailbox(es) in a variable (actually an array... it can have a single or multiple values. In this case, a single mailbox, if you only have one, or multiple mailboxes).

Next, let's get some output from this. First, let's try with single quotes:

Write-Host 'This is a list of all my mailboxes: $mailboxes'

What you get is simply:

This is a list of all my mailboxes: $mailboxes

Now let's try with double quotes:

Write-Host "This is a list of all my mailboxes: $mailboxes"

The output will list all your mailboxes, as seen below:

This is a list of all my mailboxes: Jane Doe John Doe....

I haven't found any side-effects of using double-quotes, except when you really want a particular variable/string to be treated as a string.

Released: Windows PowerShell 2.0 CTP

For all those eagerly awaiting developments on the shell front, Microsoft has released a Community Technology Preview (CTP) of Windows PowerShell 2.0.

PowerShell 2.0 boasts some interesting (many frequently requested) features, including:
- remoting (ability to execute commands on remote computers)
- "a very early alpha version" of the Graphical PowerShell utility
- background PowerShell jobs that run without interaction with the console (including ability to trigger/run these on remote computers)
- ability to write your own commandlets in PowerShell rather than having to use compiled VB.NET or C# code
- 24 new commandlets, improved WMI and ADSI support, and quite a few other features listed in "What's New in CTP of PowerShell 2.0" on the PowerShell team blog.

The Graphical PowerShell requires .Net Framework v3.0.

Download the Windows PowerShell 2.0 CTP from here, and don't rush to install it on your production Exchange Server 2007 servers just yet - it's still a beta product.

HOW TO: Hide Distribution Group membership

Exchange Server 2003's ADUC extensions made hiding a Distribution Group's membership a trivial task, accomplished by right-clicking a group, selecting Exchange Tasks and selecting Hide Membership.



As the task suggests, it hides the group's membership in Outlook Address Book/GAL. It also prevents users from clicking the + link that appears before a Distribution Group when composing a new message, and expanding the group so messages are sent individually to all members rather than the DG.

The Hide Membership task available from Exchange Tasks denies Read Property permission for the Members attribute, to the Everyone group. This also prevents Administrators trying to manage the group from seeing the group's members.

Hiding Distribution Group membership is not supported in Exchange Server 2007. Recipients are managed using Exchange management tools - the Exchange console (EMC) and the shell (EMS). There is no option to hide Distribution Group membership in the console, nor a single parameter you can flip using the shell.

Nevertheless, you can prevent users from expanding the group in Microsoft Outlook. It's not a way to hide membership completely, as noted later in the post.

Use the following command to assign Deny permission for the Members property of the DG to a particular user or Security Group (remember the security best practice - add users to Security Group -> assign permissions to Security Group?):

Add-ADPermission "Distribution Group Name" -user "User or Security Group Name" -Deny -AccessRights ReadProperty -Properties Member

Note, you can use the Everyone group in the above command to simulate what Exchange Server 2003's Hide Membership task does. This hides membership from the EMC as well, but the shell can still show membership using the Get-DistributionListMember command.

Once the permission is added, clicking on the + link in Microsoft Outlook produces the following error message (not very descriptive), and user cannot expand the Distribution Group.


Click here to see a larger image

Additionally, membership of the group is not revealed in the group's properties in Microsoft Outlook.

For the console/GUI fans amongst us or those who simply haven't developed an intimate relationship with the shell (hopefully the following will make you a convert... :), ADSIEdit is your friend. Fire it up:

1. Navigate to the Distribution Group's properties
2. Select the Security tab
3. Click Add
4. Select the user or group you want to deny permission to (you can use the Everyone group to simulate what Exchange Server 2003 does)
5. Click OK
6. click Advanced (wait... ) to open Advanced Security Settings
7. Select the Permissions tab
8. Select the user or group if not already selected
9. Click Edit to open the Permissions Entry properties for the selected user/group
10. Select Properties tab
11. Click on the "Deny" checkbox for the Read Members property so it is checked.
12. Click OK to close the Permissions pages.
13. Click OK to close the Advanced Security Settings pages
14. Click OK to close the Properties dialog box

To determine any modifications to the AD permissions for the Members property:

Get-ADPermission "Distribution Group Name" | where {$_.Properties -like "member"} | fl

To remove the Deny permission on the Member property for a Distribution Group, use the Remove-ADPermission command:

Remove-ADPermission "Distribution Group Name" -user "User/Security Group Name" -Deny -AccessRights ReadProperty -Properties Member

Caveats to the above approach:
1. Users can still send a message to the Distribution Group with a Delivery Report requested. This reveals the membership of the Distribution Group. Let's go ahead and fix that.

To prevent a Delivery Report from being sent to the originator (consider this carefully, you may want senders to receive delivery reports if messages are not delivered to members of certain Distribution Groups. You can also enable delivery reports to the group Manager only.), use the following command:

Set-DistributionGroup "Distribution Group Name" -ReportToOriginatorEnabled $false

Once this is done, Exchange simply sends a Distributtion Group expanded message in the Delivery Report, if one is requested, without revealing the group's members.



2. Membership of the Distribution Group can be viewed in Outlook Web Access (OWA 2007).

Yes, this means this workaround can't really be used to hide group membership completely. You can still use this to prevent Outlook users from expanding the group when composing messages, and hiding membership from Outlook users.

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

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

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



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



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

Managed Folders and Managed Content Settings

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

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

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

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

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



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

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



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

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

Exchange Server 2007: How to get a list of Exchange ActiveSync users

Getting a list of actual Exchange ActiveSync (EAS) users was not an easy task with Exchange Server 2003, and certainly not one that could be accomplished in a hurry.

Yes, it indeed is a one-liner shell command with Exchange Server 2007:

Get-CASMailbox | where {$_.HasActiveSyncDevicePartnership} | select Name

Exchange Server 2007: Setting Message Size Limits

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

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

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

Set-TransportConfig -MaxReceiveSize 40MB -MaxSendSize 40MB

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

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



To set ReceiveConnector limit using the shell:

Set-ReceiveConnector "CONNECTOR NAME" -MaxMessageSize 40Mb

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



To set SendConnector limit using the shell:

Set-SendConnector "CONNECTOR NAME" -MaxMessageSize 40Mb

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



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

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

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

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

To set these using the Exchange shell:

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

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

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




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

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

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

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

Exchange Server 2007 SP1 makes managing Global Settings easier.

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

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

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

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

Set-RoutingGroupConnector "CONNECTOR NAME" -MaxMessageSize 20Mb

Content conversion and message size limits

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

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

Using the Exchange shell to track failed message delivery

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

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

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

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

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

HOW TO: Create a Dynamic Distribution Group by country or city

The Exchange console does not have pre-canned filter options for Country or City to be able to create a Dynamic Distribution Group (DDG, aka "Query-Based Distribution Group") for all recipients or mailboxes in a particular country or city. You can use options to filter on Department, Company, State or Province, or the custom/extension attributes 1-15.


Fig. 1: You can filter on Department, Company, State or Province or extension attributes 1-15 using pre-canned filters

If your Active Directory OUs are structured based on location (country/state/city), you can simply scope the DDG to that OU using the Exchange console, as shown in the following screenshot.


Fig. 2: You can set the scope of the DDG to a particular OU or container. Click here to see the complete dialog box.

However, if that's not the case (e.g. OU structure is based on business units or departments, etc.), you will need to use the Exchange shell to create a DDG with a custom filter.

To create a DDG for all user mailboxes from a particular country:

New-DynamicDistributionGroup -Name "US-Users" -OrganizationalUnit "OUorContainerNameToCreateGroupIn" -RecipientContainer "yourdomain.com" -RecipientFilter {RecipientType -eq "UserMailbox" -and CountryOrRegion -eq "United States"}

You can change the RecipientType to include other types of recipients.

To view recipients/mailboxes returned by the RecipientFilter: "HOW TO: View membership of a Dynamic Distribution Group".

Similarly, to create a DDG for all user mailboxes from a particular city:

New-DynamicDistributionGroup -Name "SF-Users" -OrganizationalUnit "OUorContainerNameToCreateGroupIn" -RecipientContainer "yourdomain.com" -RecipientFilter {RecipientType -eq "UserMailbox" -and City -eq "San Francisco"}

New Dynamic Distribution Group quirkiness

I'd written about Devin's observation earlier that all new Distribution Groups created in Exchange Server 2007 do not receive internet/unauthenticated email by default (read previous post "New Distribution Groups do not receive internet email by default").

Here's some more often overlooked Dynamic Distribution Group