Exchange Server、Outlook に関する技術情報です。
Exchange Server で最低限確認したいカウンター
Exchange Server のパフォーマンスに関する問題をトラブルシューティングするときに利用できるパフォーマンス カウンターの一覧を示します。
パフォーマンスを向上させるために、ボトルネックを特定し、その原因の判断、および適切な修正操作を実施することが重要です。
CPU
\Processor(_Total)\% Processor Time
プロセッサの使用率を表すカウンターで、タスクマネージャーの「CPU 使用率」と同等です。
閾値は平均 75% 未満です。
一時的なスパイクの場合は問題ありません。
\System\Processor Queue Length
プロセッサーでの処理を待っているスレッドの数を表すカウンターです。
この値が常に 5 を超えるような場合、一般的にプロセッサがボトルネックと判断します。
マルチプロセッサのシステムでは、プロセッサごとに 5 を超えない必要があります。
(体感的には CPU 数が 4 コアの場合、8 以上の値が連続して記録されている場合はボトルネックになっている可能性があるように思いますが、文献によってもさまざまなので、結局のところ 0 にならない状況が持続するようなケースを NG とするのがよい気もします。)
\Process(<すべてのインスタンス>)\% Processor Time
タスクマネージャーで見ることができる各種プロセスの CPU 使用率を取得することができます。
マルチプロセッサ マシンでは、このカウンタの最大値は 100 パーセントにプロセッサ数をかけた数値です。
そのため、200% や 300% という数値になる場合があります。
100% 換算にする場合は CPU の数で割り平均化する必要があります。
CPU に大きな負荷を与えるプロセスは、このカウンタを使ってモニタできます。
メモリー
\Memory\Available MBytes
利用可能なメモリ領域をメガバイト (MB) で表したものです。
利用可能なメモリ領域を表すため、このサイズが大きければ、アプリケーションに大きくメモリを割り当てることができます。
閾値は RAM 合計の 5% を上回っている必要があります。ベースラインを取得しておく必要もあります。
ディスク
\LogicalDisk\Average Disk sec/Read
この値は、ディスクからデータを読み取る平均時間 (秒単位) を表示し常に平均 20 ミリ秒 (ms) 未満である必要があります。
スパイク (最大値) は 50 ミリ秒以下の値である必要があります。
\LogicalDisk\Average Disk sec/Write
この値は、ディスクにデータを書き込む平均時間 (秒単位) を表示し常に平均 20 ミリ秒未満である必要があります。
スパイク (最大値) は 50 ミリ秒以下の値である必要があります。
\LogicalDisk(*)\Avg. Disk Queue Length
ディスクの読み書きを待つリクエストの数です (待ち行列の長さ)。
この値が常に 2 以上だとディスク I/O 処理要求で常時待ち発生している状態ですのでディスク I/O がボトルネックである可能性が高いです。
ネットワーク
\Network Interface(*)\Bytes Total/Sec
NIC が1秒間に送受信したバイト数です。
\Network Interface(*)\Packets Outbound Errors
エラーのために送信できなかった送信パケットの数を示します。
常に 0 である必要があります。
Active Directory
\MSExchange ADAccess Domain Controllers(*)\LDAP Read Time
指定されたドメイン コントローラーに LDAP 読み取り要求を送信し、応答を受信するためにかかる時間をミリ秒単位 (ms) で示します。
閾値は平均 50 ミリ秒未満である必要があります。スパイク (最大値) は 100 ミリ秒以下の値である必要があります。
一時的なスパイクの場合は問題ありません。
\MSExchange ADAccess Domain Controllers(*)\LDAP Search Time
LDAP 検索要求を送信し、応答を受信するためにかかる時間 (ミリ秒) を示します。
閾値は平均 50 ミリ秒未満である必要があります。スパイク (最大値) は 100 ミリ秒以下の値である必要があります。
一時的なスパイクの場合は問題ありません。
キュー
\MSExchangeTransport Queues(_total)\Messages Queued For Delivery
キュー内のメッセージの数を示します。
メール流量
\MSExchangeTransport SmtpSend(_total)\Messages Sent Total SMTPSend
メールボックスサーバーから送信されたメッセージの総数です (Microsoft Exchange Transport サービスが開始されてからの総数。内外、内内の総数)。
\MSExchangeTransport SmtpReceive(_total)\Messages Received Total
メールボックスサーバーに送信されたメッセージの総数です (Microsoft Exchange Transport サービスが開始されてからの総数。外内、内内の総数)。
Exchange Server のメッセージ調整 (スロットリング) について
Exchange Server 2010 SP1 以降からメッセージ受信に関する以下の制限が導入されました。
メッセージ配信における メールボックス サーバーのリソース枯渇を予め防ぐための機能です。
- RecipientThreadLimit: 受信者あたりのメール配信のスレッド数の制限
- MaxMailboxDeliveryPerMdbConnections: データベースあたりのハブトランスポート サーバーからメールボックス サーバーへの配信の接続数 (スレッド数)
RecipientThreadLimit について
ユーザーごとのスロットリングが発生した場合は、以下ログを確認します。
パス: %ExchangeInstallPath%TransportRoles\Logs\Mailbox\Connectivity\Delivery
エラー表示例:
———
2018-02-05T07:22:55.416Z 08D49BBE2D75A203 MapiDelivery > Throttled delivery for recipient <ユーザー メールアドレス 1> due to concurrency limit 3
———
MaxMailboxDeliveryPerMdbConnections について
MDB 単位のスロットリングに抵触している場合は以下のログ出力先に記録されます。
以下パスの情報と後述のエラー表示例のようなログが記録されているかを確認することで、どの MDB でスロットリングが発生しているかを確認することが可能です。
閾値 (既定は 8) を超えた場合、負荷が下がるまでの一定期間メール配送は停止されます。
パス: %ExchangeInstallPath%TransportRoles\Logs\Hub\Connectivity
エラー表示例:
———
2018-02-05T00:36:30.995Z 08D49BBDDD162110 SMTP – Messages: 0 Bytes: 0 (Retry : STOREDRV.Deliver; dynamic mailbox database throttling limit exceeded.)
———
スレッド数が増加する一つの要因として、全体的な CPU 使用率が高騰するなど、サービスの処理速度低下やスループットの低下があげられます。
CPU 使用率等の高騰によりメールの処理速度が低下した状態と重なったタイミングで、メールの処理数が多くなった場合、MDB に対する接続数が高騰する (各スレッドの処理に時間を要す) 可能性があります。
メッセージ サイズの制限について
主に以下の種類の制限があります。
複数のサイズ制限がありますが、基本的に小さい方の値で制限されます。
- 組織における制限
- コネクタ制限
- サーバー制限
- 受信者の制限
サイズの制限 | Exchange 管理シェル (確認方法) |
受信するメッセージの最大サイズ (組織) | コマンドレット: Get-TransportConfig パラメーター: MaxReceiveSize |
送信するメッセージの最大サイズ (組織) | コマンドレット: Get-TransportConfig パラメーター: MaxSendSize |
メッセージあたりの最大受信者数 (組織) | コマンドレット: Get-TransportConfig パラメーター: MaxRecipientEnvelopeLimit |
受信コネクタ経由で送信されるメッセージの 最大サイズ (コネクタ) | コマンドレット: Get-ReceiveConnector パラメーター: MaxMessageSize |
送信コネクタ経由で送信されるメッセージの 最大サイズ (コネクタ) | コマンドレット: Get-SendConnector パラメーター: MaxMessageSize |
受信コネクタ経由で送信されるメッセージあたりの 最大受信者数 (コネクタ) ※ | コマンドレット: Get-ReceiveConnector パラメーター: MaxRecipientsPerMessage |
特定の受信者に送信できるメッセージの 最大サイズ (ユーザー) | コマンドレット: Get-Mailbox パラメーター: MaxReceiveSize |
特定の送信者が送信できるメッセージの 最大サイズ (ユーザー) | コマンドレット: Get-Mailbox パラメーター: MaxSendSize |
※ 既定の受信コネクターは 2 種類あります。
Client HUB サーバー名:この受信コネクタは、POP や IMAP などのすべての非 MAPI クライアントからの SMTP 接続を受け入れます。
通常は使用しません。
Default HUB サーバー名:この受信コネクタは、他のハブトランスポートサーバーおよびエッジトランスポートサーバーからの接続を受け入れます。
MaxRecipientsPerMessage のデフォルト値は 5000です。
Telnet で日本語のメールを送信する
以下手順により、Telnet で日本語のメールを送信する事が可能です。
- コマンドプロンプトを起動し、telnet コマンドで SMTP サーバーに接続します。
telnet “SMTP サーバーの FQDN” 25
helo
mail from:”差出人の SMTP アドレス” (envelope from)
rcpt to:”宛先の SMTP アドレス” (envelope to) - data コマンドでデータを送信することを指定します。data
- ヘッダ部を入力します。
from:”差出人の SMTP アドレス” (header from)
to:”宛先の SMTP アドレス” (header to)
Subject:=?ISO-2022-JP?B?GyRCRnxLXDhsJWEhPCVrJE43b0w+JEckOSEjGyhC?=
Mime-Version: 1.0
Content-Type: text/plain ; charset=”iso-2022-jp”
Content-Transfer-Encoding: base64 - 一行空けて、ボディ部 (本文) を入力します。
空行を作ることでヘッダとボディが分割されます。GyRCJDMkTiVhITwlayRPGyhCYmFzZTY0GyRCJEclKCVzJTMhPCVJJDUkbCRGQXc/ LiQ1JGwkXiQ3JD8hIxsoQg==
Subject
この例では以下の形式で日本語がエンコードされています。
charset: ISO-2022-JP
encoding: B (base64)
上記を以下の形式に当てはめたものがエンコードされた件名になります。
=?charset?encoding?encoded-text?=
この件名は日本語では「日本語メールの件名です。」となり、iso-2022-jp の「日本語メールの件名です。」を Base64 でエンコードすると「GyRCRnxLXDhsJWEhPCVrJE43b0w+JEckOSEjGyhC」という文字列になります。
日本語を Base64 エンコードする方法は複数ありますが、簡単な方法は以下です。
- コマンドプロンプトを起動します。
- 以下のコマンドを入力し、ファイルはテキストファイル形式を指定します。
certutil -f -encode “エンコード前ファイルパス” “エンコード後ファイルパス” - “エンコード後ファイルパス” に作成されたテキストファイルを開きます。
※ “エンコード前ファイルパス” のテキストファイルは ISO-2022-JP (JIS) 形式で保存されている必要があります。notepad は非対応なのでサクラエディタ等が必要です。
※ “エンコード後ファイルパス” はファイルが存在している必要はありません。
Mime-Version
MIME は SMTP で日本語を取り扱うための規格です。
MIME のバージョンを表示しています。
Content-Type
ボディ部 (メール本文) のファイルの種類を指定するヘッダです。
テキスト形式であるとか、HTML 形式である等の情報です。
日本語メールを送信する場合 text/plain になります。
text/plain の場合にはその文字コードを表す charset が追加されます。
この例では charset には「iso-2022-jp」が指定されています。一般的に文字化け等の問題が発生しずらいのは「iso-2022-jp」とされています。
Content-Transfer-Encoding
ボディ部 (メール本文) のエンコード形式が記述されている場所です。
この例では base 64 のルールに従って変換したという意味です。
以下の種類があります。
- 7 bit
- 8 bit
- binary
- base 64
- quoted-printable
上の 3 つは、それぞれ以下の意味になっており、データの種類を表します。
メール本文の変換は、特に行われていません。
7 bit : 7 bit のデータ
8 bit : 8 bit のデータ
binary : バイナリデータ
それに対して、下 2 つは変換方法を表します。
base 64 : base 64 のルールに従って変換
quoted-printable : quoted-printable のルールに従って変換
ボディ
正常にデコードされると以下のメールが配信されます。
上記メールのソース (ヘッダ、ボディ) は以下のようになります。Return-Path: “envelope from で指定した SMTP アドレス”
メールが経由した SMTP サーバーの情報
from: testuser@testdom.com
to: UserA@akbmacha.com
Subject: =?ISO-2022-JP?B?GyRCRnxLXDhsJWEhPCVrJE43b0w+JEckOSEjGyhC?=
Mime-Version: 1.0
Content-Type: text/plain ; charset=”iso-2022-jp”
Content-Transfer-Encoding: base64
Date: Thu, 1 Mar 2018 16:41:37 +0900
Message-ID: <メッセージ ID>
GyRCJDMkTiVhITwlayRPGyhCYmFzZTY0GyRCJEclKCVzJTMhPCVJJDUkbCRGQXc/ LiQ1JGwkXiQ3JD8hIxsoQg==
Outlook (例は Outlook 2016) では以下のレジストリを変更する事でソース表示が可能になります。
キーが存在しない場合は作成します。
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\Mail
以下の名前、値で新規 DWORD (32ビット) 値を作成します。
[値の名前(N):]
SaveAllMIMENotJustHeaders
[値のデータ(V):]
1
HTML 形式のメールを送信する
Content-Type: text/plain を Content-Type: text/html に変更し、以下のような本文の文字列を base64 等でエンコードする事で送信可能です。
<span style=”color:red;”> 赤い文字。</span>
以下 Telnet コマンドで HTML 形式のメールを送信するサンプルです。
通常、HTML メールを解釈できないメーラーで受信する事も想定し、テキストパートも同時に含めます。
そのために必要な Content-Type は multipart/alternative です。
boundary でパートを分割します。
telnet “SMTP サーバーの FQDN” 25
helo
mail from:”差出人の SMTP アドレス” (envelope from)
rcpt to:”宛先の SMTP アドレス” (envelope to)
data
from:”差出人の SMTP アドレス” (header from)
to:”宛先の SMTP アドレス” (header to)
Subject:=?ISO-2022-JP?B?GyRCRnxLXDhsJWEhPCVrJE43b0w+JEckOSEjGyhC?=
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=”hogehogehoge”
–hogehogehoge
Content-Type: text/plain ; charset=”iso-2022-jp”
Content-Transfer-Encoding: base64
SFRNTCAbJEI3QTwwJE4lYSE8JWskRyQ5ISMbKEINCkhUTUwgGyRCJEtCUDF+JDck
RiQkJEokJCVhITwlaSE8JE4+bDlnJE8lRiUtJTklSCRHST08KCQ1JGwkXiQ5ISMb
KEI=
–hogehogehoge
Content-Type: text/html ; charset=”iso-2022-jp”
Content-Transfer-Encoding: base64
PHNwYW4gc3R5bGU9ImNvbG9yOnJlZDsiPkhUTUwgGyRCN0E8MCROJWEhPCVrJEck
OSEjGyhCPGJyPkhUTUwgGyRCJEtCUDF+JDckRiQkJEokJCVhITwlaSE8JE4+bDln
JE8lRiUtJTklSCRHST08KCQ1JGwkXiQ5ISMbKEI8L3NwYW4+
–hogehogehoge–
受信メールは以下になります。
メーラーが HTML に対応しているため、HTML 形式で表示されています。
上記メールのソース (ヘッダ、ボディ) は以下のようになります。
Return-Path: “envelope from で指定した SMTP アドレス”
メールが経由した SMTP サーバーの情報
from: testuser@testdom.com
to: UserA@akbmacha.com
Subject: =?ISO-2022-JP?B?GyRCRnxLXDhsJWEhPCVrJE43b0w+JEckOSEjGyhC?=
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=”hogehogehoge”
Date: Mon, 12 Mar 2018 16:09:46 +0900
Message-ID: <メッセージ ID>
–hogehogehoge
Content-Type: text/plain ; charset=”iso-2022-jp”
Content-Transfer-Encoding: base64
SFRNTCAbJEI3QTwwJE4lYSE8JWskRyQ5ISMbKEINCkhUTUwgGyRCJEtCUDF+JDck
RiQkJEokJCVhITwlaSE8JE4+bDlnJE8lRiUtJTklSCRHST08KCQ1JGwkXiQ5ISMb
KEI=
–hogehogehoge
Content-Type: text/html ; charset=”iso-2022-jp”
Content-Transfer-Encoding: base64
PHNwYW4gc3R5bGU9ImNvbG9yOnJlZDsiPkhUTUwgGyRCN0E8MCROJWEhPCVrJEck
OSEjGyhCPGJyPkhUTUwgGyRCJEtCUDF+JDckRiQkJEokJCVhITwlaSE8JE4+bDln
JE8lRiUtJTklSCRHST08KCQ1JGwkXiQ5ISMbKEI8L3NwYW4+
–hogehogehoge–
MFCMAPI の使い方
MAPI に重要な概念としてプロパティというものがあります。
メッセージには件名や本文、フォルダにはフォルダ名や未読件数、受信者にはメール アドレスや表示名というように関連付けられるデータがあり、それらを MAPI ではプロパティと呼んでいます。
MFCMAPI ツールは Outlook と同様に MAPI クライアント アプリケーションであり、MAPI プロパティを自由に表示、編集、または削除できます。また Outlook では表示されない隠しアイテムを MFCMAPI で表示したり、削除することもできます。MAPI プロパティに問題がある場合に意図しない問題が発生することがあるため、MFCMAPI で不正になった MAPI プロパティを編集したり、隠しアイテムを削除したりして問題が解決することがあります。
注意事項としては、間違った操作を行うとメールボックスにアクセスできないなど深刻な問題に発展する場合があるため、基本的にはマイクロソフトの技術サポートからの案内に従って実施します。
- 展開したフォルダー内の mfcmapi.exe を実行します。
- ダイアログが表示されたら [OK] をクリックします。
(次回以降表示させないようにするには [Display at startup] をオフにします) - メニュー バーの [Tools]-[Options] をクリックし、[Use the MDB_ONLINE_ flag when calling OpenMsgSore] をオンにしてから [OK] をクリックします。
- メニュー バーの [Session]-[Logon] で [プロファイルの選択] 画面を表示し、該当するプロファイルを選択し [OK] をクリックします。
- メールボックスを選択し、ダブルクリックします。
- 表示される画面左側のツリーから [Root Container] をクリックするとメールボックス内にある全てのフォルダーが表示できます。
Outlook ではアクセスできないフォルダーも全て表示されるのでたくさんのフォルダーが出てきますが、受信トレイなど Outlook で表示される既定フォルダーは “インフォーメーション ストアの先頭” と呼ばれるフォルダーの配下を展開することで確認できます。 - 後は各フォルダーをダブル クリックすることでアイテムの MAPI プロパティを表示することができます。
情報 | MAPI プロパティ |
差出人 | PR_SENDER_EMAIL_ADDRESS |
受信者 | PR_RECEIVED_BY_EMAIL_ADDRESS |
件名 | PR_SUBJECT |
ボディ | PR_BODY |
※ 調査中のため不正確な可能性があります。
MFCMAPI は以下よりダウンロード可能です。
Title: Continuous Integration (18.2.18068.37)
URL: https://github.com/stephenegriffin/mfcmapi/releases
Outlook のキャッシュモードとオンラインモード、[共有フォルダーをダウンロード] のメリット、デメリット
Microsoft ではキャッシュモードを推奨しています。
ここではキャッシュモードとオンラインモードの動作の違いやメリット、デメリットを紹介します。
キャッシュモード
メリット
- メール一覧を表示、メールを開く、メールを作成して送信するなどの作業を行う際に、ローカルの OST ファイルに対して操作が行われるため処理がはやい。
- 一定の間隔でまとめてデータの同期が行われており、ネットワーク効率がよい。結果として、サーバーやネットワークへの負荷を低く抑えることができる。
- ネットワークの遅延や切断などの問題が発生した際は自動的にオフラインに切り替わり、ローカルのキャッシュを使用して操作し続けることができる。
デメリット
- ローカルにキャッシュするためのディスク領域が必要。
- セキュリティ上の理由によりローカルにメールなどのデータを残したくない場合は利用できない。
- Outlook で変更を行うと、まずローカルのデータに対して処理が行われた後に、一定の同期タイミングによりまとめて変更が反映されるのでそれまでは更新されない (最大 60 秒)。
- Exchange サーバーのメールボックス上で変更が行われると、一定の同期タイミングによりまとめて変更が反映されるのでそれまでは更新されない (最大 60 秒)。
- 負荷分散が構成されている仮想環境を利用する場合のように OST ファイルの再作成が頻繁に発生するような状況では、キャッシュ モードでは利用できない。
オンラインモード
メリット
- ローカルにデータがダウンロードされない。
(セキュリティ上の理由によりローカルにメールなどのデータを残したくない場合はオンライン モードで利用する必要がある)。 - ローカルにキャッシュするためのディスク領域が不要。
- 常に最新のデータを表示したり更新したりすることができる。
- 負荷分散が構成されている仮想環境を利用する場合のように OST ファイルの再作成が頻繁に発生するような状況ではキャッシュ モードでは利用できないため、オンラインモードで利用する必要がある。
デメリット
- 一般的にはキャッシュモードに比べて操作が遅くなる。
(毎回、Exchange サーバーのメールボックスにアクセスしてデータを取得するため。2 回目以降はメモリ上に読み込まれているデータが残っている場合はメモリから読み込むため高速に処理されるが、メモリ解放後は再度 Exchange サーバーにアクセスしてデータを取得する動作となる) - 頻繁に Exchange サーバーからデータを取得する必要があるため、ネットワークや Exchange サーバーに負荷がかかる。
- 検索を行うと Exchange サーバー側で検索を行うため、Exchange サーバーに負荷がかかる。
- ネットワークに接続していない場合は、データを参照できない。
キャッシュモードの [共有フォルダーをダウンロード] をオン
メリット
他のユーザーの予定表などの共有フォルダーのデータをローカルにキャッシュし、ローカルにキャッシュされたデータの表示や更新を行うため、一般的にはユーザーの操作が速くなる。
デメリット
- 他のユーザーの予定表などのデータをキャッシュするためのディスク容量が必要。
- 予定表に他のユーザーの予定表が多数登録されていると、以下のような問題が発生する場合がある。
* Outlook は起動時に予定表に登録されている全ユーザー (ユーザー名の左側のチェックがオンオフどちらでも。ただし同期が完了したことがあるユーザーのみ) の予定表を同期し、ユーザーごとのセッションを維持し続けて変更があると同期が行われる。
その影響によって Outlook の起動に時間がかかったり Outlook の全体的なパフォーマンスが悪くなったりする場合がある。
* 他のユーザーの共有フォルダーをキャッシュするため OST ファイルのサイズが大きくなり、OST ファイルのサイズに比例してパフォーマンスが悪化する。
キャッシュモードの [共有フォルダーをダウンロード] をオフ
メリット
- 他のユーザーの共有フォルダーに対して操作を行う際、最新のデータの表示と更新ができる。
(直接ネットワーク上の他のユーザーのメールボックスからクライアントのメモリにデータを読み込む動作となるため、同期タイミングの影響を受けない) - 自分のメールボックスはキャッシュし、他のユーザーの予定表などのフォルダーはキャッシュしないことになるため、OST ファイルのサイズを抑えることができる (他のユーザーの共有フォルダーをキャッシュするためのディスク容量が不要)。
- 予定表に他のユーザーの予定表が多数登録されていて、[共有フォルダーをダウンロード] がオンで以下のような問題が発生している場合は、[共有フォルダーをダウンロード] をオフにするとパフォーマンスが改善する。
* Outlook は起動時に予定表に登録されている全ユーザー (ユーザー名の左側のチェックがオンオフどちらでも。ただし同期が完了したことがあるユーザーのみ) の予定表を同期し、 ユーザーごとのセッションを維持し続けて変更があると同期が行われる。
その影響によって Outlook の起動に時間がかかったり Outlook の全体的なパフォーマンスが悪くなったりする場合がある。
* 他のユーザーの共有フォルダーをキャッシュするため OST ファイルのサイズが大きくなり、OST ファイルのサイズに比例してパフォーマンスが悪化する。
デメリット
予定表に多数のユーザーが登録されていない場合は、[共有フォルダーをダウンロード] がオンの場合に比べてユーザーの操作が遅くなる。
ネットワークに接続していない場合は、他のユーザーのデータを参照できない。
コマンドで代理人を再設定する方法
代理人設定を解除する
User1 の予定表アクセス権から User2 を削除します。
Remove-MailboxFolderPermission User1:\予定表 -User User2
GrantSendOnBehalfTo プロパティからも代理人設定が消えた事を確認します。
Get-Mailbox -Identity User1 |select GrantSendOnBehalfTo
GrantSendOnBehalfTo
——————-
{}
この作業により Outlook 側でも代理人設定が削除されます。
「予定表」のアクセス権 (既定は「編集者」) だけでなく、「受信トレイ」のアクセス権 (既定は「なし」) からも代理人が削除されます。
代理人を再設定する
User1 の予定表アクセス権に User2 を設定します。
-SharingPermissionFlags Delegate オプションを指定する事で代理人が有効になります。
Add-MailboxFolderPermission User1:\予定表 -User User2 -AccessRights editor -SharingPermissionFlags Delegate
User1 の予定表アクセス権に User2 が設定され、アクセス権が editor、SharingPermissionFlags プロパティが Delegate になっている事を確認します。
Get-MailboxFolderPermission -Identity User1:\予定表
GrantSendOnBehalfTo プロパティに User2 が代理人として設定された事を確認します。
Get-Mailbox -Identity User1 |select GrantSendOnBehalfTo
GrantSendOnBehalfTo
——————-
{User2}
この作業により Outlook 側でも User2 が代理人として設定されます。
ユーザーが接続している Outlook バージョンおよびビルド番号を調べる
以下の手順に従って、メールボックスごとに所有者のアクセス監査を有効にし、メールボックスのログオンに使用した Outlook バージョンに関する監査ログを確認します。
以下のコマンドを実行し、監査ログを有効にします。
Set-Mailbox -Identity User1 -AuditOwner MailboxLogin -AuditEnabled $true
以下のコマンドを実行し、監査ログを検索します。
Search-MailboxAuditLog -Identity User1 -LogonTypes owner -ShowDetails | ? { $_.ClientInfoString -like “*Outlook*” }
コメント