Thanks joel for sending this Microsoft Exchange guide
REBUILDING AN EXCHANGE 2000 DATABASE and Merging Lost Info into Exchange 2003 :
Overview: Our environment is as such. We were running on Exchange 2000 and experienced a Mail Store corruption due to a virus overload of our systems. Having fortunately previously built and partially implemented an Exchange 2003 server into our Active Directory, we were able to restore the 2000 Exchange system to a backup made several days prior to the corruption. We then successfully moved the mailboxes from the 2000 server to the 2003 server. This left us with 3 days of missing information that management deemed absolutely necessary. So we took steps to restore this information documented below.
The makings of a Mail Store DB are complex and highly proprietary to the point of absolute uselessness in my opinion. Nevertheless, when in Rome…. The mail store and public store databases are separate and different to confuse things more. So not only do we have worry about the user accounts, but we have to handle the public folders/calendars separately. The mail store and public folders store are similar but require separate tools for management. The databases themselves resemble MSSQL in the respect of the edb (MDF in MSSQL,) and the logs. The logs are a listing of every single transaction stored in the edb file. In our case the E00.log file serves as the current log file. If this file is interrupted, corrupted, or otherwise disturbed, the edb becomes “inconsistent” with the log files and therefore the mail store will detach (dismount,) itself from the exchange system and put itself in a frozen state as a static file on the server. This is where one begins to look for one’s backup of the database and begin the restoration process.
1. Restore if at all possible. Rebuilding the DB is dangerous and can result in serious loss of data. This is the stance of Microsoft and all of its associated documentation on the web. As we all know this is sometimes not possible due to factors beyond one’s control.
2. In the event restoration is not an option, it is likely you’ll want to work with Microsoft directly and pay that wonderful support fee to ensure your data is handled the best way possible. We did this at the prompting of our Exchange consultant and it really did pay off. If, again, this is not an option, the following steps are what I was guided through as resolution to the problem.
3. In working with Exchange 2000 and needing to restore its mail stores to a new installation of Exchange 2003, I had to first run a rebuild of the database with the eseutil /p command. This (while taking a couple of hours on our 11GB store,) restored our database. Example c:\>eseutil /p “c:\progra~1\\exchsrvr\\mdbdata\\priv1.edb” Then do the same for pub1.edb.
4. Run the eseutil /d command on your edb files Example: c:\>eseutil /d “c:\progra~1\\exchsrvr\\mdbdata\\priv1.edb”
5. After this completes several hours later, you should have a mountable mail store. However, this is only half the battle if one requires that this data be restored on a pre-existing Exchange 2003 installation. Now you must journey into the realm of exmerge. Exmerge 2000 only works with Exchange 2000 (properly that is,) and must be used to extract all of the mailboxes from the priv1.edb database file. The catch here is that Exmerge uses Active Directory to locate the accounts. In our case we had already “moved” the mail store over to the Exchange 2003 server and Active Directory didn’t see our mailboxes on the 2000 box anymore. The solution was to build an entirely separate PDC with Exchange 2000 freshly installed with all of the service packs applied. While painstaking, this is necessary. Then we copied the priv1.edb and pub1.edb files over to the new server and put them in place. We had to run an eseutil /r to sync up the mail store before we could mount it on the new system. After mounting the mail store on the new Exchange 2000 system, we had to export our list of users to a ldf file using MBConn.exe. Then we had to import the users into the new active directory database so that they would have accounts on the domain. I only half remember how to achieve this as it was very early in the morning. It’s not too difficult but I do remember having to make numerous adjustments to our ldf export via MBConn so that only the necessary fields were exported so that there were no blanks in the export file. A blank value in the export file will effectively stop you cold in your tracks to creating the new users in the new domain. After achieving this feat its time for some good ole manual labor and you have to associate every mailbox with the appropriate user in active directory via the Exchange System Manager. It’s no fun, but again necessary. We finish off using the Exmerge utility to export all of the Active Directory associated mailboxes to .pst files. In our case we were only missing 3 days of data from the corruption of the mail store, so I used the date range functionality in Exmerge to single out the proper data.
6. It’s now time to copy these pst files over to the Exchange 2003 server and download the appropriate Exmerge.exe for 2003. You’ll want to run Exmerge and point it to your pst directory. You’ll select the mailboxes to populate and then let her rip. This works pretty well without too much interdiction on one’s part.
7. So now you may ask what of the Public Folders database? Well out there in the ether is a utility called Pubmerge.exe which one would expect works the same as Exmerge.exe. However, one would be wrong. While I’m not sure of the intent of this utility, rest assured that it is completely useless in this situation. Don’t even bother downloading it. What you are going to have to do is (after mounting your Public Folder store on your new domain server,) is install Outlook to do your dirty work. After you’ve installed Outlook, you’ll select the root of the public folders and export that to a pst file. This pst file you’ll copy over to your “old” network and on a workstation you’ll use the advanced properties of you existing mail account to include this personal folder in your profile. At this point you can click and drag the Public Folders from the Personal Folder to your exchange account, thereby re-populating your Public Folder Store on your Exchange 2003 installation.
While none of this is fun, I couldn’t find it anywhere on the web and was left guessing. Hence the call to Microsoft isn’t a bad idea. You pay once and they HAVE to work with you until it’s complete to your satisfaction. Please understand that this information was specific to our installation and situation, I don’t recommend navigating Exchange without a ton of experience or an experienced consultant at your beckoned call. They make it proprietary for a reason and we all know the green answer.
REBUILDING AN EXCHANGE 2000 DATABASE and Merging Lost Info into Exchange 2003 :
Overview: Our environment is as such. We were running on Exchange 2000 and experienced a Mail Store corruption due to a virus overload of our systems. Having fortunately previously built and partially implemented an Exchange 2003 server into our Active Directory, we were able to restore the 2000 Exchange system to a backup made several days prior to the corruption. We then successfully moved the mailboxes from the 2000 server to the 2003 server. This left us with 3 days of missing information that management deemed absolutely necessary. So we took steps to restore this information documented below.
The makings of a Mail Store DB are complex and highly proprietary to the point of absolute uselessness in my opinion. Nevertheless, when in Rome…. The mail store and public store databases are separate and different to confuse things more. So not only do we have worry about the user accounts, but we have to handle the public folders/calendars separately. The mail store and public folders store are similar but require separate tools for management. The databases themselves resemble MSSQL in the respect of the edb (MDF in MSSQL,) and the logs. The logs are a listing of every single transaction stored in the edb file. In our case the E00.log file serves as the current log file. If this file is interrupted, corrupted, or otherwise disturbed, the edb becomes “inconsistent” with the log files and therefore the mail store will detach (dismount,) itself from the exchange system and put itself in a frozen state as a static file on the server. This is where one begins to look for one’s backup of the database and begin the restoration process.
1. Restore if at all possible. Rebuilding the DB is dangerous and can result in serious loss of data. This is the stance of Microsoft and all of its associated documentation on the web. As we all know this is sometimes not possible due to factors beyond one’s control.
2. In the event restoration is not an option, it is likely you’ll want to work with Microsoft directly and pay that wonderful support fee to ensure your data is handled the best way possible. We did this at the prompting of our Exchange consultant and it really did pay off. If, again, this is not an option, the following steps are what I was guided through as resolution to the problem.
3. In working with Exchange 2000 and needing to restore its mail stores to a new installation of Exchange 2003, I had to first run a rebuild of the database with the eseutil /p command. This (while taking a couple of hours on our 11GB store,) restored our database. Example c:\>eseutil /p “c:\progra~1\\exchsrvr\\mdbdata\\priv1.edb” Then do the same for pub1.edb.
4. Run the eseutil /d command on your edb files Example: c:\>eseutil /d “c:\progra~1\\exchsrvr\\mdbdata\\priv1.edb”
5. After this completes several hours later, you should have a mountable mail store. However, this is only half the battle if one requires that this data be restored on a pre-existing Exchange 2003 installation. Now you must journey into the realm of exmerge. Exmerge 2000 only works with Exchange 2000 (properly that is,) and must be used to extract all of the mailboxes from the priv1.edb database file. The catch here is that Exmerge uses Active Directory to locate the accounts. In our case we had already “moved” the mail store over to the Exchange 2003 server and Active Directory didn’t see our mailboxes on the 2000 box anymore. The solution was to build an entirely separate PDC with Exchange 2000 freshly installed with all of the service packs applied. While painstaking, this is necessary. Then we copied the priv1.edb and pub1.edb files over to the new server and put them in place. We had to run an eseutil /r to sync up the mail store before we could mount it on the new system. After mounting the mail store on the new Exchange 2000 system, we had to export our list of users to a ldf file using MBConn.exe. Then we had to import the users into the new active directory database so that they would have accounts on the domain. I only half remember how to achieve this as it was very early in the morning. It’s not too difficult but I do remember having to make numerous adjustments to our ldf export via MBConn so that only the necessary fields were exported so that there were no blanks in the export file. A blank value in the export file will effectively stop you cold in your tracks to creating the new users in the new domain. After achieving this feat its time for some good ole manual labor and you have to associate every mailbox with the appropriate user in active directory via the Exchange System Manager. It’s no fun, but again necessary. We finish off using the Exmerge utility to export all of the Active Directory associated mailboxes to .pst files. In our case we were only missing 3 days of data from the corruption of the mail store, so I used the date range functionality in Exmerge to single out the proper data.
6. It’s now time to copy these pst files over to the Exchange 2003 server and download the appropriate Exmerge.exe for 2003. You’ll want to run Exmerge and point it to your pst directory. You’ll select the mailboxes to populate and then let her rip. This works pretty well without too much interdiction on one’s part.
7. So now you may ask what of the Public Folders database? Well out there in the ether is a utility called Pubmerge.exe which one would expect works the same as Exmerge.exe. However, one would be wrong. While I’m not sure of the intent of this utility, rest assured that it is completely useless in this situation. Don’t even bother downloading it. What you are going to have to do is (after mounting your Public Folder store on your new domain server,) is install Outlook to do your dirty work. After you’ve installed Outlook, you’ll select the root of the public folders and export that to a pst file. This pst file you’ll copy over to your “old” network and on a workstation you’ll use the advanced properties of you existing mail account to include this personal folder in your profile. At this point you can click and drag the Public Folders from the Personal Folder to your exchange account, thereby re-populating your Public Folder Store on your Exchange 2003 installation.
While none of this is fun, I couldn’t find it anywhere on the web and was left guessing. Hence the call to Microsoft isn’t a bad idea. You pay once and they HAVE to work with you until it’s complete to your satisfaction. Please understand that this information was specific to our installation and situation, I don’t recommend navigating Exchange without a ton of experience or an experienced consultant at your beckoned call. They make it proprietary for a reason and we all know the green answer.
