修复企业AD与Exchange故障

故障现象

某企业使用Exchange Server 2010作为邮件系统，根据集团下发文件，在服务器上安装了某厂商的“防勒索病毒补丁”后，导致Exchange出现问题，所有用户不能登录邮箱。后来卸载了补丁，将Exchange退出域、又重新加入到域，Exchange恢复正常。

一 周 后，大多数员工的Outlook不能登录Exchange，但 OWA（在浏览器中通过Web页面登录Exchange）与手机客户端正常，只有极少数员工的Outlook能登录Exchange。对于不能登录Exchange的无论是重新安装操作系统还是重新配置Outlook，都会出现图1错误。

故障排查

经过检查，故障现象总结如下：

图1 不能登录Exchange

图2 网络拓扑图

1.Exchange Server 2010对外收发邮件正常。

2.员工使用手机客户端、使用OWA（Web页面）登录Exchange邮件系统正常。

3.只有Outlook登录Exchange时出错，错误如图1所示。如果修改Outlook使用 POP3、SMTP方式，也可以登录Exchange。

该单位有1台Exchange Server 2010，2 台 Active Directory的服务器。其中 AD1、AD2、Exchange Server都 是Windows Server 2008 R2操作系统。网络拓扑如图2所示。

经过进一步检查，发现AD2（192.168.0.249）与Exchange（192.168.0.221）的 TCP的135端口不能登录（测试方法telet 192.168.0.221 135时出错）。但在Exchange上检查，服务器的135端口已经开放。

解决方法与思路

因 为 AD1（192.168.0.249）的 AD 与 Exchange（192.168.0.221）都出现TCP 135不能登录的故障，并且故障原因也是在“勒索病毒”打补丁之后出现（192.168.0.223没有安装补丁，故一切正常）。所以解决故障的方法也就在修复TCP的135端口上。

在正式修复之前，我们做了如下的准备与测试工作：

1.将 DC（192.168.0.223）的设置为主域，转移角色到223。此时249将成为额外域控制器。

2.因为192.168.0.249上有证书服务器，所以备份该服务器的根证书私钥及数据库。

3.通过升级安装的方式（登录进入Windows，使用同操作系统、同版本的安装镜像，执行Setup，执行升级安装），升级 192.168.0.249。

4.升级安装192.168.0.249，升级之后，TCP的135端口能用。

因为通过升级192.168.0.249之 后，TCP的 135端口能用，故准备通过升级Exchange修复135端口。

为验证方法是否正确，我们进行了如下的前期测试：

图3 Exchange初始化失败

1.使用“爱数”备份设备，备份Exchange的操作系统及数据库。

2.使用一台空闲的服务器搭建出虚拟化环境，新建AD1与MBX两台虚拟机，从爱数备份设备，将AD1与MBX备份恢复到虚拟机，故障再现。

3.在MBX的虚拟机中升级 Exchange，邮 箱、Outlook正常，但Exchange控制台不能打开，错误提示为“尝试连接到指定的Exchange服务器***时出现以下错误：尝试使用"Kerberos"身份验证连接到 http://***/PowerShell失败：连接到远程服务器失败，错误消息如下：WinRM 无法处理该请求。使用 Kerberos 身份验证时发生以下错误：找不到网络路径。”（如图 3）。

4.经过分析，打开服务器管理器，添加“WINRAM IIS扩展”组件，安装该组件后正常。之后可以打开Exchange管理控制台。

在实验成功之后，我们准备修复生产环境中的Exchange，并提前在集团OA发布了此项维护通知。

本着数据第一、安全第一的原则，在修复前使用对Exchange进行备份，备份完成后再对系统进行修复，这样一旦出现问题，可以通过备份恢复。因为数据量较大，整个备份大约花了28个小时。

升级修复不成功但找到故障原因

在周六正式对Exchange进行升级安装，升级花费了大约2个小时，但升级之后，故障依旧。

因为当前操作系统是Windows Server 2008 R2，而做实验的虚拟环境的操作系统是Windows Server 2008 R2 SP1的版本，我们将当前的操作系统升级到Windows Server 2008 R2 SP1，打补丁之后，故障依旧。

经过进一步对物理服务器中的操作系统进行检查，发现telnet 127.0.0.1 135可用，但telnet 192.168.0.221 135不可用。我们分析认为Exchange各项服务、操作系统相关服务都正常，但是由于某项策略导致192.168.0.221的135不可用。

在检查到“本地安全策略”时，在“IP安全策略，在本地计算机”中有一个“Block”的策略。

1.查看该策略，在“筛选器操作→编辑”中，打开属性，查看“安全方法”为“阻止”。

2.在“身份验证方法”选项卡中，看到验证方法包括了Kerberos。之后再telnet 192.168.0.221 135，发现已经正常。

此时我们使用Outlook登录Exchange，发现登录正常，并收到了外网发来的邮件。

发现新问题并解决

在我们认为故障解决的时候，经过测试发现，Exchange能收邮件、不能发邮件（无论是向外发邮件还是内部发邮件，都不行），邮件都保存在“草稿箱”内。

经过分析，我们认为原因如下：

Exchange某项服务没有启动导致此事情发生。但经过检查，发现Exchange的所有服务都启动正常。

继续分析认为可能是安装了Windows Server 2008 R2 SP1引发的，之后卸载Windows Server 2008 R2 SP1补丁。在卸载补丁后，故障依旧。

之后继续卸载“WinRM IIS扩展”，卸载之后，系统并未提示需要重新启动。为了可靠，我们重新启动Exchange。在Exchange重新启动的过程中，停留在“发件箱”中的邮件发送成功。但再次进入系统后，故障依旧。

此时我们再次逐一检查Exchange相关服务，虽然检查到每项服务的状态为“己启动”，但在重新启动“Microsoft Exchange邮 件提交”服务之后，Exchange发信恢复正常。

此时已经是下午16：50多。在经过多次测试之后，确认Exchange恢复正常。

之后安装了“WinRM IIS扩展”，Exchange管理正常。

继续测试，Exchange的OWA、Outlook正常，收发正常，至此故障解决。

编写脚本

为了防止以后Exchange登录后，不能发送邮件，我们配置Exchange，让Exchange在重新启动后自动以Administrator账户登录进入系统，并且执行脚本重新启 动“Microsoft Exchange邮件提交”服务。

运 行regedit， 打 开“HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon”键值，新建“字符串值”，前面为键值，后面为内容。具体项如下。

"AutoAdminLogon"="1"

"DefaultUserName"="Ad ministrator"

"DefaultDomainName"="单位域名"

"DefaultPassword"="管理员密码"

用“记事本”创建startexchange.cmd，内容如下：

net stop MSExchangeFBA

net start MSExchangeFBA

net stop MSExchange MailSubmission

net start MSExchange MailSubmission

将其添加到“启动”菜单，或者编辑计划内容，选择“登录后只执行一次”。

经过这些配置，Exchange修复完成。