EventHistory を活用してメール アイテムに加えられた操作 (Store Event) を追跡する!

今回は以下の英語の Blog にて公開している受信したアイテムが意図せず移動している、削除されたといった場合のデータベース上の EventHistory テーブルを使用した調査方法について、追加の情報をご案内いたします。※以降の説明は、Exchange 2010 以上のバージョンを基に説明しております。 Title: Adventures in querying the EventHistory tableURL: http://blogs.technet.com/b/exchange/archive/2013/06/24/adventures-in-querying-the-eventhistory-table.aspx 調査の前にまず、アイテムが意図せず削除された場合にご確認いただきたい内容については、下記 Blog にてご案内しております。   Title: 突然アイテムが消えた!場合の対策  URL: http://blogs.technet.com/b/exchangeteamjp/archive/2015/04/15/3648071.aspx しかしながら、お客様よりお寄せいただくお問い合わせの中には、上記 Blog の内容をすべて確認した場合にも説明ができない現象が稀にございます。原因究明に至ることを保証するものではありませんが、問題のメールボックスが存在するデータベース上で発生する Store Event (アイテムの作成/変更/移動/削除) の記録である EventHistory テーブルを調査することで、ヒントが得られる場合があります。 本 Blog では、お客様にご案内の実績のある EventHistory テーブルの確認手順を以下にご紹介いたします。メールボックス内の特定のアイテムに関する調査で行き詰った際などに、アイテムへ操作を行ったのが Outlook なのか、OWA なのか、それとも ActiveSync なのかといったことは明確になるため、何か手がかりとなるかもしれません。 ==========================================================================EventHistory テーブルを出力し、Store Event を確認する==========================================================================既定では EventHistory テーブルは直近 7 日間の Store Event のみ保持しております。※ Get-MailboxDatabase コマンドにおける、EventHistoryRetentionPeriod…


Exchange 2013 環境におけるログの出力について

Exchange 2013 は以前のバージョンに比べ、出力されるログの種類も増えていることは Exchange 2013 を運用されている方にとってはよくご存じの内容かと思います。 これらのログが存在することで、問題が発生した際のトラブルシューティングをより円滑に進めることができるようになっていますが、これらのログ ファイルについては Exchange 2013 の CU6 でさらに種類が増え強化されています。 しかしその反面 CU6 以降のバージョンを適用してしばらく経過した後に、Exchange のインストール ディレクトリが存在するディスク容量が逼迫してしまっていたといったお問合せをいただくことがありました。 ※ 運用状況にもよりますが、CU6 以降では以前の CU に比べ、Exchange 関連のログ量が数 GB 程度増えたといった報告があります。 Exchange 2013 ではシステム要件として OS や Exchange の DB が使用する領域以外に 30GB のディスク領域を用意する必要があり、多くの環境では各ドライブの使用量を監視いただいていることやディスク容量に余裕を持って運用されていることかと思いますが、もし Exchange 2013 がインストールされたディスクの空き領域が残り少なくなってきた場合は以下の内容をご確認の上、早めの対処をご検討いただければと思います。 まずはどんなファイルにより多くの領域が使用されているか確認しましょう ドライブの使用領域が残り少なくなってきた場合、基本的には出力されるログ量を保存可能なディスク容量をご用意いただく必要がありますが、不要なファイルやディレクトリなどが存在するようでしたら、まずはそれらの退避や削除などをご検討いただければと思います。 徐々にドライブの使用量が増え続けているような状況であるものの 「何が増えた (増えている) のかわからない」 という場合は以下のようなツール (Get-DirSizeFunction.ps1) を使って簡単に特定のドライブ配下の使用量等を確認することができますので、お試しいただければと思います。 増加傾向を確認する場合はこのツールを使用して、定期的に使用量を確認・比較し、増加傾向にある情報を特定していきます。 Title : コンピューターで多くの領域を占有しているフォルダーを確認する方法はありますか URL : https://gallery.technet.microsoft.com/scriptcenter/4e83afe2-ebdf-414a-bfc9-36e76b7e9750…


よくわかる Exchange Online のメッセージ追跡 ~ Part 1 取得編 ~

みなさんこんにちは、Exchange Server サポートの 杉山 卓弥 です。Exchange Online で送受信されているメッセージを調査する場合、管理者にてメッセージ追跡を実行する機会は非常に多いかと思います。そこで、メッセージ追跡に役立つ情報を順次 Exchange Server サポートよりご紹介していきます。Part 1 では、Exchange Online のメッセージ追跡の実行方法、取得方法について使用頻度が高い順にご説明していきます。 Exchange Server サポートからのお願い********************************************************弊社サポートにメッセージ配信に関するお問い合わせをいただく際、メッセージ追跡ログをあらかじめ送付いただくことで、すぐに調査を開始することができます。また、事象の早期解決に結びつくことも多くございますので、事前の HistoricalSearch (詳細版) の取得にご協力をいただけますようお願いいたします。******************************************************** <取得方法>A. HistoricalSearch (詳細版)B. MessageTrace (詳細版)C. MessageTrace (要約版) D. HistoricalSearch (要約版) <事前準備>Windows Powershell から Exchange Online に接続します。 Title: リモート PowerShell による Exchange への接続URL: https://technet.microsoft.com/library/jj984289(v=exchg.160).aspx  ==================A. HistoricalSearch (詳細版)==================使用頻度 : ★★★詳細度 : ★★★実行時間 : ★☆☆ (長い)取得可能期間 : ★★★ (過去 90 日) 特徴…


Exchange Server 2010 の TCP / UDP の動的ポート範囲

Exchange Server をご利用のお客様でクライアントと CAS サーバー間のネットワークで特定のポートのみ空けることを検討する場合(注)があります。また Exchange Server 2010 でパブリック フォルダーを利用する場合は、Outlook クライアントは直接パブリック フォルダーを保持する MBX サーバーに対しても通信するため、クライアントと MBX サーバー間のネットワークについても考慮する必要があります。どのポートを空ければよいのかは Exchange Server が使用するポートを把握する必要がありますが、今回は、Exchange Server 2010 の動的ポートの範囲についてご紹介致します。 注)Exchange Server 2010 についての使用する一般的なネットワーク ポート情報を以下にて公開しております。 Title : Exchange ネットワーク ポートのリファレンスURL : https://technet.microsoft.com/ja-jp/library/bb331973(v=EXCHG.141).aspx 上記の公開情報では以下に記載されている通りExchange サーバー間、または MBX あるいは CAS サーバーと Active Directory との間へのファイアウォールのインストールはサポートされないことをご留意下さい。 ———- 抜粋ここから ———–メールボックス サーバーを含む各 Active Directory サイトには、クライアント アクセス サーバーが必要であることに加えて、Exchange サーバー間でトラフィックの制限を避けることが重要です。Exchange が使用する定義済みのすべてのポートが、送信元と送信先のサーバー間で双方向に開いていることを確認します。Exchange サーバー間、または…


Forefront 製品のサポート終了に伴う FPE のアンインストール方法について

Exchange/Forefront サポート チームの伯谷です。 Forefront 製品のサポートも 2 週間を切り、サポートには Forefront のアンインストール手順の確認やアンインストール時のトラブルシューティングのお問い合わせが増えています。アンインストール シリーズの第三弾は Microsoft Forefront Protection 2010 for Exchange です。以下の TechNet でも手順は公開していますが、本ブログではスクリーンショットも併せてご紹介します。 Title: FSC ユーティリティを使用した製品の無効化/有効化URL: https://technet.microsoft.com/ja-jp/library/dd639369.aspx Title: スタンドアロン サーバーからのアンインストールURL: https://technet.microsoft.com/ja-jp/library/cc482969.aspx – 手順1. Microsoft Forefront Protection 2010 for Exchange (以下 FPE) をアンインストールする対象のサーバーにログオンし、以下のサービスを停止します。サービスの停止に伴い、メールボックスへのログオンやメッセージの配信はできなくなりますので、利用するユーザーの少ない時間帯にご実施ください。 ・ハブ トランスポート サーバー   Microsoft Forefront Server Protection コントローラー    Microsoft Exchange Transport ・メールボックス サーバー   Microsoft Forefront Server Protection コントローラー   Microsoft Exchange Information Store 2….


Exchange 2013 DAG データセンター切り替え時の注意点

Exchange 2013 DAG (Database Availability Group) では、DAG を構成したサーバー間で同一メールボックス データベースのコピーを保持し、ディスク、サーバー、ネットワークの障害などのメールボックス データベースに影響を与える障害が発生した際に、自動的に回復する機能を提供します。データセンターに何らかの障害が発生した場合に備え、別のデータセンターに障害時に使用するための Exchange サーバーを構築 (災対サイトとも呼ばれています) いただいているお客様も多くいらっしゃいます。今回はこの別のデータセンターに切り替えた際の注意点についてご紹介します。 説明のため、普段使用するデータセンターを Primary DC、障害時に使用するデータセンターを Secondary DC とします。通常は Primary DC で運用しており、 Secondary DC は Primary DC  の障害時のみ利用することを想定している場合、メールボックス データベースが意図せず Primary DC  から Secondary DC へフェールオーバーされることを防ぐため、Secondary DC にあるメールボックス サーバーの DatabaseCopyAutoActivationPolicy パラメータを Blocked に設定して運用することがあります。この設定はパッチ適用などメンテナンス中にも良く使われています。当該設定をすることで、Primary DC から Secondary DC へデータベースが自動でフェールオーバーされることを防ぐことができます。しかし、DatabaseCopyAutoActivationPolicy パラメータを Blocked に設定したまま、Secondary DC にてメールボックス データベースをアクティブ化した場合、Primary DC…


Exchange Online のインプレース電子情報開示にて、SearchQuery に Body を指定して検索を行うと添付ファイルも出力される

こんにちは。 Exchange サポートの山崎です。      インプレース電子情報開示と保持を利用してメールボックス内のアイテムを検索する際に、特定の条件でメッセージの検索を実施するかと思います。検索にはキーワード クエリ言語 (KQL) が使用され、例えば、件名に “northwind” という文言を含む場合は「Subject:northwind」、本文に “Northwind Traders” を含む場合は「body:”Northwind Traders”」と指定します。 また、body や subject 以外にも cc や to なども指定可能であり、New-MailboxSearch や Set-MailboxSearch コマンドの  SearchQuery パラメーターで指定できるプロパティは、以下の TechNet にてご案内しております。 TITLE: インプレース電子情報開示のためのメッセージ プロパティと検索演算子URL: https://technet.microsoft.com/ja-jp/library/dn774955(v=exchg.150).aspx(Exchange の検索可能なプロパティ) なお、body を指定した際の動作として上記のページでは「[電子メール メッセージの本文内のテキスト] に指定したキーワードを含むアイテムを検索するプロパティ」と記載されています。しかしながら、 Exchange Online の動作といたしましては、body を指定した場合は 「本文」 以外にも 「件名」、「添付ファイルのファイル名」、「添付ファイル内にキーワードを含む」も検索対象となります。 例えば、以下のコマンドはUserA のメールボックス内において本文に “northwind” を含むメッセージを検索するように SearchQuery パラメーターを指定しています。 ——New-MailboxSearch -Name Northwind -SearchQuery “body:’northwind”…


Exchange Online のリモート PowerShell におけるエラー ハンドリング

こんにちは。Exchange サポート チームの小間です。今回は Exchange Online に接続する PowerShell でエラー ハンドリングを行う方法をご紹介します。 Exchange Online の管理を PowerShell スクリプトとして記述して実行している管理者の方は多いと思いますが、その時に必要となるのがエラー ハンドリングです。例えば Get-Mailbox コマンドの引数に存在しないユーザー名を指定して実行してしまった時、コマンドの実行はエラーになりますのでエラー時は別の処理を行いたいという要件があると思います。その場合は以下のように try-catch 構文を使用するのが一般的ですが、Exchange Online のリモート PowerShell では意図した通りに catch ブロックに処理が移りません。Get-Mailbox コマンドに ErrorAction パラメーターで Stop を指定しても動作が変わりません。(参考として Exchange Server 2010 以降に接続するリモート PowerShell では Get-Mailbox コマンドに ErrorAction パラメーターで Stop を指定することで、この方法でも意図した通りに動作します。) # sample01.ps1 param([Parameter(Mandatory=$true,ValueFromPipeline=$true)]$UserName) try{    Get-Mailbox $UserName    Write-Host “成功”}catch{    Write-Warning “失敗”} なお上記のスクリプトでは省略していますが、Exchange Online に…


メッセージ追跡ログを CSV ファイルに出力する方法

こんにちは。Exchange サポート チームの小間です。今回はメッセージ追跡ログを CSV ファイルに出力する方法をご紹介します。 Exchange 2007 以降、Exchange 管理シェルの Get-MessageTrackingLog コマンドでメッセージ追跡ログを検索して表示することが出来ます。また、PowerShell には Export-Csv コマンドが用意されており、CSV ファイルへのデータの出力も可能です。 これらを組み合わせることで検索したメッセージ追跡ログを CSV ファイルに保存することが出来ます。例えば以下のようにコマンドを実行して、変数に保存したメッセージ追跡ログの内容を CSV ファイルに保存したとします。   $Logs = Get-MessageTrackingLog -MessageSubject “Test Mail”  $Logs | Export-Csv C:\Logs.csv -Encoding Default -NoTypeInformation ところが保存した CSV ファイルを開くと、以下のように正しく情報を読むことが出来なくなっています。以下の例では、P 列の Recipients などが「System.String[]」となってしまっています。   これは PowerShell (Exchange 管理シェル) の内部で Recipients のデータ型が配列になっており、配列の内容をそのままでは Export-Csv コマンドで出力することが出来ないためです。配列の内容を CSV にエクスポートするには、Select コマンドを併用します。例えば Recipients の内容をすべて出力するには以下のようにコマンドを実行します。…


膨大な数の Office 365 ユーザーへの PowerShell コマンドレットの実行

(この記事は 2015 年 11 月 2 日に Exchange Team Blog に投稿された記事 Running PowerShell cmdlets for large numbers of users in Office 365 の翻訳です。最新情報については、翻訳元の記事をご参照ください。)   PowerShell は Exchange 2007 の時代に登場したスクリプト言語であり、多くの Exchange 管理者に恩恵をもたらしています。PowerShell のおかげで、管理者は大量のオブジェクトをすばやくシームレスに管理できるようになりました。以来、PowerShell は、管理者がユーザー、グループ、その他のオブジェクト セットを更新する際に欠かせないものとなりました。 ただし、Office 365 の提供が開始されてからは、少し状況が変わりました。もはやローカルの Exchange サーバーに対してコマンドレットを実行するのではなく、インターネット経由で共有のリソースに対して通信を行うことが必要になりました。そのため、以前には存在しなかった大量のオブジェクトを管理する必要が生じ、さまざまな課題が発生するようになりました。 PowerShell のスロットル Office 365 には多くのスロットルが導入されており、1 つのテナントまたは 1 ユーザーがリソースを過剰に使用して多くのユーザーに悪影響を与えることがないようになっています。PowerShell では、主に、Micro Delay として表示されます。 WARNING: Micro delay applied. Actual delayed:…