exchange 2007邮箱服务器传输服务恢复

ewr23

事件原因：
     4月21日下午，在我删除垃圾邮件队列之后邮箱服务器报错。报错信息为：Mircosoft Exchange 传输服务是否启动。使得所有人员不能正常发送邮件，可以收到邮件。
根据报错信息提示我做了两点：
   第一：在服务列表找到MircosoftExchange 传输服务重启这个服务，然后查看相关的服务是否启动正常。
   解决方法：
   重启Mircosoft Exchange 服务，经多次重启该服务无效。
   第二：接下来做的是把邮件队列清空，我是这样做的：
   在E:\mailccr\transportroles\data文件下的queue更改名字。首先把MircosoftExchange 服务停止，然后再把queue里面的文件拷贝到新建的queuexxx 文件夹里，这样再把邮件队列清除。
   然后重启MircosoftExchange 传输服务，但此时Mircosoft Exchange 传输服务还是启动不起来。
   第三：接下来，查看邮件服务器版本，发现Exchange2007没有升级补丁。然后下载安装包升级SP3补丁包。安装完之后，服务器重启，Mircosoft Exchange 传输服务启动正常。这时总部邮箱收发正常，但是分公司和英语部人员邮箱不能收发邮件。
   经查看邮箱数据库，分公司数据库（Branch）英语部（ozieltes）装载不上去，服务器复制状态为“失败”
   因为是Exchange日志文件被删除，则必须通过备份还原存储组数据库文件，然后必须重播日志文件。
  Microsoft Exchange
错误
装入数据库
“xxxx”
失败。
xxxx
失败
错误:
Exchange
无法装入指定的数据库。指定的数据库
: WIN2003\xxxx\xxxx
；错误代码
MapiExceptionCallFailed:Unable to mount database.
(hr=0x80004005,ec=-515)
首先声明我用的是
exchange server 2007
还有类似的比如
544、455错误等，主要是因为某种原因数据库的日志文件丢失或者错误造
成的。可以通过以下方法来解决。
这里要使用到eseutil.exe这个程序，他在ex的安装目录下的\bin\eseutil.exe 好下面我们来操作来恢复日志文件。首先关掉杀毒软件，这主要是为了防止它扫描ex安装的目录造成文锁定之类的问题，然后在出问题的数据库所在的的目录，比如\exchange\mailbox\firststroagegroup目录下是数据库所在目录，那么在这个文件夹上运行cmd，然后再命令窗口中输入eseutil -p "xxx.edb"  然后运行eseutil -mh "xxx.edb",在显示出来的结果中查看状态= 干净关闭或者state=cleanshut；然后我们进行下一步运行 eseutil /r e00    ,运行后会看到很多log文件，这里最后会提示你最后一个log文件是比如0ad，缺少了log文件0ae，这说明丢失了0AE.LOG这个文件，不要紧，进行下面操作，（注意）虽然进行后会丢失0ad之后的数据，但是也比加载不了数据库好吧！来吧继续吧：找到\exchange\mailbox\firststroagegroup目录下最新的LOG文件，将其改名为LOG文件的最前三个字符，比如LOG文件全名是“e000000000ad”那么把它改成“e00”,同理如果是“e010000000ad”那么把它改成“e01”，这时你会发现本文件夹有E01这个文件重复了，备份好原来的那个文件，然后删除它，再吧0AD改名成E00，好啦大功告成了，去EMC
里加载这个数据库试试，是不是可以了奶？哈哈其他数据库也这么操作，OWA又可以正常访问了嘎嘎！
数据库主动节点与被动节点复制状态失败，通过以下操作可以解决。
计划中断
通过 CCR，可以将特定节点计划为长时间发生系统中断，但群集邮箱服务器 (CMS) 不会长时间中断。CCR 计划中断功能可以确保主动节点上的所有日志数据成功复制到被动节点上。因此，即使发生异步复制，计划中断也始终不会有数据损失。故障及其导致的故障转移会导致被动节点在联机时无法获得非常新的日志数据。
未计划中断
未计划中断是对某些类型的故障产生的自动系统响应。CCR 会将自动恢复侧重于某些情况下存在的故障，在这些情况下，提高可用性的可信程度较高，或者大多数环境都期望进行自动恢复。
未计划中断允许系统激活被动节点上的邮箱服务器，从而将其设置为主动，然后装入复制的数据库和存储组。被装入之后，数据库将成为用于任何后继复制的所有后续更新的源。两个副本会切换复制角色，即一个副本产生数据库更改，另一个副本接收和应用数据库更改。
从上面的话，我们可以看出，计划中断是人为操作的，而未计划中断是自动发生的。
请问您的情况属于计划中断还是未计划中断？
如果您的情况属于计划中断的话，请问您是安装下面的步骤进行操作的吗？
1.      先用Move-ClusteredMailboxServer cmdlet来启动计划中断，
2.      您的计划中断是否完成成功（在与计划中断相关联的传输过程中未显示任何故障）？
如果您的计划中断没有完全成功，在这种情况下，源数据库和目标数据库将会不一致。在某些情况下，CCR 可自动从某些不一致状况中恢复过来。如果发生该情况，则复制将会启动并处理任何可用日志。如果复制无法自动进行恢复，则会将副本标记为已损坏并会生成表明该问题的事件。
如果存储可用，您需要重新将副本设定为种子。大致步骤如下：
1、运行Suspend-StorageGroupCopy -Identity:<Server\StorageGroupName>
2、删除新的被动节点（原主动节点）上的所有日志文件、数据库文件、检查点文件等等，
3、在新的被动节点上（原主动节点）上运行Update-StorageGroupCopy-Identity:<Server\StorageGroupName>
4、运行Get-StorageGroupCopyStatus命令检查结果。
我的具体操作如下：
1.由于是RAID出问题，所以硬盘内所有的信息都没有，在出现故障后，邮箱服务自动切到
节点B上面，数据保存完整。
2.重新做完系统，将其加入到现在的集群中
3.配置了相应的MNS
4.以被动节点的身份安装Exchange 2007
5.装完就发现Exchange的信息无法复制
6.正如你上面所写的操作：
1、运行Suspend-StorageGroupCopy-Identity:<Server\StorageGroupName>
2、删除新的被动节点（原主动节点）上的所有日志文件、数据库文件、检查点文件等等，
3、在新的被动节点上（原主动节点）上运行Update-StorageGroupCopy -Identity:<Server\StorageGroupName>
4、运行Get-StorageGroupCopyStatus命令检查结果。

事件总结：
通过这次事故，服务器出问题首先要查看相关的日志文件，如系统日志（里面可以看到服务器的硬件，操作系统等情况）应用服务器日志文件（应用软件的日志）还有就是根据报错提示查找相关原因。然后再扩展到系统。