If anyone still care about Microsoft online services SLA, Microsoft just announced it SLA for Q3 2016
But did you ever ask yourself how Microsoft calculate the SLA for its online services
Microsoft is calculating the SLA based on the below formula
Where Downtime is Any period of time when users are unable to send or receive email with Outlook Web Access. There is no Scheduled Downtime for this service.
You Can refer to this document for more clarification about SLA for Microsoft Online services onlinesvcsconsolidatedslawwenglishnovember212016cr
References: Microsoft Products
How to Restore the Exchange Database from A Backup File in state of inconsistency?
For restoring the database on Exchange Server, the user needs to have an up-to-date and usable backup in hand, because an incomplete or even no backup can create a troublesome situation during the database the process of restoration. Additionally, Microsoft Information Store needs to be in a healthy state to mount the database successfully.
With an unmounted Exchange Store, the users face several issues such as restricted access to the data and the mail flow. In order to smoothly restore your database on Exchange Server, it is important to perform certain tests to verify the database consistency.
Pre-assessment Phase: Verify the State of the Database on Exchange
Use the following steps to verify the state of the database:
- Launch a command prompt.
- Move to the Drive:\Program Files\Exchsrvr\Bin
(The default location of the of Exchange 2000 Server program files are located in this folder)
Move to Drive:\Program Files\Microsoft\Exchange Server\V15\Bin
(When using Exchange 2013/2016, then use the above-mentioned default path)
- Enter the below-mentioned command:
eseutil /mh “drive:\program files\exchsrvr\mdbdata\database_name.edb”
Note: The default location of database files is on this Drive:\Program Files\Exchsrvr\MDBDATA folder. The public database file can be found with the name: “Public.edb”, whereas the mailbox store database file can be found with the name: “Priv1.edb”.
- Read the Output, in order to verify the state of the database. If the database appears in the state of inconsistency, then the output will appear, as:
State: Dirty Shutdown
Restoration Phase: How to Restore the database from a backup file
Upon using the pre-assessment phase, if the database appears in a consistent state, then simply restore the backup using the file.
Steps to Restore Database in A Consistent State:
Implement the following steps to restore the database from the backup file.
- Transfer the E00.log file to an another path or simply rename it.
The default location of E00.log file can be found on this Drive:\Program Files\Exchsrvr\MDBDATA folder.
- Restore the storage group and the log files from the backup file.
Note: Do not remove the existing log files, until you have performed the restore operation. Upon completing the restore operation, the log files are restored, and replay inside the restored database. This is how, the user can bring the database into a consistent state without involving the E00.log file.
- Once the storage group is restored, you can successfully mount the databases in the storage group.
Steps to Restore Database in an Inconsistent State:
- Launch the command prompt.
- Reach to the location – Drive:\Program Files\Exchsrvr\Bin folder.
- Enter the following command in the command prompt:
eseutil /p “drive:\program files\exchsrvr\mdbdata\database_file_name.edb”
- To use the database in a productive environment, try to defragment and then rebuild the database. Use the below mentioned command to proceed:
eseutil /d /t:x “drive:\program files\exchsrvr\mdbdata\database_file_name.edb”
Note: ‘x’ is a temporary drive location in the above-mentioned command.
- To determine the state of the database, enter the following command, and then read the output:
eseutil /mh “drive:\program files\exchsrvr\mdbdata\database_file_name.edb”
When database is consistent, the output will appear, as:
State: Clean Shutdown
- Use the Microsoft’s Store Integrity utility (Isinteg.exe) to fix the logical corruption issues in the database. Use the following commands to repair it:
Isinteg –s exchange_server_name –fix –test alltests
After executing the command, the user is prompted to choose the database in the utility. Repeat the aforementioned command until no errors or fixes are appeared in the output.
However, if zero errors are not displayed for a database that you want to repair, then the other option is to rebuild the database. To do that create a new mailbox store on either the existing Exchange server or new server and then transfer all the mailboxes to that one. However, if you are still unable to create a new mailbox store, then try to rebuild the database from the following method. To do it, try to export all mailbox information to PST files, and delete the database, and finally import the data.
- Repeat the steps from 3 to 6 for each database in the storage group.
- Mount the databases.
Once the database is restored and you can also perform an online backup of the storage group. However, if the database is not restored or rebuilt in the state of inconsistency, then try using a third-party Exchange recovery software like Kernel for Exchange Server to perform accurate recovery of lost information from corrupt EDB and STM files, and without requiring log files. The Exchange mailbox items can be successfully restored to live Exchange Server, Office 365 mailbox or to Outlook PST files.
When Exchange database creates mounting troubles, then try to investigate the issues hampering the restore operation. Verifying the shutdown state (whether consistent or inconsistent) of the database becomes important, and Eseutil can be helpful in this scenario, but with certain restrictions.