Exchangeメールボックスを無効にすると、どのような影響がありますか？
Exchange Server 2007以降を使用している場合、メールボックスを無効にすることはかなり一般的な操作です。ただし、Technetのドキュメントには、メールボックスを無効にすることによる副作用についての詳細はありません。これが言うすべてです。
「このタスクは、Active DirectoryのユーザーオブジェクトからすべてのExchange属性を削除します。削除済みアイテムの保持ポリシーに基づいて、Exchangeストアはユーザーオブジェクトのメールボックスデータを保持します。」
ソース： http://technet.Microsoft.com/en-us/library/bb123730（v = exchg.141）.aspx
しかし、それだけですか？現実世界のExchangeメールボックスは、高度に相互接続されている傾向があります。おそらく、上司が秘書にカレンダーの管理を委任したのでしょう。多分スタッフメンバーのチームはすべてパブリックフォルダーへのアクセスを共有しています。おそらく、パワーユーザーには、いくつかの異なるアドレスで電子メールを受信する機能が付与されています。 2つの明確な質問が思い浮かびます。
- メールボックスが切断された後、メールボックス間のリンクはどうなりますか？
Disable-Mailbox操作は簡単に元に戻せますか？
Microsoftのドキュメントによると、メールボックスを無効にすることは簡単な操作であるとのことです。残念ながら、いくつかの「落とし穴」があります。
メールボックスの保持
メールボックスが無効になると、「切断されたメールボックス」として再分類されます。既定では、Exchangeは切断されたメールボックスを30日間保持します。これは、メールボックスが存在するデータベースの属性です。ただし、Exchange管理者がこの値を変更することは可能です。 MailboxRetentionの値が0に設定されている場合、メールボックスは即座に削除されます。 （エラー） （technet.comで削除されたメールボックスの保持）
編集：初期化されていないメールボックスを切断すると、すぐに回復不可能な削除も行われます。初期化されていないメールボックスは、OWAまたはOutlookを介してアクセスされたことがないメールボックスです。一部のメールボックスは再接続できない可能性があるため、これにより、メールボックスを切断して再接続するスクリプトを作成するときに問題が発生することがあります。
メールボックスの再接続
メールボックスを無効にして接続することは、すぐにできるわけではありません。メールボックスを無効にするだけの場合は問題ありませんが、すぐにメールボックスを再接続する場合は、2つの点に注意する必要があります。
- 「切断されたメールボックス」のリストは、メールボックスデータベースが消去されるまで読み込まれません。無効にしたメールボックスが見つからないためにパニックに陥っている場合は、データベースのクリーニングを開始して数分待つようにExchangeに指示します。
- PowerShellスクリプトを記述している場合は、変更がActive Directoryに伝達されるのを待ってから、さらに操作を実行する必要があります。あなたの環境とあなたの運次第で、これは数秒から数分の範囲です。 （ヒント：ループで
Get-Userを呼び出して、変更が完全に伝達されたかどうかを確認できます。）
メールボックスのメタデータ
メールボックスが切断されると、クォータ情報は破棄されます。メールボックスクォータを保持する場合は、メールボックスを無効にするコマンドを発行する前にそれらの値を記録する必要があります。
同じことがEmailAddressesのリストとメールボックスのエイリアスにも当てはまります。
委任と権限
今、物事は不親しみ始めます。特定のユーザーについて、通常のExchangeメールボックスまたはレガシースタイルのパブリックフォルダーとのいくつかの可能なリンクがあります。
- 通常のメールボックス
- 送信者の権利
- 代理送信
- メールボックスサブフォルダーのACL
- 完全なアクセス権
- パブリックフォルダー
- 送信者の権利
- 代理送信
- フォルダーのアクセス許可
メールボックス->送信者
Send-As権限は、Active DirectoryユーザーオブジェクトのACLによって表され、ACLはSID値のリストとして内部的に保存されます。したがって、このアクセス許可はExchangeの外部で完全に管理できます。
メールボックスがdisabledの場合、送信者権限には影響しません。ユーザーオブジェクトのACLは変更されていないため、情報が失われることはありません。
切断されたメールボックスが同じユーザーに対してreconnectedである場合、以前そのユーザーとして送信できたすべてのユーザーがその機能を取り戻します。
切断されたメールボックスが別のユーザーに接続されている場合、ユーザーは新しいユーザーとして送信できません。新しいユーザーに必要な「送信者」権限を再適用する必要があります。
メールボックス->代理送信
Send on behalf権利は、Outlookクライアントによって提示される「委任」の概念と密接に関連しています。特にカレンダーの管理を委任する場合は、send on behalfを別のユーザーに付与するのが一般的です。 Exchangeがこれを内部的にどのように格納するかは明確ではありませんが、Send on behalf権限はユーザーではなくメールボックスオブジェクトに接続することを知っています。
メールボックスがdisabledの場合、「代理送信」接続はすべて破棄されます。これは、無効になっているメールボックスだけでなく、別のメールボックスがこのメールボックスに代わって送信を許可している場合にも影響し、そのリンクはすぐに削除されます。
言うまでもなく、メールボックスがreconnectedである場合、「代理送信」権限は復元されません。メールボックスが無効になると、その情報はすぐに永久に失われます。私はこれらのリンクを「揮発性」と呼んでいます。このボラティリティは、代理送信権がSIDとともに内部的に保存されない唯一の特権であるという事実から生じています。
ボーナスヒント：Exchangeは、ADユーザーオブジェクトにpublicDelegatesとpublicDelegatesBLの2つの属性を入力します。それぞれ。
メールボックス->サブフォルダーのACL
メールボックスフォルダーのアクセス許可は、メールボックス間で最も一般的に使用されるリンクの1つです。 Outlookの "委任"の後半として、フォルダのアクセス許可は重要ですが、多くの場合、それらは手動で割り当てられ、関連付けられた代理送信権限はありません。
Exchangeは、ユーザーのSIDに基づく一般的なACLでフォルダーのアクセス許可を表しますが、通常のACLのように操作することはできません。 Outlookでは、メールが有効なユーザーのみを選択できます。同様に、PowerShell Add-MailboxFolderPermissionコマンドレットを使用すると、メールボックスが関連付けられている別のユーザーのアクセス許可のみを追加できます。
ユーザーの代理人にフォルダーのアクセス許可（たとえば、レビュー担当者、編集者）が付与されており、その代理人のメールボックスが後でdisabledの場合、アクセス許可は "NT User：DOM\samname"のように表示されます。
代理人のメールボックスがreconnectedが同じユーザーに対している場合、外観が正しくないにもかかわらず、アクセス許可を利用できるようです。
ただし、代理人のメールボックスが別のユーザーに接続されている場合、一致するSIDがないため、新しいユーザーは元の委任を継承しません。フォルダーのアクセス許可はメールボックスに付与されているように見えますが、実際にはADセキュリティプリンシパルに付与されています。
メールボックス->フルアクセス
完全なアクセス許可は、Exchange管理者のみが割り当てることができます。 Send-Asアクセス許可と同様に、それらはADユーザーオブジェクトに付与され、SIDに基づいて内部的に保存されます。ただし、送信者アクセス許可とは異なり、完全なアクセス許可は実際にはExchangeメールボックスオブジェクトの一部として格納されていることがわかります。
メールボックスがdisconnectedの場合、フルアクセスを持つユーザーのリストはメールボックスオブジェクトに保持されます。
切断されたメールボックスがreconnectedの場合、接続しているユーザーに関係なく、以前にフルアクセスを持っていたユーザーは、そのメールボックスに対してフルアクセス権限を行使する機能を再び取得します。
ボーナスヒント： AutoMapping と呼ばれるフルアクセス許可のオプション機能があります。 AutoMappingが有効な状態でフルアクセスが許可されている場合、ExchangeはFullAccessアクセス許可を受け取っているユーザーのmsExchDelegateListBL属性を設定します。これにより、FullAccessの対象を簡単に確認できますが、常に有効であるとは限らないため、完全な回答を得るためにこれに依存することはできません。
パブリックフォルダー->送信者
パブリックフォルダーのSend-As権限は、通常のメールボックスの場合とほとんど同じように機能します。 「しかし、パブリックフォルダーはユーザーオブジェクトに関連付けられていません！」あなたは叫ぶ。実際、Exchangeは、作成したパブリックフォルダごとにActive Directoryにシークレットオブジェクトを作成します。
（ADSI Editを使用して、Exchangeサーバーがインストールされているフォレストのルートドメインの既定の名前付けコンテキストを開き、 "CN = Microsoft Exchange System Objects"を検索できます。このコンテナーには、各パブリックフォルダーのオブジェクトがあります、各オブジェクトにはSend-As権限を含むACLがあります。）
パブリックフォルダー->代理送信
Outlookからの「委任」の概念はパブリックフォルダーにはまったく適用されないため、パブリックフォルダーを「代理送信」するという考えは少し奇妙です。しかし、それはそれでもあります。
パブリックフォルダに対する代理送信アクセス許可の差別化要因は、代理送信権限が付与されているユーザーオブジェクトの "publicDelegatesBL"属性を設定しないことです。
現時点では、代理送信権もパブリックフォルダで不安定であるかどうかは不明です。誰かがこれを知っている場合は、この回答を自由に編集してください！ （TODO/FIXME）
パブリックフォルダー->権限
パブリックフォルダーのアクセス許可は、メールボックスのアクセス許可とは異なります。それらはメールボックスにリンクされているため、揮発性です。
メールボックスがdisconnectedの場合、そのメールボックスは、付与されていたパブリックフォルダーのアクセス許可をすべて失います。 （TODO/FIXMEまたはNT USER形式に従っていますか？）
「シームレスな移行」
2つの異なるドメインにADユーザーアカウントを持つ人物がいて、あるドメインのユーザーから別のドメインのユーザーにメールボックスを移動する場合は、困難な戦いになります。
残念ながら、Exchangeでは、アクセス許可と委任がどのように適用されたかを簡単に追跡することはできません。メールボックスを1つのADユーザーから同じフォレスト内の別のユーザーに移動する必要があり、アクセス許可を完全に保持したい場合は、それらのアクセス許可を自分で検出して復元する必要があります。
これは中規模のフォレストでも非常にコストのかかる操作になるため、メールボックスを頻繁に移動する場合は、すべてのメールボックスに対して1つの大きな列挙を行って、現在のすべてのリンケージのリストを収集することをお勧めします。次に、メールボックスを別のADユーザーアカウントに割り当てる場合、アクセス許可を更新する必要がある他のメールボックスを正確に把握します。
結論
- これらの権限は永続的です。メールボックスが無効になった後もそのまま残ります。
- 送信者
- メールボックスフォルダのACL
- 全権アクセス
- パブリックフォルダーの送信者
- これらの権限は揮発性です。メールボックスが無効になると、それらは失われます。
- 代理送信
- パブリックフォルダの送信
- パブリックフォルダーのアクセス許可
- メールボックスを切断すると、多数の副作用があります。
- 割り当ての喪失設定
- 接続されたメールアドレスの喪失
- メールボックスを無効または接続するスクリプトを作成するときは、AD伝播による遅延に注意してください。