Automatic archive creation with Cmdlet Extension Agents

An Exchange fellow inquired about the possibility to automatically enable personal archives when creating mailboxes with the added requirement to create those personal archives in a specific mailbox database, depending on the location of the mailbox. Dedicated mailbox databases were used for personal archives. Simply said, the idea was that mailboxes located in database MDB1 should get a personal archive in mailbox database ADB1, MDB2 in ADB2, etc.

Your first thought could be creating a script to automatically provision those personal archives in the proper database depending on the mailbox database. But alas, when using Exchange 2010’s automatic mailbox provisioning system you never know upfront what mailbox database will be appointed.

That leads us to Exchange 2010’s Cmdlet Extension Agents, more specific the Scripting Agent. I won’t go into much detail now on those Agents, but look at them as a way to extend cmdlets by adding pre- and post-jobs, additional constraints, reporting or override parameters.

Now, when you haven’t already done so, first exclude the mailbox databases containing personal archives from automatic provisioning. If you have a dedicated server for hosting personal archives, use the IsExcludedFromProvisioning with the Set-MailboxServer cmdlet; to exclude a mailbox database use IsExcludedFromProvisioning with the Set-MailboxDatabase, e.g.

Set-MailboxDatabase <Archive Database ID> –IsExcludedFromProvisioning $true

image

I’ll first show you how the scripted version could work. We’ll start by creating some mailboxes. We don’t require anything fancy, so this will do:

$pwd= ConvertTo-SecureString -AsPlainText “Welcome1 -Force
1..10 | ForEach { New-Mailbox “User$_ -Password $pwd -UserPrincipalName user$_@<domain> }

A quick overview of the result shows the mailboxes are created in a round robin fashion:

image

What you could do now is enabling the archive on ADB1 for MDB1 and ADB2 for MDB2 mailboxes, e.g.

Get-Mailbox –Database MDB1 | Enable-Mailbox –Archive -ArchiveDatabase ADB1
Get-Mailbox –Database MDB2 | Enable-Mailbox –Archive -ArchiveDatabase ADB2

image

This is what we wanted. As you probably understand, the main disadvantage now is that this only works for the current mailbox population. Administrators should appoint the proper mailbox database for personal archives when creating new mailboxes. Can the Scripting Agent overcome this problem?

Let’s have a look on how to configure the Scripting Agent. Open up Notepad and create a file \bin\CmdletExtensionAgents\ScriptingAgentConfig.xml located in Env:ExchangeInstallPath, e.g. C:\Program Files\Microsoft\Exchange Server\V14\Bin\CmdletExtensionAgents, using the following contents:

<?xml version="1.0" encoding="utf-8" ?>
  <Configuration version="1.0">
  <Feature Name="MailboxProvisioning" Cmdlets="New-Mailbox">
  <ApiCall Name="OnComplete">
  If($succeeded) {
    $Name= $provisioningHandler.UserSpecifiedParameters["Name"]
    If ((Get-Mailbox $Name).ArchiveDatabase -eq $null) {
      $MailboxDatabase= (Get-Mailbox $Name).Database
      $ArchiveDatabase= "A"+ ( $MailboxDatabase.Name).Substring( 1)
      Enable-Mailbox $Name -Archive -ArchiveDatabase $ArchiveDatabase
    }
  }
  </ApiCall>
  </Feature>
  </Configuration>

A small explanation might be appropriate:

  • The Cmdlets specified in this feature extension dictates which cmdlets will be extended;
  • OnComplete dictates that our script will fire when the cmdlet has finished;
  • We check for OnComplete parameter $succeeded, only enabling archives when the preceding cmdlet was successful;
  • $provisioningHandler.UserSpecifiedParameters contains user provided parameters passed to the cmdlet. So, $provisioningHandler.UserSpecifiedParameters["Name"] will return the value of -Name;
  • We’ll check if the mailbox already has a personal archive configured; if not, we can proceed;
  • Next, we’ll get the current MailboxDatabase. Then we’ll map that to our personal archive naming scheme by stripping the first character and prefix it with “A”;
  • Finally, we can execute the cmdlet to enable the personal archive of the mailbox on the database specified.

Now, before we test our scripting agent, we need to distribute the XML file on all of our Exchange servers. The reason for this is that you don’t know which Exchange server an administrator will connect to or which server will execute the cmdlet. The location to copy the XML file to is the local CmdletExtensionAgents folder.

Now there’s one more thing we need to do, which is enabling the Scripting Agent. The Scripting Agent is disabled by default. Use the Enable-CmdletExtensionAgent cmdlet to enable it, e.g.:

Enable-CmdletExtensionAgent “Scripting Agent”

Now, when we use the same cmdlet we used before to create those mailboxes, we get the following result:

image

As you can see, archive databases are now nicely aligned with the automatically assigned mailbox databases.

A small note for those wishing to experiment with the Scripting Agent. Alternatively to OnComplete, you can also try defining the personal archive parameters using the ApiCall ProvisionDefaultProperties. This ApiCall can be used to define default attributes when creating a mailbox. However, this leads to a catch 22 situation and has to do with the Mailbox Resources Management Agent.

By default the Mailbox Resources Management Agent has higher priority (2) than the Scripting Agent (6). This means it will override any settings made in our Scripting Agent.

image

The Mailbox Resources Management Agent is responsible for the automatic mailbox distribution when you don’t specify a mailbox database when creating a mailbox. But it is also responsible for assigning a mailbox database for the personal archive when you don’t specify the ArchiveDatabase parameter.

So, unless we want to add all the automatic mailbox distribution logic to our script, we can’t use the ProvisionDefaultProperties ApiCall properly, because if we want to use that, we need to assign the Scripting Agent a higher priority than the Mailbox Resources Management Agent, but at that point we have no database value so we can’t determine the proper archive database.

If you’re interested in playing with this, check out the ScriptingAgentConfig.xml.sample file which is located in the CmdletExtensionAgents as well. If you’re looking for more information on Cmdlet Extension Agents, check here; information on the Scripting Agent can be found here. More information on the automatic mailbox distribution process here.

Setting up Disclaimers in Exchange 2010 SP1

Disclaimers are a controversial subject when added to e-mail messages; some lawyers think they should be mandatory for business communications, some think they’re just jibber-jabber. Fact of the matter is that your e-mail message may end up anywhere and in some countries you can’t legally bind recipients after receiving something he or she may not even wished to receive in the first place. If you’re interested, Exchange fellow Tony Redmond blogged shortly on some legal aspects of disclaimers in June here.

Despite the disputed legal status of these disclaimers, I am however consulted on how to configure them once in a while, so here’s how to implement them properly in Exchange 2010 SP1.

Disclaimers are set up using transport rules. You can inspect the current set of transport rules in the Exchange Management Console (EMC) under Organization Configuration > Hub Transport > Transport Rules or by using the Get-TransportRule cmdlet using the Exchange Management Shell (EMS). By default there will be no transport rules defined.

Before we begin you need to be aware of the following:

  • Transport rules will be processed in the order of priority. If a message meets the conditions configured in a transport rule, the actions defined in that rule will be processed. When done, the Exchange will continue evaluating transport rules with a higher priority number (so rule with priority will be evaluated first);
  • Adding disclaimers will invalidate signed and may corrupt encrypted messages.

This introduces the following complications:

  • When using multiple disclaimers, you need to mark the message after processing to prevent processing by one of the other transport rules. If you don’t, disclaimers will pile up at the end of your message.
  • Strangely enough, you can only make an exception for signed or encrypted messages, not both. This means that when you create a rule it is either for unsigned or unencrypted messages; what we want here is rules for unsigned, unencrypted messages.

To work around these limitations, we’ll use message classification for tagging encrypted or signed messages, so we can use that tag in the exception clause. In additional we’ll use custom message headers for flagging processed messages. Note that we could use custom headers for signed, encrypted messages as well but we don’t want to add yet another unnecessary named property.

We’ll start off by create the rules which are going to tag encrypted or signed e-mail messages. We choose to use message classifications for this purpose, so we need to add a new message classification first. This can only be performed using the EMS using the New-MessageClassification cmdlet:

New-MessageClassification “SignedOrEncrypted” –DisplayName “Signed or Encrypted Message” –SenderDescription “Signed or Encrypted Message” –PermissionMenuVisible:$false

image

The DisplayName and SenderDescription parameters are mandatory and their purpose is to state the purpose of the classification when displaying the message in Outlook. By setting PermissionMenuVisible to $false, users won’t be able to assign this classification to messages Outlook themselves.

Next, we’ll set up the transport rules to tag messages using this classification. Since these will be the first transport rules we’re going to create we don’t need to worry about the priority numbers yet. Since there isn’t much editing required with these rules, we can use EMS to define these rules:

New-TransportRule “Tag Encrypted Messages” –Enabled $true –MessageTypeMatches “Encrypted” –ApplyClassification “SignedOrEncrypted”

New-TransportRule “Tag Signed Messages” –Enabled $true –MessageTypeMatches “Signed” –ApplyClassification “SignedOrEncrypted”

image

Now we can start setting up the default (English) disclaimer using transport rules. This default disclaimer will be the default disclaimer attached to all outgoing e-mail messages. Using EMC, open up the Transport Rules tab and select New Transport Rule. Fill in a proper description and click Next.

Now we can select the conditions to meet in order for the rule to be processed. In this example, select From users that are inside or outside the organization and Sent to users that are inside or outside the organization or partners. In the bottom pane you can now fine tune these conditions by clicking on the underlined elements. Click Inside the organization, part of sent to users condition. Set this parameter to Outside the organization. When finished, click Next.

image

Next we’ll define the actions for this rule. First, select Append disclaimer text and fallback to action if unable to apply. In the bottom pane, leave append unchanged so the disclaimer will be added to the bottom of the message. Note that Exchange can’t insert the disclaimer below replies, only at the end of the complete message. Click disclaimer text and insert your disclaimer text in the editing window. Note that you can use HTML here as well as certain Active Directory attributes to make the disclaimer dynamic. For information on which Active Directory attributes are available, consult this TechNet article. When make use of HTML options, I suggest editing it in an HTML editor or something similar, so you can preview the result. Also, when using styles include those as well. Finally, leave wrap unchanged so Exchange will create a new message using the disclaimer text attach the original message attached if the disclaimer can’t be inserted in the original message.

Second, check Set header with value. Set header to X-Disclaimer and value to Yes. Note that this value is case-sensitive when we’re matching it later on. When finished, click Next.

image

Now we can enter exceptions for this rule. Select Except when the message is marked as classification and set classification to Signed or Encrypted Message. This will make sure that signed or encrypted messages tagged earlier will be skipped. Also check Except when the message header contains specific words; set Message header to X-Disclaimer and specific words to Yes. This will make sure the message is skipped when we’ve already added a disclaimer. When done, click Next.

image

Check the generated cmdlet on the configuration summary screen and click New to create the transport rule. Click Finish when done. Note that this rule will be added with Priority 0, so you need to alter the order setting Priority of this rule to the highest value possible, e.g. 2. As stated before, rules will be evaluated in ascending priority order.

Now we’re set up for a default disclaimer in English, but suppose you want to add a different disclaimer in a different language for users working in a different country. In order to establish this repeat the above steps for creating a disclaimer using transport rule, but at the conditions page add an additional condition by selecting When the sender’s properties contain specific words, setting the Property CountryOrRegion to the country code required, e.g. NL. To see which country code you need to use, consult the ISO 3166 table or check the C attribute in Active Directory (CountryOrRegion in OPATH maps to the C attribute in LDAP).  Needless to say, this filtering requires that the sender’s Country has been configured properly in Active Directory.

image

Then on the actions page, configure the alternative disclaimer text. After saving, don’t forget to put this rule before the default disclaimer rule by changing it’s Priority to n-1 , i.e. when the default disclaimer has priority 3 set the priority for this country specific disclaimer to 2.

image

The way this works is as follows:

  1. The first two rules will set the classification to SignedOrEncrypted for signed or encrypted messages;
  2. The Disclaimer NL rule checks the sender’s CountryOrRegion attribute; when it’s NL and the message isn’t classified as SignedOrEncrypted and the message doesn’t contain an “X-Disclaimer” header field with a value of “Yes”, it will add the configured disclaimer and set the header field “X-Disclaimer” to “Yes”;
  3. The Disclaimer (Default) rule checks if the message isn’t classified as SignedOrEncrypted and the message doesn’t contain an “X-Disclaimer” header field with a value of “Yes”. When both are not true, it will add the configured disclaimer and set the header field “X-Disclaimer” to “Yes”. This rule will be skipped for messages by sender with CountryOrRegion NL because the Disclaimer NL rule will be processed earlier and will add X-Disclaimer=Yes to the header.

Visio of Exchange 2010 SP1 Network Ports Diagram v0.31

By popular demand and since many of you requested this: I’ve put the Visio file of the Exchange 2010 SP1 Network Ports Diagram online. The original post in PDF format is of April 5th.

If you got any comments or additions worth sharing, do not hesitate to write ‘em down in the comments or send me an e-mail. When used, crediting or a reference is appreciated.

The Visio document can be downloaded from here.

The case of the missing Free/Busy public folder

A customer who recently migrated to Exchange 2010 and was still in the co-existence setup with Exchange 2003, reported lots of users experiencing issues with regards to Free/Busy information. Symptoms were inaccurate or missing Free/Busy information, which especially gets annoying when scheduling appointments.

It turned out these users were using Outlook 2003; users on Outlook 2007 or later experienced no issues. As you probably know, Outlook 2003 still utilizes public folders to publish users’ Free/Busy information. This information is consulted by Outlook 2003 when scheduling appointments; Outlook 2007 or later uses Exchange Web Services for this purpose.

A quick look in the Eventlog revealed lots of 14031 errors were generated by the FreeBusy Assistant:

Err14031

This told us Exchange was unable to store Free/Busy information in a public folder, in this case /o=EUROPE/ou=First Administrative Group. A quick look at the Public Folder Management Console in Exchange 2010 showed that the folder didn’t exist. Since the Free/Busy public folder to be used by an Outlook 2003 user is determined by the legacyExchangeDN attribute, this was the cause of the issue.

The reason for the folder’s absence was unknown so one can only speculate. My best guess is improper decommissioning of the organization and administrative group originally hosting those users, identified by that “orphaned” legacyExchangeDN.

With the Free/Busy public folder missing and the original Exchange infrastructure gone, there are two alternatives to resolving this issue, apart from upgrading clients to a recent version of Outlook of course:

  1. Edit the legacyExchangeDN attribute of the users affected;
  2. Recreate the Free/Busy public folder.

The 1st option has consequences for the users, like being able to reply to earlier e-mail by co-workers. This can be resolved by adding the current legacyExchangeDN as an X500 address to the current set of e-mail addresses, but that also makes things a bit messy.

The 2nd option is to recreate the Free/Busy public folder; Here’s how to proceed:

  1. First, using the Exchange System Manager (luckily, Exchange 2003 was still present), create an Administrative Group, e.g. First Administrative Group
  2. Then, using ADSIedit.msc, navigate to CN=<Administrative Group>,CN=Administrative Groups,CN=<Organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>
  3. Right-click the Administrative Group, e.g. First Administrative Group, and click Properties. There, edit the legacyExhangeDN attribute. Set it to match the missing Free/Busy public folder, e.g. /o=EUROPE/ou=First Administrative Group
  4. Next, edit the siteFolderServer attribute. Set it to match the distinguishedName of a a public folder database. Note that you can pick the Exchange 2003 as well as Exchange 2010 Public Folder database here. In this example, I picked the Exhange 2003 public folder database, hence the storage group (SG1):

siteFolderServer

Now we need to wait for the store to recreate the Free/Busy public folder during its maintenance cycle, which may take up to 24h. If you’re in a hurry, and the situation allows you because of the service interruption, you can also restart the Information Store. When the Information Store has created the Free/Busy public folder, event 3047 is logged by the MSExchangeIS Public Store:

Recreate_FB_PF

To verify this, startup the Public Folder Management Console or any other Public Folder management tool, and you’ll see the newly created folder:

PFMC_Appear

After a while you’ll notice Outlook 2003 users are now storing their Free/Busy information in this public folder and Free/Busy will work again for these users. You can verify clients are storing Free/Busy information using EMS, ExFolders or MFCMAPI, e.g.:


Finally, don’t forget to create replicas of this new Free/Busy public folder when appropriate.

Exchange 2010 SP1 Rollup 4 v2

After pulling Rollup 4 for Exchange Server 2010 SP1 on July 13th, after potential data loss issues were discovered during folders movements, and publishing an intermediate hotfix to resolve the RU4 issues without a rollup rerelease, the Exchange team decided to publish an updated version of rollup 4. This is somehow unexpected because of the expected release of rollup 5 in August. It’s good to see the Exchange team getting very open in this post about recent missteps in published rollups for such a mission critical application.

Exchange 2010 SP1 Rollup 4 v2 raises Exchange 2010′s version number to 14.1.323.6 (initial release was 14.1.323.1). The related knowledgebase article is kb2579150.

For the correct procedure on how to update a DAG and its members, check here.

You can download Exchange 2010 SP1 Rollup4 v2 here.

Exchange 2010 SP1 RU4 pulled

Just a quick notice that few minutes ago the Exchange Team pulled Exchange Server 2010 Service Pack 1 Rollup 4.

As reported earlier, there were potential data loss issues with this rollup when moving folders around in public folders or PST files using any version Outlook; Note that moving folders using OWA through Exchange Web Services works fine.

A fix for this issue will be incorporated in the RU5 update which is scheduled for August. So, like RU3 v2 v3 which took about a month to appear after the initial RU3 release was pulled, we’ll have to wait until August for RU5.

For those who already deployed RU4 an interim update has been made available that fixes this issue. The interim update can be obtained by contacting support.

 

Managing Remote IP Ranges of Receive Connectors

When managing receive connectors in Exchange, you probably had to configure IP addresses or IP ranges on those receive connectors. This may be required when limiting access to a certain receive connector for applications to drop their mail using SMTP. Of course this can be done using the Exchange Management Console, but this may become tedious when lots of addresses are involved. Also, when multiple Hub transport servers are involved you may need to keep those IP ranges in sync on those Hub Transport servers in which case mismatches are likely.

As you’ve probably guessed, a little PowerShell makes life more easier. To configure the allowed IP ranges we need to use Set-ReceiveConnector and configure the RemoteIPRanges attribute. We’ll use a text file to maintain the list of allowed IP ranges and a PowerShell one-liner to set RemoteIPRanges.

The file should contain IP ranges in a RemoteIPRanges acceptable format, e.g.:

  • 192.168.1.10
  • 192.168.1.20-192.168.1.29
  • 192.168.2.0/24

When we have prepared the file, we can use the following cmdlet to set RemoteIPRanges:

Get-ReceiveConnector *\APPRELAY | Set-ReceiveConnector -RemoteIPRanges (Get-Content RemoteIPRanges.txt)

This will configure all receive connectors named APPRELAY on all Hub Transport servers in the organization using IP ranges defined in the file RemoteIPRanges.txt. Be advised that this cmdlet overwrites the current configuration of RemoteIPRanges; if you need to add it to the current configured set of IP ranges on each receive connector, use the following cmdlet:

Get-ReceiveConnector *\Appl-Relay | ForEach { Set-ReceiveConnector -RemoteIPRanges ($_.RemoteIPRanges+ (Get-Content ipranges.txt) | Sort -Unique) }

By adding the Sort -Unique filter, we make sure each range is only specified once. This prevents errors caused by setting a range using the RemoteIPRanges.txt file when that range has already been configured in the current value of RemoteIPRanges.

Note that when inspecting the results you can set $FormatEnumerationLimit to a value higher than the default (16) to have Get-ReceiveConnector * | fl RemoteIPRanges display all its values. Also, keep in mind when configuring connectors that the connector with the most specific matching IP address wins.

Exchange 2010 SP1 Update Rollup 4 Issues

Be advised that in addition to earlier reports, there are not only data loss issues with Exchange 2010 SP1 Rollup 4 when moving folder structures from public folders to mailboxes or other public folders.  Apparantly, data loss can also occur when moving folder structures to PST files. In both cases, only the top folder and messages are moved, subfolders and their contents are not moved but deleted.

On the issue, Microsoft’s Ross Smith said the following:

In SP1 RU4 we addressed the issue where you could not recover deleted public folders from dumpster. However, Outlook incorrectly passes a flag that indicates the item has been deleted when it has not.  As a result, when you perform a copy or move in the manner Jens described, the sub-folders are deleted.  As mentioned previously, you can recover these deleted folders from dumpster.  We’ve contacted the Outlook team to assist in further diagnosis of the issue and to help us determine the right vehicle for a fix, we’ll provide more details soon – in the meantime please open a CSS case.

You can uninstall Rollup 4 from your Exchange servers to prevent potential data loss caused by these issues.

Note that Rollup 5 is scheduled for August, so you might start to wonder what will arrive first, RU5 or RU4v2.

Creating Batches of Legacy Mailbox Move Requests

When migrating users from Exchange 2003 to Exchange 2010, you get to a point where you actually want to move all those Exchange 2003 mailboxes. When you have a decent environment and a lot of mailboxes are involved, you perhaps may want to move those mailboxes in a more phased, batch-oriented fashion.

If so, perhaps the following one-liner may come in handy, which is to be executed from the Exchange Management Shell:

Get-Mailbox -RecipientTypeDetails LegacyMailbox -ResultSize Unlimited | Where { ($_.MailboxMoveStatus -eq ‘None’) -and ( $_.WhenChanged -lt (Get-Date).AddDays(-1)) } | Select -First 100 | New-MoveRequest

I’ll talk you through the one-liner:

  • We’ll start off by selecting all mailboxes using Get-Mailbox using an unlimited result size (defaults to 1,000). By selecting only “LegacyMailbox” using the RecipientTypeDetails parameter, we’ll only select the Exchange 2003 mailboxes;
  • Next, we filter the those mailboxes on the following properties:
    • MailboxMoveStatus. By selecting “None”, we get mailboxes not in the process of being moved;
    • WhenChanged. We select mailboxes unaltered in the last 24 hours to accomodate for users currently accessing their mailbox (since it’s an offline move). For this purpose, we take the current timestamp (Get-Date) and subtract 1 day (by adding -1 day which is the same).
  • Then  we select only the first N (the sample uses 100) mailboxes of the result (or lower if there are less mailboxes elegible so far);
  • Finally we pipe that to New-MoveRequest. We don’t mention any Remote parameters so it’s a local move. Also, by omitting the target database, we let Exchange select an Exchange 2010 database.  This is done in a round-robin fashion (as you can see below) and does all the work for us like checking availability of the database as well the auto provisioning status of those databases or servers.

Now you can start or schedule this and check back in the morning on the results. When situation requires, you can start off using smaller batches increasing things depending on the results, ultimately leaving out the Select and date condition altogether.

And don’t forget to clean up those move requests afterwards.

Exchange 2010 SP1 Update Rollup 4

Update June, 29th: Reports of issues with PF after installing RU4 here (comments section). Exchange fellow Paul Cunningham reproduced a PF issue which can lead to data loss. More about this on his blog here. Once again I emphasize to properly test updates prior to implementing in production. Although I’m aware of possible budget constraints, not having a proper test environment in fact means you have no production environment.

Today the Exchange Team released Rollup 4 for Exchange Server 2010 Service Pack 1 (KB2509910). This update raises Exchange 2010 version number to 14.1.323.1.

After the rollup 3 debacle, I’d recommend to thoroughly test rollup 4 in a test and acceptance environment prior to implementing it in production.

Here’s the big list of changes included in this rollup:

  • 2537099  “80040154″ error message when you try to configure external Client Access namespaces on an Exchange Server 2010 server
  • 2536700  Outlook stops responding when you try to copy a folder to its subfolder by using Outlook in online mode in an Exchange Server 2010 SP1 environment
  • 2536517  The Microsoft Exchange RPC Client Access service crashes intermittently on an Exchange Server 2010 server
  • 2536494  It takes a long time to return results when you perform an Advanced Find search on a mailbox by using Outlook in online mode in an Exchange Server 2010 SP1 environment
  • 2535648  The EMC takes a long time to open in an Exchange Server 2010 environment
  • 2535130  Performance in Outlook or in OWA decreases when you use IMAP4 to access the contacts folder in an Exchange Server 2010 environment
  • 2535105  There is no option to disable the Availability service in an Exchange Server 2010 environment
  • 2533543  Event ID 2153 is logged on each database availability group member in an Exchange Server 2010 environment
  • 2533538  You cannot look up the free/busy information of a user who is located on an Exchange Server 2010 organization from another Exchange Server 2010 organization
  • 2533451  A RBAC role assignee can unexpectedly run the “Update-FileDistributionService” command on an Exchange Server 2010 server that is outside the role assignment scope
  • 2519359  “Changes to the rule cannot be saved.” error message when you try to create a reply rule by using Outlook in an Exchange Server 2010 environment
  • 2518850  You cannot receive email messages on a mobile phone by using ActiveSync in an Exchange Server 2010 environment
  • 2517088  Public folder conflict resolution does not work as usual in an Exchange Server 2010 environment
  • 2515259  “The items could not be copied.” error message when you run the Get-MailboxSearch cmdlet in an Exchange Server 2010 SP1 environment
  • 2514709  Event ID 1001 after you successfully the install Exchange Server 2010 Unified Messaging server role
  • 2514574  The Exchange RPC Client Access service crashes in an Exchange Server 2010 environment
  • 2513723  The “New-MailboxImportRequest” cmdlet does not import all messages in a .pst file in the ANSI format in an Exchange Server 2010 environment
  • 2512023  “GetUserOofSettings”, “SetUserOofSettings” and “GetUserAvailability” operations do not support Exchange Impersonation on the Exchange Server 2010 SP1 schema
  • 2511897  You cannot send an email message to a mailbox for a brief period when you move the mailbox by using online move in an Exchange Server 2010 environment
  • 2507463  You cannot move a mailbox that contains a corrupted Search Folder in an Exchange Server 2010 environment
  • 2506820  The free/busy information does not display of a user whose mailbox is located on an Exchange Server 2003 server
  • 2506049  The hierarchy of a new public folder database on an Exchange Server 2010 SP1 server is not replicated
  • 2505968  The EdgeTransport.exe process crashes when you apply a rule that contains a bad email address in an Exchange Server 2010 environment
  • 2504453  You cannot retrieve statistical information about a public folder by using the “Get-PublicFolderStatistics” cmdlet in an Exchange Server 2010 SP1 environment
  • 2503337  Comments of your meeting response message is missing when you decline a meeting request in an Exchange Server 2010 environment
  • 2501070  A RBAC role assignee can stop queue processing on an Exchange Server 2010 Hub Transport server or an Exchange Server 2010 Edge Transport server that is outside the role assignment scope
  • 2500903  A space is missing in the subject line of a “Tentative” meeting response in an Exchange Server 2010 environment
  • 2500648  “There are no items to show in this view.” error message when you try to view a folder in Outlook in an Exchange Server 2010 environment
  • 2495167  You cannot recover a deleted public folder by using Outlook or MFCMAPI in an Exchange Server 2010 environment
  • 2495010  The EdgeTransport.exe process consumes 100% CPU usage on an Exchange Server 2010 Edge Transport server or an Exchange Server 2007 Edge Transport server
  • 2493393  You cannot use ECP to perform a wipe on a mobile phone in an Exchange Server 2010 SP1 environment
  • 2492068  “The item cannot be saved to this folder.” error message when try to post an item to a mail-disabled public folder in an Exchange Server 2010 SP1 environment
  • 2491354  You cannot view the free/busy information of users in a mixed Exchange Server 2007 and Exchange Server 2010 environment
  • 2490134  A deferred delivery email message is not delivered by using Outlook 2007 in online mode in an Exchange Server 2010 environment
  • 2489964  An update enables range 0x-0x1F characters in the display name of an Exchange Server 2010 user account
  • 2489938  The “Connect-ExchangeServer” function does not change the target Exchange server in Exchange Server 2010
  • 2489130  A RBAC role assignee can unexpectedly change mailbox properties that are outside the management role group scope in an Exchange Server 2010 environment
  • 2488643  Outlook downloads duplicated POP3 email messages in an Exchange Server 2010 environment
  • 2479188  The iCal parts of an email message contain invalid entries when they are sent from an Exchange Server 2003 mailbox to an Exchange Server 2010 mailbox
  • 2477273  The DomainController parameter does not work when you use the “MoveMailbox.ps1″ script to move mailboxes in an Exchange Server 2010 environment
  • 2471964  A NDR is sent to the sender when you move an email message to a personal folder file in an Exchange Server 2010 SP1 or a later version environment
  • 2467619  A user who manages a distribution group cannot remove another user whose mailbox is disabled in an Exchange Server 2010 environment
  • 2465292  “MAPI_E_FAILONEPROVIDER (0x8004011D)” error message when you access an Exchange Server 2010 mailbox by using a MAPI application
  • 2446908  ESE event descriptions are missing in Event Viewer when the Eseutil utility is called on an Exchange Server 2010 SP1 server
  • 2394554  An email message is not delivered if it contains unsupported encoded characters in the subject line in an Exchange Server 2010 environment
  • 2491951  You cannot install Exchange Server 2010 SP1 if the NetBIOS domain name of the domain controller contains an ampersand (&) character
  • 2507066  Administrator audit logging is disabled unexpectedly during an Exchange Server 2010 SP1 installation

When running ForeFront Protection for Exchange, make sure you disable ForeFront before installing the rollup and re-enable it afterwards, otherwise the Information Store and Transport services may not start. You can disable ForeFront using fscutility /disable and enable it using the fscutility /enable command.

For the correct procedure on how to update a DAG and its members, check here.

Note that update rollups are cumulative, i.e. they contain fixes released in earlier update rollups for the same product level (RTM, SPx). This means you don’t need to install previous update rollups during a fresh installation but can start with the latest rollup available right away.

You can download Exchange 2010 SP1 Rollup 4 here.