由于硬盘驱动器故障重buildExchange 2003服务器之后,Exchange在未知的时间之后变得不可用。 绝大多数用户现在在Outlook 2007(less数仍在2003年)。
我们调高了日志logging级别,现在我们已经注意到了这些警告。 我一直在跟踪他们,看起来他们每15分钟左右发生一次(不确定时间框架是否与此有关)
这些警告有时会导致错误,昨天我们重新启动服务器两次; 上午8:30到下午2:30(大概6个小时 – 再次,不知道时间与它有什么关系)
处理INETINFO.EXE(PID = 1300)。 由于错误0x80040951,DSAccess需要closures到域控制器AD-server.domain.com的连接。
- 服务器join域不会创build计算机名称的DNSlogging
- 我需要find最后一个从ADlogin到电脑的用户
- MSSQL 2008服务帐户
- Windows 2003和2008 AD集成了DNS区域
- 基于nagios ldap-group的前端login权限问题
进程STORE.EXE(PID = 2936)。 由于错误0x80040952,DSAccess需要closures到域控制器AD-server.domain.com的连接。
处理MAD.EXE(PID = 2160)。 由于错误0x80040952,DSAccess需要closures到域控制器AD-server.domain.com的连接。
每三个警告中的每一个都会每十五分钟左右重复一次。
我们之前重新启动交换的错误看起来像
目录AD-server.domain.com上的LDAP绑定在专有名称“'上不成功。 目录返回错误:[0x51]服务器closures。 DC =域,DC = com的
我们不确定这些警告是否与错误有关(最终,随后的重新启动)。 按照上面的时间,我们认为它会在下午8:30和2:30左右再次发生,但什么都不是。 自昨天下午2:30左右重启后没有错误。
我应该注意到Exchange在DMZ 1 ,AD在DMZ 3但是防火墙(Sonicwall)在2个DMZ之间是完全开放的。
Exchange曾经在自己的服务器上,但是从一些技术人员的推荐,我们已经把它移到了虚拟机。 2008服务器是主机,VMWare服务器2用于VM和Windows 2003运行2003 Exchange。
对于发生的事情,我们真的感到不知所措。 我们重新启动了防火墙,closures了AV / Content Filtering,重新启动了AD和Exchange。
我们正在考虑将Exchange移动到与AD相同的DMZ中。 我们所说的每个人都会build议,但我们现在还不能这样做。 最好的部分是,在我们不得不重buildExchange之前,我们运行了3年以上完美的,相同的防火墙,相同的DMZ设置,相同的操作系统版本(VM除外)。 只有在我们失去交换并重build之后,我们才有了这些问题。
有任何想法吗?
—添加注释11-23-11 11:11 EST — @连安德森
我不完全确定如何完成你要求我做的事情; 我们通常不会在这里嗅探stream量
然后我想起我们的Sonicwall NSA已经build立了数据包捕获function。
所以我input交换服务器和AD服务器,让它将捕获的数据发送到我的PC上的FTP服务器上,现在我可以观察交换机和AD之间的stream量了。 它发送给我的.cap文件,我正在用Wireshark查看。
今天早上1点到3点发生“问题”,今天上午9点左右再次发生。 当我早上六点左右进来时,我重新启动,以保证安全,并在上午9点左右交换无响应时重新启动。
筛选LDAP协议,我看到以下条目:
SASL GSS-API Inegrity – 这些看起来像实际查找,每个searchRequest都有一个searchResEntry
bindRequest和bindResponse – 这些看起来1到1 – 所以看起来不错。
我看到一些从交易所到AD的取消绑定请求,似乎没有任何回应 – 我不确定是否应该有回应。
我没有看到任何与实际同步的东西。
仍在寻找 – 运行捕捉并不会影响到性能的任何地方,所以我希望继续运行它,直到出现错误,交换停止响应。
错误0x80040951是“LDAP_SERVER_DOWN”错误,而0x80040952是“LDAP_LOCAL_ERROR”。 这两个都让我觉得Exchange Server计算机正在变得无法通过LDAP与DC进行通信。
我首先嗅探Exchange与DC之间的stream量。 如果可以,请使用SPAN端口或其他方法在DC和Exchange之间的专用嗅探器计算机中“开球”,以便您的长期嗅探可以在任一服务器上运行而不会导致性能问题。 您可以使用捕获筛选器将通信隔离到Exchange Server和DC之间的对话。 如果可以的话,使用两台计算机嗅探并在每台服务器和隔离它们的防火墙设备之间“开球”。
没有看到实际的networkingstream量发生了什么,我很难做出进一步的build议。 如果你最终得到了一些“在行动中”的失败,你可以把它们放在这里,我们来看看。 基于目前为止我所看到的,我希望你发现Exchange服务器计算机反复SYN为DC上的LDAP端口,并没有得到一个响应。 如果你足够幸运能够从防火墙设备的“双方”捕获,我敢打赌,你会看到没有穿越防火墙的stream量。 你的问题当然有它的感觉…