h1

Automatic Personal Archive Provisioning

August 23, 2011

Exchange 2010 supports automatic provisioning for new mailboxes. Unfortunately this mechanism does not extend to personal archives. As mailboxes are moved to Exchange 2010, they must be enabled for archives manually with the operator managing the size of each database and dividing the load accordingly.

The script below was created to automate this function and is intended to run automatically using a scheduled task on each CAS server.

Typically archive databases are flagged so that they do not participate in automatic provisioning for new mailboxes. The script selects the smallest archive database from the databases that are excluded from provisioning using the –IsExcludedeFromProvisioning parameter. Users are then enabled for archives using the target database.

The script also assigns one of two custom archive policies – a 180 day policy and a 360 day policy based on a group that defines users that get 360 days of retention in their mailbox. The script uses a custom attribute to overcome the issue of identifying mailboxes that are not members of the 360 day retention group.

Let me explain the issue:

PowerShell scripts often handle the ‘reverse group membership check’ issue by using a script that first assigns the common value (in this case 180 day retention) to everyone and then assigns the special value (in this case 360 day retention) to the members of a group.

The main weakness to this approach, especially for something like a retention policy is that any error with the second part of the script (say if someone renamed the group) would result in everyone getting a more restrictive retention policy and more archived items which is potentially disruptive and difficult to reverse.

My solution is to assign everyone in the org the less restrictive setting using a custom attribute field in AD once. Then adjust that custom attribute value based on the group membership and use the custom attribute value to configure the retention policy. This means that if the group is renamed or another error occurs, new members of the group might get the wrong policy but existing members would not be impacted.

Note that this can be accomplished with less effort if you deploy the Quest PowerGUI tools since the get-QADUser command does support a parameter –NotMemberOf. I didn’t use this since I was trying to create a solution that didn’t require additional software (in other words, come on Microsoft and implement this function!)

 

In addition, the script uses custom attribute 13 to identify a mailbox that shouldn’t use a personal archive. This is intended for service accounts and special purpose mailboxes.

#
#
# NAME: Maintenance.ps1
#
# AUTHOR: Guy Yardeni
#
# COMMENT: Script to run various maintenance tasks for Exchange 2010
#
#        Enable archives for mailboxes
#        Configure archive policy based on AD group
#

# Script to enable archive for any users who don’t already have one
# using the smallest archive database
#         
# Any text in Custom Attribute 13 will cause the script to skip the mailbox
#
#

# Return archive database with smallest size
$TargetDB = Get-MailboxDatabase -status | where {($_.ExchangeVersion.ExchangeBuild.Major -eq 14) -and ($_.IsExcludedFromProvisioning -eq $true)} | sort-object "DatabaseSize" | select-object -first 1

# Enable archive to relevant mailboxes to the target database
$results = Get-Mailbox | where {($_.ExchangeVersion.ExchangeBuild.Major -eq 14) -and ($_.ArchiveDatabase -eq $null) -and ($_.CustomAttribute13 -eq "")} | enable-mailbox

-archive -archivedatabase $TargetDB.Name -retentionpolicy "360 Day Default" |measure-object
 
#Write output for testing
Write-Host $results.count "mailbox(es) were enabled for archiving on database" $TargetDB.Name

# Script to set correct archiving policy
Get-Mailbox | where {($_.CustomAttribute12 -eq "")} | set-mailbox -CustomAttribute12 "180"
Get-DistributionGroupMember "Exchange Archive Users – 360 day" | Get-Mailbox | set-mailbox -CustomAttribute12 "360"
Get-Mailbox | where {($_.ExchangeVersion.ExchangeBuild.Major -eq 14) -and ($_.CustomAttribute12 -eq "180")} | set-mailbox -retentionpolicy "180 Day Default"
Get-Mailbox | where {($_.ExchangeVersion.ExchangeBuild.Major -eq 14) -and ($_.CustomAttribute12 -eq "360")} | set-mailbox -retentionpolicy "360 Day Default"

As always, comments about the code and approach are welcome!

h1

Exchange 2010 – monitoring move requests

August 22, 2011

A quick post to make a common task a little easier.

When managing move mailbox requests, it is often useful to be able to view certain statistics to ensure that progress and migration pace are as expected and that each server is playing its expected roles.

Exchange 2010 SP 1 makes that possible using the get-moverequeststatistics powershell command-let but some manipulation and formatting makes a big difference in monitoring the results.

Try this command for a friendly view of useful information about each open move request (as well as some cool tricks you can use with the format-table command):

Get-MoveRequest | Get-MoveRequestStatistics  |Sort-Object CompletionTimeStamp| ft DisplayName, @{Expression={$_.BadItemsEncountered};Label=”Errors”}, @{Expression={$_.PercentComplete};Label=”Percent”}, @{Expression={$_.TotalMailboxSize.ToString().Split(“(“)[0]};Label=”Size”}, @{Expression={$_.totalinprogressduration};label=”Time”},@{Expression={(($_.BytesTransferred/$_.TotalInProgressDuration.TotalMinutes)*60).ToString().Split(“(“)[0]};Label=”Pace/hr”}, @{Expression={$_.MRSServerName.ToString().Split(“.”)[0]};Label=”CAS”}, @{Expression={$_.SourceDatabase.ToString().Split(“\”)[0]};Label=”SourceServer”},SourceDatabase,Status,CompletionTimestamp -auto

Redirecting the output to a file on a scheduled basis also makes troubleshooting after hours mailbox moves much easier.

h1

Publishing Exchange 2010 with TMG

August 15, 2011

Part III: Redirection (virtual directory and SSL)

Typically when users want to access Outlook Web App (OWA), they are unlikely to type the correct URL: https://webmail.domain.com/owa or /exchange. In order to accommodate common URL combinations that users may enter, commonly using HTTP instead of HTTPS and omitting the virtual directory name, we can employ redirection.

To this end, there are two types of redirection:

The first redirects HTTP traffic to HTTPS and is very easy to accomplish in a TMG environment. If you refer to the previous post, you will see a configuration step for the web listener that accomplishes this function. In the ‘Connections’ tab for the listener, HTTP connections are allowed and redirected to HTTPS. Nice and easy.

The second form of redirection help redirect URLs that reference the root of the web site, i.e. https://webmail.domain.com , to the correct virtual directory. In an Exchange 2007/2010 environment, the destination should be https://webmail.domain.com/owa. If coexistence with legacy versions  (Exchange 2003) is needed, the destination will be https://webmail.domain.com/exchange.

In either case, we will use the ‘HTTP redirection’ feature of IIS 7.5 to configure the required setting using the following process on each CAS server:

  1. Open IIS Manager and navigate to the Default Web Site
  2. Open the HTTP Redirect feature and configure the following options:
  • Redirect all requests to this destination: https://webmail.domain.com/owa
  • Redirect all requests to exact destination: unchecked
  • Only redirect requests to content in this directory: checked
  • Status code: Found (302)

While those are the required settings for the web site, settings these configuration options will automatically set the same options on any sub folders and virtual directories that do not currently have redirection configured. Since we only want the redirection on the web site, we need to remove the redirection from all sub folders.

This process results in a problem: there are three directories that do need to be redirected and those are ‘/Exchange’, ‘/Exchweb’ and ‘/Public’. These three virtual directories must be redirected to ‘/owa’ in order for the OWA service to function correctly.

The problem is evident right after turning off redirection on the ‘/owa’ virtual directory using the UI – this change also disables redirection on the three folders listed above. If you re-enable redirection on any of the three, it will also re-enable redirection on ‘/owa’. This confusing and frustrating loop creates a series of unusable configurations that aren’t simple to correct.

The problem occurs because once the settings are configured using the UI, they are stored in the web.config file for the virtual directory and the four directories discussed all share a single web.config file. If the settings are configured using appcmd.exe the information is stored elsewhere (presumably in the metabase) and the problem is resolved.

The process to correct the issue is as follows:

  1. Remove the HttpRedirect section from the web.config file for /owa.
  2. Use the following commands to configure the correct settings for all folders:

cd %windir%\system32\inetsrv
appcmd set config “Default Web Site/Exchange” /section:httpredirect /enabled:true -commit:apphost
appcmd set config “Default Web Site/Exchweb” /section:httpredirect /enabled:true -commit:apphost
appcmd set config “Default Web Site/Public” /section:httpredirect /enabled:true -commit:apphost

appcmd set config “Default Web Site/owa” /section:httpredirect /enabled:false -commit:apphost

Finally, while you are configuring virtual directories on each CAS server, confirm that the authentication settings are set to Basic Authentication for all of the virtual directories – OWA, ECP, ActiveSync, and Outlook anywhere (configured on the properties of the CAS server). I recommend viewing and making changes to these settings through the Exchange Management Console or Shell.

That should be all that’s needed. The results of following the instructions in all 3 posts of this series are an Exchange 2010 system published with TMG using a single public IP address and a seamless user experience.

A big thanks and credit for various aspects of this post go to a couple of colleagues at Convergent Computing for helping discover, test and document this information. Thank you Yasu SabaLin and Aman Ayaz.

Hope this is helpful and as always please post any comments or questions

Follow

Get every new post delivered to your Inbox.