Microsoft has released the following update rollup for Exchange Server 2007:

• Update Rollup 8 for Exchange Server 2007 SP1 (968012)

If you’re running Exchange Server 2007 SP1, you need to apply Update Rollup 8 for Exchange 2007 SP1 to address the security issues listed below.

Remember, you only need to download the latest update for the version of Exchange that you’re running. RTM updates can’t be installed on SP1 and vice versa.

Rollup 8 for Exchange Server 2007 SP1 supersedes the following:

1. 945684 Update Rollup 1 for Exchange Server 2007 Service Pack 1
2. 948016 Update Rollup 2 for Exchange Server 2007 Service Pack 1
3. 949870 Update Rollup 3 for Exchange Server 2007 Service Pack 1
4. 952580 Update Rollup 4 for Exchange Server 2007 Service Pack 1
5. 953467 Update Rollup 5 for Exchange Server 2007 Service Pack 1
6. 959241 Update Rollup 6 for Exchange Server 2007 Service Pack 1
7. 960384 Update Rollup 7 for Exchange Server 2007 Service Pack 1

Here is a list of the fixes included in rollup 8:

1. 948856 Event ID 9667 occurs when you create a new named property on an Exchange Server 2007 server
2. 952935 A software update is available that provides the log tracing feature for the LogTruncator tag in Exchange Server 2007
3. 954639 Exchange Information Store service stops responding intermittently on an Exchange 2007 server
4. 955480 Meeting requests from external senders are displayed as Busy instead of Tentative in an Exchange 2007 environment
5. 956633 User calendar permissions are removed after you run the Set-MailboxCalendarSettings cmdlet in an Exchange Server 2007 environment
6. 957640 The “test-*” command fails when you run it on a site that contains only CAS roles in an Exchange 2007 environment
7. 958239 Exchange Server 2007 does not generate an event log message for public folder replication messages even though a property validation exception is thrown and the replications do not occur
8. 958881 All HTML content in attachment files of messages is run through an HTML filter when you open or save the attachment by using Outlook Web Access (OWA)
9. 958938 The importance attribute of a message is lost when an Exchange 2007 user accesses a high-importance message or a low-importance message from Exchange Server 2007 by using a non-Outlook POP3 client or IMAP4 client
10. 959510 A meeting request that is sent from OWA causes a “553 5.0.0 Message-Id header line format error” NDR message in an Exchange Server 2007 environment
11. 959748 An account with the “Exchange View-Only Administrator” permission can review user mailbox contents by using an administrative application in Exchange Server 2007
12. 959861 Some clients cannot connect to back-end Exchange Server 2003 IMAP servers after Exchange 2007 Service Pack 1 RU2 is applied
13. 959990 An error occurs when you try to update a recurring appointment by using an Outlook client that is connected to an Exchange 2007 server
14. 960178 You receive an NDR when you send an e-mail using OWA Premium and the ANR cache if the Exchange organization name has more than one space
15. 960354 Edge Attachment Filtering does not honor the ExceptionConnectors value in Exchange Server 2007
16. 960367 Error message when you run the Export-Mailbox command on a folder that has more than 5000 items in Exchange 2007: “-1056749164”
17. 960495 The Information Store service crashes continuously on an Exchange Server 2007 server
18. 960633 The Microsoft Exchange Information Store service crashes on an Exchange Server 2007 that has the mailbox server role installed
19. 960703 Extended characters are replaced by question marks when you send an e-mail message that contains extended ASCII characters by using an IMAP4 client in Exchange 2007
20. 960775 You receive a “Message too large for this recipient” NDR that has the original message attached after you restrict the Maximum Message Send Size value in Exchange Server 2007
21. 960869 A queue that has multiple connections cannot enter a Retry state in Exchange Server 2007
22. 961152 The Exchange information store service (Store.exe process) crashes intermittently when you migrate user data from Lotus Notes to Exchange Server 2007
23. 961347 Error message when you export an Exchange 2007 mailbox to a .pst file and a filter is defined: “Export-Mailbox : Error was found for <username> (<SMTP address>)”
24. 961443 Users cannot use Outlook Web Access for Exchange Server 2007 to open an address book
25. 961524 Some journal messages are stuck in the Submission queue in Exchange Server 2007
26. 961606 After you apply Rollup Update 5 for Exchange Server 2007, Outlook Web Access users find the font size of plain text messages is extremely small when they use some third-party Web browsers
27. 961693 Japanese (1 byte Kana) characters in the subject and display name are corrupted when you try to reply or forward task requests or calendar items in Outlook client
28. 962235 The date and time information for a “Follow Up” flag is missing if an Exchange 2007 user sends a message to an external recipient
29. 966535 Duplicate messages are sent to an external recipient if the recipient is included in multiple distribution lists in an Exchange Server 2007 environment
30. 967038 Many log entries are generated in Exchange Server 2007 if you turn on the Exchange log to audit the logons that do not use the primary account for shared resource mailboxes
31. 967097 Users may receive duplicate calendar items for the updated instance on mobile devices
32. 967109 A delegate cannot accept a meeting request for an online meeting in an Exchange Server 2007 environment
33. 967255 Only the tracing information of the last user is logged when you configure Exchange Server 2007 to trace multiple users at the same time
34. 968310 Many log entries are generated on an Exchange Server 2007 computer when you enable the Exchange log to audit user logons that do not use the primary account for their mailbox
35. 968352 The W3wp.exe process crashes when you use the Italian version of the spelling checker on a message in Outlook Web Access in Exchange 2007
36. 968589 The managed policy does not work if the ptagProvisionedFid attribute is missing in Exchange Server 2007
37. 968673 The EdgeTransport.exe file of Exchange 2007 servers crashes continuously and Event ID 10003 and Event ID 5000 occur
38. 968745 Incomplete tasks show in the Complete tasks view in OWA 2007 in an Exchange 2007 environment
39. 968966 Many log entries are generated in Exchange Server 2007 if you turn on the Exchange log to audit administrator logons that do not use the primary account for mailboxes
40. 969690 Unresolved sender for delivery status notifications after applying update rollup 7 for Exchange Server 2007 Service Pack 1
41. 970687 A search operation in Outlook does not return a correct result if there is a corrupted HTML message in the target folder in an Exchange Server 2007 environment

Download the rollup here. It will be available via Windows Update May 26th.

Installation Notes:

If you haven’t installed Exchange Server yet, you can use the info at Quicker Exchange installs complete with service packs and rollups to save you some time.

Microsoft Update can’t detect rollups for Exchange 2010 servers that are members of a Database Availability Group (DAG). See the post Installing Exchange 2010 Rollups on DAG Servers for info, and a script, for installing update rollups.

Update Rollups should be applied to Internet facing Client Access Servers before being installed on non-Internet facing Client Access Servers.

If you’re installing the update rollup on Exchange servers that don’t have Internet access, see “Installing Exchange 2007 & 2010 rollups on servers that don’t have Internet access” for some additional steps.

Some of the PowerShell scripts I use and/or write send email to either users or myself. In order for that to work, a Hub Transport server has to allow the SMTP traffic from the script. So, we need a receive connector that will allow the email to be sent under the right conditions. Here’s how we can easily accomplish that.

I find it best to run scripts that send email right from a Hub Transport server. So we’ll create a new receive connector called “Internal Relay” using the New-ReceiveConnector cmdlet, and set it to allow mail from itself. This is done with the -RemoteIPRanges parameter. We’ll set it to 127.0.0.1, the loopback address for the server.

Since we don’t need to authenticate, we’ll set -AuthMechanism to ‘none’, and set the -PermissionsGroups to ‘AnonymousUsers’.

Last, we’ll set it to enabled, and configure which server it should be on. Remember, it needs to be on a server holding the Hub Transport role.

New-ReceiveConnector -Name "Internal Relay" -Bindings 0.0.0.0:25 -RemoteIPRanges 127.0.0.1 -AuthMechanism Tls -Enabled $true -Fqdn "myserver.mydomain.com" -PermissionGroups AnonymousUsers -Server mysever

Change the highlighted info to suit your needs. I use 127.0.0.1 if I’ll be running the scripts on the local Exchange server.

We allow anonymous users to actually relay by granting the ‘ms-Exch-SMTP-Accept-Any-Recipient’ extended right to the Anonymous Logon account using Add-AdPermission. This is done using:

Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

We can also grant NT Authority\Anonymous Logon the right to bypass anti-spam agents using:

Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-exch-bypass-anti-spam"

We can pipe all of the commands together into a one-liner. The finished script looks like this:

New-ReceiveConnector -Name "Internal Relay" -Bindings 0.0.0.0:25 -RemoteIPRanges 127.0.0.1 -AuthMechanism Tls -Enabled $true -Fqdn "myserver.mydomain.com" -PermissionGroups AnonymousUsers -Server mysever | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient, ms-exch-bypass-anti-spam"

This gives us a connector that we can use to send email from PowerShell. Verify it by using

Get-ReceiveConnector -Name "Internal Relay" | Get-ADPermission | ft User, ExtendedRights

In the coming posts, we’ll use this to our advantage.

Description

I’ve had several client ask me lately how to set retention periods on mailboxes, and, equally important, how to make sure that all newly created mailboxes have the policy applied. Some organizations will have more than one admin who creates mailbox enabled user accounts, and leaving it up to the admins to manually set the account for a retention policy is just prone to mistakes.

I won’t go into a lot of detail talking about what MRM is and what can be done. It’s already been covered many times on other sites, including this short but informative video from the Exchange product group. This article assumes that you have a working policy already in place. What I’ll cover here is how to use PowerShell to be consistent in applying an MRM policy to all users. For the most part, we’ll “set it and forget it”.

We can use PowerShell to apply an MRM policy using the ManagedFolderMailboxPolicy parameter of the Set-Mailbox cmdlet. This script basically looks for all users who are not resource accounts, not disabled, and don’t already have a policy applied (since we don’t generally want to override that). We do that with this line:

$MBXArray = @(Get-Mailbox | Where-Object {($_.RecipientType -eq 'UserMailbox') -and ($_.UserAccountControl -notmatch 'AccountDisabled') -and ($_.ManagedFolderMailboxPolicy -eq $null)})

$MBXArray is thus a list of mailboxes that pass the query. We then cycle through the array with ForEach and apply a policy to each mailbox using Set-Mailbox, like this:

Set-Mailbox -identity $Mailbox.SAMAccountName -ManagedFolderMailboxPolicy $strPolicyName -ManagedFolderMailboxPolicyAllowed

I use the -ManagedFolderMailboxPolicyAllowed parameter to get past confirmation prompts, since we’ll run the PowerShell script has a Windows scheduled task. $strPolicyName is a variable that holds the name of the policy we’d like to apply.

That’s simple enough, really. But it’s generally a good idea to have some sort of record that a policy was applied. PowerShell gives us a couple of ways to record the event, and we’ll use both.

First, when the script first starts, we’ll write an event to the application event log noting that the script is starting. First, set some variables and create a new object with

$strWhoAmI = $MyInvocation.MyCommand.Name
$evt.Source=$strWhoAmI
$evt=new-object System.Diagnostics.EventLog("Application")
$infoevent=[System.Diagnostics.EventLogEntryType]::Information

The first line actually creates a variable, $strWhoAmI, and assigns it the name of the PowerShell script. The second line sets that same info to be the source of the event log entry we’re about to write.

We use the two lines below to set the text for the event log, and write it.

$strEventLogText = "Beginning processing."
$evt.WriteEntry($strEventLogText,$infoevent,70)

When the script is finished, we also write another event log entry to say we’re done, along with a count of how many mailboxes were processed.

Next is where we build some flexibility into the script. At the beginning of the script, we define another variable, $strLogEachUser (and set it to $false) to disable writing an event log entry for EACH user we apply a policy to. In larger environments, it’s not a good idea to have that set to $true when the script runs the first time, as it can result in a LOT of event log entries. But, after that, it might provide some valuable information. The log entry will look something like

Messaging Records Management policy ‘MyManagedFolderPolicy’ applied to Claudia Richard

The next logging option we have is to stamp the actual AD account when we apply the policy to it. We do this by using one of the Custom Attributes available on Active Directory objects. For a user account, there are 15 Custom Attributes, and they can be viewed by opening a recipient in Exchange Management Console, and clicking on the Custom Attributes button near the bottom of the General tab. We’ll use Custom Attribute 13 for this example. This is easily accomplished by using the -CustomAttribute13 parameter of the Set-Mailbox cmdlet.We assign the text we’ll use with the $strMRM variable near the top of the script:

$strMRM = "MRM policy applied by " + $strWhoAmI + " " + $strToday

This allows for the script name, policy name, and a time stamp, and looks like this:

MRM policy applied by AutoApplyMRMPolicy.ps1 05/16/2009 12:16:38

The last feature built in is a status indicator while the script is running. This probably won’t be very valuable unless you plan to only ever manually run the script. The status indicator is disabled by default, but can be enabled by changing

$strShowStatus = $false

to

$strShowStatus = $true

it’s the same status indicator you see when doing many tasks at one time, such as moving or export mailboxes.

Here’s the finished script. Save it as AutoApplyMRMPolicy.ps1 in your \scripts folder on your Exchange server. Edit the three variables under the header block to suit your needs.

###############################################################################
# AutoApplyMRMPolicy.ps1 by Pat Richard, MVP
# https://www.ucunleashed.com/85
#
# Automatically apply a Messaging Records Management policy to
# all users who are:
#        a) not resource accounts
#        b) not disabled
#        c) don't already have a policy applied
#
# This script is designed to be run as a Windows Scheduled task on an Exchange
# server.
#
# UPDATES
# =======
# v1.3 05/22/2009 Updated array per Nick's additional suggestions
# v1.2 05/19/2009 Updated array per Nick's suggestions
# v1.1 05/15/2009 Added status indicator;
#            cleaned up/added event log entries
#            added variables for enabling/disabling each
# v1.0 04/30/2009 Initial version
#
# Simply edit the settings below to fit your needs
###############################################################################

$strPolicyName = 'MyManagedFolderPolicy'
$strLogEachUser = $false
$strShowStatus = $false

############ DO NOT EDIT ANYTHING BELOW THIS LINE ############
$strToday = Get-Date
$strWhoAmI = $MyInvocation.MyCommand.Name
$strMRM = "MRM policy applied by " + $strWhoAmI + " " + $strToday
$evt=new-object System.Diagnostics.EventLog("Application")
$evt.Source=$strWhoAmI
$infoevent=[System.Diagnostics.EventLogEntryType]::Information
$strEventLogText = "Beginning processing."
$evt.WriteEntry($strEventLogText,$infoevent,70)
$MBXArray = @(Get-Mailbox | ? {($_.RecipientType -eq 'UserMailbox') -and ($_.UserAccountControl -notmatch 'AccountDisabled') -and ($_.ManagedFolderMailboxPolicy -eq $null)})

    ForEach ($Mailbox in $MBXArray) {
        $x=$x+1
        if($strShowStatus){
            Write-Progress -id 1 -activity "Applying Messaging Records Management policy '$strPolicyName'" -status $Mailbox.SAMAccountName -percentComplete (100/$MBXArray.count*$x) -CurrentOperation '' -SecondsRemaining ($MBXArray.count-$x)
        }
        Set-Mailbox -identity $Mailbox.SAMAccountName –ManagedFolderMailboxPolicy $strPolicyName -ManagedFolderMailboxPolicyAllowed -CustomAttribute13 $strMRM
        if($strLogEachUser){
            $strEventLogText = "Messaging Records Management policy '$strPolicyName' applied to "+$mailbox.DisplayName
            $evt.WriteEntry($strEventLogText,$infoevent,70)
        }
    }
############ Blank line after next line is intentional for cleaner event log entry ############
$strEventLogText = "Finished processing "+$MBXArray.count+" accounts.

For more information on Messaging Records Management, see http://technet.microsoft.com/en-us/library/bb310756.aspx."
$evt.WriteEntry($strEventLogText,$infoevent,70)

Create a scheduled task

The last piece of this is a scheduled task. This is quite easy. Go to Scheduled Tasks on the server (Control Panel–> Scheduled Tasks). Right click and choose New>Scheduled Task. Call the task what ever you like, such as AutoApplyMRMPolicy. Right click the task and choose Properties. For the RUN field, paste this:

c:\windows\system32\windowspowershell\v1.0\powershell.exe -psconsolefile "c:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1" -Command "AutoApplyMRMPolicy.ps1"

but change the -psconsole parameter to point to your \bin folder. The default path is shown. For the START IN field, enter the path to your \scripts folder, such as the default:

"c:\program files\microsoft\exchange server\scripts"

Set RUN AS to an administrator account. Click the Schedule tab and configure the task to run at least once a day. Be careful to ensure that it runs outside of your backup and maintenance windows. Click Ok. That’s all there is to it.

Some things to note:

The script will apply a policy to ALL users who are not disabled, resource accounts, or already configured for a policy. If you need it to be more restrictive, alter the line that starts with “$MBXArray =”

There is no error checking in the script. If there is enough call for that, I’ll work that into the script.

Feel free to make suggestions as to how to improve the script.

UPDATED 5/22/09: Cleaned up the array stuff a little per more Nick’s suggestions. Thanks, Nick!

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Donations

I’ve never been one to really solicit donations for my work. My offerings are created because *I* need to solve a problem, and once I do, it makes sense to offer the results of my work to the public. I mean, let’s face it: I can’t be the only one with that particular issue, right? Quite often, to my surprise, I’m asked why I don’t have a “donate” button so people can donate a few bucks. I’ve never really put much thought into it. But those inquiries are coming more often now, so I’m yielding to them. If you’d like to donate, you can send a few bucks via PayPal at https://www.paypal.me/PatRichard. Money collected from that will go to the costs of my website (hosting and domain names), as well as to my home lab.

This is the changelog page for New-DirectoryUpdateReminder.ps1. You will find a complete list of released versions, their dates, and the features and issues addressed in each. Please refer to the script’s main page for more information including download links, installation details, and more.

v1.7 – 01-27-2014

1. -noprofile switch added to install routine
2. bug fix for demo mode where the check for title wasn’t working
3. comment help cleaned up

v1.5 – 09-02-2011

1. converted code to PowerShell v2, including New-MailMessage, comment based help, etc.
2. Exchange 2010 support
3. moved most variables to param block
4. install routine for scheduled task
5. email preview mode

v1.4 – 03-27-2010

1. use registry for last run info

v1.3 – 01-15-2010

1. optimized $MBXArray a little more

v1.2 – 10-16-2009

1. added filter to prompt when manager is disabled

v1.0 – 05-14-2009

1. initial version