Outlook 2007 で追加された空き時間情報の権限

Exchange Server 2007 以降の環境で、Outlook 2010/2007 により予定表フォルダーのアクセス権を見ると、既定のアクセス権が [空き時間情報のみ] となります。一方、Outlook 2003 では既定のアクセス権は [なし] となっているため、Outlook 2007 以降でアクセス権が緩められたように錯覚される方もいるかもしれません。しかし、実際には Outlook 2003 の [なし] という権限は、Outlook 2007 の [空き時間情報のみ] と同じ権限になります。では、いったい何が変わったのでしょう?

Outlook 2003 では空き時間情報をパブリック フォルダーにある Schedule+ システム フォルダーから取得します。このフォルダーには空き時間情報を格納したアイテムが 1 ユーザー 1 アイテムとして保存されていますが、Exchange サーバーではアクセス権が基本的にはフォルダー単位でしか設定できず、空き時間情報のアクセス権はアイテム (ユーザー) 単位ではなくシステム単位で設定する必要があります。そのため、既定では全ユーザーにアクセス権があり、個々のユーザーでアクセス権を指定することはできませんでした。

一方、Outlook 2007 以降では Exchange Server 2007 から追加された可用性サービスから HTTP を使用して空き時間情報の取得を行います。この可用性サービスでは単に空き時間情報だけでなく、一覧表示で使用される件名や場所も取得が可能となっており、ユーザーがほかの人にどの程度まで公開するかを設定することが可能です。そのため、Outlook 2007 には [空き時間情報のみ] や [空き時間情報、件名、場所] というアクセス権が追加されています。

なお、Outlook 2007 で予定表の既定のアクセス権を [なし] にしてしまうと、Outlook 2003 との混在環境においては、ちょっとややこしいことになります。Outlook 2003 は Exchange Server 2007 の環境であってもパブリック フォルダーの空き時間情報を参照しますが、前述のとおりパブリック フォルダーに対してはアイテム単位でしかアクセス権が設定できません。そのため、Outlook 2007 で予定表の既定のアクセス権を [なし] とすると、Outlook 2007 はパブリック フォルダーへの空き時間情報の発行を行わないという動作になります。この結果、たとえ他のユーザーに空き時間情報へのアクセス権を含む参照者などの権限を与えたとしても、そもそもパブリック フォルダーに空き時間情報がないため、空き時間情報が見えなくなるという現象が発生します。
したがって、Outlook 2007 以降で予定表のアクセス権を不用意に [なし] に変更するのは避けるべきといえるでしょう。

広告

すべてのフォルダーで閲覧ウィンドウを表示させない方法

Outlook 2010/2007 の閲覧ウィンドウは Outlook 2003 以前のバージョンに比べてはるかに安全になってるのですが、いまだにセキュリティ上の理由で無効にしたいという需要があるようです。
閲覧ウィンドウのオン・オフはビューの設定で可能ではあるものの、フォルダごとに設定する必要があるため、フォルダが多数の場合にすべてオフにするのが大変という話を聞きました。

そのような場合、Outlook.exe /nopreview として実行すると、閲覧ウィンドウを表示せずに Outlook を起動することができますので、デスクトップに以下の手順でショートカットを作り、こちらから起動することですべてのフォルダの閲覧ウィンドウをオフにしたのと同様な動作となります。

  1. デスクトップを右クリックし、[新規作成]-[ショートカット] をクリックします。
  2. [項目の場所を入力してください] に以下のように入力し、[次へ] をクリックします。

    Outlook 2010 の場合
    "C:\Program Files\Microsoft Office\Office14\Outlook.exe" /nopreview

    Outlook 2007 の場合
    "C:\Program Files\Microsoft Office\Office12\Outlook.exe" /nopreview

  3. ショートカットの名前を適切なものにし、[完了] をクリックします。

[mailto リンクで UTF-8 を使う] と Outlook

Internet Explorer 7.0 以降には [mailto リンクで UTF-8 を使う] というオプションがあります。
この設定とメールクライアント、および mailto リンクの指定方法の組み合わせによっては、件名や本文で文字化けが発生します。
以下では IE7 の挙動がどのように変わるかと、その結果 Outlook をはじめとするマイクロソフトのメール クライアントでどのような動作が行われるかについてまとめました。

Internet Explorer 6.0 以前について

HTML 中に mailto が出現する場合、FORM で指定する場合と HREF で指定する場合があり、HREF で指定する場合はさらに全角文字を事前にエンコードする場合とそうでない場合があります。それぞれについての動作は以下の通りです。

1. フォームの ACTION を mailto: とし、Subject および Body をフォームのパラメータとして送信した場合

Subject や Body の DBCS は、HTML で指定されている文字コードで % エンコードされ、ShellExecuteA によりメールソフトに渡されます。
例えば、Shift-JIS で記述されたページのフォームで Subject を「日本語件名」、Body を「日本語本文」とすると、下記の文字列がメールソフトに渡されます。

  mailto:test@example.com?subject=%93%FA%96%7B%8C%EA%8C%8F%96%BC&body=%93%FA%96%7B%8C%EA%96%7B%95%B6

一方 UTF-8 で記述されたページのフォームで同様のパラメータを指定すると、下記の文字列がメールソフトに渡されます。

  mailto:test@example.com?subject=%E6%97%A5%E6%9C%AC%E8%AA%9E%E4%BB%B6%E5%90%8D&body=%E6%97%A5%E6%9C%AC%E8%AA%9E%E6%9C%AC%E6%96%87

2. HTML 中の HREF タグで mailto のリンクの Subject および Body の全角文字があらかじめ % エンコードされている場合

HTML で指定されている文字コードに関わらず、指定された文字列がそのままメールソフトに渡されます。
例えば、下記の文字列は全角文字を Shift-JIS のコードにより % エンコードしたものですが、UTF-8 が指定されている HTML にこのようなリンクがあっても、この文字列のままメールソフトに渡されます。

  mailto:test@example.com?subject=%93%FA%96%7B%8C%EA%8C%8F%96%BC&body=%93%FA%96%7B%8C%EA%96%7B%95%B6

3. HTML 中の HREF タグで mailto のリンクの Subject および Body に全角文字を指定した場合

HTML で指定されている文字コードのまま、ShellExecutteA によりメールソフトに渡されます。
例えば、Shift-JIS で記述されたページの mailto リンクで Subject を「日本語件名」、Body を「日本語本文」とすると、下記の文字列が Shift-JIS の文字列としてメール ソフトに渡されます。

  mailto:test@example.com?subject=日本語件名&body=日本語本文

一方、UTF-8 で記述されたページの mailto リンクで同様の文字列を指定した場合、上記の文字列がエンコードされず、UTF-8 のバイト文字列としてメールソフトに渡されます。

Internet Explorer 7.0 以降について

Internet Explorer 7.0 以降では [mailto リンクで UTF-8 を使う] の設定がありますが、これをオフにした場合は Internet Explorer 6.0 以前と同様の動作となります。
また、オンにした場合でも、上記の 1. および 2. の動作は変わりません。
そして、3. の HREF タグの mailto の Subject および Body に全角文字を指定した場合に、以下のような動作をします。

  1. 文字列を HTML で指定された文字コード (または自動認識されたページの文字コード) により Unicode に変換します。
  2. Unicode 文字列を UTF-8 とし、% エンコードを行います。

そのため、 Subject を「日本語件名」、Body を「日本語本文」とすると、HTML の文字コード指定に関わらず、下記の文字列がメールソフトに渡されます。

  mailto:test@example.com?subject=%E6%97%A5%E6%9C%AC%E8%AA%9E%E4%BB%B6%E5%90%8D&body=%E6%97%A5%E6%9C%AC%E8%AA%9E%E6%9C%AC%E6%96%87

Outlook 2010/2007 について

Outlook 2010/2007 は Internet Explorer の [mailto リンクで UTF-8 を使う] の設定により動作が変わります。Outlook 2010/2007 にも [ツール]-[オプション]-[メール形式]-[文字設定オプション] に [mailto: プロトコルで UTF-8 をサポートする] がありますが、どちらのオプションも設定されるレジストリは同じ HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Protocols\Mailto\UTF8Encoding になります。そのため、このオプションをオンにすると自動的に Internet Explorer の [mailto リンクで UTF-8 を使う] がオンになります。
[mailto リンクで UTF-8 を使う] がオンである場合、mailto のリンクは Internet Explorer で UTF-8 による % エンコードが行われていると仮定します。
そのため、指定された mailto の文字列については、% エンコードをデコードし、UTF-8 の文字列として取得します。
その結果、ShellExecute やショートカットを使い、Internet Explorer を経由せずに Subject や Body に Shift-JIS の全角文字を指定した場合、文字化けが発生します。
一方、[mailto リンクで UTF-8 を使う] がオフである場合、mailto のリンクは Windows の既定のコードページによりエンコードされていると仮定します。
そのため、指定された mailto の文字列については、% エンコードをデコードし、日本語環境では Shift-JIS の文字列として取得します。

Windows メールについて

Windows メールでは Internet Explorer の [mailto リンクで UTF-8 を使う] の設定によって動作が変わることはありません。
mailto リンクで指定された文字列をデコードした後、パラメータごとに処理します。
そして、件名については UTF-8 が使用されている場合でも正しく識別できますが、本文については文字化けが発生します。

Outlook 2003 以前、および Outlook Express について

Outlook 2003 以前、および Outlook Express が開発された際には、[mailto リンクで UTF-8 を使う] というオプションは存在していません。したがって、mailto に指定された文字列については、常に Shift-JIS として解釈されます。
その結果、以下の状況では文字化けが発生します。
1. UTF-8 で指定されたページにおいて、フォームにより全角文字が送信される場合
2. [mailto リンクで UTF-8 を使う] がオンにされた状態で、HTML の HREF で mailto に全角文字が指定された場合

まとめ

上記の動作をすべてまとめると以下のようになります。

Internet Explorer 6 以前、または [mailto リンクで UTF-8 を使う] がオフである場合

・フォームによる送信

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
NG
NG (件名は OK)
NG
Shift-JIS
OK
OK
OK

・全角文字の mailto

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
NG
NG (件名は OK)
NG
Shift-JIS
OK
OK
OK

※ UTF-8 の文字がエンコードされずに指定された場合、UTF-8 の 3 バイト目の文字が DBCS の 1 バイト目と解釈され、パラメータの連結を意味する & が正しく識別できなくなることがあります。そのような場合には、順序によって本文または件名が空白となります。

・ShellExecute 直接指定

すべてのクライアントで OK
※ ファイル名を指定して実行やショートカットなどで mailto リンクに全角文字を指定した場合も ShellExecute 直接指定と同様です。

[mailto リンクで UTF-8 を使う] がオンである場合

・フォームによる送信

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
OK
NG (件名は OK)
NG
Shift-JIS
NG
OK
OK

・全角文字の mailto

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
OK
NG (件名は OK)
NG
Shift-JIS
OK
NG
NG

・ShellExecute 直接指定

Outlook 2010/2007 は NG、他は OK

Exchange Server 2003 環境の Outlook 2010/2007 で HTML メールを送信すると、メッセージの一部が文字化けしたり、取り消し線が引かれたりする現象について

Outlook 2010 や Outlook 2007 で HTML メールを送信すると、以下のような現象が発生することがあります。

パターン 1: メッセージ中の全角文字が半角英数字になる

この電子メール メッセージはPOP3 $B%"%+%&%s%H$N@_Dj%F%9%HCf$K!

パターン 2: メッセージ中に意味不明な全角文字が混ざる

この電子メール メッセージはw)・鹿齔瘤昭齔瘤€・

パターン 3: 意図しないところで取り消し線が引かれる

この電子メール メッセージはPOP3 アカウントの設定テスト中

このような現象は、以前このブログでも記事にしたことがありますが、すべて下記の Web ページに記載されている Exchange Server 2003 の不具合により発生します。

835992 電子メール メッセージはフォーマットできません正しく、受信者の電子メール メッセージ、Exchange Server 2003 コンピューターから別の Exchange 受信者に送信

回避策としては、Exchange Server 2003 に Service Pack 2 を適用し、以下のレジストリ設定を各サーバーで行うというものになります。

  レジストリ キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent
  値の名前: TransferEncodingFor7bit
  値の種類: REG_DWORD
  値のデータ: d (10 進数で 13)

この問題の原因は、Exchange Server 2003 が iso-2022-jp などの 7 ビットの文字コードによりメッセージを送信する際に、HTML の本文を適切に折り返さないことにあります。
インターネットのメール送信に使用される SMTP の規約には 1 行が 998 文字以内という制限があるのですが、Exchange Server 2003 はこれを超える長さの HTML 本文をそのまま送信します。その結果、受信側のサーバーや経路中のサーバー、ファイアウォール、ウイルススキャンゲートウェイなどにより 1 行の長さが 998 文字を超えないようにするため強制的に改行が行われると、エスケープ シーケンスや HTML タグの途中に改行コードが埋め込まれることで、文字化けや意図しない取り消し線などが発生します。
改行コードの埋め込みがされるかどうかは中継サーバーや受信サーバーの設定によって決まるため、同じメールでも受信者によって現象が発生する場合としない場合があります。

ただ、この問題は以前から存在するにもかかわらず、最近になってこのような現象に遭遇するという事例が増えてきています。その理由は Outlook 2010/2007 が HTML メールの作成に使用している Word のコンポーネントの修正にあると考えられます。

下記の技術情報に記載されている Outlook 2007 の修正に HTML メールのソースの量を減らすというものがあります。その修正により、HTML ソースの BODY タグの中のテキストには基本的に改行が含まれなくなっています。

2203971 は、Office Word 2007 修正プログラム パッケージ (Mso ・ x ・ none.msp、Word の X-none.msp) の説明: 2010 年 6 月 29日

そして、この修正は 2010/6/29 以降にリリースされるすべての Word の修正に含まれるため、たとえば MS10-056 のようなセキュリティ修正プログラムを適用しても動作が変わります。
また、Outlook 2010 が使用する Word 2010 のコンポーネントでは、リリース当初からこのような動作となっています。

このような Word の動作により、HTML ソースの 1 行の長さが 998 文字を超える状況が発生しやすくなり、Exchange Server 2003 の不具合が顕在化してしまったのです。
残念ながら、Word の設定ではこの動作を変更することができないため、上記の Exchange Server 2003 の設定変更により対処する必要があります。

なお、HTML メールのソースの 1 行の長さには特に制限が設けられていないため、ソースに極力改行を入れないという Word の動作自体は不具合ではありません。そのため、この動作が変更されることは今後もないでしょう。
また、Outlook 2003 以前のバージョンで Word をメール エディタとして使用して HTML 形式のメールを作成した場合には、1 行の長さが 998 文字を超えることはほとんどありませんが、全く発生しないということではありません。
本文の内容によっては Outlook のバージョンや Word をエディタとして使うかどうか、またメールの形式に関わらず発生することが考えられます。そのため、Exchage Server 2003 での上記の設定を行うことが唯一の完全な回避策です。

Outlook 2007 用予定表印刷アシスタントの SP2 がリリース

先日、Office 2007 用の SP2 がリリースされましたが、それと同時に Outlook 2007 用の予定表印刷アシスタントにも SP2 がリリースされていたようです。

このリリースでは定期的な予定の印刷に関する不具合の修正のほか、非公開の予定の印刷に関する機能強化が行われています。

ダウンロードは以下のリンクからできます。

Microsoft Office Outlook 2007 用予定表印刷アシスタント Service Pack 2 (SP2)

また、こちらのプログラムの詳細については、以下のリンクも参考にしてください。

Outlook2007 用予定表印刷アシスタントServicePack2 について

Office 2007 SP2 の適用後にプロファイル名が文字化けして Outlook 2007 がハングアップする現象について

MAPI プロファイルの名前に全角文字が含まれている場合、Office 2007 の SP2 を適用するとプロファイル名が文字化けして Outlook 2007 がハングアップするという現象が発生します。
ハングアップの原因は Outlook Mobile Service (以下、OMS) のアドイン モジュールなので、このアドインを無効にしてしまえば現象が回避できます。

OMS のアドインを無効にする手順は以下の通りです。(コンピュータの管理者権限が必要です。)

  1. メモ帳を開きます。
  2. 以下のテキストを貼り付けます。

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins\Microsoft.OMSAddin]
    "LoadBehavior"=dword:00000002

  3. [ファイル]-[名前をつけて保存] で "DisableOMS.reg" というファイル名で保存します。
  4. 保存した DisableOMS.reg をダブルクリックし、警告のメッセージには [続行] または [はい] をクリックします。

ファイルの編集に自信がないという場合は、以下の URL より DisableOMS.reg をダウンロードし、これをダブルクリックして適用してください。

    http://cid-9d7ea61ec7daa750.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/DisableOMS.reg

また、ドメイン環境ではグループ ポリシーを使用することですべての PC の OMS アドインを一括で無効にできます。以下はグループ ポリシーを設定する手順です。

  1. ドメイン コントローラ上でメモ帳を開きます。
  2. 以下のテキストを貼り付けます。

    CLASS MACHINE

    CATEGORY !!L_MicrosoftOfficeOutlook12
        CATEGORY !!L_Addins
            POLICY !!L_OMSAddin
                KEYNAME Software\Microsoft\Office\Outlook\Addins\Microsoft.OMSAddin
                VALUENAME LoadBehavior
                VALUEON NUMERIC 3
                VALUEOFF NUMERIC 2
                EXPLAIN !!L_OMSAddinExplain
            END POLICY
        END CATEGORY
    END CATEGORY

    [Strings]
    L_MicrosoftOfficeOutlook12="Microsoft Office Outlook 2007"
    L_Addins="アドイン"
    L_OMSAddin="Outlook Mobile Service アドイン"
    L_OMSAddinExplain="日本国内でサービスが提供されていない Outlook Mobile Service のアドインを制御します。既定では有効になっています。"

  3. [ファイル]-[名前をつけて保存] で "OMSaddin.adm" というファイル名で保存します。
  4. [Active Directory ユーザーとコンピュータ] を開きます。
  5. ドメインを右クリックし、[プロパティ] をクリックします。
  6. [グループ ポリシー] タブをクリックし、[新規] をクリックします。
  7. ポリシーの名前を入力して、[編集] をクリックします。
  8. [コンピュータの構成] の下の [管理用テンプレート] を右クリックし、[テンプレートの追加と削除] をクリックします。
  9. [追加] をクリックし、手順 3 で保存した OMSaddin.adm を追加します。
  10. [コンピュータの構成] の下の [管理用テンプレート] を右クリック、[表示]-[フィルタ] をクリックします。
  11. [完全に管理されているポリシーの設定のみ表示します] のチェックを外し、[OK] をクリックします。この手順を実施しない場合、以降の設定が表示されません。
  12. [管理用テンプレート] の下の [Microsoft Office Outlook 2007]-[アドイン] を開きます。
  13. [Outlook Mobile Service アドイン] をダブル クリックし、[無効] を選択して [OK] をクリックします。
  14. グループポリシーを閉じます。
  15. 必要に応じて、gpupdate によりグループポリシーを適用します。

こちらも、ファイルの編集に自信がないという場合は、以下の URL より OMSaddin.adm をダウンロードしてください。

     http://cid-9d7ea61ec7daa750.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/OMSaddin.adm

なお、OMS のサービスは日本国内で提供されていません。そのため、このアドインを無効にしても実害はないといえるでしょう。

6/22 追記:
この現象についての技術情報が下記の通り公開されました。
文書番号: 972782 – 2007 Microsoft Office スイート SP2 を適用した後、Outlook 2007 が起動できない

Office 2007 SP2 は 4/29 リリース

Office の Sustained Engineering (サービスパックや修正プログラムなどリリース後の製品の開発を担当するチーム) のブログによると、Office 2007 の SP2 は 4/28 にリリースされるようです。(http://blogs.technet.com/office_sustained_engineering/archive/2009/04/16/service-pack-2-for-the-2007-microsoft-office-system-due-to-ship-april-28th.aspx より)
日本時間だと 4/29 ですね。

Outlook 2007 に関しては SP2 で以下のような修正・変更が行われるようです。

  1. 起動や終了、ビューの表示やフォルダの切り替えのパフォーマンス向上
  2. 予定表の更新や検索、RSS 購読の信頼性の向上
  3. オブジェクト モデルの改善

これらの修正のほとんどは、おそらくすでにリリースされている  KB961752 で修正済みと思われますが、こちらの修正プログラムを適用していないのであれば SP2 を適用したほうがよいでしょう。