ある日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 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 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 にも詳細が記録されておりますので、そちらを参考にしても良いかと思います。

インターネットへの直接接続が無い環境での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]

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とどう違うの？

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

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

先日の投稿の続編です。

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

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

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

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

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

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