6月の月例更新でのイベントビューアーの問題

久々にローカル環境で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月以降の更新プログラムを当てた後、待避していたファイルをまた元の場所に戻してあげればカスタムビューが復活します。

Office 365とIPv6

この投稿はOffice 365 Advent Calendar 2015に参加しています。

2011年4月にAPNICのIPv4アドレス在庫が枯渇し、今年の9月には遂にARINでもIPv4アドレスが枯渇し、IPv6への移行がいよいよ喫緊の課題となってきました。

特に、サービスを提供するServer側においては従来提供しているIPv4の他、IPv6にも対応したIPv4/v6デュアルスタックでのサービス提供が求められております。
Microsoftにおいても様々な分野でIPv6対応を進めており、以前の投稿で紹介した通り、Office365もIPv6での提供が進んでいます。

今回は、Office365側でIPv6化が進んでいく中で、接続ができない、接続が遅いなど、いくつかトラブルになる事例などがありますので紹介します。

日本リージョン開設に伴い、Exchange Onlineの接続先である outlook.office365.com のDNS解決は日本エリアでは、以下の様にAPACに収容されていた際に比べて数が多く、IPv6が9個、IPv4が9個返ってきます(執筆時)
20151205_01

Windowsをはじめ、多くのOSではIPv4よりIPv6の利用の方が優先的に利用されるように設計されています。
しかしながら、特に企業ネットワークなどではIPv6での通信が十分にサポートされていない設計のまま、IPv6意図せず有効化されているといるケースもあります。

この場合、IPv6の接続が失敗した後にIPv4での接続を試みるために、Office365への最初の接続が遅くなったように見えます。回避をするためには、IPv6の優先度をIPv4より下げる(こちらが推奨されている)もしくはIPv6を無効化するという形になります。

また、Proxyとして以前のバージョンのsquidをそのまま利用している環境では、DNSラウンドロビンで複数返ってきたIPからいくつまで接続を試みるかという forward_max_tries というパラメータがデフォルトで10の状態なので、IPv6で既に9個使ってしまっていて残り1の状態です。現在はまだそのラスト1回で接続できればOKなのですが、将来的に増設された場合は完全にIPv6のみで試行が終わってしまうことになります。

こちらのケースでは、IPv6の優先度を下げるか、もしくは forward_max_tries を25など、outlook.office.comのDNSの名前解決で返ってくる数よりある程度多く設定することにより回避可能です。

 

Office 365のIPv6のサポート状況は、以下のページで随時最新情報が提供されますので、定期的にチェックされることをお勧め致します。

(現時点のトピックとしては、Exchange OnlineはデフォルトでIPv4/v6のデュアルスタック、SharePoint OnlineとSkype for Business OnlineではMicrosoftでのリクエストベースでの有効化となっているという位でしょうか。)

Office 365 サービスでの IPv6 サポート