会議出席依頼を遅延配信すると発生する問題について

誤送信対策のため、Outlook の送信ルールの遅延配信設定やアドインにより、メールの送信を数分保留するというような運用をされている方は多いと思います。
その際、メールだけでなく会議出席依頼にも遅延配信が設定されるようになっているかもしれませんが、その場合に送信トレイの会議出席依頼を開いてしまうと以下のような事象が発生します。

  • 送信トレイの会議出席依頼を開くと、その会議出席依頼が送信トレイから削除される
  • 削除済みアイテムに移動された会議出席依頼を送信トレイに移動しても送信されない
  • 会議出席依頼が削除されてしまった会議については会議の更新しか送信できなくなるが、それを送信しても出席者側では正しく処理できない

これは、会議出席依頼の特殊な動作によって発生します。

Outlook の会議出席依頼は、元になる予定表上の会議アイテムが必要となり、単独では存在できません。
そして、会議出席依頼自体の変更などは想定されておらず、何らかの変更が必要な場合は会議アイテムを変更することになります。
そのため、送信トレイの会議出席依頼を開くと、その会議出席依頼自体ではなく元になった会議アイテムが開かれ、送信トレイの会議出席依頼は削除されるという動作になります。

このような事象を回避するためには会議出席依頼については遅延配信をさせないという運用をする必要があります。
例えば、自動仕分けの送信時のルールで遅延配信を設定している場合であれば、例外条件として [会議出席依頼または会議の更新である場合を除く] を追加します。
また、マクロやアドインなどであれば、MessageClass が IPM.Schedule で始まるアイテムについては遅延配信を設定しないというものが考えられます。

Outlook アドインの有効・無効に関連するレジストリ

Outlook では、アドインの有効・無効に関連する様々なレジストリがあり、それぞれ用途が異なります。
そのため、用途が異なるレジストリを誤って使用すると、想定した結果が得られないことになります。
今回は、優先度が高い順にそれぞれの用途を説明します。

1.ポリシーの AddinList


キー:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Resiliency\AddinList

名前:
アドインの ProgID

種類:
REG_SZ

値:
0 = 無効、1 = 有効、2 = ユーザー設定

用途:
管理者が特定のアドインの有効化または無効化を強制したいときに使用します。
このレジストリで設定を行うとユーザーが有効・無効の変更ができなくなるため、最も優先順位が高いといえます。
ただし、キーとしては HKEY_LOCAL_MACHINE で設定はできず、あくまでもユーザー単位のポリシーで設定するものとなります。
なお、設定する値が数値ですが、値の種類が REG_SZ となる点に注意が必要です。
また、DLL ファイルの破損やレジストリ設定の不備、アドイン自体の不具合などの理由でアドインの読み込みが失敗する場合、このレジストリで有効化を強制してもアドインを有効にすることはできません。

2.HKEY_CURRENT_USER の DisabledItems と CrashingAddinList


キー 1:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Resiliency\DisabledItems

キー 2:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Resiliency\CrashingAddinList

名前:
8 桁のランダムな 16 進数

種類:
REG_BINARY

値:
アドインの DLL のパスを含むバイナリデータ

用途:
Outlook がアドインの実行によるクラッシュやロードの失敗などを検知して無効化した場合に、無効化したアドインの情報を保存するために使用します。
上記のレジストリに登録されているアドインについては、Outlook の正常な動作を保つため、後述の LoadBehavior で 3 が指定されていても、アドインは無効となります。

3.HKEY_CURRENT_USER の LoadBehavior


キー:
HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins

名前:
アドインの ProgID

種類:
REG_DWORD

値:
0-2 = 無効、3  = 有効

用途:

ユーザーが指定したアドインの起動時の読み込みを行うかどうかの設定です。
ユーザー単位でインストールされたアドインにはもともとキーが存在しており、インストール時に値が設定されます。
一方、マシン単位でインストールされたアドインでも、ユーザーがアドイン設定のダイアログで有効・無効の設定を変更すると、こちらの LoadBehavior が設定され、この設定が HKEY_LOCAL_MACHINE の設定より優先されます。

4.HKEY_LOCAL_MACHINE の LoadBehavior


キー:
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\Addins

名前:
アドインの ProgID

種類:
REG_DWORD

値:
0-2 = 無効、3  = 有効

用途:

マシン単位でインストールされたアドインの起動時の読み込み設定の初期値です。
アドインのインストーラーで設定されますが、前述の通りユーザーで設定が変更されると HKEY_CURRENT_USER に設定が行われ、そちらが優先されます。
そのため、この設定でアドインの有効・無効を管理者が制御することはできません。

5.HKEY_CURRENT_USER の DoNotDisableAddinList


キー:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Resiliency\DoNotDisableAddinList

名前:
アドインの ProgID

種類:
REG_DWORD

値:
アドインが無効になった理由を示す値

用途:

Outlook により自動的に無効化されたアドインについて、ユーザーが無効化しないよう指定するものです。
この設定は DisabledItems に設定されたアドインでも有効にすることができるので、その点に関しては優先度が高いといえます。
しかし、ユーザーが意図的に無効化し、LoadBehavior が 0 や 2 になっている場合は、その設定が優先されてアドインが無効になります。
つまり、あくまでもユーザーが設定することを目的としているものであり、管理者がこの設定でアドインの有効化を強制することはできません。
無効化されたアドインを有効化するためのレジストリとして紹介されていることもあるため、このレジストリを展開してアドインの有効化を強制しようと考えてしまうこともあるかと思いますが、前述の通り管理者がアドインの有効化を強制するためには AddinList というレジストリ設定があり、DoNotDisableAddinList を使用するのは不適切かつ不十分です。
また、設定する値によっては、ユーザーに対して「このアドインにより Outlook の起動が遅くなりました。」のように、実際には発生していない事象が発生したかのように表示されるため、ユーザーの不安を煽る可能性があります。

CSV ファイルへのエクスポートで分類項目が全角だと 3 文字以上だと出力できない

Outlook で予定表などのデータを CSV ファイルにエクスポートをする際に、分類項目が全角で 3 文字以上になるとその分類項目が欠落するという事象が発生します。

これは、Outlook で CSV ファイルにエクスポートすると 1 行目が文字化けする現象についてでも説明した、CSV ファイルの UTF-8 化による不具合のようです。
この不具合についてはまだ修正が行われていないようですので、上記の記事でも紹介した以下のレジストリ設定を行うことで回避が可能です。

キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\UserInfo
名前: ExportWithAscii
種類: REG_DWORD
値: 1

Outlook オブジェクト モデルによりメールを送信しようとしても、送信トレイに滞留してしまう現象について

RPA や Excel マクロなどで Outlook オブジェクト モデルを使用して MailItem の Send メソッドによりメールを送信した際に、メールが送信されずに送信トレイに滞留したままの状態となる場合があります。
これは以下のような条件で発生します。

  • メールを送信する際に Outlook が起動していない
  • インターネット アカウントを使用しているか、Exchange アカウントでキャッシュ モードを有効にしている
  • Send メソッドで送信した後、すぐに Outlook のオブジェクトを開放している
  • メールサイズが大きかったり、一度に複数のメールを送信するなど、送信処理に時間がかかる状況である

上記の条件でメールが送信されない場合があるのは、Outlook の送信処理が以下のような順序で行われるためです。

  1. Send メソッドが実行されると、メールが送信トレイに保存され、送信のためのバックグラウンド タスクが起動される
  2. バックグラウンド タスクにより送信が実行される
  3. 送信が完了すると送信トレイのメールが送信済みアイテムに移動される

上記の 1. の処理が完了すると、それ以降の処理が行われる前に呼び出し元に制御が戻ります。
そして、呼び出し元のアプリケーションなどが直後に Outlook のオブジェクトを開放すると、Outlook 上では誰も Outlook を利用していない状態になります。
この状態になると、Outlook はバックグラウンド タスクが完了次第終了するのですが、何らかの理由でメール送信のタスクが起動していなかったり、複数のタスクの合間で実行中のタスクがない状況になると送信前のメールがあっても Outlook は終了します。
その結果、マクロなどでの送信が完了しても実際にはメールが送信されず、次に Outlook が起動されたタイミングで送信が行われるということになります。
これを回避するには、Outlook でメールの送信が完了したことを確認するまで、Outlook のオブジェクトを参照し続ける必要があります。
メールの送信が完了したかどうか判断する方法としては、送信トレイのアイテム数が 0 になるのを待つというものが考えられるでしょう。
appOlk という変数に Outlook.Application オブジェクトが格納されている場合に送信完了を待つ Excel VBA のサンプル コードは以下の通りです。
なお、サーバーやネットワークの問題などにより送信処理がいつまでも完了しない場合を考慮し、60 秒待っても送信トレイのアイテム数が 0 にならなければエラー表示するようにしています。

    Dim fldOutbox As Object
    Dim dtStart As Date
    Dim bAbort As Boolean
    Set fldOutbox = appOlk.Session.GetDefaultFolder(4) ' 4 = olFolderOutbox
    dtStart = Now
    bAbort = False
    While fldOutbox.Items.Count > 0 And Not bAbort
        ' Send メソッド実行から 60 秒以上経過していたら待つのをやめる
        If DateDiff("s", dtStart, Now) > 60 Then
            bAbort = True
        End If
        ' 送信トレイにアイテムが残っていたら 5 秒待つ
        Application.Wait (Now + TimeValue("00:00:05"))
    Wend
    '
    If bAbort Then
        MsgBox "送信処理が完了しませんでした。Outlook を起動して送信トレイを確認してください。"
    End If

「仕分けルールには、サーバーが処理できない条件が含まれています。[ルールの処理を中止する] を選択すると、すべてのサーバールールが実行されなくなります。このまま続行してよろしいですか?」という警告の意味

タイトルの警告の意味ですが、仕分けルールにサーバーで確認できない条件が含まれていて、そのルールに [ルールの処理を中止する] というアクションが含まれている場合、それ以降のルールを実行すべきかサーバー側で判断ができないため、サーバー ルールが実行されなくなるということです。

例えば、以下のような優先順位でルールがあったとします。

  1. 受信者のアドレスに info が含まれている場合、ルールの処理を中止する (クライアント ルール)
  2. 件名に 問い合わせ が含まれていた場合、メールを 問い合わせ フォルダーに移動する (サーバー ルール)

この場合、件名に「問い合わせ」が含まれ、受信者のアドレスに「info」が含まれているメールを受信した際には、1. でルールの処理が中止され、2. の動作は行われないことが想定されます。

しかし、サーバーでは 1. の条件が判定できないため、仮にクライアントルールを無視してルールを実行してしまうと、受信者のアドレスに「info」が含まれているにもかかわらずメールが移動されてしまうことになります。

このような意図しないルールの実行を防ぐため、クライアントでしか確認できない条件が含まれるルールで [ルールの処理を中止する] を指定すると、警告が表示されて実際に当該ルール以降のサーバー ルールが実行されなくなるのです。

Outlook の連絡先に意図しない連絡先アイテムが追加される

先月半ばごろから、Microsoft 365 の環境で Outlook と Teams を使用している場合、意図しない連絡先アイテムが Outlook の連絡先に追加されるという事象が発生しているようです。
これは何らかのトラブルというわけではなく、MC695487 として公開されていた Outlook と Teams の連絡先の同期機能によるものと考えられます。

公開情報を見る限り、この同期処理を無効化するような方法は用意されていないようなので、不要な連絡先が追加されており、Teams でも使用しないということなのであれば、削除するしかないでしょう。

なお、同期が完了する前に連絡先の削除をしたり、Teams で連絡先の変更を行ったりすると、削除した連絡先が復活したり、編集した連絡先が重複するなどの現象が発生するというような情報もあるので、Outlook の連絡先と Teams の連絡先が完全に同期するまではあまり変更を加えないほうが良いかもしれません。

参考リンク:

New Outlook & Teams Instant Contact Syncing Inconsistencies – Microsoft Community Hub

Outlook から HTML 形式のメールを送信すると本文が空白になる現象について

ごくまれに、Outlook から HTML 形式のメールを送信した際に、以下のような事象が発生する場合があります。

  • 受信者側でも、送信者の送信済みアイテムでも本文が空白になる
  • 転送や返信を行うと本文が表示される
  • テキスト形式で表示を行うと本文が表示される

このような現象が発生する原因として、[ファイル]-[オプション]-[メール] の [ひな形およびフォント] をクリックして表示される設定の [新しいメッセージ] の文字書式で [隠し文字] がオンになっているというものが考えられます。
image

[隠し文字] はその名の通り書き込んだ文字列を表示させないようにするためのものです。
しかし、作成中まで非表示になっていると書き込んでいる文字列が見えないということになるので、メールの作成中は通常通り文字が表示され、送信されたメールを開く際には非表示の状態となるのです。

この設定が自動的に行われるということは通常あり得ませんが、いつの間にかこの設定がオンになってしまい、それ以降に作成した HTML メールで本文が非表示になるということがあるようです。

もし、特定のユーザーが送信した HTML メールの本文が常に空白になるというような現象が発生したら、そのユーザーについて上記の [隠し文字] の設定がオンになっていないか確認してみてください。

なお、この設定をオフにしたとしても、すでに隠し文字属性付きで送信された HTML メールの本文が表示されるようになるわけではありません。

Outlook の [ショートカット] モジュールにある [Microsoft Office Online] をクリックするとスクリプト エラーになる

Outlook のナビゲーション ウィンドウには [ショートカット] というモジュールがあり、そこに追加したリンクを Outlook 内のブラウザで表示させることができます。
しかし、このショートカットに既定で追加されている [Microsoft Office Online] をクリックすると、スクリプト エラーが多発します。
これは、Outlook 内のブラウザが Internet Explorer のコンポーネントを使用しているために発生しています。

[Microsoft Office Online] をクリックすると Microsoft 365 の紹介ページが開かれますが、Microsoft 365 のサイトは Internet Explorer をサポートしていません。
そのため、Internet Explorer で使用できない JavaScript の記述が多用されており、様々なスクリプト エラーが表示されることになるのです。

残念ながら Outlook が使用する Web ブラウザのコンポーネントを変更することはできないため、回避策としては [Microsoft Office Online] を削除するというものが考えられます。
ただ、多数のユーザーがいる組織で個々のユーザーに手動で [Microsoft Office Online] のリンクを削除してもらうというのは現実的ではないでしょう。
そこで他の対処方法としては、以下のレジストリを展開するというものがあります。

キー: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Preferences
名前: ModuleVisible15
種類: REG_DWORD
値: 1,1,1,1,1,1,0,1,0

このレジストリはナビゲーション ウィンドウに表示されるモジュールの表示・非表示を設定するもので、左から 7 番目が [ショートカット] に相当します。
そこで、7 番目の数字を 0 として設定することで、[ショートカット] 自体を非表示にしてしまうのです。
[ショートカット] 機能が使えなくなるということにはなりますが、最近は Internet Explorer に対応していない Web サイトも増えてきており、[ショートカット] がなくてもほとんど支障はないと考えられます。

なお、0 にする個所を間違えると、他のモジュールが使用できなくなるのでご注意ください。

参考:

ショートカット関数から [Microsoft Office Online] をクリックすると Outlook でスクリプト エラーが発生する – Microsoft サポート

予定表機能を利用しないよう制御する方法 (microsoft.com)

Outlook から Exchange Online (Microsoft 365) に POP3、IMAP4 で接続ができない

Outlook から Exchange Online に接続する場合、MAPI/HTTP というマイクロソフト独自のプロトコルが利用されます。
一方、Outlook や Exchange Online は POP3 や IMAP4 といったインターネットの標準プロトコルもサポートしています。
そうなると、Outlook から POP3 や IMAP4 を使用して Exchange Online に対して接続はできるように思えますが、実際には接続はできません。

これは、先進認証のサポートの問題により発生しています。

以前は Exchange Online に接続する際の認証方法として、基本認証と先進認証という二つの認証方式が存在していました。
しかし、基本認証はパスワードをそのまま送信するという安全性の低いものであるため、2023 年 1 月をもって Exchange Online では使用できなくなりました。
これに対し、Outlook では先進認証のサポートが MAPI/HTTP と一部の IMAP4 サーバー (Google および Yahoo) に限られており、Exchange Online への POP3/IMAP4 での接続に対しては先進認証を使用することができません。
そのため、Outlook では Exchange Online に POP3 や IMAP4 での接続ができないということになります。

Outlook で Exchange Online への接続における先進認証がサポートされれば接続できるようになるかもしれませんが、POP3 や IMAP4 で接続しても Exchange Online 固有の機能が全く使えず、ほとんどメリットがないため、おそらくサポートされることはないでしょう。

参考リンク:
POP/IMAP および先進認証を使用して Outlook に接続できない – Exchange | Microsoft Learn
Exchange Online での基本認証の廃止 | Microsoft Learn

予定表で本文の一部が表示される

Outlook の既定の予定表の表示では、予定の件名と場所だけが表示されます。
しかし、何かの拍子に本文の一部まで表示されるようになってしまうことがあります。
この現象は、予定表のビューとして「プレビュー」もしくはこのビューをもとにして作成したビューを使用すると発生します。
タネを明かせば特に問題のない正常な動作なのですが、ビューの設定などを見ても本文の表示・非表示の切り替えを行うようなところはないのが厄介なところです。
通常表示されない本文が表示されることで、意図しない情報が公開されてしまっていると誤解される方もいるのですが、あくまでも本文が参照できる権限がない限りは「プレビュー」というビューを使用しても本文が表示されることはないのでご安心ください。