Export (0) Print
Expand All

White Paper: Database Integrity Checking in Exchange Server 2010 SP1

 

Topic Last Modified: 2011-08-01

Steve Bryant

June 2011

Microsoft Exchange Server 2010 Service Pack 1 (SP1) has reintroduced the functionality that was previously provided by the Information Store Integrity Checker (ISInteg) tool. The following set of Exchange Management Shell cmdlets are included with Exchange 2010 SP1:

  • New-MailboxRepairRequest

  • New-PublicFolderDatabaseRepairRequest

This white paper describes how to use these cmdlets to find and eliminate errors from the public folder and mailbox databases

In versions of Microsoft Exchange Server earlier than Exchange 2010, the ISInteg tool found and eliminated errors from the public folder and mailbox databases at the logical level. ISInteg was a stand-alone program, and the database had to be offline while ISInteg checked its integrity.

Because of the overhaul of the Store’s schema in Exchange 2010, the old ISInteg tool could not work with the new schema. A new integrity checking solution was required. The new integrity checking solution is included with Exchange 2010 SP1.

In Exchange 2010 SP1, an integrity checking solution is provided by the following Exchange Management Shell cmdlets:

New-MailboxRepairRequest

New-PublicFolderDatabaseRepairRequest

noteNote:
These cmdlets are still subject to the same Role-Based Access Control (RBAC) scoping restrictions as other mailbox cmdlets. For more information about RBAC, view the topic Understanding Role Based Access Control.

The following list describes the new functionality that is provided with the new integrity checking cmdlets:

  • Integrity checking works at the database or mailbox level. The new schema in Exchange 2010 effectively partitions the database by mailbox. Therefore, the top problems that are fixed by integrity checking are now mostly limited to the affected mailboxes.

  • Earlier versions of the ISInteg tool require the database to be offline when validation and fixing are in progress. The integrity checking solution included with Exchange 2010 SP1 enables you to do these checks at the mailbox level. This means that you do not have to dismount the database.

  • The new integrity checking solution writes to the event log instead of writing to text files as in earlier versions.

The New-MailboxRepairRequest cmdlet detects and fixes the following types of mailbox corruption:

  • Search folder corruption (SearchFolder) Repair tasks now look for all folders named in ptagSearchBacklinks, ptagSearchFIDs, and ptagRecursiveSearchFIDs and verifies that each folder exists. If the folder no longer exists, it will remove that folder from the list.

  • Aggregate counts on folders (AggregateCounts) For Aggregate counts on folders that are not reflecting correct values, repair tasks will tally all messages in a folder and keep a running total of various counts and sizes. Once the iteration is complete, it will verify the computed counts against the persisted counts on the Folders table record for the folder. If there is a difference, it will update the persisted counts to reflect the computed counts.

  • Views on folders (FolderView) For views on folders that are not returning correct contents, repair tasks will iterate over all views for a folder and for each one, bringing the view fully up to date and will then reconstruct a temp copy. If there is a difference between the existing view and the contents of the temp table, it will delete the view so that it can be rebuilt from scratch the next time that it is requested.

  • Provisioned folders (ProvisionedFolder) For Provisioned folders that are incorrectly pointing into unprovisioned parent folders, repair tasks can fix Provisioned folders incorrectly pointing into an unprovisioned parent or vice-versa.

  • Missing ptagCn (MessagePTagCn) This switch resolves issues where the Message ptagCn property tag is missing or invalid. This property tag is used to build the index and is not exposed to clients.

New-MailboxRepairRequest -Mailbox <MailboxIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Archive <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

New-MailboxRepairRequest -Database <DatabaseIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

You can run a repair task with many parameters if you separate them with a comma. For an example of using more than one parameter, see the Examples section later in this white paper.

Database (required)

If you want to repair a database instead of a specific mailbox, this parameter specifies the database on which you will run this command. If you use this parameter, all mailboxes on the database are searched for corruption. To avoid performance issues, you're limited to one active database repair request at a time. You can use the following values:

  • GUID of the database

  • Database name

noteNote:
You cannot use this parameter together with the Mailbox parameter.

Mailbox (required)

If you want to repair a specific mailbox instead of a database, this parameter specifies the mailbox against which you will run this command. You can use the following values to identify the mailbox:

  1. GUID

  2. Distinguished name (DN)

  3. Domain\Account

  4. User principal name (UPN)

  5. LegacyExchangeDN

  6. SMTP address

  7. Alias

noteNote:
You cannot use the Alias parameter together with the Database parameter.

CorruptionType (at least 1 required)

The CorruptionType parameter specifies one of the following types of mailbox corruption. For more information about each of these corruption types, see the New-MailboxRepairRequest section earlier in this white paper.

  • SearchFolder

  • AggregateCounts

  • ProvisionedFolder

  • FolderView

  • MessagePTagCn

Archive (optional)

Use the Archive parameter to detect corruption and repair the archive mailbox that is associated with the specified mailbox. If you do not specify this parameter, only the primary mailbox is repaired.

noteNote:
You cannot use this parameter together with the Database parameter.

Confirm (optional)

Use the Confirm parameter to suppress the confirmation prompt that appears by default when this cmdlet is run. To suppress the confirmation prompt, use the syntax -Confirm:$False. You must include a colon (:) in the syntax.

DetectOnly (optional)

The DetectOnly parameter specifies that you want this command to report errors, but not fix them. You do not have to specify a value with this parameter.

DomainController (optional)

The DomainController parameter is used to specify the fully qualified domain name (FQDN) of the domain controller that writes this configuration change to Active Directory.

WhatIf (optional)

The WhatIf parameter instructs the command to simulate the actions that it would take on the object. By using WhatIf, you can see what changes would occur without having to apply any one of those changes. You do not have to specify a value with this parameter.

Other Optional Parameters

The New-MailboxRepairRequest cmdlet also supports the following common parameters:

  • Verbose

  • Debug

  • ErrorAction

  • ErrorVariable

  • WarningAction

  • WarningVariable

  • OutBuffer

  • OutVariable

For more information about the parameters that can be used with the New-MailboxRepairRequest cmdlet, type the following command in the Exchange Management Shell, and then press ENTER: get-help about_common parameters.

The New-PublicFolderDatabaseRepairRequest cmdlet detects and fixes replication state problems.

New-PublicFolderDatabaseRepairRequest -Database <DatabaseIdParameter> -CorruptionType <PublicFolderDatabaseCorruptionType[]> [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

Database (required)

The Database parameter specifies the database on which you will run this command. You can use the following values:

  • GUID of the database

  • Database name

CorruptionType (required)

The only corruption type that can be used with the CorruptionType parameter for the New-PublicFolderDatabaseRepairRequest cmdlet is ReplState.

Confirm (optional)

The Confirm parameter is used to suppress the confirmation prompt that appears by default when this cmdlet is run. To suppress the confirmation prompt, use the syntax -Confirm:$False. You must include a colon (:) in the syntax.

DetectOnly (optional)

The DetectOnly parameter specifies that you want this command to report errors, but not fix them. You do not have to specify a value with this parameter.

DomainController (optional)

The DomainController parameter is used to specify the fully qualified domain name (FQDN) of the domain controller that writes this configuration change to Active Directory.

WhatIf (optional)

You can use the WhatIf parameter to instruct the command to simulate the actions that it would take on the object. By using WhatIf, you can view what changes would occur without having to apply any one of those changes. You do not have to specify a value with the WhatIf parameter.

Other Optional Parameters

The New-PublicFolderDatabaseRepairRequest cmdlet also supports the following common parameters:

  1. Verbose

  2. Debug

  3. ErrorAction

  4. ErrorVariable

  5. WarningAction

  6. WarningVariable

  7. OutBuffer

  8. OutVariable

For more information about the parameters that can be used with the New-PublicFolderDatabaseRepairRequest cmdlet, type the following command in the Exchange Management Shell, and then press ENTER: get-help about_commonparameters.

The following examples show you some possible parameters and values that can be used with the integrity checking solution cmdlets.

New-MailboxRepairRequest –Mailbox administrator@contoso.com –CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

New-MailboxRepairRequest –Mailbox administrator –CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView –WhatIf

New-PublicFolderDatabaseRepairRequest -Database PFD01 -CorruptionType ReplState -DetectOnly

For more examples, run the following cmdlets in the Exchange Management Shell:

Get-help New-MailboxRepairRequest -examples

Get-help New-PublicFolderDatabaseRepairRequest –examples

For more information about the ISInteg cmdlets, run the following cmdlets in the Exchange Management Shell:

Get-help New-MailboxRepairRequest –detailed (or –full)

Get-help New-PublicFolderDatabaseRepairRequest –detailed (or –full)

After you submit the Mailbox or Public Folder repair request, you can monitor its progress by using the Event Viewer. That’s right: no more text logs to weed through. The events are logged under the MSExchangeIS Mailbox Store source.

The following event IDs are logged for repair requests:

  • 10044 Provisioned folders cleanup failed for a mailbox

  • 10045 Provisioned folders cleanup failed for a database

  • 10046 Provisioned folders cleanup successfully completed

  • 10047 A mailbox-level repair request started

  • 10048 The repair request successfully completed

  • 10049 Online Integrity check failed

  • 10050 The mailbox repair request task skipped a mailbox

  • 10051 Online Integrity check canceled

  • 10059 A database-level repair request started

  • 10062 Corruption was detected

  • 10063 Corruption was detected

  • 10064 A Public Folder repair request started

When you run the integrity checking solution cmdlets, remember the following important points:

  • Only one active repair task is permitted to run for each server if the active task is a database level repair.

  • Only 100 mailbox level active repair tasks are permitted to run at the same time for each server.

  • There is no parameter that can be applied that will run the cmdlets on all databases or mailboxes on a server. Each databases or mailbox must be addressed separately.

  • The repair task will stop if a database dismount or if a mailbox store stop/crash occurs.

  • The only way to stop a repair is to stop the store service or dismount the database.

  • When you repair a mailbox, access to that mailbox will be disrupted until the repair is completed.

  • Repair for a mailbox will skip a quarantined mailbox.

  • Repair will cause a move-mailbox operation to be delayed until the repair is completed

The new integrity checking solution can use Event Tracing for Windows (ETW) to gather diagnostic information for troubleshooting repair task problems.

Also, the Exchange Troubleshooting Assistant (ExTRA) includes the Trace Control tool. Use the Trace Control tool to enable and configure tracing on a server that is running Exchange 2010. Trace Sessions can also be started from a Performance Monitor console in Microsoft Windows Server 2008.

To enable tracing you must specify the component to trace and the trace tags for the component. The trace settings for the integrity checking solution are stored in the EnabledTraces.Config file that is created when trace components and tags are specified by using the ExTRA tool. To enable tracing for the integrity checking solution, specify the Store as the component to trace and tagISINTEG as the trace tag.

When a new repair request is created, the administrator can specify to detect and repair corruption, or only to detect and report on corruption but not apply any fixes. These two modes determine the information that appears in the trace log when tracing online database repair.

Typically, there is a trace entry that reports when corruption has been found. When processing using Detect and Repair mode, another trace entry is logged when the actual fix is made.

In this first example, the Store is processing a repair request where AggregateCounts has been specified as a repair type. When a folder fails AggregateCounts validation because of corruption, the following information is recorded in the trace:

StoretagISINTEGCORRUPTION DETECTED: Folder 2ae8-DD2D56 (MsgHeader=2ae8-DD2D53, foldt=2): Persisted value (2) of aggregate folder prop 0x36020003 (PR_CONTENT_COUNT) does not match the computed value (0)

At this point, the corruption has been reported but not fixed. Because the repair request is to both detect and fix, the following trace entry is recorded when the actual fix is made:

StoretagISINTEGCORRUPTION DETECTED: Folder 2ae8-DD2D56 (MsgHeader=2ae8-DD2D53, foldt=2): Persisted value (2) of aggregate folder prop 0x36020003 (PR_CONTENT_COUNT) will be fixed-up to match the computed value (0)

In this next example, SearchFolder corruption has been detected as recorded in the trace output. At this point the corruption is reported but it has not yet been fixed. If the mailbox repair request is operating in detect-only mode, there is no other reporting in the trace for this corruption.

StoretagISINTEGFolder 2ae8-46471B0 (MsgHeader=2ae8-DD2D53)is not provisioned, skipping validation.

StoretagISINTEGCORRUPTION DETECTED: Folder 2ae8-46471B4 (MsgHeader=2ae8-DD2D53, foldt=7): Backlinks prop 0x67850102 (ptagSearchFIDs) is not empty, but for this type of folder, it should be

StoretagISINTEGCORRUPTION DETECTED: Folder 2ae8-46471B4 (MsgHeader=2ae8-DD2D53, foldt=7): Backlinks prop 0x67860102 (ptagRecursiveSearchFIDs) is not empty, but for this type of folder, it should be

StoretagISINTEGCORRUPTION DETECTED: Folder 2ae8-46471B4 (MsgHeader=2ae8-DD2D53, foldt=7): Backlinks prop 0x67870102 (ptagSearchBacklinks) is not empty, but for this type of folder, it should be

Later in the same trace, because the repair request is operating by using Detect and Repair mode, the repair action is recorded when the three corrupted properties are updated:

StoretagISINTEGFolder 2ae8-46471B0 (MsgHeader=2ae8-DD2D53)is not provisioned, skipping validation.

StoretagISINTEGCORRUPTION DETECTED: Folder 2ae8-46471B4 (MsgHeader=2ae8-DD2D53, foldt=7): Clearing non-empty backlinks prop 0x67850102 (ptagSearchFIDs) because this type of folder shouldn't have backlinks

StoretagISINTEGCORRUPTION DETECTED: Folder 2ae8-46471B4 (MsgHeader=2ae8-DD2D53, foldt=7): Clearing non-empty backlinks prop 0x67860102 (ptagRecursiveSearchFIDs) because this type of folder shouldn't have backlinks

StoretagISINTEGCORRUPTION DETECTED: Folder 2ae8-46471B4 (MsgHeader=2ae8-DD2D53, foldt=7): Clearing non-empty backlinks prop 0x67870102 (ptagSearchBacklinks) because this type of folder shouldn't have backlinks

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft