<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

Exchange 2010<\/strong> is not the latest but an advanced version of the Microsoft Exchange environment that offers many features and benefits to its users. However, this does not make it error-free or failsafe. Although not prone to corruption it has the chances of becoming corrupt or getting damaged. And, such a situation can arise once a while if not frequently. Well, when users i.e. the Exchange Administrators face such a situation it becomes essential to restore Exchange 2010 database to a different server.<\/em><\/div>\n<\/div>\n
\n
<\/div>\n<\/div>\n<\/div>\n
Different Approaches to Restore Exchange 2010 Database <\/strong><\/p>\n
Well, the Exchange administrators can take different approaches to restore Exchange 2010 database from one server to the other. The approaches that can be taken are as follows:<\/p>\n
\n
Use of Database Portability<\/strong> feature<\/li>\n
Use of Mailbox Server Recovery<\/strong><\/a><\/li>\n
If the mailbox server is present in Database Availability Group (DAG)<\/strong>, then the database can be activated on another DAG member that contains a copy of the database.<\/li>\n<\/ol>\n
Note \u2013 <\/em><\/strong>Database Portability is the most beneficial to restore Exchange 2010 database to a different server. <\/em><\/p>\n
Database Portability feature and its functionality<\/strong><\/p>\n
This has been first introduced in Exchange Server version 2007<\/strong>, and available in Exchange 2010,<\/strong> Exchange 2013,<\/strong> and Exchange 2016<\/strong> as well, the Database Portability<\/strong> feature owns a significance. Its basic functionality is to move or mount exchange 2007\/2010\/2013\/2016<\/strong> database from one mailbox server to the other<\/strong> which is in the same organization. Users can move the mailboxes to distinct Storage Group on the same server. Once the mailboxes are moved to a different server, they can be reconnected. However, this feature cannot be used to move the public folders of the database from one server to the other.<\/p>\n
\n
Its key points <\/em><\/strong><\/li>\n<\/ul>\n
\n
Mailbox database can be moved or mounted into another mailbox<\/strong> only in the same organization.<\/li>\n
The mailbox database to be moved or mounted should be from the same or newer Exchange version<\/strong>. The reason being, an older Exchange version is not valid<\/strong> when the need is to move or mount mailbox database from one server to the other.<\/li>\n
The mailbox database cannot be moved from Public Folder of Exchange Database<\/strong> i.e. pub.edb files of Exchange.<\/li>\n<\/ol>\n
\n
Process of moving\/mounting Exchange Database using this feature<\/em><\/strong><\/li>\n<\/ul>\n
\n
Yield the log files<\/em><\/strong> and database<\/em> to the Exchange Server where it is required to mount or move the database. This can be accomplished by restoring the database from the backup, or the new server can be attached to the same Storage Group where the old server was connected.<\/li>\n<\/ol>\n
$\"restore$ <\/p>\n
Figure 1 (Indicative): Yielding the log files<\/em> and database<\/em> to the Exchange Server<\/strong><\/p>\n
\n
Confirm the shutdown status\/state<\/strong> of the Exchange database. This can be done by opening Exchange Management Shell and then going to the folder that contains the database file, followed by running the below-mentioned command:<\/li>\n<\/ol>\n
$\"restore$ <\/p>\n
Figure 2 (Indicative)<\/strong>: Confirming Exchange Server\u2019s shutdown status<\/strong><\/p>\n
\n
If the Exchange database is in a dirty shutdown state<\/strong> and transaction log files<\/strong> are also available, then execute \u2018soft recovery\u2019<\/strong> of the Exchange database.<\/li>\n<\/ol>\n
Note \u2013<\/em><\/strong> This step does not cause any change in the transaction log file<\/strong>, and thus there is no situation of data loss. However, if the database is in a \u2018clean shutdown\u2019<\/strong> state and there is an absence of transaction log file this step is not needed.<\/em><\/p>\n
\n
Run the command line<\/strong> by replacing \u2018E00\u2019<\/strong> with log file prefix of the database that is present in a folder of the transaction log file. This is because, here, it is assumed that the database is in \u2018dirty shutdown\u2019<\/strong> state.<\/li>\n<\/ol>\n
$\"restore$ <\/p>\n
Figure 3 (Indicative)<\/strong>: Running the command line<\/strong><\/p>\n
\n
Create<\/strong> a new mailbox database in the new mailbox server<\/strong> where it is required to mount the database. Also, allocate new location for transaction log file<\/em> <\/strong>and database<\/em> <\/strong>that is different from the existing location.<\/li>\n<\/ol>\n
$\"\"$ <\/p>\n
Figure 4 (Indicative): Creating a new mailbox database in the new mailbox server<\/strong><\/p>\n
\n
Copy<\/strong> the log files<\/strong> <\/em>and Exchange database<\/em> <\/strong>from the present to the new location that was assigned during the process of creating the new mailbox.<\/li>\n<\/ol>\n
$\"restore$ <\/p>\n
Figure 5 (Indicative): Copying of log files and Exchange database <\/strong><\/p>\n
\n
Mark the database as \u2018Overwritable.\u2019<\/strong><\/li>\n<\/ol>\n
$\"restore$ <\/p>\n
Figure 6 (Indicative): Marking of the database<\/strong><\/p>\n
\n
Get ready to \u2018Mount the Database\u2019<\/strong><\/li>\n<\/ol>\n
$\"\"$ <\/p>\n
Figure 7 (Indicative): Mounting of database<\/strong><\/p>\n
\n
The process of mounting or moving database is completed, but the users of the mailboxes still go to the old database name and server.<\/strong><\/li>\n<\/ol>\n
$\"restore$ <\/p>\n
Figure 8 (Indicative): Mailboxes going to the old database name and server<\/strong><\/p>\n
\n
Point users to the new mailbox server by upgrading<\/strong> the Exchange Server properties.<\/li>\n<\/ol>\n
$\"restore$ <\/p>\n
Figure 9 (Indicative): Users pointed to the new mailbox server<\/strong><\/p>\n
\n
After upgrading the changes, the ‘users\u2019<\/strong> accounts that are available in new mailbox server can be seen.<\/li>\n<\/ol>\n
$\"restore$ Figure 10 (Indicative): Users\u2019 accounts in new mailbox server seen<\/strong><\/p>\n
Once the move or mounting process<\/strong> is completed users can reconnect<\/strong> the mailboxes under assumptions that are as follows:<\/p>\n
\n
In Outlook 2010 and 2007<\/strong>, and Outlook Web Access (OWA)<\/strong>, clients will get the access to the new database automatically.<\/li>\n
In Outlook 2003<\/strong>, users need to upgrade<\/strong> the accounts or profile manually to connect to the new database.<\/li>\n
The upgraded accounts of users should use Active Directories (AD)<\/strong> for a copy.<\/li>\n<\/ul>\n
Well, Database Portability can fail to move or mount Exchange database owing to its manual characteristic. Manual ways require in-depth knowledge and experience to achieve the requirement. <\/em><\/p>\n
Next What? <\/em><\/p>\n
Action-to-be-taken when Database Portability fails to mount Exchange Database<\/em><\/strong><\/p>\n
When using Database Portability feature does not help or fails to mount Exchange Database,<\/strong> users should employ a third-party automated tool that can restore Exchange 2010 database to a different server automatically. Stellar Repair for Exchange<\/strong> is an unparalleled quality software that can repair damaged Exchange Server Database (EDB) files automatically and in a defined manner as it is programmed. Therefore, users can accomplish their purpose of restoring Exchange 2010 database easily without hassle. It can also do the following:<\/p>\n
$\"restore$ <\/a><\/p>\n
Stellar Repair for Exchange Review :<\/strong><\/p>\n
\u00a0 <\/iframe><\/p>\n<ul>\n<li>Recover<\/strong> Exchange database that is dismounted or is in offline state<\/li>\n<li>Repair<\/strong> several Exchange EDB files in one go, thereby, saves time<\/li>\n<li>Restore<\/strong> all mailbox data, such as emails & attachments, calendars, tasks, contacts, journals, etc.<\/li>\n<li>Move recovered database mailboxes to Office 365<\/strong> environment or Live Exchange Server<\/li>\n<li>Permits users to save the retrieved emails in several formats that are PST, MSG, RTF, EML, HTML, and PDF.<\/li>\n<li>Works with Exchange Server 2019, 2016, 2013, 2010, 2007, 2003, 2000, and 5.5 versions.<\/strong><\/li>\n<\/ul>\n\u00a0<\/em><\/strong>Conclusion<\/strong><\/p>\nOwing to the disadvantages of the manual method-using Database Portability in comparison to the advantages of Stellar Repair for Exchange \u2013 <\/strong>the automated recovery tool for Exchange Server, it is advised that users use the latter to restore Exchange 2010 database to a different server. Undoubtedly, users will be elated on using it!<\/p>\n","protected":false},"excerpt":{"rendered":"Exchange 2010 is not the latest but an advanced version of the Microsoft Exchange environment that offers many features and benefits to its users. However, this does not make it error-free or failsafe. Although not prone to corruption it has the chances of becoming corrupt or getting damaged. And, such a situation can arise once a while if not frequently. Well, when users i.e. the Exchange Administrators face such a situation it becomes essential to restore Exchange 2010 database to a different server. Different Approaches to Restore Exchange 2010 Database Well, the Exchange administrators can take different approaches to restore <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[106],"amp_validity":null,"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.stellarservertools.com\/blog\/wp-json\/wp\/v2\/posts\/799"}],"collection":[{"href":"https:\/\/www.stellarservertools.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.stellarservertools.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.stellarservertools.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.stellarservertools.com\/blog\/wp-json\/wp\/v2\/comments?post=799"}],"version-history":[{"count":15,"href":"https:\/\/www.stellarservertools.com\/blog\/wp-json\/wp\/v2\/posts\/799\/revisions"}],"predecessor-version":[{"id":1736,"href":"https:\/\/www.stellarservertools.com\/blog\/wp-json\/wp\/v2\/posts\/799\/revisions\/1736"}],"wp:attachment":[{"href":"https:\/\/www.stellarservertools.com\/blog\/wp-json\/wp\/v2\/media?parent=799"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.stellarservertools.com\/blog\/wp-json\/wp\/v2\/categories?post=799"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.stellarservertools.com\/blog\/wp-json\/wp\/v2\/tags?post=799"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}