Friday, February 25, 2011

Hey dude! Where is my Isinteg in Exchange 2010 Sp1????


doesn't longer exists ...
ISInteg has offered Exchange administrators a way to check mailbox and public folder database integrity. ISInteg checks and fixes Exchange database errors that may prevent the database from mounting, prevent the user from logging on or from receiving, opening or deleting email. Curious to know what changes are coming to ISInteg in Exchange 2010 SP1? Let's take a look.

Also ISInteg is no longer a standalone program.
The functionality provided by the ISInteg tool has been rolled into two new Exchange Management Shell cmdlets:


These new ISInteg cmdlets come with some cool new functionality!

The cmdlets work with the database mounted. It's no longer required to unmount the database to perform an integrity check or fix database errors.
You can repair logical corruption at the mailbox level.
You can fix corrupt search folders.
You can fix the Provisional Fid.
You can fix Aggregate Counts.
ISInteg can now work at the database or mailbox level

How does it do that? Well, the new schema in Exchange 2010 effectively partitions the database by mailbox. So the top problems fixed by ISInteg are now mostly limited to the affected mailboxes only. Previous versions of ISInteg required the database to be offline while validation and fixing are in progress. In Exchange 2010 SP1, the ability to do these checks at the mailbox level removes the need to dismount the database. It is actually required to have ISInteg operate against an online database!

The New-MailboxRepairRequest cmdlet detects and fixes the following types of mailbox corruptions:
Search folder corruptions (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, then it will remove that folder from the list.
Aggregate counts on folders that aren't reflecting correct values (AggregateCounts): Repair tasks 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 discrepancy, it will update the persisted counts to reflect the computed counts.
Views on folders that aren't returning correct contents (FolderView): Repair tasks will iterate over all views for a folder and for each one, bring the view fully up to date and then reconstruct a temp copy. If there is a discrepancy between the existing view and the contents of the temp table, it will delete the view so it can be rebuilt from scratch the next time it is requested.
Provisioned folders that are incorrectly pointing into unprovisioned parent folders (ProvisionedFolder): Repair tasks can fix Provisioned folders incorrectly pointing into unprovisioned parents or vice versa.
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>]]
Database, Mailbox and Archive:
You can repair an entire mailbox database or a specified mailbox by specifying either the Database or the Mailbox parameter. You can't use both. To repair the archive mailbox for the specified user, use the Archive switch.
(at least 1 required) you are already familiar with, we discussed them above:

You can run a repair task with multiple parameters if you separate them with a comma (as shown in the Examples section below).
DetectOnly: (Optional) The DetectOnly switch secifies that you want this command to report errors, but not fix them. You don't have to specify a value with this switch.
Other Optional Parameters: This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer and OutVariable. For more information, type "get-help about_commonparameters".


New-MailboxRepairRequest -Mailbox -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

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

Event Reporting
After submitting the Mailbox or Public Folder repair request, you can monitor its progress with 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 will be logged for repair requests:
10047 A mailbox-level repair request started
10064 A Public Folder repair request started
10048 The repair request successfully completed.
10050 The mailbox repair request task skipped a mailbox .
10059 A database-level repair request started.
10062 Corruption was detected

NOTE: in order to run this cmdlets you new belongs to below managed grop role

Just in case
Organization Management
Server Management
Recipient Management




1 comment:

  1. Very good post. I will be dealing with some of these issues as
    my website :: 2007


Note: Only a member of this blog may post a comment.