问题处理 ：1、分析IIS日志发现发生故障期间大约08:50~10:00发现有大量rpc 401，说明Outlook验证失败
Line 56668: 2015-06-02 00:54:53 172.20.2.5 RPC_OUT_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6002 443 xxx.xxx@xxx.com 172.16.240.36 MSRPC 401 1 64 296
Line 56687: 2015-06-02 00:54:54 172.20.2.5 RPC_IN_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6001 443 xxx.xxx@xxx.com 172.16.240.36 MSRPC 401 1 1326 78
Line 56688: 2015-06-02 00:54:54 172.20.2.5 RPC_OUT_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6001 443 xxx.xxx@xxx.com 172.16.240.36 MSRPC 401 1 64 15
Line 56773: 2015-06-02 00:54:58 172.20.2.5 RPC_IN_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6002 443 xxx.xxx@xxx.com 172.16.240.36 MSRPC 401 1 1326 93
Line 56774: 2015-06-02 00:54:58 172.20.2.5 RPC_OUT_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6002 443 xxx.xxx@xxx.com 172.16.240.36 MSRPC 401 1 64 62
Line 56802: 2015-06-02 00:55:00 172.20.2.5 RPC_OUT_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6002 443 xxx\wl.ye 172.20.32.232 MSRPC 200 0 0 0
Line 56879: 2015-06-02 00:55:06 172.20.2.5 RPC_IN_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6004 443 xxx\chuxu.su 172.16.147.17 MSRPC 200 0 0 15
Line 56880: 2015-06-02 00:55:06 172.20.2.5 RPC_OUT_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6004 443 xxx\chuxu.su 172.20.32.232 MSRPC 200 0 64 0
Line 56889: 2015-06-02 00:55:06 172.20.2.5 RPC_IN_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6001 443 xxx.xxx@xxx.com 172.16.240.36 MSRPC 401 1 64 2371
Line 56890: 2015-06-02 00:55:06 172.20.2.5 RPC_OUT_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6001 443 xxx.xxx@xxx.com 172.16.240.36 MSRPC 401 1 64 2324
Line 57749: 2015-06-02 00:55:57 172.20.2.5 RPC_OUT_DATA /rpc/rpcproxy.dll hqcasarray.xxx.com:6001 443 xxx\wl.ye 172.20.32.232 MSRPC 200 0 0 46
2、RCA日志也有记录：
过滤RCA日志，发现RCA日志里xxx.xxx用户仅仅有10点半的连接记录，说明之前验证没过，应用层RCA日志还没记录。
3、应用程序日志2080正常，说明和DC的连接没有问题
4、outlook ETL看到outlook拿了Cred去server做了验证。可是验证失败。结合IIS日志OA的401.1。说明弹框是server的验证问题。
5、分析抓取的RPC Client Access进程的三次Dump（发生故障时每隔30秒抓了一个）。发现第一个dump中都没有活动的RPC 线程；第二个dump中仅仅有一个RPC活动线程，该用户/o=TPVAOC/ou=ExchangeAdministrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Dm.Hu在做邮箱操作； 第三个dump中还是没有活动的RPC线程。以上也相同说明弹框还没有到RPC应用层。
6、分析性能日志。进行NTLM验证的性能分析，我们不难发如今问题发生的时候发生了NTLM性能瓶颈， 怎样推断是否发生了NTLM性能瓶颈， 我们能够參考例如以下的官方KB：
https://support.microsoft.com/en-us/kb/2688798
我们使用例如以下的公式计算：
The formula for determining your ideal setting (permachine) is:
(semaphore acquires + semaphore timeouts) * avg semaphorehold time / collection time = < MaxConcurrentAPI>
我们计算例如以下：
[（（1058174-1057996）+ （45748-44433））X 2.033 ] / 179 = 17.36 >> 默认设置值2
所以NTLM性能问题发生了。
正常的时候抓取的perfmon日志计算：
相同的计算机方式，我们计算正常的情况例如以下：
[（(50460 - 50460) + (1086454 - 1086304) ）X 0.003 ] / 89 = 0.005 < 默认设置值2
所以此时没有NTLM性能问题。
我们知道
1. 默认windows 2008R2成员serverMaxConcurrentAPI的值是2， 默认windows 2008R2域控server默认值是1
2. The maximum configurable setting in Windows Server 2008 R2(without the hotfix in this article) is 10. With the hotfix, the maximum is150.
因为问题发生的时候，我们能计算到17.36这个值，我们能够通过例如以下的设置方法，将MaxConcurrentAPI设置大点。以避免瓶颈的发生。
解决方法
=========
为了避免NTLM瓶颈，麻烦在非工作时间进行下面操作：
1. 在两台Exchange CASserver上，以及三台域控server上，都打上例如以下的补丁：
http://support.microsoft.com/kb/975363
补丁重新启动生效
目的：打补丁补丁是能让server的MaxConcurrentAPI的值的设置范围变大。最大能够设置成150；
2. 使用管理员的身份登录到两台Exchangeserver，以及三台域控server上。右击以管理员权限执行cmd, 执行下例如以下的命令：
reg add"HKLM\system\currentControlSet\services\netlogon\parameters" /vMaxConcurrentAPI /t reg_dword /d 35 /f
3. 在这个调整的server计算机上，右击以管理员权限执行cmd, 执行例如以下命令重新启动下netlogon的服务就可以：
net stop netlogon
net start netlogon
贵方能够在各个调整后的计算机上，按例如以下的路径查看下是否设置的值及时设置成功了：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
DWORD： MaxConcurrentApi
Value： 35
