Office 365のサービスの一つであるEOP（Exchange Online Protection）を利用すると、ハイブリッド構成時に受信時だけではなく送信時についてもspam判定を行うように構成をすることができます。

今回は、Exchangeハイブリッド構成時にOffice 365への通常のメール送信速度を理論上数倍にする方法をご紹介します。

Exchange Serverからの送信時のメールフローは、これにするかEdgeから直接出すかというほぼ2択になりますが、送受信でメールフローが同じでありシンプルだということもあり、この構成を取っている方も多いかと思います。

EOP を介した基本的なメール フローの設定に必要なコネクタを作成する などの記事を参照にこちらのEDGEサーバからExchange Online Protectionへの送信コネクタを作成します。サーバからEOPに円滑かつ継続的にメールを送信する為の注意点として、以下の記載が有ります。

1. 1 接続当たりの送信電子メール数が 50 通以下
2. 使用する同時接続数が 50 未満

今回は、この値を守りつつ、少しでもパフォーマンスを上げられるようにしていきたいと思います。

まず、1番です。こちらは送信コネクタのパラメータにSmtpMaxMessagesPerConnectionという値が有り、20に設定されています。

SMTP接続時のネゴシエーションに時間がかかるようであればこの値を大きくするのですが、インターネットを経由して送信していることもあってか、プロトコルログを確認する限りEdgeからEOPへの送信は、実際のメール送信に殆どの時間を費やしているのでこれを50などに増やしてもあまりパフォーマンスは向上しなさそうです。

次に2番。前提として、こちらの「同時接続数」の判定ですが、受信コネクタのMaxInboundConnectionPerSource の設定と同じように制御された場合、IPアドレスをベースにEOPに判定されてしまう可能性があります。複数台のEdgeサーバが同一のグローバルIPでNAPTして送信される場合は、50を台数で割った数字になるように調整しましょう。

この値は、Set-TransportService(Exchange 2010の場合はSet-TransportServer)のMaxPerDomainOutboundConnectionsで指定できます。デフォルト値は20になります。これだけ見ると、単一のスマートホスト先であるEOPへは、デフォルト設定でも20平行なのでそれなりにパフォーマンスが確保できるように見えますね。

が、実際に比較的メール流量が多い環境で利用すると、かなりEdge→EOPのパフォーマンスは低く、メールが滞留するポイントになりがちです。

なぜかというと、MaxPerDomainOutboundConnectionsというのはあくまで制限値であり、Exchangeがそこまで利用しようとするかとすると必ずしもそうではないからです。Edgeサーバ上でGet-Message -Queue [EOPへのキュー]などで挙動を観察してみると、キューの数が20までは1つのセッションで送信しようとして、それを越えると1つSMTPセッションを張るという挙動に見えます。

つまり デフォルトの制限値である20同時セッションになるにはキューが400通溜まる状態に、50同時セッションなら1000通までにならないといけない ことになります。そんな状態になったら、メールの配信遅延が顕在化してしまっている頃ですよね。

という訳で、ここをチューニングしてみたいと思います。

ここの数値ですが、コマンドの設定で変えられる設定は見つかりません。

色々と調べた結果、EdgeTransport.config にSmtpConnectorQueueMessageCountThresholdForConcurrentConnections パラメータを設定することにより、こちらをチューニングすることができました。

C:\Program Files\Microsoft\Exchange Server\V15\Bin\EdgeTransport.exe.config の<app Settings> </app Settings>の間に以下の値を入れます

<add key="SmtpConnectorQueueMessageCountThresholdForConcurrentConnections" value="新たにセッションを張る閾値"/>

例えば、デフォルトは20になりますので、値を5にした場合は理論上4倍の速度でセッションが張られて処理速度が向上することになります。

どんな値を設定したほうが良いかは、利用するリソースやメールサイズ等の特性によりケースバイケースだと思いますので、定期的にキューの状態やプロトコルログなどを確認していただいてチューニングするのがよろしいかと思います。

Exchange Serverでは、以前のバージョンより同じメールが複数届いた場合に最初の1通のみ受信し、残りのメールを重複として削除するシングルインスタンス機能が備わっています。Exchange Server 2013においても同機能が備わっております。

重複と検出判断されたメールは、メッセージ追跡ログを見ると、2通目以降のメールには Source STOREDRIVER の EventId DUPLICATEDELIVER が記録され、メールボックスには最初の1通だけ配送されます。

、同一のメッセージと見なされる条件は以下の通りです。

• 同一のMessageIDヘッダであること
• 同一のDateヘッダであること
• 同一のメールボックスへの配送であること

参照：How does duplicate detection work? / Exchange 2007 で重複するメッセージを検出する方法

この機能自体は、ユーザー側のメールを読む負荷を軽減すると共に、メールのループ防止などの意味で重要な役割を担っているのですが、一定のケースで2通目以降のメールを受け取りたい場合があります。例えば、

1. ウィルスが誤検知されて添付ファイルが削除されたメールをアンチウィルスソフトから再送する場合
2. ユーザが誤って削除して復元できなくなったメールをジャーナルアーカイブから再送する場合
3. システム上の制約で同じMessageIDで送信してくるメールを受信する場合
4. Toに自身のアドレスが、Ccにメーリングリストが入っていて、メーリングリスト毎にフォルダ分けしている場合

などです。Exchange Server 2007/2010では、デフォルトで1時間の間このメッセージの重複を検知します。また、情報自体は7日間保存しております。この時間を変更する際には、レジストリの HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server_Name>\Private-<GUID>\ 配下のDeliveredTo Expiration in Hours や DeliveredTo Cleanup Interval in Seconds を変更する事により変更することが可能でした。

ところが、Exchange Server 2013においては、検証する限りでこの設定が変更になっているようで、今までデフォルトでは1時間待てば配送されていた物が、7日間配送されないようになっておりました。また、今まで設定していたレジストリを設定してみても動作は変わりません。

Microsoftのサポートに問い合わせて調査したところ、Exchange Server 2013 CU7現在、上記設定は7日にハードコーディングされており変更できなくなっているとのことでした。

Exchange Serverは、基本的にExchange Onlineと同じコードがベースになっているという話を聞いたことがあるので、Online側でカスタマイズ不可としてハードコーディングされているのであれば、それも考えられるかなとは思う反面、今までとデフォルト値を変更した上に設定変更も不可…というのはちょっと厳しいかなとも感じております。

最近、Exchange Onlineの挙動を見る限りでは、重複検出期間が24時間に仕様が変更になったっぽいので、オンプレも今後のCU8やそれ以降で挙動が変更にならないかどうか注視していきたいと思います。

関連記事：　重複メッセージの除去（Exchange Online）

Exchange Server 2010で、ある日突然CASやメールボックスサーバがMSExchange ADAccessの2130,2102,2103など、いずれもドメインコントローラに接続できない旨のエラーが出てサービスが利用できなくなる事があります。

事象自体はOS再起動をすると治るのですが、たまに発生する割には、出る環境と出ない環境が決まっていて変だなと思って調査をしたのでそのメモを。

まず、この事象に陥ってもRDPでサーバに接続できます。でも、なぜかドメインコントローラに接続ができない、詳しく言うと、ドメインコントローラの名前解決のDNSに失敗します。nslookupでDNSサーバに接続しようとしても接続できません。

もっと調べると、この状態ですがTCPやICMPの通信には影響を及ぼさない（なのでRDP接続はできる）のですが、UDPでのみ通信ができないという状態だということが分かりました。

ここで、セッションの状態を見てみようとnetstat -anoを打ってみます。 

と、延々と続くUDPの待ち受けポート。どうやらこいつが原因のようです。TCPの動的ポート枯渇というのは497日問題で良く聞いた話ですが、UDPにも動的ポートがあります。どうやらこれが枯渇しているようです。

netstatの結果より調べたプロセスを特定します。タスクマネージャーを開き、必要に応じて更に列の選択でコマンドラインを表示させます。（w3wp.exeの場合、ワーカープロセスの特定に使います）

こちら場合によっていくつかケースがあるのですが、多くの場合はCASはOWAかExchangeServicesのIISのワーカープロセス、メールボックス（特にパブリックフォルダを有している）の場合はRPC Client Accessが多いです。

サービスの再起動か、ワーカープロセスの場合はIISマネージャーから、被疑アプリケーションプールのリサイクルを実施します。

これでしばらく待つとMSExchange ADAccessが自動的にドメインコントローラを見つけてくれ、動作が再開します。

そもそもの原因なのですが、どうやら上記を初めとする一部のExchangeアプリケーションが全ドメインコントローラに接続できないタイミングで、そのアプリケーションでリークが発生。UDPの動的ポートが掴みっぱなしになり、そのポートが徐々に溜まっていき、16000超の領域を全部埋め尽くすと、今回の様な事象になるようです。

確かに、検証環境でADが1台しかなかったり、複数台有ってもメンテナンスの時などに一定時間（例えば15分）とか開けずに1台目のドメインコントローラが上がってきたタイミングですぐに2台目を再起動するなどの運用をしている環境でたまに発生していました。

特に直す気配も無さそうなので、対策としては

1. 常時最低1台はMSExchange ADAccessからドメインコントローラに接続できているようにする
2. UDPの動的ポートの数を増やす
3. UDPのポート数を監視（1万くらいになったら対象プロセスを再起動）

とかになりますね。

昨年末ごろから、Exchange 2013の管理系の自作スクリプトが失敗する様になったという話を色々な所で耳にするようになりました。

Exchange Server 2013のコンソールからExchange管理シェルのプログラムを起動すると、黄色い字で「○○○（サーバ名）に接続しています／接続しました」と表示されます。

ただ、実際には別のサーバに接続しているケースがあります。例えば、下のスクリーンショットではmbxcas02ではなくmbxcas01に接続していることが、Get-ExchangeCertificateコマンドレットの実行結果からお分かり頂けると思います。

これは、Exchange Server 2013のCU 11から実装されたExchange管理シェル（EMS）の仕様変更に依るものです。

Exchange 管理シェルとメールボックスのアンカー設定

簡単に説明すると、今まではExchange管理シェルは接続した先のサーバにそのまま接続されていましたが、Exchange 2013 CU11からはCAS（クライアントアクセスサーバ）に接続した場合は自分のメールボックスの存在するメールボックスサーバ（メールボックスを持たないアカウントの場合は調停メールボックスの存在するサーバ）に接続するようになりました。

なので、ローカルサーバへのオペレーションだと思って実行しているコマンドは違うサーバに対して実行されてしまうことがあります。接続先のサーバが異なるADサイトに存在をしている場合、AD情報の同期タイミングも考慮しなければいけません。

なお、CASの役割がインストールされていないサーバ（メールボックスのみやエッジトランスポートサーバ）の場合は影響ありません。

基本的な対処策としては、例えば Get-ExchangeCertificate であればGet-ExchangeCertificate -Server (hostname)などとして、明示的に実行先のサーバを指定するようにするという形になります。

いままで通りでやりたい場合は、PowerShellを管理者権限で立ち上げたあと、

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

と実行すれば今までと同じ感覚で利用できますので、私なんかは.ps1スクリプトにしてデスクトップに置いておいてます。

先日の投稿の続編です。

Exchange Server 2013 CU11から、Exchange管理シェルの接続先が自身のメールボックスのサーバに変更になった旨告知がありました。

その後ですが、CU12の公開に合わせて以下のような告知がありました。

Exchange 2013 CU12 および Exchange 2016 でのリモート PowerShell のプロキシ転送時の処理

しかし、CU11 に実装された変更により、オンプレミス環境のリモート PowerShell では予想外の問題が複数発生しました。これらの問題について詳細にコードを見直した結果、CU11 に実装された変更を取り消し、Exchange 2013 CU12 のリリース時に従来のサーバー バージョンによるルーティングを使用するように戻すことになりました。

Oh, 色々とスクリプトを修正していたのですが…。

まあ、Microsoft側も速い判断で良かったと思います。ということで、CU12以降を入れれば元通りということになりました。

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のみの想定です。別の発生要因により直らなかった場合はアラートを出すなどの処理を加えても良いかもしれません。

6/25(土)に日本Microsoft品川本社で行われるInteract x Cloud Samurai 2016 Summerに登壇させて頂く事になりました。

タイトルは【オンプレミス x Exchange Server 2016 という選択肢】ということで、Exchange Onlineではなくサーバ製品であるExchange Server 2016について話をさせて頂きたいと思います。

Exchange Serverってそれなりにまだ出ているみたいだけど、普段なかなか勉強会で話を聴く機会がないよね…って話がありまして、誰も喋らないのであればじゃあ私が、ということで枠を頂きました。

内容としてはまだこれから考えていくのですが、なるべく具体的に、実際に役に立つ内容となるようにしたいと思ってます。今考えてる（というか、自分が聴きたい内容なのですが）トピックは、以下の感じです。全部喋れるかわかりませんが…。こういった事が聴きたいとかのリクエストもあれば是非御連絡下さい。

• Exchange Onlineとはどういった違いがあるの？
• 実際作るとどういったH/W構成になるの？
• 構築や運用で気をつけるべき所とかあるの？
• 価格はどれくらい？
• 2010とか2013とどう違うの？

お時間が許すようであればご参加頂ければ幸いです。

インターネットへの直接接続が無い環境でのExchange 2013組み込みのマルウェア対策のパターンファイル更新についてメモ。

Exchange Server 2010の頃のFPE(Forefront Protection for Exchange)はGUIで設定できる項目があったのですが、Exchange Server 2013では標準に組み込まれて、Exchange管理シェル(EMS)からも設定することができません。

winhttpで設定することもできるのですが、意外とBypass-listを書くのが面倒だったりするので、FPEの頃のようにパターンファイル更新のみ特定のProxyサーバ経由で実行するように設定できます。

1. http://forefrontdl.microsoft.com/server/scanengineupdate に対して、認証なしで接続できるようにProxyサーバを設定
2. PowerShellを管理者として開いて以下のコマンドを実行する

Add-PSSnapin Microsoft.Forefront.Filtering.Management.PowerShell
Set-ProxySettings -Enabled $true -Server [ProxyサーバのIP] -Port [Proxyサーバのポート]

しばらく待てば更新が開始されます。即時で実行したい場合は、以下のコマンドで。

cd 'c:\Program Files\Microsoft\Exchange Server\v15\scripts\'
.\Update-MalwareFilteringServer.ps1 -Identity [対象のExchangeサーバのFQDN]

Exchange Server 2013 / 2016の累積更新プログラム(CU)を初めとする更新プログラムの適用においては、インストール開始時にExchange関連のサービスが停止されるのみならず、自動起動の状態が「無効」として設定されます。

これにより、インストール中に故障が発生してOS再起動した場合などにおいても、更新が中途半端になされた状態でExchange Serverが立ち上がって全体の動作に悪影響を及ぼすなどの事が無いように設計されております。

反面、これも万能ではなく、意図せずサービスが無効化された状態のままインストーラーが終了（しかも再開ができない）してしまうケースが比較的に多く存在します。再現性は無いのですが、以下私が遭遇したケースです。

• インストーラーが異常終了してしまった
• 途中でハードウェア障害でOSが再起動した
• 厳密な名前の検証を無効化せずに中間更新プログラム(IU)を適用した
• SCCM経由で他の更新プログラムと一緒にExchangeの更新プログラムをインストールした

正常に動作しているサーバーのサービスの状態と見比べながら戻すのが一番単純な方法ですが、特に時間に追われているメンテナンス作業などの場合は途方に暮れることになってしまいます。

こうしたケースにおいて覚えておいた方が良いコマンドがあるので紹介します。

① PowerShellを管理者モードで開く
② インストールディレクトリのBin（C:\Program Files\Microsoft\Exchange Server\V15\Bin）に移動
③ .\ServiceControl.ps1 AfterPatch

更新プログラム適用の処理において、実際にはどういった処理がされているかは C:\ExchangeSetupLogs\ExchangeSetup.log にも詳細が記録されておりますので、そちらを参考にしても良いかと思います。

おかげさまで、MicrosoftのMVPアワードをOffice Servers and Servicesの分野で受賞しました。
2012年にOffice 365で初受賞して以来、5年連続での受賞となります。

これも偏にblogやコミュニティ運営などでご協力を頂いている皆さまの応援のおかげと感謝しております。

これからもよろしくお願い致します。

Exchange Server 2013/2016では、これまでのバージョンと同じく細かいカスタマイズを行う場合やバグフィックスの為にweb.confgを直接書き換えるというシーンが比較的あります。

例）
クライアント固有のメッセージのサイズ制限を構成する
MSExchangeApplicationLogic Event 3018 in Exchange Server 2013
Exchange Server 2013 doesn’t display all OUs when it creates a new mailbox
Using security groups to set calendar permissions does not work in an Exchange resource forest

しかしながら、こちらのファイルはCUを適用する度にデフォルトの状態にリセットされます。CUは基本的に四半期に一度リリースされますので、3か月に一度設定がクリアされるという形になります。

毎回メモ帳などを利用して書き戻すというのも運用上の負担になりますし、作業漏れやミスによって障害が引き起こされる可能性もあるので、今回はその変更作業をPowerShellを利用して行いたいと思います。

web.configは中身はXMLドキュメントになりますので、Get-Contentした物を[XML]キャストすればPowerShellから普通に扱えます。例えば、KB2882961対策でOWAのweb.configのAppSettingsの欄に<add key=”UseDisabledAccount” value=”1″ />を加えたい場合、以下の様に行います。

$webConfig = "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\web.config"
$AppSetKey = "UseDisabledAccount"
$AppSetValue = "1"
$doc = [XML](Get-Content $webConfig)
$newAppSetting = $doc.CreateElement("add")
$doc.configuration.appSettings.AppendChild($newAppSetting)
$newAppSetting.SetAttribute("key",$AppSetKey);
$newAppSetting.SetAttribute("value",$AppSetValue);
$doc.Save($webConfig)

同様に、AppSettings以外のsystem.webなどの項目も書き換えられます。例えば、ActiveSyncの最大送受信サイズを20MBにするためにCASのweb.configの既存のmaxRequestLengthを書き換える場合は、

$webConfig = "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\sync\web.config"
$ObjKey = "maxRequestLength"
$NewValue = "20480"
$doc = [XML](Get-Content $webConfig)
$obj = $doc.configuration."system.web".httpRuntime.$ObjKey
if ($obj -ne $null) {
  $doc.configuration."system.web".httpRuntime.$ObjKey = $NewValue
  $doc.Save($webConfig)
} else {
  Write-Host "$ObjKey not found"
}

こんな感じです。（既存の値を変更するので、既存の値の存在チェックを入れています）

なお、同様に既存のweb.configの設定内容を確認することもできますので、書き戻しが必要かどうかチェックする際にも利用することが可能です。色々ご自分の環境に合わせてお試しいただくと良いかと思います。

ある日Exchange Server管理シェルを起動しようとしたところ、見覚えの無いエラーで何のコマンドも実行できないようになってしまいました。

「Import-PSSession を使用して現在のセッションのエクスポート モジュールを生成できません。」

特に変更をした直後ではなく、エラーメッセージの内容も良く分かりません。原因が何かを悩んでいたのですが、色々検索をしたところ、2-3日前に実行したWindows Updateが原因であることが分かりました。

発生する条件は以下の通り。

• Exchange Server 2013もしくはExchange Server 2016
• KB3000850を未適用の環境
• 2017年07月以降の月例累積更新プログラムを適用

これを満たしても、一定期間（2-3日？）についてはローカルキャッシュから利用されるために事象は発生しませんは、ふと気がつくと発生するようになります。

その環境ではKB3000850がSCCMから必須と表示されなくなっていたので気づかなかったのですが、後から手動でKBを適用したところ、解消しました。

なお、KB適用前に一時的にコマンドを実施したい場合などは、Exchange管理センター(EAC)からブラウザで実行をするか、以下のコマンドで手動でPowerShellスナップインを追加してコマンド実行が可能です。

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

Exchange Online と連携したアプリケーションを利用する際、アプリケーション偽装（ApplicationImpersonation）という特権（管理者権限）を利用するケースが多いです。

これを利用する事により、アプリケーションは自身の権限設定を利用して対象のユーザーになりすましてメールを取得したり、予定表を更新したりできます。

例えば、以下の様なことができます。

1. モバイルアプリケーションがExchange Serverのメールを取得する
2. 会議室有効利用のサービスが会議室の利用情報を取得、更新する
3. メールの移行ツールが各ユーザーのメールボックスの中身を取得する

最近特にExchange Onlineと連携するアプリケーションやサービスが沢山出てきて、その中で利用されています。

導入手順などでは、単純に「①システムで利用するアカウントを作る　②作成したアカウントのパスワードを無期限に設定する　③作成したアカウントにApplicationImpersonationの権限を付与する」などの内容が詳細な手順と共に記載されていることが殆どです。

確かに、アプリケーション開発者の立場からするとそういった記載になるのは理解はできるのですが、Exchange管理者の立場としては、単にアプリケーションを利用するにはこの手順が必要だから…と思考停止せずに、きちんとこれを設定することの意味（リスクを含めた）を理解した上で設定する必要があります。

○権限に対する認識について

この特権は、全てのユーザーに偽装してメールを読み書きできます。つまり、このアカウントが悪用された場合、役員を含む全てのメールボックスの内容を見られてしまいます。

しかも、都合の悪いことに、このアカウントは平常時から様々なメールボックスにアクセスしているため、メールボックス監査のログからも悪用されていること自体が判別することが困難です。

○役割ベースアクセス制御（RBAC）について

権限の付与にはExchangeの役割ベースアクセス制御（RBAC）という物が利用されます。これにより、設定された権限の組み合わせを元にした管理者役割グループの作成や、ユーザーへの権限の割り当てを行います。

この中に、管理役割スコープの設定という項目が有り、これを利用する事によりこの権限が有効な範囲を決定することができます。

例えば、一般社員向けにモバイルアクセスの為の権限付与で必要な場合に、そのスコープに役員を初めとしたモバイルを使わない社員を含めない事により、リスクを最小化することが可能です。

会議室のスケジューラーのアプリケーションには、会議室メールボックスに対する権限のみスコープに含めれば、例え会議室に設置されているKIOSKがハッキングされたとしても、その端末に設定されている権限を利用して社長のメールボックスにアクセスされるというリスクは少なくなります。

○アカウントの棚卸しについて

Exchangeの最上位である組織管理者（Organization Management）の権限については、それが付与されているユーザーについての棚卸しが行われているケースが多いかと思います。

ApplicationImpersonationの権限を持つユーザーに関しても、前述の通り非常に強い特権になりますので、同様にきちんと棚卸しをする必要があります。Get-ManagementRoleAssignment コマンドレットを利用すれば、その権限を付与されているユーザーもしくはグループの一覧が取得できます。（以下、出力例）

PS C:\> (Get-ManagementRoleAssignment -Role "ApplicationImpersonation").RoleAssigneeName
Organization Management
RIM-MailboxAdmins6be8fce7ca594ef89a6175fb7746b304
admin

システムの仕組み上、パスワードの変更が容易でないというケースもあるかと思いますが、それでも不可能では無いと思いますので、メンテナンスなどのタイミングで実施は試みた方が良いと思います。

アクセス元のIPアドレス情報などが取得できる環境であれば、設定したシステム以外からアクセス試行が無いかもきちんと管理しておくとより望ましいですね。

久々にローカル環境でExchangeのトラブルシュートをしていたところ、特定の条件でイベントビューアーがクラッシュする事に気がつきました。

• 2019年6月の更新プログラムを適用したExchange環境で発生
• [カスタムビュー]またはイベントビューアーから [現在のログをフィルター] を選択すると発生
• エラー内容は以下の通り

別のプロセスで使用されているため、プロセスはファイル 'C:\ProgramData\Microsoft\Event Viewer\Views\msexchangerepl_events.xml' にアクセスできません。

 例外の種類:
 　System.IO.IOException

 例外のスタックトレース:
    場所 System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
    場所 System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
    場所 System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
    場所 Microsoft.Windows.ManagementUI.CombinedControls.EventsNode.get_IsReadOnlyView()
    場所 Microsoft.Windows.ManagementUI.CombinedControls.EventsNode.UpdateReadOnly()
    場所 Microsoft.Windows.ManagementUI.CombinedControls.EventsNode.InitializeQueryNode(FileInfo fileInfo)
    場所 Microsoft.Windows.ManagementUI.CombinedControls.EventsNode.AddSubNodes(DirectoryInfo dir, EventNodeType nodeType, Boolean userQuery, String standardViewConfig)
    場所 Microsoft.Windows.ManagementUI.CombinedControls.EventsNode.AddSavedQueryNodes()
    場所 Microsoft.Windows.ManagementUI.CombinedControls.EventsNode.CreateChildNodes()
    場所 Microsoft.EventViewer.SnapIn.MMCEventsNode.ExpandNode()
    場所 Microsoft.EventViewer.SnapIn.MMCEventsNode.OnExpand(AsyncStatus status)
    場所 Microsoft.ManagementConsole.NodeSyncManager.ProcessRequest(NodeRequestInfo info, IRequestStatus requestStatus)
    場所 Microsoft.ManagementConsole.SnapIn.ProcessRequest(Request request)
    場所 Microsoft.ManagementConsole.Internal.SnapInClient.Microsoft.ManagementConsole.Internal.IMessageClient.ProcessRequest(Request request)
    場所 Microsoft.ManagementConsole.Internal.IMessageClient.ProcessRequest(Request request)
    場所 Microsoft.ManagementConsole.Executive.RequestStatus.BeginRequest(IMessageClient messageClient, RequestInfo requestInfo)
    場所 Microsoft.ManagementConsole.Executive.SnapInRequestOperation.ProcessRequest()
    場所 Microsoft.ManagementConsole.Executive.Operation.OnThreadTransfer(SimpleOperationCallback callback)

これは、6月の更新プログラムの適用により、イベントビューアーからExchangeをインストールした際に自動的に作られるイベントビューアーのカスタムフィルタのxmlファイル（msexchangerepl_events.xml）が読み込めなかった為に発生しています。

7月の更新プログラムで解消されているので、7月の更新プログラムを当てれば解消されますが、当然再起動を伴いますので、運用中の環境の場合はすぐには難しいことも有ると思います。

暫定回避したい場合は、このファイルの実体を別のフォルダに一旦移動してあげれば事象は解消可能です。

Move-Item "C:\ProgramData\Microsoft\Event Viewer\Views\msexchangerepl_events.xml" c:\temp

7月以降の更新プログラムを当てた後、待避していたファイルをまた元の場所に戻してあげればカスタムビューが復活します。