Forefront TMGがサポート切れとなり、Microsoftが提供しているIISモジュールであるARR（Application Request Routing）を利用してExchange ServerのOWAやActiveSyncなどをインターネットに公開されている方も多いかと思います。
ある特定の環境下でARRを利用していると、ある時からARR上にSchannel 36871（内部エラー：10013）が記録され続け、そのままアクセスできない状態が続くことがあります。
10013のエラーコード自体は、サーバ側から返された利用可能な暗号化スイートの一覧にクライアント側で対応した物が無いという物なのですが、Schannelの設定はARRのクライアント側もExchangeのCASのサーバ側も同じに設定していますし、そもそも通常時は利用できているのでそういったことは無いのではと推測しました。
色々と検証したところ、以下のような事が分かって来ました。
- 発生する環境は、SSL3.0を無効化した環境
- 発生するタイミングは接続先のCASが起動してきたタイミング
- ヘルスチェックを有効化している環境もしくは、アクセスが多いタイミングで発生する可能性が高い
- 一度発生すると出続ける
以上のことから、Exchange Server側でIISが立ち上がりきる前にARRからアクセスし、TCPセッションの確立自体は成功したものの、その後のSSL通信の確立に失敗した為に発生。かつARRは都度セッションを張るのでは無く、一度張ったセッションを再利用し続ける仕様の為に発生している可能性が高いと思われます。
こちらを解消するためには、ARR側のOSを再起動しても勿論直りますが、一番簡単なのはARRのアプリケーションプールをリサイクルすることにより、完全に立ち上がったCASに対してセッションを張り直して貰うことです。
あとは、これを自動的に事象発生時に実行して貰うように、以下の様なスクリプトを作成してタスクスケジューラでイベントログをトリガーにして起動すれば自動的に復旧してくれます。
Import-Module WebAdministration $SysDate = Get-Date -Format "yyyy/MM/dd HH:mm:ss" $HostName = hostname "$SysDate $HostName ARR Recovery Script Start" | Out-File C:\scripts\recovery_arr\recovery_arr.log -encoding default -append $site = "Default Web Site" $pool = (Get-Item "IIS:\Sites\$site"| Select-Object applicationPool).applicationPool Restart-WebAppPool $pool sleep 300 $SysDate=Get-Date -Format "yyyy/MM/dd HH:mm:ss" "$SysDate $HostName ARR Recovery Script End" | Out-File C:\scripts\recovery_arr\recovery_arr.log -encoding default -append
このイベントログは発生すると大量に出続けるので、同時起動を無しに設定し、スクリプト中で5分間のwaitを入れていますが、この値は環境により調整して下さい。WebアプリケーションプールはDefault Web Siteのみの想定です。別の発生要因により直らなかった場合はアラートを出すなどの処理を加えても良いかもしれません。