Exchange 2010 RTM Rollup 4

Posted on by
Reply

Microsoft released Rollup 4 for Exchange Server 2010 RTM (KB982639). This update raises Exchange 2010 version number to 14.0.702.1.

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

  • 979342 An attachment is not visible when an Exchange Server 2010 user opens a signed mail message by using Outlook 2003
  • 979517 You cannot send a message to a Dynamic Distribution Group in a mixed Exchange Server 2007 and Exchange Server 2010 environment
  • 979790 An IMAP4 client crashes when accessing an Exchange Server 2010 mailbox
  • 979801 An error message is generated in Exchange Server 2010 when you use Exchange Troubleshooting Assistant
  • 979810 You cannot connect an Exchange Server 2010 mailbox by using a MAPI client
  • 979848 Event ID 1066 is logged and you cannot move a mailbox from an Exchange Server 2003 server to an Exchange Server 2010 server
  • 979862 Event ID 4999 and Event ID 7031 are logged when you move a mailbox to an Exchange Server 2010 server
  • 979921 You cannot replicate a public folder from one Microsoft Exchange Server 2010 server to another, and Event ID 3079 is logged on the target server
  • 980149 The Add-MailboxDatabaseCopy command fails when it is used to add a database copy to a Database Availability Group in an Exchange Server 2010 environment
  • 980353 A MAPI application that is used to access Exchange Server 2010 mailboxes crashes when the application accesses an address book
  • 980354 “MAPI_E_INVALID_PARAMETER” error message when you copy email messages from an Exchange Server 2010 mailbox
  • 980364 Microsoft Exchange Transport service on an Exchange Server 2010 server crashes when a certain message is processed
  • 980701 An Exchange Server 2010 mailbox user receives a NDR error message when the user sends an email message to multiple internal users
  • 980852 The RpcClientAccess process on an Exchange Server 2010 server crashes when you access a mailbox by using a MAPI application
  • 981033 Error message when you expand the Microsoft Exchange On-Premises node in the EMC of Exchange Server 2010
  • 981961 Event ID 4033 is logged and the Free/Busy replication from an Exchange Server 2003 server to an Exchange Server 2010 server fails
  • 982209 Some embedded messages are corrupted when they are contained in a message that is sent from an Exchange Server 2010 mailbox address
  • 982378 A delegate receives only one meeting request when someone sends a meeting request to several principals in an Exchange Server 2010 RU1 or later environment
  • 982944 The msExchVersion attribute value of a user is stamped incorrectly after you run the Enable-MailUser cmdlet to mail-enable the user
  • 983200 The .xls file as an attachment is empty when you access an Exchange Server 2010 mailbox by using OWA
  • 983631 “redirect it to people or distribution list” rule does not work on an Exchange Server 2010 mailbox address
  • 2084061 A user intermittently fails to access an Exchange Server 2010 mailbox after the mailbox is moved

The last fix is interesting because we (me and Johan) are experiencing the issue during a cross-forest migration.

To download this rollup, click here. The Exchange versions, builds and dates table has been updated accordingly and can be found here.

Jetstress 2010 & LoadGen 2010 RTM

Posted on by
Reply

In the long list of recent Exchange news today Microsoft published the RTM versions of Exchange Jetstress 2010 and Load Generator AKA LoadGen 2010.

Both tools are now at version 14.01.0180.003.

Jetstress can be used to check performance and stability of storage under load. It simulates Exchange I/O behaviour for Exchange 2003, 2007 or 2010 in order to verify dimensioning and check if storage meets performance expectations for a certain number of users with a certain I/O profile.

LoadGen can be used to simulate MAPI, OWA (2007, 2010 or 2010SP1), EAS, IMAP, POP and SMTP client load against Exchange 2007 or 2010 servers. LoadGen will use real clients to simulate the load and, like Jetstress, LoadGen can be used to verify dimensioning and check if the design meets performance expectations.

Unlike Jetstress, which can be used to verify things from a database perspective, LoadGen can be used to verify things from a client (handling) perspective.

You can download the Jetstress 2010 here and LoadGen 2010 here (x64, x86 version here).

Note: If you used the beta version of JetStress you should recreate the databases for the RTM version as Doug Gowans found out.

Exchange Mailbox Role Calculator updates

Posted on by
Reply

Updates? Yes, updates. Both the Exchange 2007 Mailbox Role Calculator as well as the Exchange 2010 Mailbox Role Calculator have been updated.

The Exchange 2010 Mailbox Role Calculator has been updated to version 7.7 (was 6.3, so major update). This version includes the following enhancements:

  • 32-core support;
  • Fourth mailbox tier in the calculator;
  • Two new columns to the primary data center “Active Database Configuration / DAG” table to expose the total number of databases activated in each site after server failure events. This change was added to expose cross-site database fail-over events;
  • Option to activation block secondary data center mailbox servers that host HA database copies. This allows you to design a solution where you can activate the secondary data center in the event of a primary data center failure mode, or choose to activate a copy in the secondary data center manually, but prohibits Active Manager from automatically activating a copy in the secondary data center;
  • Modified IOPS Multiplication Factor calculations from “Base + (Base * Multiplier)” to “Base * Multiplier” to accommodate some 3rd party factors (so now you should use 1.5 instead of 0.5).

Besides enhancements, the updated Exchange 2010 Mailbox Role Calculator also contains some bug fixes which are described in the changeblog. You can download the updated calculator here. Usage instructions can be found here.

Regarding the Exchange 2007 Mailbox Role Calculator, it has been updated to version 17.5 (was 17.3). It contains some minor fixes. The Exchange 2007 Mailbox Role Calculator can be found here (changeblog, instructions).

New-MoveRequest changes for Exchange 2010 SP1

Posted on by
Reply

Note: The following information is based on Exchange 2010 SP1 Beta and subject to change in the final product.

If you transferred mailboxes using PowerShell or performed cross-forest mailbox moves using Exchange 2010 you’re probably familiair with the New-MoveRequest cmdlet. This cmdlet is used to initiate an asynchronous mailbox move talking to the Mailbox Replication Service (MRS) located on one of the Exchange Servers hosting the Client Access Server role. A few changes have been made to the New-MoveRequest cmdlet in Exchange 2010 SP1, which I would like to share with you.

The first interesting new option is the Outbound parameter. With Outbound  you can specify that the cross-forest mailbox move is to be initiated from the source forest. To initiate the move from the target forest you can use the Remote (identical to RTM). Note that Outbound and Remote are mutually exclusive.

Because of Exchange 2010 SP1’s capability to host the personal archives on a different database than the associated primary mailboxes, the following parameters have been added to New-MoveRequest for SP1:

  • ArchiveOnly can be used to specify that you want to move the personal archive only;
  • PrimaryOnly can be used to specify that you want to move the primary mailbox only;
  • ArchiveTargetDatabase can be used to specify the database you want to move the personal archive mailbox to. When omitted, the database hosting the primary mailbox will be used;
  • RemoteArchiveTargetDatabase can be used to specify the database in the remote forest you want to move the personal archive mailbox to. When omitted, the database hosting the primary mailbox will be used.

This enables you to bulk transfer the personal archives to another database using simple cmdlets. For example, to select all mailbox users with personal archives and move those personal archives to another database you could use:

Get-Mailbox | where { $_.ArchiveDatabase -ne $null } | New-MoveRequest -ArchiveOnly -ArchiveTargetDatabase MDB02


Like with regular mailbox move requests, you need to clean up afterwards by clearing completed moves. You could do that from EMC or use the following command in EMC:

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest

The updated New-MoveRequest cmdlet will also enable you to immediately create the associated personal archive on a seperate database when performing cross-forest mailbox moves:

$cred = get-credential
New-MoveRequest -Identity UserA -RemoteLegacy -TargetDatabase MDB1 -TargetArchiveDatabase MDB2 -RemoteGlobalCatalog dc.olddomain.nl -RemoteCredential $cred -TargetDeliveryDomain targetdomain.com

Note that this cmdlet will not enable archiving for moved mailboxes.

Finally, the EMC has been updated to reflect the possible split between primary mailbox location and personal archive location when moving mailboxes around. When selecting Mailbox > .. Move Request (Local or Remote), you’ll have additional options:

For more background on mailbox moves in Exchange 2010 and the role of the Mailbox Replication Service, please consult this TechNet article.

Goodbye IsInteg, hello new-MailboxRepairRequest

Posted on by
18

Update (2/23/2010): Adjusted request limits to SP1 RTM.

Update (8/24/2010): The Exchange team at EHLO posted a blog on IsInteg replacements. This article has been updated with the information that there is also a cmdlet to integrity check public folder databases.

Note: The following information is based on Exchange 2010 SP1 Beta and subject to change in the final product.

As of Exchange 2010 the well-known IsInteg tool was dropped. The IsInteg tool could be used with earlier versions of Exchange to detect and repair inconsistencies in the Exchange databases also known as information stores. IsInteg was complimentary to ESEUtil; Where ESEutil is used for maintaining, verifying and repairing ESE databases (which could happen to be Exchange databases), IsInteg is used to check and repair the integrity of Exchange databases. Note that for the tools to work you had to take your Exchange databases offline. Also, the process could take a while with large databases.

Then came Exchange 2010’s with it’s online database maintance. The database maintenance runs 24 x 7 on your Exchange 2010 databases in the background, without the need to take databases offline. The ESEUtil is still installed when you install an Exchange 2010 Mailbox Server role. Its purpose shifted from maintenance (which is now done 24 x 7) to inspecting and recovering ESE databases. Jaap Wesselius has written a nice article on using ESEUtil in Exchange 2010.

IsInteg is also installed with the Mailbox Server role (default location C:\Program Files\Microsoft\Exchange Server\V14\Bin). But please, don’t use it. IsInteg hasn’t been updated to understand Exchange 2010’s new database structure. But I hear you asking, without IsInteg, how can you (manually) check database integrity?

This is where the SP1’s new cmdlet New-MailboxRepairRequest comes into play. This cmdlet is meant to be a replacement for IsInteg ability to check & repair the integrity of mailbox databases integrity. New-MailboxRepairRequest can be used to detect and fix mailbox corruption, per mailbox or per database. This functionality is an improvement over IsInteg, since you can not only check databases but individual mailboxes as well without taking databases offline. Even better, only the mailbox that is currently being checked becomes unavailable; all other mailboxes in the databases remain fully operational.

The syntax of New-MailboxRepairRequest is as follows (left common parameters like Confirm and WhatIf out):

new-MailboxRepairRequest [-Mailbox <MailboxID> | -Database <DatabaseID>] -CorruptionType <CorruptionType> [-DetectOnly] [-DomainController <FQDN>]

which dissects into:

  • With Mailbox or Database you select if you want to perform the check against a mailbox or database (i.e. all mailboxes in a database) and against what identity;
  • CorruptionType specifies the sort of checks you want to perform (multiple can be specified, comma seperated). Possible values are:
    • SearchFolder: Search for folder corruption;
    • AggregateCounts: Check aggregate counts on folders;
    • ProvisionedFolder: Check for provisioned folders with unprovisioned parent folders;
    • FolderView: Check folder views returning incorrect results.
  • DetectOnly specifies if you want the cmdlet to fix problems it finds (similar to IsInteg’s fix parameter);
  • DomainController can be used to specify a preferred domain controller to update changes.

For example, to run all checks on the mailbox of ‘Michel’, without automatic repair, execute the following from the Exchange Management Shell:

New-MailboxRepairRequest -Mailbox <MailboxID> -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView -DetectOnly

To run the SearchFolder check on the mailbox database ” with automatic repair, execute the following from the Exchange Management Shell:

New-MailboxRepairRequest -Database <DatabaseID> -CorruptionType SearchFolder

As you can see, New-MailboxRepairRequest doesn’t show any results. For that, you need to open the application eventlog of the Exchange Server hosting the mailbox or (active) database you checked or repaired and look for ‘MSExchangeIS Mailbox Store’ events. Use the RequestID the cmdlet new-MailboxMoveRequest returned to look up the events. It will log when it started (and what parameters were specified) and log results. In the example above, New-MailboxRepairRequest returned 2661da49- … for the mailbox check. As we can see, the integrity check of the mailbox was succesful.

Exchange 2010 SP1 will also introduce a new cmdlet to repair public folder replication issues. The cmdlet to use is:

New-PublicFolderDatabaseRepairRequest -Database <DatabaseID> -CorruptionType <CorruptionType> [-DetectOnly]

where CorruptionType can be ReplState (no other values possible).

Be advised that, like ESEUtil and IsInteg, repairing an Exchange database or mailbox might cause data loss. To bring the mailbox or database back to a readable and consistent state the utility might cut out the parts it doesn’t understand .. with an axe.

And finally a quick note that to avoid possible performance issues the number of repair requests is 1 for database-level repairs and 100 for mailbox-level repairs per server.