下午四点赶往陆家嘴，解决客户Exchange群集问题，问题倒不是很紧急，但是客户环境比较特殊，只能在非工作时间解决，看来今天又要加班咯～～～
1.客户邮件服务器是Exchange 2003 Cluster, 群集资源中Exchange HTTP Virtual Server Instance 100 资源不能启用，导致用户无法访问OWA页面。
在日志中有MSExchangeCluster 1013等报错信息
事件描述：
Event Type: Error
Event Source: MSExchangeCluster
Event Category: Services
Event ID: 1013
Date: 25/80/2005
Time: 9:16:44 AM
User: N/A
Computer: exchange1
Description:
Exchange HTTP Virtual Server Instance 100 (exchange1): Failed to get the
protocol IP address and port bindings from the metabase.

打开IIS，里面虚拟服务器是停用状态，因为用户是比较重要的生产环境，所以暂时没有做任何操作，开始检查日志，Cluster日志，应用程序日志，系统日志，然后查EventID,微软KB。 看起来IIS元数据损坏的可能性比较大。
突然从网上找到一篇BBS, 里面的问题和现在问题一样，里面提到了This problem can be caused by the HTTP Virtual Server not having an SSL port defined when we are requiring SSL.
立刻检查IIS里面SSL端口定义，果然是空值。输入443, 应用设定。重新启用群集中HTTP资源，服务正常启动了。
OWA页面正常开启。hoho~~， 万幸，还好不是IIS元数据库问题，否则今天加班到几点还是问题，万恶的加班啊～～～，万恶的加班又没有加班费啊～～～～

2.问题提前解决，时间充裕，那就继续解决客户的其它问题，客户反应DC服务器上周期出现Userenv 1054错误，组策略无法下发。
事件描述：
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 3/12/2008
Time: 8:42:38 AM
User: NT AUTHORITY\SYSTEM
Computer: ServerName
Description:
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.
经过检查，不光DC上有，多台成员服务器上也有这个现象。
这个问题以前也多次见过，一直没有好好解决。
看了EventID，很多人都说这个问题和硬件有关。继续查找资料～～
功夫不负有心人啊，总算找到篇有用的资料，说明问题和AMD CPU有关，AMD有Fix程序可以解决。
打开服务器硬件属性，果然都是用的AMD的CPU，看来问题有眉目。
接下来的工作就交还给客户了，请他明天先联系下HP，看下HP的Case记录里面是否对这个错误有解决方案，如果确实是CPU的问题话，应该HP会碰到很多类似问题。

Just thought I'd throw this in here. Spent a bunch of time researching this, finally decided to call MS.

Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 3/12/2008
Time: 8:42:38 AM
User: NT AUTHORITY\SYSTEM
Computer: ServerName
Description:
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.
-------------------------------------------------------
We were getting this on a bunch of new servers, all running Win2003 R2 64bit. It's also showing up on a number of XP machines. Finally decided to just open a ticket with MS.

The problem is apparently a "slow link detection", which is of course abundantly obvious from the errors. Per MS, we did the following reghacks:

Registry subkey: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System
Value name: GroupPolicyMinTransferRate
Value type: DWORD
Value Data: 0

Registry subkey: HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System
Value name: GroupPolicyMinTransferRate
Value type: DWORD
Value Data: 0

Note: if the "System" key doesn't exist, please create it under HKCU\Software\Policies\Microsoft\Windows & HKLM\Software\Policies\Microsoft\Windows first.

From the MS tech support rep:

"It is possible that certain firewall program (such as Windows Firewall) is installed on all your machines and configured to block the normal ICMP packets. Sometimes it may be also caused by some models of CPU.

For example, there is a known bug with AMD Opteron Processor driver for Windows XP and Windows Server 2003 Version (x86 and x64 exe) 1.3.2.16, which allows the system to automatically adjust the CPU speed, voltage and power combination that match the instantaneous user performance need. The slow link detection depends on the CPU clock to calculate the speed. However, it may fail when working along with AMD Opteron driver. Recently we have received many reports that this known bug in the AMD CPU driver often causes the group policy detection failure. AMD has provided a new version of driver to solve such similar problems. You can get this point from:

http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_9033,00.html"

All our new servers are 64-bit Opterons. We haven't upgraded the driver yet.