more2know.nl

Exchange 2010 SP1: Database Integrity checking

Since the earliest versions of Exchange Server, the Information Store Integrity Checker
(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.

In Exchange 2010 SP1, ISInteg is no longer a standalone program.

The functionality provided by the ISInteg tool has been rolled into two new Exchange Management Shell cmdlets:

• New-MailboxRepairRequest
• New-PublicFolderDatabaseRepairRequest

Note: Like other Shell cmdlets, these are subject to Role-Based Access Control (RBAC) scoping restrictions. For details, see Understanding Management Role Scopes.

Cool Features

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!

New-MailboxRepairRequest

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.

Syntax

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>]]

Parameters

· 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.

· CorruptionType: (at least 1 required) you are already familiar with, we discussed them above:

• SearchFolder
• AggregateCounts
• ProvisionedFolder
• FolderView

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-PublicFolderDatabaseRepairRequest

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

Syntax

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

Parameters

• Database: (required) Specifies the Public Folder database on which you will run this command. You can use one of the following values:
  • GUID of the database
  • Database name
• CorruptionType: (required) Pretty easy, there’s only one value.
  • ReplState
• DetectOnly: (optional) Specifies that you want this command to report errors, but not fix them. You don’t have to specify a value with this parameter.
• 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”.

Examples

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

Some additional examples are provided in the cmdlet help. You can retrieve them using the following commands, or refer to New-MailboxRepairRequest and New-PublicFolderDatabaseRepairRequest cmdlet reference:

Get-help New-MailboxRepairRequest -examples
Get-help New-PublicFolderDatabaseRepairRequest -examples

I recommend that you get to know the cmdlets by using the cmdlet reference docs, or by using the following commands to retrieve detailed help from the shell:

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

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.

Figure 1: Mailbox or Public Folder database repair request events are logged in the Application event log

Note: the repair events will only show up on the mailbox server where the mailbox or Public Folder is located.

This is very important to remember. Just because you fired off a repair task on a mailbox server does not mean the events will show up on that server. The repair task will be run on the database where the mailbox itself is, and the events will be in the event log on that mailbox server and that server alone.

Things to remember:

• Only 1 active repair task is permitted to be running per server if the active task is a database level repair.
• Only 100 mailbox level active repair tasks are permitted to be running at once per server.
• There is no -Server parameter to do all databases or mailboxes on a server.
• The repair task dies on database dismount or store stop/crash.
• The only way to stop a repair is to stop the store or dismount the database.
• Mailbox access will be disrupted for the mailbox that is being repaired.
• Repair for a mailbox will skip a mailbox if it has been quarantined.
• Repair will cause a move-mailbox operation to be delayed until the repair is completed.

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

• Update Rollup 5 for Exchange Server 2010 (KB2407113)  Download the rollup here.

This update rollup is highly recommended for all Exchange Server 2010 customers.

For a list of changes that are included in this update rollup, see KB2407113.

Here is a list of the fixes included in update rollup 5:

1. 2266458 Setup cannot perform a mode:/uninstall on a HT role server since RU2 delivered MSFTE.msi

Download the rollup here.  

Note to Forefront users:

If you don’t disable Forefront before installing a rollup or service pack, and enable afterwards, you run the risk of Exchange related services not starting. You can disable Forefront by going to a command prompt and navigating to the Forefront directory and running FSCUtility /disable. To enable Forefront after installation of a UR or SP, run FSCUtility /enable.

By default Exchange 2010 is configured to only accept SMTP email for domains it is authoritative for, and will only relay email onto other domains for authenticated local users. This is the best practice. So nobody like spammers can send mail to external people from your mail domain. But when you have an application that must relay mail. You should think about what you want to do for your relay permissions. For security reasons I should always make a new special Receive Connector and lock down so only that wants needed is open. But how we do it. We want that the application can authenticate. Because we want to send mail to distribution list with the option “Require that all senders are authenticated”

Like its predecessor, Exchange 2010 is configured to accept and relay email from hosts that authenticate by default. Both the “Default” and “Client” receive connectors are configured this way out of the box. Authenticating is the simplest method to submit messages, and preferred in many cases.

The Permissions Group that allows authenticated users to submit and relay is the “ExchangeUsers” group. The permissions that are granted with this permissions group are:

NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Submit} NT AUTHORITY\Authenticated Users {ms-Exch-Accept-Headers-Routing} NT AUTHORITY\Authenticated Users {ms-Exch-Bypass-Anti-Spam} NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Accept-Any-Recipient}

Here are the equivalent options for how to configure this in Exchange 2010.

The next screen you must specify on with local ip and port this receive connector must listen. I’ve chosen all available ip addresses on port 26.

The next screen you must pay particular attention to is the “Remote Network settings”. This is where you will specify the IP ranges of servers that will be allowed to submit mail. You definitely want to restrict this range down as much as you can. In this case, I want my application server, 172.16.16.24 to be allowed to relay.

The next step is to create the connector, and open the properties. Now you have two options, which I will present. The first option will probably be the most common.

Option 1: User permissions

We must select what permission is set to this connector. Because we want the application to authenticate. We select Exchange Users.

Next, continue to the authentication mechanisms page and add the Basic Authentication with TLS and Integrated Windows euthentication.

The connector is Ready. If you are authenticated you can send mail like you do from your outlook client. Now we want to give the specified user that right rights mail can relayed.

Add the right permissions to the receive connector.

[PS] Get-ReceiveConnector -Identity “HubServer”\Relay_ReceiveConnector | add-ADPermission -user Relay_User -ExtendedRights “Ms-Exch-Accept-Headers-Routing”,”Ms-Exch-SMTP-Accept-Any-Sender”,”Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender”,”Ms-Exch-SMTP-Submit”,”Ms-Exch-SMTP-Accept-Any-Recipient”

Ms-Exch-SMTP-Accept-Any-Sender
Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
Ms-Exch-SMTP-Submit
Ms-Exch-SMTP-Accept-Any-Recipient
Ms-Exch-SMTP-Accept-Authentication-Flag

Basically you are telling Exchange to ignore internal security checks because you trust these user. The nice thing about this option is that it is simple and grants the common rights that most people probably want.

Option 2: Grant the relay permission to Anonymous on your new scoped connector

This option grants the minimum amount of required privileges to the submitting application.

Taking the new scoped connector that you created, you have another option. You can simply grant the ms-Exch-SMTP-Accept-Any-Recipient permission to the anonymous account. Do this by first adding the Anonymous Permissions Group to the connector.

This grants the most common permissions to the anonymous account, but it does not grant the relay permission. This step must be done through the Exchange shell:

[PS] Get-ReceiveConnector “Relay_ReceiveConnector” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”

 Summary Extended Rights 

 Full description Extended Rights

ms-Exch-SMTP-Submit If the SMTP receive session does not have this permission, it will fail to submit messages. It will fail both the “MAIL FROM” and “AUTH” command. The “AUTH” command will also fail as the credential might have been correct, but the authenticated user or computer will have no chance to do anything useful with the session.

ms-Exch-SMTP-Accept-Any-Recipient If the SMTP receive session does not have this permission, the server will reject the “RCPT TO” command if the recipient domain does not match any accepted domain. You could call this permission also the Relay permission.

ms-Exch-SMTP-Accept-Any-Sender If the SMTP receive session does not have this permission, the server will check sender address spoofing. If the spoofing check fails, the message gets rejected at either “MAIL FROM” or EOD (End Of Data), depending on which sender

(envelop or message/header) was found to be spoofed.

ms-Exch-SMTP-Accept-Authoritative-Domain-Sender If the SMTP receive session does not have this permission, the server will reject “MAIL FROM” if the specified address is at an authoritative domain. (An authoritative domain is an administrative domain with at least one mail server responsible for the final delivery of messages addressed to that domain.)

ms-Exch-SMTP-Accept-Authentication-Flag If the SMTP receive session does not have this permission, the server will ignore the AUTH= option that was specified on the “MAIL FROM” command. (Internally, Exchange Servers transfer anonymous messages using “AUTH=<>”.)

ms-Exch-Accept-Headers-Routing If the SMTP receive session does not have this permission, the server will strip all “Received:” headers. Note: This should only happen for client message submissions over SMTP, which is why by default ExchangeUsers do not get this permission. (See RFC 2476.)  

ms-Exch-Accept-Headers-Organization If the SMTP receive session does not have this permission, the server will strip all organization headers. Those headers all start with “X-MS-Exchange-Organization-”.  

ms-Exch-Accept-Headers-Forest If the SMTP receive session does not have this permission, the server will strip all forest headers. Those headers all start with “X-MS-Exchange-Forest-”.  

ms-Exch-SMTP-Accept-Exch50 If the SMTP receive session does not have this permission, the server will not accept the “XEXCH50″ command. Note: This command is necessary for interoperability with Exchange2000 and Exchange2003. In an environment with only Exchange2007 servers, the “XEXCH50″ command won’t be used once disabled.  

ms-Exch-SMTP-Send-Exch50 If the SMTP send session does not have this permission, the server will not send the “XEXCH50″ command.  

ms-Exch-Send-Headers-Routing If the SMTP send session does not have this permission, the server will strip all “Received:” headers.  

ms-Exch-Send-Headers-Organization If the SMTP send session does not have this permission, the server will strip all organization headers. Those headers all start with “X-MS-Exchange-Organization-”.  

ms-Exch-Send-Headers-Forest If the SMTP send session does not have this permission, the server will strip all organization headers. Those headers all start with “X-MS-Exchange-Forest-”.  

ms-Exch-Bypass-Message-Size-Limit If the SMTP receive session has this permission, the server will skip message size restrictions at the protocol level.  

ms-Exch-Bypass-Anti-Spam If the SMTP receive session has this permission, the server will pass this permission to anti spam agents, as to skip this message for anti-spam checks.

For all who want this nice Poster on the wall.

Download
Exchange Server 2010 Architecture Poster

Kind Regads,

Rene van Maasakkers

Microsoft released a new “Exchange Processor Query tool” to enable you to quickly locate the SPECInt 2006 Rate value for your server. This tool automates the manual steps, described in Mailbox Server Processor Capacity Planning TechNet article, to determine your planned processor’s SPECInt 2006 Rate Value.

MS Exchange Team Blog:

“This tool automates the manual steps, described in the Mailbox Server Processor Capacity Planning TechNet article, to determine your planned processor’s SPECInt 2006 Rate Value.  To run this tool you must be connected to the Internet.  The tool will take your planned processor model as input and execute a web query against the spec.org website returning all test result data for that particular processor model.    The tool will also calculate an average SPECint 2006 Rate Value based on the number of processors planned to be used in each mailbox server.  Once you complete the steps below you can plug the result value for your planned processor into the megacycles per core field in step 5 of the input range in the Mailbox Role Calculator to assist in your Exchange 2010 server planning.  If your particular server model is not listed in the dataset returned by the web query you can use the calculated average value and input that number into the megacycles per core field.”

Download hier

In Exchange 2010 you are able to manage distribution lists in Outlook Web App.
By design you are not able to modify the distribution groups where you are the owner from.

If you want that all the owners of a distribution list can manage there own distribution list follow the steps below. With the great feature RBAC (Role Based Access Control) in Exchange 2010 we are able to give the users the right permissions to manage there own distribution lists. So we have more time to drink coffee.

1. Create a new Custom Role based on the default ‘MyDistributionGroups’ Role.
 

[PS] New-ManagementRole -Name Custom_OwnerDistributionGroups -Parent MyDistributionGroups –Description “This role enables individual users to view distribution groups and add or remove members to distribution groups they own or add a Mailtip.”

Parameters
Name: The Name parameter specifies the name of the role. The maximum length of the name is 64 characters. If the name contains spaces, enclose the name in quotation marks (“).
Parent: The Parent parameter specifies the identity of the role to copy. If the name of the role contains spaces, enclose the name in quotation marks (“). If you specify the Parent parameter, you can’t use the UnScopedTopLevel switch.
Description: The Description parameter specifies the description that’s displayed when the management role is viewed using the Get-ManagementRole cmdlet. Enclose the description in quotation marks (“).

2. Modify the new Custom Role.

Because we’ve made a new Role based on MyDistributionGroups we have to make change to we dont have the same settings as MyDistributionGroups. We remove the settings for make new distribution groups, Remove distribution groups and set group. These powershell commando’s are not availeble for those users if we remove them. We also make some changes to the powershell commando Set-distributiongroup. Now have the users the permissions to add or remove members from the distribution groups and make changes to the mailtip.

[PS] Remove-ManagementRoleEntry Custom_OwnerDistributionGroups\New-DistributionGroup -Confirm:$false
[PS] Remove-ManagementRoleEntry Custom_OwnerDistributionGroups\Remove-DistributionGroup -Confirm:$false
[PS] Remove-ManagementRoleEntry Custom_OwnerDistributionGroups\Set-Group -Confirm:$false
[PS] set-ManagementRoleEntry Custom_OwnerDistributionGroups\Set-DistributionGroup -parameter Confirm ,ErrorAction ,ErrorVariable ,Identity ,MailTip ,MailTipTranslations , OutBuffer ,OutVariable ,WarningAction ,WarningVariable ,WhatIf

3. Add the new Custom Role to the “Default Role Assignment Policy”

If you want that all people get these setting you must add the new role to the existing “Default Role Assignment Policy” which is applied to every one. You can also go to Outlook Web App change the “Default Role Assignment Policy” there.

[PS] New-ManagementRoleAssignment -Role VU_OwnerDistributionGroups -Policy “Default Role Assignment Policy”

4. Add the right owners to the distribution lists

Finaly you must add the owners to the distribution list so the owners can modify the members of the Distribution Group.

5. Outlook Web App

If the users logon into Outlook Web App they will see the next pages.

For more information see also the technet sites from microsoft:

New-ManagementRole  http://technet.microsoft.com/en-us/library/dd298073.aspx

Remove-ManagementRoleEntry http://technet.microsoft.com/en-us/library/dd351187.aspx

New-ManagementRoleAssignment http://technet.microsoft.com/en-us/library/dd335193.aspx

Installation Exchange 2010 SP1

In this article I will describes the installation procedure for the installation of Service Pack 1 for Exchange 2010 prerequisites and Known Issues.

Prerequisites

Exchange 2010 SP1 has a number of prerequisites that must be performed before the Service Pack installation is started. These are:

- Installation Hotfixes

- Schema Update Active Directory

Installation hotfixes

The Exchange installation Setup will tell you which hotfixes you must have. If you are up2date you should see that you must have the hostfixes as below. But i recommended dat you run setup to show which hotfixes you must have.

1. Here’s a matrix of the updates required, including download locations and file names.

On all the Hub and Mailbox severs the Office 2010 Filter Pack must be installed.

http://www.microsoft.com/downloads/en/details.aspx?familyid=5CD4DCD7-D3E6-4970-875E-ABA93459FBEE&displaylang=en

You can run setup to find all the hotfixes you need.

Update Active Directory Schema

Before install Exchange 2010 SP1 we must run a schema update.

How to find the server with the schema master role:

1. Start MMC
2. Load the Schema Snap in
3. In the Snap in, Right click on Active Directory Schema
4. Choose Operations Master…
5. By Current Schema is listed the Schema Master

From this schema master you can run the command:

1. Logon locally on the Schema Master Server
2. Start Command Prompt
3. From the Exchange 2010 SP1 location, start this command:
4. “setup.com / prepareAD”

Installation Service Pack 1

It’s important to install also this Service Pack from out-side to in-side. So we must first upgrade the edge servers and the last server should be the mailbox servers. You should always apply hotfixes/service packs as described.

1. Edge Transport Servers
2. Client Access Servers
3. Hub Transport Servers
4. Unified Messaging Servers
5. Mailbox Servers

Start setup.exe from the media kit.

“Choose Exchange Language option for upgrade”
“Upgrade all languages from the language bundle”
“Download the latest language pack bundle from the internet”
Setup download the latest language pack from internet
After download choice “Finish”.
“Install Microsoft Exchange Server Upgrade”
Next
Accept the License Agreement
“Upgrade” after all Readiness Checks are finish. If you not installed all hotfixes, Setup tells you to install before you can upgrade
Show progress
Finish

Overview

Download Exchange Service Pack 1

http://www.microsoft.com/downloads/details.aspx?FamilyID=50b32685-4356-49cc-8b37-d9c9d4ea3f5b&displaylang=en

Microsoft has  just released the Exchange 2010 Update Rollup 4. You can download the update here and read more information about fixes included in the following KB article:

http://support.microsoft.com/?kbid=982639

This is a cumulative update rollup and replaces the following:

• KB976573 Update Rollup 1 for Exchange Server 2010 (KB976573)
• KB979611 Update Rollup 2 for Exchange Server 2010 (KB979611)
• KB981401 Update Rollup 3 for Exchange Server 2010 (KB981401)

Legacy Exchange Recovery Storage Groups

Exchange 2010 no longer includes the concept of storage groups. In earlier versions of Exchange, one or more Exchange store databases can be grouped into a storage group, which can then be managed as a unit. However, storage groups complicate many high-availability scenarios, and make single-database restores more complex.

Exchange 2010–compatible backup and restore applications that work with the Windows Volume Shadow Copy Service (VSS) no longer provide storage group identifiers in the VSS backup component paths.

Recovery Storage Group Replaced with Recovery Database

Because storage groups were removed from Exchange Server 2010, the recovery storage group no longer exists. Instead, if your application needs to restore, recover, and mount an Exchange database to a different location or server, it will use a recovery database. The recovery database is not tied to any original server or database. Each Exchange 2010 server can have no more than one mounted recovery database. There can be multiple recovery databases, but only one can be mounted at a time.

You can use the Restore-Mailbox cmdlet to extract data from an RDB. After extraction, the data can be exported to a folder or merged into an existing mailbox. RDBs enable you to recover data from a backup or copy of a database without disturbing user access to current data.

Microsoft Exchange Server 2010 supports the ability to restore data directly to a recovery database. Mounting the recovered data as a recovery database allows the administrator to restore individual mailboxes or individual items in a mailbox. Restoring to a recovery database can be accomplished in two ways:

• If a recovery database already exists, the application can dismount the database, restore the data onto the recovery database and log files, and then remount the database.
• The database and log files can be restored to any disk location. Exchange analyzes the restored data and replays the transaction logs to bring the databases up to date, and then a recovery database can be configured to point to already recovered database files.

Steps how to restore a mailbox

1.   Restore EDB, Logs and Replay the logs

First you have to Recover the edb and log files to a recovery directory. We have restored the files to D:\restore

The EDB file we have restored will not include any data that is contained in the log files as these are committed to the database AFTER we perform the backup.

We need to know the log file numbering before we can run ESEUTIL.  To do this, navigate to the folder you restored the EDB & Log files to (in the case of this article it is D:\Restore) and look for the file that starts with an E and has 2 numbers after the E and an extension of .chk, so for example E00.chk.  This is what is known as the checkpoint file, or the working log file.  All the other log files will start with the same 3 digits and they are created when the checkpoint file gets full.

So assuming your checkpoint file is called E00.chk we now need to run the command to replay the log files in the Exchange Management Console.

Once the Exchange Management Shell is open type the following commands:

Cd \ <enter>
CD Restore
ESEUTIL /R E00 /L “path of logfiles” /D “Path of database” /i

This will replay the log files that you have restored from the backup into the database.

When you don’t use the /i you might get this error:

“Operation terminated with error -1216 (JET_errAttachedDatabaseMismatch, An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info) after n seconds.”

To resolve this, run soft recovery with the “/i ” switch at the end and it will override the EDB-STM mismatch.

You also may Use /a . Use the /a – allow recovery to lose committed data if database integrity can still be maintained.

Run Eseutil /mh “Path of the database *.edb” to check if the database is in a state: Clean shutdown

2.   Create a Recovery Database from the EDB file

Once we have restored the EDB file and Log files, we then need to create a Recovery Database.  This process can only be performed using the Exchange Management Shell.
Assuming the following Information:

• Servername is MBX1 (must be an Exchange Server that holds the Mailbox Role)
• The EDB & Log files have been restored to D:\Restore\
• EDB File Name is databases01.edb
• The recovery database name will be RecoveryDatabase01

Run the following command in the Exchange Management Shell:

[PS] New-MailboxDatabase -Recovery -Name “RecoveryDatabase01” -Server MBX1 -EdbFilePath “D:\Restore\Databases01.edb” -LogFolderPath “D:\Restore”

If there are problems to mount the recovery databas. Use the /a – allow recovery to lose committed data if database integrity can still be maintained.

[PS] New-MailboxDatabase -Recovery -Name “RecoveryDatabase01” -Server MBX1 -EdbFilePath “D:\Restore\Databases01.edb” -LogFolderPath “D:\Restore”

The next step is to mount the Recovery Database.  To do this we run the following command from the Exchange Management Shell:

Mount-Database RecoveryDatabase01

We can confirm the database has been created and that it is a recovery database by running the following command from the Exchange Management Shell:

Get-MailboxDatabase

The important part of this screenshot is that the database listed as RecoveryDatabase1 has the value of True under the Recovery setting.

We now have a recovery database created.  

3.    Show list of mailboxes in the recovery database

To show all the mailboxes which are in the recovery database use the following command from the Exchange Management Shell:

[PS] Get-MailboxStatistics -Database RecoveryDatabase01 

4.   Recover the required mailbox/mail items

Unlike previous versions of Exchange, there is no Graphical User Interface for the recovery process.  To recover mail items we need to use the Exchange Management Shell.

4.1 Restore the completed mailbox

So for example, we have a user called Rene_vm and he has deleted the entire contents of his mailbox and you need to recover all his mail.

We have a copy of the mailbox belonging to Rene_vm in our Recovery Database.  To restore the required mailbox, we would use the Exchange Management Shell and run the following command:

[PS] Restore-Mailbox -Identity rene_vm -RecoveryDatabase RecoveryDatabase01

This will recover a mailbox called rene_vm from the Recovery Database called RecoveryDatabase01 to the rene_vm mailbox in the live database.  This method relies on the original mailbox still being intact. 

4.2 Restore to a Folder

The next option is to recover the rene_vm mailbox from the Recovery Database and place it into a folder called “Rene_vm Recovery” within a mailbox called servicedesk.

[PS] Restore-Mailbox -Identity servicedesk -RecoveryDatabase RecoveryDatabase01 -RecoveryMailbox Rene_vm -TargetFolder “Rene_vm Recovery”

4.3 Restore selective Mail

Restores only the mail with the subject more2know, with the message body containing the word business, and with the message location either in the Inbox or Calendar folder. This example assumes that the mailbox is in English. Place the restored items into a recovery folder.

[PS] Restore-Mailbox -Identity info -RecoveryDatabase RecoveryDatabase01 -RecoveryMailbox rene_vm -SubjectKeywords “more2know” –ContentKeywords “business” –IncludeFolders \inbox,\calendar –TargetFolder “Rene_vm recovery with more2know”

4.4      Bulk Restore

Bulk restores all the mailboxes in the Databases01 mailbox database that are also present in RecoveryDatabase01

[PS] Get-Mailbox -Database Databases01 | Restore-Mailbox -RecoveryDatabase RecoveryDatabase01

5.   Removing the recovery database

After the restore is completed we must remove de recovery database. To do this we would run the following command:

[PS] Remove-MailboxDatabase -Identity RecoveryDatabase01

For more information see also the technet sites from microsoft:

Recovery Databases http://technet.microsoft.com/en-us/library/dd876954.aspx

Understanding Backup, Restore and Disaster Recovery http://technet.microsoft.com/en-us/library/dd876874.aspx

Restore-Mailbox http://technet.microsoft.com/en-us/library/bb125218.aspx