Exchange 2007 Mailbox Server transport Service recovery

Event Reason:

4 Month afternoon, after I delete the junk e-mail queue, the mailbox server error. The error message is:Mircosoft whether the Exchange transport service is started. So that all people can not send the message normally, you receive the message.

According to the error message I made two points:

first: Found in the list of services The Mircosoftexchange Transport service restarts the service and then checks to see if the related service is up and running.

Workaround:

Restart The Mircosoft Exchange service is not valid for multiple restarts of the service.

Second: The next thing to do is to empty the mail queue, which I did:

in the The queue change name under the E:\mailccr\transportroles\data file . Stop the Mircosoftexchange service first, and then copy the files in the queue into the new Queuexxx folder so that the mail queue is cleared.

and then restart Mircosoftexchange Transport Service, but at this point the Mircosoft Exchange transport service is still not up.

Third: Next, look at the mail server version and Discover Exchange2007 no upgrade patches. Then download the install package upgrade SP3 patch Pack. After the installation is complete, the server restarts and theMircosoft Exchange transport service starts normally. At this time the headquarters mailbox send and receive normal, but branch and English department personnel mailbox can't send and receive mail.

after viewing the mailbox database, branch office database ( Branch) The English Department (ozieltes) does not load, the server replication status is "failed"

because it is When the Exchange log files are deleted, you must restore the storage group database files through a backup, and then you must replay the log files.

Microsoft Exchange

Error

Mount Database

" xxxx "

Failed.

Xxxx

Failed

Error :

Exchange

Unable to mount the specified database. The specified database

: win2003\xxxx\xxxx

; Error code

Mapiexceptioncallfailed:unable to mount database.

(hr=0x80004005,ec=-515)

First of all, I'm using

Exchange Server 2007

and a similar example.

544 , 455 errors, and so on, mainly because of some reason the database log file is missing or incorrectly created

The. Can be resolved by the following methods.

here to use theEseutil.exeThis program that he was inexthe installation directory of the\bin\eseutil.exeOK, let's do the following to recover the log file. First turn off antivirus software, which is primarily to prevent it from scanningexThe installed directory causes problems such as text locking, and then in the directory where the problematic database resides, such as\exchange\mailbox\firststroagegroupdirectory is the directory where the database is located, then run on this foldercmd, and then in the Command window, entereseutil-p "Xxx.edb"and then runeseutil-mh "Xxx.edb",View the status in the displayed results= Clean off orState=cleanshut; Then we run the next stepeseutil/r e00,after running, you will see manyLogfile, you will be prompted at the end of the lastLogfiles are like0AD, the lack ofLogfile0ae, which means the loss of0AE. LOGThis file does not matter, do the following, (note) Although it will be lost after the0ADafter the data, but also than the database can not be loaded well! Come on , go ahead: find\exchange\mailbox\firststroagegroupdirectory under the latestLOGfile, rename it toLOGThe first three characters of a file, such asLOGthe full file name is "E000000000AD "then change it to "e00 ",Similarly, if it is "E010000000AD "then change it to "E01 ", you will find that this folder hasE01This file repeats, back up the original file, then delete it, then0ADrenamed asE00Okay, all right, go.EMC

riga to download this database to try, is not the milk? haha other database also this operation,OWA can normally access the quack!

The database active node and the passive node replication state failed, which can be resolved by the following actions.

Scheduled outage

through CCR , you can schedule a specific node to have a system outage for a long time, but the clustered mailbox server (CMS) will not be interrupted for a long time. the CCR scheduled outage feature ensures that all log data on the active node is successfully replicated to the passive node. Therefore, even if asynchronous replication occurs, there is always no data loss for scheduled outages. A failure and its resulting failover can cause the passive node to fail to obtain very new log data when it is online.

No scheduled outage

unplanned outages are automated system responses to certain types of failures. CCR focuses automatic recovery on failures that exist in some cases, in which case higher availability is more trustworthy, or most environments expect automatic recovery.

Unplanned interrupts allow the system to activate the mailbox server on the passive node, set it to active, and then mount the replicated database and storage group. Once loaded, the database becomes the source for all subsequent updates for any subsequent replication. Two replicas switch the replication role, where one replica results in database changes, and the other receives and applies database changes.

From the above, we can see that the planned interruption is an artificial operation, and unplanned outages occur automatically.

Is your situation a planned or unplanned outage?

If your situation is a planned interruption, would you like to install the following steps to do it?

1. Start the schedule interrupt with the Move-clusteredmailboxserver cmdlet first ,

2. is your planned outage complete successfully (no failures are shown during the transfer associated with the planned outage)?

If your planned outage is not fully successful, the source and target databases will be inconsistent in this case. In some cases,CCR can automatically recover from certain inconsistencies. If this happens, replication will start and process any available logs. If replication does not recover automatically, the copy is marked as corrupted and an event is generated that indicates the problem.

If the storage is available, you need to re-seed the copy. The approximate steps are as follows:

1 , run suspend-storagegroupcopy-identity:<server\storagegroupname>

2 , Delete all log files, database files, checkpoint files, and so on, on the new passive node (the original active node),

3 , running on the new passive node (the original active node) update-storagegroupcopy-identity:<server\storagegroupname>

4 , run Get-storagegroupcopystatus command to check the results.

My specific operation is as follows:

1. because of the RAID problem, all the information in the hard disk is not, after the failure, the mailbox service automatically cut to

node B above, the data is saved intact.

2. re-finish the system and add it to the current cluster

3. The appropriate MNS is configured

4. Install Exchange as the passive node

5. Exchange information cannot be copied when you finish loading

6. As you have written above:

1 , run suspend-storagegroupcopy-identity:<server\storagegroupname>

2 , Delete all log files, database files, checkpoint files, and so on, on the new passive node (the original active node),

3 , running on the new passive node (the original active node) update-storagegroupcopy-identity:<server\storagegroupname>

4 , run Get-storagegroupcopystatus command to check the results.

Summary of events:

Through this accident, the server problem first to see the relevant log files, such as the system log (inside can see the server hardware, operating system, etc.) application server log file (application software log) also is based on the error prompt to find the relevant reasons. And then extend it to the system.

This article is from the "Network access issues" blog, so be sure to keep this source http://gaoguoch.blog.51cto.com/3231820/1659350

Exchange 2007 Mailbox Server transport Service recovery