このモニターは、同時 API 接続が最大数に達したときにアラートを発生します。
サーバーが一度に取り扱える NTLM 認証や Kerberos の PAC のパスワードによる認証の最大数は、MaxConcurrentApi の設定によって決まります。この MaxConcurrentApi の既定値が小さいことが原因で、顧客の Windows 認証で問題が発生したり、Exchange や SharePoint と組み込み基幹業務システムを利用できなくなったりすることがあります。
このような場合は、まず、次のことを確認してください。
複数のドメインを持つフォレストがある。
異なる複数のドメインに、それぞれユーザーとリソース (アプリケーションやプロキシ サーバー) が含まれている。
Windows Server を実行しているリソース サーバーに、リモート ドメインのユーザーからの NTLM によるログイン要求が多数発生する。
上の条件が当てはまる場合は、NTLM のログイン要求がタイムアウトします。たとえば、Exchange クライアントは Exchange サーバーから認証を受けることができません。したがって、ユーザーは自分のメールボックスにアクセスできず、Microsoft Outlook が応答しなくなります。
この問題は、NTLM API の調整の限界に達したことが原因で発生します。
認証要求を生成するデバイスが増えるにつれて、大規模な組織で認証機能停止が頻発する傾向が強まっています。
クラウド コンピューティングの導入によって規模の経済は達成できますが、Active Directory を利用する Windows インフラストラクチャに大きな負荷がかかります。
BPOS と Office 365 では、この値は既にそれぞれ 10 と 150 に上がっています。これまでの CSS ケース エンゲージメントによって、レジストリの修正が広くデプロイされています。
問題が発生しているサーバーの MaxConcurrentApi レジストリ値を大きくします。このためには、次の手順に従います。
1.[スタート] ボタン、[ファイル名を指定して実行] の順にクリックし、「regedit」と入力して [OK] をクリックします。
2.次のレジストリ サブキーを見つけてクリックします。
3.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
4.[編集] メニューの [新規] をポイントして [DWORD 値] をクリックします。
5.「MaxConcurrentApi」と入力して Enter キーを押します。
6.[編集] メニューの [変更] をクリックします。
7.MaxConcurrentApi の新しい値を 10 進数で入力して、[OK] をクリックします。
8.コマンド プロンプトで、次のコマンドを入力して Enter キーを押します。
9. net stop netlogon
10.次のコマンドを入力して、Enter キーを押します。
11. net start netlogon
サーバーとそのドメイン コントローラー (問題がドメイン コントローラーで発生していた場合は、信頼されたドメイン コントローラー) とのネットワーク接続に遅延が見られないことを確認します。ネットワークの遅いことが原因で問題が発生したり、悪化したりすることがあります。
NTLM を使用しているアプリケーションとサービスで、代わりに Kerberos 認証を使用するように構成します。この構成手順は、アプリケーションによって異なります。
Kerberos の PAC による認証で問題が発生している場合は、サービスが許す限り、この認証を無効にします。これは、Kerberos が原因のシステム イベント 7 が発生しているサーバーで行ってください。
注:IIS アプリケーション プールや Exchange 関連サービスのいくつかでは、Kerberos の PAC による認証を無効にすることはできません。
注:環境に合った MaxConcurrentApi の設定値を決める方法については、次のサポート技術情報の記事を参照してください。
サポート技術情報の記事: 2688798
MaxConcurrentApi の設定を使用して NTLM 認証のパフォーマンスを調整する方法
関連情報
この問題に関する詳細は、次の TechNet の記事をご覧ください。 MaxConcurrentAPI を NTLM パススルー認証用に構成する。
Target | Microsoft.Windows.Server.10.0.OperatingSystem | ||
Parent Monitor | System.Health.AvailabilityState | ||
Category | StateCollection | ||
Enabled | True | ||
Alert Generate | True | ||
Alert Severity | MatchMonitorHealth | ||
Alert Priority | Normal | ||
Alert Auto Resolve | True | ||
Monitor Type | Microsoft.Windows.Server.MaxConcurrentAPI.MonitorType | ||
Remotable | True | ||
Accessibility | Public | ||
Alert Message |
| ||
RunAs | System.PrivilegedMonitoringAccount |
<UnitMonitor ID="Microsoft.Windows.Server.10.0.MaxConcurrentAPI.Monitor" Accessibility="Public" Enabled="true" Target="ServervNext!Microsoft.Windows.Server.10.0.OperatingSystem" ParentMonitorID="SystemHealth!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="WindowsServer!Microsoft.Windows.Server.MaxConcurrentAPI.MonitorType" ConfirmDelivery="false" RunAs="System!System.PrivilegedMonitoringAccount">
<Category>StateCollection</Category>
<AlertSettings AlertMessage="Microsoft.Windows.Server.10.0.MaxConcurrentAPI.Monitor.AlertMessage">
<AlertOnState>Error</AlertOnState>
<AutoResolve>true</AutoResolve>
<AlertPriority>Normal</AlertPriority>
<AlertSeverity>MatchMonitorHealth</AlertSeverity>
<AlertParameters>
<AlertParameter1>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</AlertParameter1>
</AlertParameters>
</AlertSettings>
<OperationalStates>
<OperationalState ID="MaxConcurrentAPIAvailable" MonitorTypeStateID="Success" HealthState="Success"/>
<OperationalState ID="MaxConcurrentAPIReached" MonitorTypeStateID="Error" HealthState="Error"/>
</OperationalStates>
<Configuration>
<DiagnosticMode>0</DiagnosticMode>
<IntervalSeconds>900</IntervalSeconds>
<SyncTime/>
<TimeoutSeconds>300</TimeoutSeconds>
<ThresholdWaiters>50</ThresholdWaiters>
<ThresholdTimeouts>2000</ThresholdTimeouts>
</Configuration>
</UnitMonitor>