Exchange ブログ JAPAN https://docs.microsoft.com/archive/blogs/exchangeteamjp/feed.xml Exchange Server、Exchange Online について、Exchange Server サポート チームより関連情報をお届けいたします。 Tue, 11 Jun 2019 04:02:56 GMT ja hourly 1 Exchange 2013 のメールボックス サーバー上で自己署名証明書の有効期限が切れた際の注意点 https://docs.microsoft.com/archive/blogs/exchangeteamjp/notice-about-the-expiration-for-a-self-signed-certificate-on-the-mailbox-servers-in-exchange-2013 Wed, 17 Oct 2018 15:09:50 GMT https://blogs.technet.microsoft.com/exchangeteamjp/?p=10335 現象 メールボックスの役割がインストールされた Exchange 2013上で実施されている 2 つのプローブ (OutlookRpcSelfTestProve と OutlookRpcDeepTestProbe) が自己署名証明書の有効期限が切れた後からエラーで失敗するようになります。 具体的にはメールボックスの役割がインストールされた Exchange 2013 上で IIS の Web サイト (Exchange Back End) にバインドされている自己署名証明書の有効期限が切れた以降から 2 つのプローブが失敗するようになり、その結果として可能性管理の機能により該当サーバー上で以下の事象が発生してしまいます。 ・アプリケーション プール MSExchangeRpcProxyAppPool のリサイクル ・Microsoft Exchange RPC Client Access サービスの再起動 なお、Exchange 2013 CU2-v2 など初期のバージョンでは上記以外にデータベースのフェールオーバーが実施される場合もございます。 ただし、Exchange 2013 CU3 以降では OutlookRpcSelfTestProve や OutlookRpcDeepTestProbe のプローブが失敗してもデータベースのフェールオーバーは実施されなくなっています。 - 補足 本不具合が発生している場合、ProbeResult に関するイベント ログにはそれぞれ以下の例外内容でエラーが記録されます。 << OutlookRpcSelfTestProve のエラー >> [詳細] タブの ExecutionContext 項目には以下の例外が記録 ・Exception = System.Net.WebException: 基礎になる接続が閉じられました: SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした ---&gt; System.Security.Authentication.AuthenticationException: 検証プロシージャによると、リモート証明書は無効です。 << OutlookRpcDeepTestProbe のエラー >> [詳細] タブの ExecutionContext 項目には以下の例外が記録 ・Exception = Microsoft.Exchange.Rpc.ServerUnavailableException: Error 0x6ba (RPC サーバーを利用できません。) from ClientAsyncCallState.CheckCompletion: RpcAsyncCompleteCall  

原因

Exchange 2013 のメールボックス サーバーにインストールされる自己署名証明書は組織内の Exchange Server から自動的に信頼されるように設計されています。 ただし、Exchange 2013 のメールボックス サーバー上で実施される 2 つのプローブ (OutlookRpcSelfTestProbe および OutlookRpcDeepTestProbe) に関しては自己署名証明書を自動的に信頼できない不具合があり、この不具合により自己署名証明書の有効期限が切れたタイミングで該当のプローブが失敗するようになります。 なお、Exchange 2013 のインストール時に作成される自己署名証明書は [コンピュータ アカウント] の [信頼されたルート証明機関] に登録されていますが、自己署名証明書を更新しただけでは [コンピュータ アカウント] の [信頼されたルート証明機関] には自動的には登録されません。 そのため、Exchange 2013 のメールボックス サーバー上で自己署名証明書を更新して IIS の Web サイト (Exchange Back End) にバインドする作業を実施しても、[コンピュータ アカウント] の [信頼されたルート証明機関] に登録していない場合にも該当のプローブが失敗する現象が発生いたします。  

対処方法

証明書の更新作業は一般的にはクライアントからの要求を受け付けるクライアント アクセス サーバーでのみ必要となります。 ただし、本不具合を回避するためにも、Exchange 2013 をご利用のお客様は後述の手順を参考にメールボックス サーバー上の自己署名証明書を更新してくださいますようお願いいたします。 なお、クライアント アクセスの役割とメールボックスの役割を共存させているサーバー上でも本作業を明示的に実施いただく必要がございますのでご注意ください。 - 作業概要 [0] IIS の Web サイト (Exchange Back End) にバインドされている自己署名証明書の確認 [1] 自己署名証明書を新規に発行 [2] 新規に発行した自己署名証明書を [コンピュータ アカウント] の [信頼されたルート証明機関] に登録 [3] 新規に発行した自己署名証明書を IIS の Web サイト (Exchange Back End) にバインド [4] (必要に応じて) 他のサービスに割り当てている自己署名証明書を変更   IIS の Web サイト (Exchange Back End) にバインドされている自己署名証明書の確認 以下の手順は更新対象のメールボックス サーバー上で実施してください。 1. インターネット インフォメーション サービス (IIS) マネージャーを起動します。 2. [<サーバー名>] - [サイト] - [Exchange Back End] を右クリックして [バインドの編集] をクリックします。 3. "種類" が https で "ポート" が 444 のエントリを選択した状態で [編集] をクリックします。 4. [SSL 証明書] に設定されている証明書を確認します。(必要に応じて [表示] をクリックして証明書の詳細についても確認してください)   自己署名証明書を新規に発行 Exchange 管理シェルから以下のコマンドを実行して自己署名証明書を新規に発行します。

Get-ExchangeCertificate -Server "<MBX サーバー名>" -Thumbprint "<更新対象の自己署名証明書の拇印>" | New-ExchangeCertificate -Service None

なお、更新対象の自己署名証明書の拇印 (Thumbprint) に関しては以下のコマンドを実行することでも確認することができます。

Get-ExchangeCertificate -Server "<MBX サーバー名>" | fl

  新規に発行した自己署名証明書を [コンピュータ アカウント] の [信頼されたルート証明機関] に登録 以下の手順は更新対象のメールボックス サーバー上で実施してください。 1. Microsoft 管理コンソールを起動します。([ファイル名を指定して実行] で "mmc" と入力して [OK] をクリックしてください) 2. [ファイル] メニューから [スナップインの追加と削除] を選択します。 3. [証明書] (コンピュータ アカウント) を追加して [OK] をクリックします。 4. 左ペインから [証明書] - [個人] - [証明書] を選択します。 5. 新規に発行した自己署名証明書を右クリックして [コピー] を選択します。 6. 左ペインから [証明書] - [信頼されたルート証明機関] - [証明書] を選択します。 7. 中央ペインの空白部分を右クリックして [貼り付け] を選択して該当の自己署名証明書をコピーします。 * [コンピュータ アカウント] の [信頼されたルート証明機関] に登録後は Get-ExchangeCertificate で該当の自己署名証明書を確認すると RootCAType パラメータは "Registry" と表示されます。   新規に発行した自己署名証明書を IIS の Web サイト (Exchange Back End) にバインド 以下の手順は更新対象のメールボックス サーバー上で実施してください。 1. インターネット インフォメーション サービス (IIS) マネージャーを起動します。 2. [<サーバー名>] - [サイト] - [Exchange Back End] を右クリックして [バインドの編集] をクリックします。 3. "種類" が https で "ポート" が 444 のエントリを選択した状態で [編集] をクリックします。 4. [SSL 証明書] に新規に発行した自己署名証明書を設定して [OK] をクリックします。   (必要に応じて) 他のサービスに割り当てている自己署名証明書を変更 メールボックスの役割のみをインストールしているサーバーなどでは以下の箇所も自己署名証明書のまま利用されている場合もあるかと存じます。 ・IIS の Web サイト (Default Web Site) にバインドしている証明書 ・Transport サービスの内部トランスポート証明書 上記に割り当てている自己署名証明書の有効期限が切れても特に問題はございませんが、これらの証明書も新規に発行した自己署名証明書に変更したい場合は Exchange 管理シェルから以下のコマンドを実行してください。

Enable-ExchangeCertificate "<MBX サーバー名>" -Thumbprint "<新規に発行した自己署名証明書の拇印>" -Service IIS,SMTP

]]> XPS ファイル内が検索できず、XPS ファイルに関する重大イベントがイベント ログに出力される件について https://docs.microsoft.com/archive/blogs/exchangeteamjp/failed-to-load-the-format-handler-used-to-parse-documents-of-the-xps-format Wed, 10 Oct 2018 14:10:58 GMT https://blogs.technet.microsoft.com/exchangeteamjp/?p=10315 現象 オンプレミスの Exchange Server のメールボックス内 ( "受信トレイ" 、"送信済みアイテム" の他に、"下書き" や "削除済みアイテム" 等も含みます) に、XPS ファイルが添付されたメールアイテムが存在する場合に、Outlook や Ootw などのメール クライアントから XPS ファイル内の文字列を検索しても該当のメール アイテムがヒットしないという現象が発生します。 また、以下のようなエラー イベントがイベント ログに記録されます。 ====================================================================== ログの名前 : Microsoft-Office Server-Search/Operational ソース : Microsoft-Office Server-Search 日付 : 2018/10/05 8:20:48 イベント ID : 64 タスクのカテゴリ: Document Parsing レベル : 重大 コンピューター : E2013.contoso.com 説明: Search Component: ContentEngineNode1-Fsis - Failed to load the format handler used to parse documents of the xps format. Error parsing document exchange://localhost/Attachment/3e908c15-90d1-4e8c-8ecd-5e25a2a97259/00822440-3336-4bd7-87dc-2fc2bb103738/e9302730-583d-45d9-bd1c-e300adf22fbb/98222f89-aa96-47ea-aaae-17a1189685c0/468151437433.0/aaaa.xps. Filter loading error. No filter installed for extension '.xps'. ======================================================================

発生環境

この現象は以下の条件に当てはまる環境を利用している場合に発生します。 ・メールボックス サーバーとして Exchange Server 2013、もしくは Exchange Server 2016 を利用している。 ・上記のメールボックス サーバーに後述の "XPS ビューアー" を導入していない。

原因

この現象が発生する原因は、XPS ファイルに対応する OS コンポーネントが足りていないこととなります。 メール アイテムがメールボックスに格納される際には通常、Exchange Search によるインデックス処理がメールボックス サーバー上で行われます。 インデックス処理は添付ファイルに対しても行われ、Exchange Server にインストールされている検索フィルターの有効/無効の設定と、iFilter と呼ばれる OS コンポーネントに従ってインデックス処理を行う添付ファイルを決定します。 以下の弊社公開情報にも記載されている通り、XPS ファイルの検索フィルターは既定で有効となっていますが、XPS ファイルの iFilter は既定では OS にインストールされていません。 これが本現象の発生する根本原因となります。 Title : Exchange Search によってインデックス処理されるファイル形式 URL : https://technet.microsoft.com/ja-jp/library/ee633485(v=exchg.150).aspx

影響

[現象] の章にも記載しましたが、XPS ファイルに含まれるテキストを利用した検索がうまくいかないという事象が発生します。 ただし、レベルが “重大” のイベントとして記録されるものの、Exchangeのその他の動作 (クライアントからのアクセスやメールの送受信等)に影響を与えるイベントではありません。また、XPS ファイルの添付されたメール アイテム自体の検索はメール アイテムの件名や本文中の文字列等を検索することで正常に行えることが期待できますので、「XPS ファイルが添付メール アイテムすべてが検索できなくなる」といったユーザー影響が発生するわけではない点にご注意下さい。

対処方法

"XPS ビューアー" の機能を各メールボックス サーバー上で有効化することで、 XPS ファイルの iFilter が OS にインストールされ、本現象は改善されます。 お客様のご利用環境下でも同様の事象が見られた場合には、Exchange がインストールされたマシンの OS 上で以下の手順を実行し、XPS ビューワーをインストールすることで事象が回避されるかどうかを確認して下さい。 <機能有効化手順>
  1. サーバー マネージャーを起動します。
  2. 右上の "管理" から [役割と機能の追加] を選択します。
  3. "開始する前に" 画面で [次へ] を選択します。
  4. "インストールの種類の選択" 画面で [役割ベースまたは機能ベースのインストール] をチェックして、[次へ] を選択します。
  5. "対象サーバーの選択" にて追加する対象のメールボックス サーバーを選択して、[次へ] を選択します。
  6. ウインドウ左側の "機能" を選択して "機能の選択画面" にて [XPS ビューアー] をチェックして、[次へ] を選択します。
  7. "インストール オプションの確認" にて、[インストール] を選択します。
  8. インストールが開始されます。インストール終了後のシステムの再起動は不要です。
  9. インストール完了後に以下のサービスを再起動してください。 Microsoft Exchange Search Host Controller Microsoft Exchange Search

補足

Exchange Server にインストールされている検索フィルターが有効となっているかどうかは、Get-SearchDocumentFormat コマンドレットを Exhcnage 管理シェル上で実行することで確認することが可能です。こちらのコマンドレットの詳細につきましては、以下の弊社公開情報をご参照ください。 Title : Get-SearchDocumentFormat URL : https://docs.microsoft.com/en-us/powershell/module/exchange/mailbox-databases-and-servers/get-searchdocumentformat?view=exchange-ps お手数をおかけいたしますが、XPS ファイル内の検索をメールクライアント上で検索する必要がある場合や、上記のイベントの出力を抑制されたい場合は、上記の対処を検討いただけますと幸いです。 今後とも、弊社サポート ブログならびにサポートチームをよろしくお願いいたします。 ※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。]]> 管理スコープと配布グループの管理 https://docs.microsoft.com/archive/blogs/exchangeteamjp/management-scope-and-distribution-group-management Fri, 10 Aug 2018 18:46:04 GMT https://blogs.technet.microsoft.com/exchangeteamjp/?p=10295

Exchange の管理者の役割をユーザーに与えるときに、書き込み可能な範囲 (スコープ) を指定することが可能です。 この機能を利用して一部の管理者権限をユーザーに与える運用も多いのではないかと思いますが、今回は管理者の役割とユーザーの役割の両方が指定されている場合の動作を紹介します。 なお、本投稿は Exchange Online を前提としていますが、オンプレミスの Exchange Server 2016 でも同様です。

はじめに、ユーザー権限で配布グループの管理を行う役割は MyDistributionGroupMembership と MyDistributionGroups の 2 つがあります。 MyDistributionGroupMembership は自分のメンバーシップ (自分がどの配布グループに所属するかなど) を管理する役割です。 MyDistributionGroups は自分が所有者となっている配布グループを管理する役割です。 つまりこれらはスコープが制限されています。

次に管理者の役割としては Distribution Groups の役割があります。 この役割は配布グループ全般の管理を行うことができる管理者の役割です。 既定ではスコープの制限はありませんのですべての配布グループを管理することができますが、ユーザーに役割を割り当てる際にスコープを制限することができます。 スコープの使用方法についてはこちらの技術情報に詳しい情報があります。 なお、セキュリティ グループの管理を行う役割として別途 Security Group Creation and Membership もあります。

では MyDistributionGroups と、スコープの制限された Distribution Groups の両方を割り当てられたユーザーが配布グループの管理を行うとき、スコープはどうなるでしょうか。 答えは、一部の例外を除きどちらかのスコープに当てはまれば管理可能、となります。 つまり、対象の配布グループの所有者であれば Distribution Groups のスコープ外であっても管理可能であり、Distribution Groups のスコープ内であれば所有者ではない配布グループの管理も可能です。

ただし、管理対象の配布グループの所有者であっても、Distribution Groups のスコープ外であり、かつアドレス帳に非表示の配布グループについては、Add-DistributionGroupMember / Remove- DistributionGroupMember によるメンバーの管理ができません。 これは現時点で Exchange の実装上の制限となります。

対処策としては Update-DistributionGroupMember コマンドを代わりに使用する方法があります。 Update-DistributionGroupMember コマンドは、配布グループのメンバーを、パラメータに指定したメンバーに置き換えるコマンドです。 Exchange 管理センターで配布グループのメンバーを管理する際はバックグラウンドで Update-DistributionGroupMember コマンドを使用することで、先述の制限を回避しています。

ちなみに Distribution Groups のスコープとして、配布グループが持っていない属性を条件 (例えば Office 属性が Tokyo であることを条件にするなど) とした場合はどうなるでしょうか。 答えは、すべての配布グループがスコープ外となります。 このため、スコープの条件を検討する際には、実際に配布グループなど管理対象のオブジェクトが持っている属性を条件として使用する必要があります。

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります

小間 竜太郎 ]]> Azure AD と Exchange Online 間の同期に関するエラーの事例集 https://docs.microsoft.com/archive/blogs/exchangeteamjp/case-studies-of-synchronization-aad-exo Fri, 10 Aug 2018 17:32:24 GMT https://blogs.technet.microsoft.com/exchangeteamjp/?p=10235 先日公開したブログで、Azure AD と Exchange Online 間の同期の問題に関するトラブルシューティングの基本をご紹介させていただきました。 ただ、あまり事例の紹介ができていないので、今回はトラブルシューティングによって確認できたエラー内容毎に、いくつか詳細と対処方法をご紹介できればと思っています。  

事例を紹介するその前に、Exchange Online のメールボックスのおさらい

 先日のブログではオンプレミスのリモート メールボックスや Exchange Online のメールボックス等について説明しました。 今回の事例を紹介するにあたっては、他の種類のメールボックスもいくつか登場してくるので、改めて登場人物の整理からしていきます。  

アーカイブ メールボックス (インプレース アーカイブ)

 ※ここではいわゆる普通のメールボックスをプライマリ メールボックスと呼ぶことにします。 アーカイブ メールボックスはプライマリ メールボックスとは別にユーザーが利用できる追加のメールボックスです。 アーカイブ メールボックスが何なのか自体はここではあまり関係無いので詳細は割愛します。詳しくは以下の公開情報をご確認ください。     Title : Exchange Online のアーカイブ メールボックス   URL : https://technet.microsoft.com/ja-jp/library/dn922147(v=exchg.150).aspx   今回の話をするにあたって、アーカイブ メールボックスについて知っておいていただきたいのは、以下の 2 点です。     - オンプレミス側でアーカイブ メールボックスの有効/無効を管理する (※1)   - あくまで、プライマリ メールボックスに紐付いた追加のメールボックスであること   まず 1点目についてはそのままなのですが、Exchange Online でアーカイブ メールボックスを有効化したいときは、オンプレミスのリモート メールボックスに対して Enable-RemoteMailbox コマンドの Archive スイッチを使って有効化します。(逆に無効にするなら Disable-RemoteMailbox -Archive です) ※1 : 厳密にはハイブリッド環境であっても、オンプレミス側でメールユーザーとして作成して Exchange Online にメールボックスを作成している場合等、Exchange Online 側から Enable-Mailbox コマンドでアーカイブ メールボックスを有効化できる場合もあるのですが、ここではオンプレミス側がリモートメールボックスである前提とします。   2 点目については下の絵を見ていただいた方がもしかしたらわかりやすいのかもしれませんが、アーカイブ メールボックスも単に 1 人のユーザーに紐付いたメールボックスの 1 つであり、アーカイブ メールボックス用のユーザー (オブジェクト) ができるわけではありません。 Get-Mailbox や Get-RemoteMailbox で 1 人の情報を取得すれば、そこにはプライマリ メールボックスの情報 (ExchangeGuid) もアーカイブ メールボックスの情報 (ArchiveGuid) も含まれています  

非アクティブ メールボックスと Soft-Deleted Mailbox

 続いて、非アクティブ メールボックスと Soft-Deleted Mailbox (正しい日本語訳が見つからなかったのですが、オンプレミスで言うところの”切断されたメールボックス”や”削除済みメールボックス” などと呼ばれていたものと似たようなものです) についてです。 どちらも基本的には既に Azure AD 上のユーザーからは切り離されている (紐付いていない) 状態になっているメールボックスを指しており、違いと言えば 30 日で完全に削除されるか、それ以降も保持され続けるかの違いです。このあたりの違いについては以下の公開情報をご確認ください。     Title : Office 365 の非アクティブなメールボックスの概要   URL : https://support.office.com/ja-jp/article/overview-of-inactive-mailboxes-in-office-365-1fbd74e8-7a60-4157-afe8-fe79f05d2038   この 2 つのメールボックスについても今回に限って知っておいてもらいたいのは以下の 2 点だけです。     - Exchange Online にユーザー (オブジェクト) が残っている   - Azure AD 上のユーザーは既に削除されている (Azure AD 上のユーザーが同名で存在していても別のオブジェクトになっている)   よくあるシナリオとしては、対象のオンプレミスのユーザーを削除したり (あるいは AAD Connect の非同期の対象にする)、Azure AD 上のユーザーを直接削除すると作られます。 以下はオンプレミスのユーザーを AAD Connect の同期対象外として Azure AD のユーザーを削除 (削除済みユーザーとなる) したときと、完全削除 (削除済みユーザーからも削除) したときのイメージです。 削除済みユーザーの時点では Soft-Deleted Mailbox の ExternalDirectoryObject に Azure AD のユーザーの ObjectId が設定されていますが、Azure AD のユーザーが削除されると Soft-Deleted Mailbox からも削除されていることが確認できますね。 ※ Azure AD 上のユーザーが削除済みユーザーとして残っている場合、Exchange Online 上では Soft-Deleted Mailbox になっていますが、実はまだメールボックスと紐付いた状態になっています。 なので、削除済みユーザーを復元すれば (ディレクトリ同期の対象に戻せば)、ユーザーに紐付いているメールボックスに再接続して引き続き利用可能になります。  

Azure AD - Exchange Online 間の同期の問題でよくある事例

 それでは、Azure AD と Exchange Online 間の同期で発生する問題について、いくつかのパターンを紹介していこうと思います。   大抵の場合、目に見える事象としては、メールボックスが作成されない、設定変更したのに反映されない、メールボックスが削除されないのいずれかになりますが、その原因は様々です。 ここでは、先日のブログで紹介した Get-MsolUser コマンドを使って確認できるエラー毎にまとめていきます。  

1. 訴訟ホールド、インプレース保持、保持ポリシー(SCC) が有効な場合のエラー

 まずはエラーの内容から確認しましょう。 といっても、Get-MsolUser コマンドでのトラブルシューティング方法を紹介したときに使用したものと同じで、ここで取り上げるのは以下のエラーです。  
ErrorDescription : Exchange can't disable the mailbox "JPNPR01A004.PROD.OUTLOOK.COM/Microsoft Exchange Hosted Organizations/yowatana002.onmicrosoft.com/testuserA" because it is on In-Place Hold.
  基本的にはユーザーを削除した場合に非アクティブ メールボックスになるようなシナリオにおいて、ユーザーは削除せずにライセンスだけを剥奪したりすると発生します。 非アクティブ メールボックスになるシナリオはいくつかあるのですが、以下の 4 つのいずれかによる保持を有効にした状態でユーザーを削除すると作られます。 いずれもライセンスが必要な機能となるため、この状況下でライセンスだけを剥奪するとこのエラーが発生します。     - ExO のeDiscovery でインプレース保持を有効にする   - ExO で訴訟ホールドを有効にする   - SCC (セキュリティ/コンプライアンス センター) の eDiscovery でインプレース保持を適用する   - SCC のアイテム保持ポリシーを適用する   ※ ExO の訴訟ホールドが有効な場合だけは少し違うメッセージになります。  
ErrorDescription : Exchange can't disable the mailbox "JPNPR01A004.PROD.OUTLOOK.COM/Microsoft Exchange Hosted Organizations/yowatana002.onmicrosoft.com/testuserB" because it is on litigation hold.
  これらの保持が有効かどうかについては、基本的には Get-Mailbox コマンドで確認できます。 LitigationHoldEnabled が True なら訴訟ホールドが有効で、InPlaceHolds に何かの値が入っていれば他の 3 つのうちのどれかの設定で保持が有効になっています。  
  いずれの保持が有効であったとしても対処方法は以下の公開情報にあるとおりで、ライセンスを剥奪して削除するのではなく、同期元のオンプレミスのユーザーを AAD Connect の同期対象外にして Azure AD 上から削除し、Exchange Online 側で非アクティブ メールボックスに変換します。     Title : 非アクティブなメールボックスを作成する際の注意点   URL : https://answers.microsoft.com/ja-jp/msoffice/forum/msoffice_o365admin-mso_exchon-mso_o365b/非アクティ/e82edc4b-d65f-4089-be72-ddfc91a0240a   なお、Get-Mailbox の結果の LitigationHoldEnabled が False で InPlaceHolds が空の場合でも、同様のエラー メッセージが記録される場合も実はあります。 しかも2パターンあります。   1 つ目は、SCC のアイテム保持ポリシーを個別のメールボックスに対してではなく、組織レベルで適用している場合です。 組織レベルで適用されているかなどの詳細は以下のブログでご紹介しているので、もしいずれの保持も設定されていなそうなときはご確認ください。     Title : セキュリティ コンプライアンス センターで設定する保持ポリシーのメールボックスへの適用状況を確認する方法   URL : https://blogs.technet.microsoft.com/exchangeteamjp/2018/04/17/how-to-see-which-retention-policy-is-applied-to-your-mailbox/   2 つ目は、削除の直前までインプレース ホールドや訴訟ホールドが有効だった場合です。 このようなシナリオで削除を試みた場合は、Get-Mailbox の DelayHoldApplied の設定を確認してみてください。  
  この画像のように DelayHoldApplied が True となっている場合は、意図的にメールボックスの削除が 30 日遅延される動作になり、Exchange Online 的にはその間はインプレース ホールドが有効な状態と判断するため、同じエラーが出ます。 これは、直前まで保持が有効なメールボックスであったので、誤操作などで本来は必要であったデータを間違って削除してしまうことがないように、Exchange Online が意図的に値を True に設定して削除を遅延させています。 もちろん、対象のメールボックスに誤りがなければ遅延させる必要はないので、以下のコマンドで DelayHoldApplied を False に変更してメールボックスが削除されるか確認していただければと思います。   Set-Mailbox -Identity <対象のメールボックス> -RemoveDelayHoldApplied  

2. ExchagneGuid 関連のエラー

 続いてのエラーは、一度メールボックスを削除しようとしたものの、やはりメールボックスが必要だということになり、新しいメールボックスを作成しようとしたときに発生したものです。 実際はこのエラーにより新しいメールボックスは作成されていませんでした。  
ErrorDescription : The value "01855e55-d849-4631-b160-5c9c1ad491dc" of property "ExchangeGuid" is used by another recipient object. Please specify a unique value.
  エラーの内容通り、ExchangeGuid に設定されている値が、他の受信者オブジェクトと競合してしまっているために、エラーになっているようです。   下の絵を見ながら読んでもらえればと思うのですが、このユーザーは以前のメールボックスを削除する前からオンプレミスのリモート メールボックスに、Exchange Online のメールボックスと同じ ExchangeGuid が設定されていました。 オンプレミスのメールボックスを Exchange Online に移動すると自動的にこのような設定になりますね。 そしてメールボックスを削除するためにオンプレミスのリモート メールボックスを Azure AD の同期対象外として Azure AD 上のユーザーを削除したことで、Exchange Online のメールボックスは Soft-Deleted Mailbox になりましたが、引き続き ExchangeGuid は設定されたままになっています。   そして、今回メールボックスを再作成する必要がでてきたので、改めて AAD Connect によりオンプレミスのリモート メールボックスを Azure AD に同期し、新しい Azure AD 上のユーザーを作成しました。 ここでポイントになるのが、最初の Soft-Deleted Mailbox の説明に書いた、Azure AD のユーザーを削除しているため Soft-Deleted Mailbox の ExternalDirectoryObject は既に空になっている (どのユーザーとも紐付いていない) ということです。 つまり、新しく作成された Azure AD のユーザーと Soft-Deleted Mailbox は紐付いていない ≒ 別のオブジェクト であるため、別のオブジェクトと ExchangeGuid が競合していますよということでエラーになっています。 じゃあどうするのかというと、対処は簡単で以下の手順を実施するだけで、オンプレミスのリモート メールボックスの ExchangeGuid を削除すれば Exchange Online に新しいメールボックスが作成されます。     1. オンプレミスでリモート メールボックスの ExchangeGuid を削除して値の競合を回避 (Set-RemoteMailbox -ExchangeGuid 00000000-0000-0000-0000-000000000000)   2. AAD Connect によるディレクトリ同期を実行   3. 作成された新規ユーザーにライセンスを付与   4. 必要があれば (必須ではありません)、オンプレミスのリモート メールボックスに対して、Exchange Online のメールボックスに設定されている ExchangeGuid を付与 (Set-RemoteMailbox -ExchangeGuid xxx)   補足: 上に書いたとおりオンプレミスのリモート メールボックスの ExchangeGuid を空にすることが正しい手順ですが、「じゃあ競合しない ExchangeGuid なら設定しててもいいの？」と思った方向けに補足します。 これの答えは「NO」です。 なぜかと言うと、最初から ExchangeGuid が設定されているユーザーはオンプレミスにメールボックスが存在していた場合のみを想定しており、そのようなユーザーに関しては Exchange Online 上でライセンスを付与しても、メールボックスが作成されない (オンプレミスのメールボックスを移動する必要がある) からです。 ※ この場合は属性値の競合が発生しているわけではないので、Get-MsolUser 上は何もエラーは発生しません。メールボックスが作られない＋エラーもないときは、リモート メールボックスに ExchangeGuid が設定されていないか確認してみましょう。  

3. ArchiveGuid 関連のエラー

 3 つ目のエラーですが、大抵の場合 2 で紹介した ExchagneGuid のエラーに対処した後に出てくることが多いです。 理由は後ほど、、、ということで、ひとまずエラーの内容を見てみましょう。  
ErrorDescription : The value "ecbdbf6a-de22-4464-b5a6-332a5c2396e2" of property "ArchiveGuid" is used by another recipient object. Please specify a unique value.
  先ほどの ExchangeGuid のエラーと同じように、今度は ArchiveGuid で競合が発生しているようです。 最初に ExchangeGuid を対処した後に出てくることが多いと書きましたが、発生原因は ExchangeGuid と同じで、オンプレミスに設定されている値と同じ値を持つ他の受信者オブジェクトが存在していることが原因なので、ExchangeGuid だけ対処しても今度は ArchiveGuid の競合でひっかかってしまうからというのがその理由です。 1 回の対処で ExchangeGuid と ArchiveGuid の競合両方に対処した方が手間も少ないので、ExchangeGuid のエラーが出たら Archive が有効なメールボックスでないか (このエラーが発生しうる状態でないか) も確認しておきましょう。   次は対処についてなのですが、ExxchangeGuid と同じようにオンプレミスのリモート メールボックスに設定された ArchiveGuid を削除すればいいよねと思った方、少しお待ち下さい。 実はこれをやると今度は下のエラーが発生します。  
ErrorDescription : Cannot validate argument on parameter 'ArchiveGuid'. The argument is empty. Supply an argument that isn't empty, and try the command again.
  残念ながら、ArchiveGuid は ExchangeGuid とは違って値を未設定にして同期を行うことができません。 最初にアーカイブ メールボックスはオンプレミスで有効/無効を管理すると説明しましたが、オンプレミス側で有効化しているのにオンプレミスの ArchiveGuid が未設定というのはそもそもおかしいのでエラーになっているというわけです。   では、どうすればいいのかと言うと、実は ArchiveGuid の競合の場合は ExchangeGuid とは違って、オンプレミスのリモート メールボックスに設定されている ArchiveGuid を競合しないものに変えるだけで問題ありません。 そのため、以下の手順で対処できます。     1. オンプレミスでリモート メールボックスの ArchiveGuid を別の値に変更する (Set-RemoteMailbox -ArchiveGuid xxx)   2. AAD Connect によるディレクトリ同期を実行   補足: 新しい ArchiveGuid を付与するときは、自動的に GUID を作成してくれる NewGuid メソッドを以下のように使うと便利です。     Set-RemoteMailbox userA -ArchiveGUID ([guid]::NewGUID())     -- 参考   Title : Guid.NewGuid メソッド ()   URL : https://msdn.microsoft.com/ja-jp/library/system.guid.newguid(v=vs.110).aspx  

まとめ

 今回、いくつか Azure AD と Exchange Online の同期に関する内容を紹介しました。 すべてのエラーについて紹介するのはなかなか難しいですが、先日のブログで紹介した Error の確認方法と上で説明したような現在の状態・構成・動作さえ把握できていれば、対処方法などもイメージしやすいのではないかと思ってまとめたつもりではありますので、今後の運用に役立てていただけたら幸いです。   ※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。]]> 情報採取プラン（e. netsh トレース） https://docs.microsoft.com/archive/blogs/exchangeteamjp/%E6%83%85%E5%A0%B1%E6%8E%A1%E5%8F%96%E3%83%97%E3%83%A9%E3%83%B3%EF%BC%88e-netsh-%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%EF%BC%89 Mon, 06 Aug 2018 14:14:05 GMT https://blogs.technet.microsoft.com/exchangeteamjp/?p=9615 Office 365 サポートにお問い合わせいただく際に事前に確認いただく内容 の一部です。   1. コマンドプロンプトを管理者権限で起動します。 2. 以下のコマンドを実行し、DNS キャッシュを削除します。 ipconfig /flushdns   3. 以下のコマンドを実行し、ネットワーク トレースの採取を開始します。 ▼Windows 7 の場合 netsh trace start scenario=AddressAcquisition,InternetClient capture=yes tracefile=C:\temp\inet.etl   ▼Windows 8.1 以降の場合 netsh trace start scenario=AddressAcquisition,InternetClient_dbg capture=yes tracefile=C:\temp\inet.etl ※ファイルの出力先として C:\temp\ フォルダを指定していますが、お客様の環境に合わせて変更ください。   4. 事象が発生する操作を行います。 5. 以下のコマンドを実行し、ネットワーク トレースの採取を終了します。 netsh trace stop   6. 保存されたファイルを提供ください。   - 参考情報 ネットワーク トレースの Netsh コマンド https://msdn.microsoft.com/ja-jp/library/jj129382(v=ws.11).aspx]]> 情報採取プラン（d. Ootw トレース）- Firefox https://docs.microsoft.com/archive/blogs/exchangeteamjp/%E6%83%85%E5%A0%B1%E6%8E%A1%E5%8F%96%E3%83%97%E3%83%A9%E3%83%B3%EF%BC%88d-ootw-%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%EF%BC%89-firefox Mon, 06 Aug 2018 13:40:04 GMT https://blogs.technet.microsoft.com/exchangeteamjp/?p=9605 Office 365 サポートにお問い合わせいただく際に事前に確認いただく内容 の一部です。   -------------------------------------- 事前準備 -------------------------------------- 1. ブラウザーを起動して、F12 キーを押下して開発者ツールを起動します。 2. 開発者ツールの [コンソール] タブに移動します。 3. ゴミ箱のアイコンの右にある漏斗のアイコンをクリックします。 4. [エラー]、[警告] 、[ログ] 、[情報] 、[デバッグ] 、[CSS] 、[XHR] 、[要求] などの項目をすべて選択状態 (水色) にします。 5. [永続ログ] のチェックをオンにします。 6. 以下のようになっていることを確認します。   7. ゴミ箱アイコンをクリックしてログを削除します。 8. 開発者ツールの [ネットワーク] タブに移動します。 9. [すべて] が選択状態 (水色) になっていることを確認します。非選択状態 (グレー) になっている場合は [すべて] をクリックして選択状態 (水色) にしてください。 10. [永続ログ] と [キャッシュの無効化] のチェックをオンにします。 11. ゴミ箱アイコンの左のアイコンが、「||」のように一時停止を示すアイコンが表示されていることを確認します。横向き三角アイコンが表示されている場合はアイコンをクリックしてください。 12. 以下のようになっていることを確認します。   13. ゴミ箱アイコンをクリックしてログを削除します。   -------------------------------------- 事象再現 -------------------------------------- 1. https://outlook.office365.com/owa にアクセスし、Ootw にサインインします。 2. 受信トレイが表示されましたら、URL の末尾 "#path=/mail" や "?realm" などを削除し、"?traceLevel=4" と入力した後、[Enter] キーを押下します。 ※ 大文字、小文字が区別されますので、"?traceLevel=4" はそのままコピー & ペーストしてください。 URL 例 ： https://outlook.office365.com/owa/?traceLevel=4   3. 事象を再現します。   -------------------------------------- 情報採取 -------------------------------------- 1. 開発者ツールの [ネットワーク] タブを表示します。 2. 記録されたログの一覧上で右クリックし、[HAR 形式ですべて保存] を選択し、任意の場所にファイルを保存します。 3. 開発者ツールの [コンソール] タブに移動します。 4. ログが表示されている部分を右クリックし、[すべて選択] をクリックします。 5. 同様に右クリックし、[メッセージをコピー] をクリックします。 6. コピーした内容をメモ帳などに張り付け、テキスト ファイルとして保存します。 7. 保存されたファイルを提供ください。   - 参考情報 再現手順の取得と Office 365 サポートへ取得したファイルを送信する手順 https://answers.microsoft.com/wiki/e2fea319-2875-471c-9f68-48617361dd6f]]> 情報採取プラン（d. Ootw トレース）- Chrome https://docs.microsoft.com/archive/blogs/exchangeteamjp/%E6%83%85%E5%A0%B1%E6%8E%A1%E5%8F%96%E3%83%97%E3%83%A9%E3%83%B3%EF%BC%88d-ootw-%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%EF%BC%89-chrome Mon, 06 Aug 2018 13:37:25 GMT https://blogs.technet.microsoft.com/exchangeteamjp/?p=9595 情報採取プラン「d. Ootw トレース」の Chrome での手順をご案内いたします。 ※この手順は、F12 開発者ツールで HTTP トレースを採取する手順も含みます。 この記事は、Office 365 サポートにお問い合わせいただく際に事前に確認いただく内容 の一部です。   -------------------------------------- 事前準備 -------------------------------------- 1. ブラウザーを起動して、F12 キーを押下して開発者ツールを起動します。  2. 開発者ツールの [Console] タブに移動します。  3. [Group similar] の左の下向き三角ボタンをクリックし、以下のように [Errors]、[Warnings]、[Info]、[Verbose] が選択状態 (チェックがついている) になっていることを確認します。選択されていない場合はクリックして選択します。   4. [Group similar] の右の歯車アイコンをクリックします。  5. 以下のように各項目が選択されていることを確認します。   6. [Clear console] (以下の赤枠で囲まれているボタン) をクリックしてログを削除します。   7. 開発者ツールの [Network] タブに移動します。  8. [All] が選択されていることを確認します。選択されていない場合は [All] をクリックして選択された状態にしてください。  9. [Preserve log] と [Disable cache] のチェックをオンにします。    10. 一番左の丸アイコン (以下の赤枠で囲まれているボタン) が赤色で表示されていることを確認します。丸アイコンが黒色で表示されている場合はアイコンをクリックしてください。   11. 以下のようになっていることを確認します。   12. [Clear] (以下の赤枠で囲まれているボタン) をクリックしてログを削除します。   -------------------------------------- 事象再現 -------------------------------------- 1. https://outlook.office365.com/owa にアクセスし、Ootw にサインインします。 2. 受信トレイが表示されましたら、URL の末尾 "#path=/mail" や "?realm" などを削除し、"?traceLevel=4" と入力した後、[Enter] キーを押下します。 ※ 大文字、小文字が区別されますので、"?traceLevel=4" はそのままコピー & ペーストしてください。 URL 例 ： https://outlook.office365.com/owa/?traceLevel=4   3. 事象を再現します。   -------------------------------------- 情報採取 -------------------------------------- 1. 開発者ツールの [Network] タブを表示します。 2. ログが表示されている部分を右クリックし、[Save as HAR with content] をクリックして、任意の場所にファイルを保存します。 3. 開発者ツールの [コンソール] タブに移動します。 4. ログが表示されている部分を右クリックし、[Save as] をクリックして、任意の場所にファイルを保存します。 5. 保存されたファイルを提供ください。   - 参考情報 再現手順の取得と Office 365 サポートへ取得したファイルを送信する手順 https://answers.microsoft.com/wiki/e2fea319-2875-471c-9f68-48617361dd6f]]> 情報採取プラン（d. Ootw トレース）- Edge https://docs.microsoft.com/archive/blogs/exchangeteamjp/%E6%83%85%E5%A0%B1%E6%8E%A1%E5%8F%96%E3%83%97%E3%83%A9%E3%83%B3%EF%BC%88d-ootw-%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%EF%BC%89-edge Mon, 06 Aug 2018 13:30:14 GMT https://blogs.technet.microsoft.com/exchangeteamjp/?p=9585 情報採取プラン「d. Ootw トレース」の Edge での手順をご案内いたします。 ※この手順は、F12 開発者ツールで HTTP トレースを採取する手順も含みます。 この記事は、Office 365 サポートにお問い合わせいただく際に事前に確認いただく内容 の一部です。   -------------------------------------- 事前準備 -------------------------------------- 1. ブラウ/ザーを起動して、F12 キーを押下して開発者ツールを起動します。[コンテキスト メニューに [要素の検査] と [ソースの表示] が表示されるようになりました。] が表示される場合は [OK] をクリックしてください。  2. 開発者ツールの [コンソール] タブに移動します。  3. [すべて] が選択状態 (グレー) になっていることを確認します。選択されていない場合はクリックして選択します。  4. [ログを保持] のチェックをオンにします。  5. 以下のようになっていることを確認します。   6. ゴミ箱アイコンをクリックしてログを削除します。  7. 開発者ツールの [ネットワーク] タブに移動します。  8. [コンテンツの種類] をクリックして [すべて] のチェックがオンになっていることを確認します。オフになっている場合は [すべて] をクリックしてチェックをオンにしてください。  9. [キャッシュのクリア] と [ドメインのクッキーをクリアします] (それぞれ以下の赤枠で囲まれているボタン) をクリックして、キャッシュとクッキーを削除します。   10. [ナビゲーション時にエントリをクリア] (以下の赤枠で囲まれているボタン) をクリックして選択されていない状態にします。   11. 一番左の横向き三角アイコン (以下の赤枠で囲まれているボタン) がグレーで表示されていることを確認します。横向き三角アイコンが緑色で表示されている場合はアイコンをクリックしてください。   12. 以下のようになっていることを確認します。   13. [セッションのクリア] (以下の赤枠で囲まれているボタン) をクリックしてログを削除します。   -------------------------------------- 事象再現 -------------------------------------- 1. https://outlook.office365.com/owa にアクセスし、Ootw にサインインします。 2. 受信トレイが表示されましたら、URL の末尾 "#path=/mail" や "?realm" などを削除し、"?traceLevel=4" と入力した後、[Enter] キーを押下します。 ※ 大文字、小文字が区別されますので、"?traceLevel=4" はそのままコピー & ペーストしてください。 URL 例 ： https://outlook.office365.com/owa/?traceLevel=4   3.  事象を再現します。   -------------------------------------- 情報採取 -------------------------------------- 1. 開発者ツールの [ネットワーク] タブを表示します。  2. [HAR としてエクスポート] (以下の赤枠で囲まれているボタン) をクリックし、任意の場所にファイルを保存します。   3. 開発者ツールの [コンソール] タブに移動します。  4. ログが表示されている部分の一部を以下のように選択します。   5. [Ctrl] + [A] キーを押下して、すべてのログを選択します。  6. 選択したログ上で右クリックし、[コピー] をクリックします。  7. コピーした内容をメモ帳などに張り付け、テキスト ファイルとして保存します。  8. 保存されたファイルを提供ください。   - 参考情報 再現手順の取得と Office 365 サポートへ取得したファイルを送信する手順 https://answers.microsoft.com/wiki/e2fea319-2875-471c-9f68-48617361dd6f]]> 情報採取プラン（d. Ootw トレース）- Internet Explorer https://docs.microsoft.com/archive/blogs/exchangeteamjp/%E6%83%85%E5%A0%B1%E6%8E%A1%E5%8F%96%E3%83%97%E3%83%A9%E3%83%B3%EF%BC%88d-ootw-%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%EF%BC%89-internet-explorer Mon, 06 Aug 2018 12:17:37 GMT https://blogs.technet.microsoft.com/exchangeteamjp/?p=9575 情報採取プラン「d. Ootw トレース」の Internet Explorer での手順をご案内いたします。 ※この手順は、F12 開発者ツールで HTTP トレースを採取する手順も含みます。 この記事は、Office 365 サポートにお問い合わせいただく際に事前に確認いただく内容 の一部です。   -------------------------------------- 事前準備 -------------------------------------- 1. ブラウザーを起動して、F12 キーを押下して開発者ツールを起動します。  2. 開発者ツールの [コンソール] タブに移動します。  3. [エラー]、[警告] 、[メッセージ] が選択状態 (水色) になっていることを確認します。選択されていない場合はクリックして選択します。  4. [ナビゲーション時にクリア] をクリックして選択されていない状態にします。  5. 以下のようになっていることを確認します。   6. [クリア] (以下の赤枠で囲まれているボタン) をクリックしてログを削除します。   7. 開発者ツールの [ネットワーク] タブに移動します。  8. [コンテンツの種類] をクリックして [すべて] のチェックがオンになっていることを確認します。オフになっている場合は [すべて] をクリックしてチェックをオンにしてください。  9. [キャッシュのクリア] と [クッキーのクリア] (それぞれ以下の赤枠で囲まれているボタン) をクリックして、キャッシュとクッキーを削除します。   10. [ナビゲーション時にエントリをクリア] (以下の赤枠で囲まれているボタン) をクリックして選択されていない状態にします。   11. 一番左の横向き三角アイコン (以下の赤枠で囲まれているボタン) がグレーで表示されていることを確認します。横向き三角アイコンが緑色で表示されている場合はアイコンをクリックしてください。   12. 以下のようになっていることを確認します。   13. [セッションのクリア] (以下の赤枠で囲まれているボタン) をクリックしてログを削除します。   -------------------------------------- 事象再現 -------------------------------------- 1. https://outlook.office365.com/owa にアクセスし、Ootw にサインインします。 2. 受信トレイが表示されましたら、URL の末尾 "#path=/mail" や "?realm" などを削除し、"?traceLevel=4" と入力した後、[Enter] キーを押下します。 ※ 大文字、小文字が区別されますので、"?traceLevel=4" はそのままコピー & ペーストしてください。 URL 例 ： https://outlook.office365.com/owa/?traceLevel=4   3. 事象を再現します。   -------------------------------------- 情報採取 -------------------------------------- 1. 開発者ツールの [ネットワーク] タブを表示します。  2. [HAR としてエクスポート] (以下の赤枠で囲まれているボタン) をクリックし、任意の場所にファイルを保存します。   3. 開発者ツールの [コンソール] タブに移動します。  4. ログが表示されている部分を右クリックし、[すべてコピー] をクリックします。  5. コピーした内容をメモ帳などに張り付け、テキスト ファイルとして保存します。 6. 保存されたファイルを提供ください。   - 参考情報 再現手順の取得と Office 365 サポートへ取得したファイルを送信する手順 https://answers.microsoft.com/wiki/e2fea319-2875-471c-9f68-48617361dd6f]]> 情報採取プラン（d. Ootw トレース） https://docs.microsoft.com/archive/blogs/exchangeteamjp/%E6%83%85%E5%A0%B1%E6%8E%A1%E5%8F%96%E3%83%97%E3%83%A9%E3%83%B3%EF%BC%88d-ootw-%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%EF%BC%89 Mon, 06 Aug 2018 11:50:09 GMT https://blogs.technet.microsoft.com/exchangeteamjp/?p=9565 こんにちは。いつも Office 365 を利用いただきまして、ありがとうございます。 今回は、Office 365 に関する問題をトラブルシューティングする際に必要となる情報採取プランの中で 「d. Ootw トレース」の採取手順をご案内します。 この記事は、Office 365 サポートにお問い合わせいただく際に事前に確認いただく内容 の一部です。   Ootw トレースは、Outlook on the Web にて発生している事象の場合に採取していただく情報となります。

使用されているブラウザーごとに手順を記載しましたので、参照ください。

・Internet Explorer ・Edge ・Chrome ・Firefox

]]>