ハイブリッド環境の予定表共有のトラブルシューティングについて

こんにちは、Exchange サポートチームです。 ハイブリッド環境の予定表共有のトラブルシューティングについて、以前以下のブログで紹介をさせていただいております。   基本的には、まずは以下のブログを参考にトラブルシューティングをしていただければと思いますが、今回は、予定表共有のトラブルシューティングについてもう少し紹介をさせていただきます。 Title : ハイブリッド環境で行うトラブル シューティング – 空き時間/予定表参照 – URL : https://blogs.technet.microsoft.com/exchangeteamjp/2016/07/22/troubleshooting-in-a-hybrid-deployment-freebusycalendar-lookup/ クロスプレミス接続では、招待メッセージを送り合うことで、予定表の共有が可能になる旨、上記ブログや以下のブログ等にて記載をしております。 この招待メッセージから予定表を開くと、左ペインの “共有の予定表” に追加されます。 Title : Exchange Server ハイブリッド環境における予定表の共有について URL : https://blogs.technet.microsoft.com/exchangeteamjp/2017/10/31/sharing-calendar-in-hybrid-enviroment/ 上記方法で予定表を追加すると、参照元組織の Exchange サーバー上のメールボックス アシスタンス サービスが起点となり、参照先組織の Exchange サーバーに対して EWS で通信を行い、予定表の同期 (参照先ユーザーの予定アイテムを取得) を行います。 そして、こちらの動作は、スケジュールアシスタントを使用した空き時間情報の取得と違い、必ずしもリアルタイムに同期を行うわけではないため、以下の画面のように、招待メッセージを受け取った側で、[予定表を開く]を選択してもすぐに Outlook 上で予定の情報が見えてこない場合があります。 前置きが長くなりましたが、今回は、上記の動作を考慮しつつ、Exchange Online のユーザーが、オンプレミス Exchange ユーザーの予定を Outlook (左ペインの “共有の予定表”) で見えない場合におけるトラブルシューティング方法について紹介します。 今回は、以下のような事象が起こったと仮定します。   <事象> Exchange ハイブリッド環境で、Exchange…


Outlook が Exchange に接続できない、動作が非常に遅い際のヒアリング項目について

こんにちは。Exchange サポートの益森です。 今回は、Outlook が使用できない、Outlook の動作が非常に遅いなどの非常にクリティカルな問題が発生し、弊社にお問い合わせいただく際によくヒアリングさせていただく項目を改めて整理しました。 このような問題の原因は多岐に渡るため、問題を早急に解決するためには、情報を正確に把握して、問題の被疑箇所を絞り込むことが重要です。 既に実施している方も多くいらっしゃると思いますが、事前に正確な情報を把握しているかどうかで、資料を解析する時間や精度も変化するため、今後このような問題が発生した際は、以下の情報についても参考にしていただけますと幸いです。   <オンプレミス Exchange Server /Exchange Online 共通> ・ 事象が発生した正確な時間帯 (どのユーザーで何時ごろに発生したか特定できている場合は、事象発生ユーザー名/メールアドレスと時間帯) ・エンドユーザー様からの事象発生の申告数 ・事象の再現頻度 ・OWAは使用することが出来るか ・具体的な事象について  例) Outlook が起動しない、何らかのオペレーションを行うと固まる、エラーやバルーンが表示されるなど ・事象が発生した端末での対処  例)時間が経過すると復旧する、Outlook 再起動で改善されるなど ・事象発生端末について、特定の拠点に所属しているなど、ネットワーク経路などに何か傾向はあるか ・事象が発生している Outlook のバージョン  以下の画面により確認が可能です。     ・Outlook の動作モード (オンラインモードかキャッシュモードか)    1) Outlook の [ファイル] – [アカウント設定] より、電子メールアドレスを選択し、[変更] をクリックします。  2) 以下の画面より、[Exchange キャッシュモードを使う] にチェックが入っているかを確認します。 ・Outlook の接続プロトコル (MAPI/HTTP、Outlook Anywhere かなど)…


Exchange 2013 CU14 以前のサーバーに CU 16 以降の CU を適用するお客様へ

以下の TechNet 内の “重要” にも記載しております通り、Exchange 2013 CU14 以前のサーバーを CU16 以降にアップグレードする際のサポートされている手順としては CU15 を介する必要がございます。 これは Exchange 2013 CU16 以降で必須となる .Net Framework 4.6.2 が Exchange 2013 CU14 以前ではサポートされていないためとなります。   Title : Exchange 2013 の前提条件 URL : https://technet.microsoft.com/ja-jp/library/bb691354(v=exchg.150).aspx —————————————— Exchange 2013 CU16 以降には .NET Framework 4.6.2 が必要です。先にサーバーを .NET Framework 4.6.2 にアップグレードしてから Exchange 2013 CU16 をインストールしてください。そうしないと、エラーが発生します。.NET Framework 4.5.2 が Exchange…


Office 365 のアイテム保持ポリシーについて

こんにちは。本日は Office 365 のアイテム保持ポリシーについてご紹介いたします。「アイテム保持ポリシーなんて知ってるし、とっくに使っているよ!」という声も聞こえてきそうですが、Exchange 管理センターのアイテム保持ポリシーと、Office 365 のアイテム保持ポリシーは異なる設定であるということをご存知でしょうか。 冒頭よりややこしくて恐縮ですが、今回焦点を当ててご紹介するのは Exchange 管理センターのアイテム保持ポリシーではなく、Office 365 のアイテム保持ポリシーとなります。 で、何が違うの? 早速ですが機能の違いを表にまとめました。まずは以下をご覧ください。 表1 Exchange Online のアイテム保持ポリシーと Office 365 のアイテム保持ポリシーの比較 全然違いますね。同じ名前ではあるものの、利用方法も動作も全然違います。特に機能的な差異で言えば、Office 365 のアイテム保持ポリシーではこれまでインプレース保持等で設定いただく必要があった「アイテムのホールド (保持) が行える」という特徴があります。 すでに Exchange 管理センターでは警告が表示されていますが、インプレース保持を利用するための新しい検索は 2018 年初頭には行えなくなる予定であるため、ご利用のお客様にはインプレース保持の代わりとしてこの記事でもご紹介している Office 365 のアイテム保持ポリシーをご案内しています。 あくまでイメージとはなりますが、「ある期間が過ぎたアイテムを削除/アーカイブするなど、古いアイテムを自動的に整理したい」という目的で利用するのが Exchange Online のアイテム保持ポリシーであり、「ある期間は絶対にアイテムを保持したい」という目的で利用するのが Office 365 のアイテム保持ポリシーであると認識いただければ、概ねイメージ通りにご利用いただくことが可能かと思います。 設定と動作の例 例えば、Exchange Online に既定で設定されているアイテム保持ポリシーに加え、以下のように 3 年間アイテムを保持する設定を行った状況を想定します。(Office 365 のアイテム保持ポリシーは、既定の設定は空となっています。) この状況で、アイテムの一生をいくつかのパターンごとに追ってみましょう。 パターン1: 受信後、ユーザーはそのアイテムを何も触らない。 Exchange Online の既定のアイテム保持ポリシーでは、2…


コネクタ設定における 3 つのポイント (送信元 : 組織のメール サーバー)

今回は Exchange Online のメール フローにおいて、お客様からしばしばお問い合わせをいただいておりますオンプレミスのサーバー向けにコネクタ設定を行う際の注意点をお伝えします。 Exchange Online は特定の送信元 IP から急激なメール受信量の増加を検知すると、サービスを保護するために当該 IP からのメール受信を自動的に制限し、遅延受信させます。 これは以下の blog でご案内の IP スロットリングの機能ですが、この特定の IP がお客様にて運用されている問題のないサーバーである場合には本機能の動作は不要であり、回避するためには送信元を組織のメール サーバー、送信先を Office 365 とするコネクタの設定が有効です。   Title: IP スロットリングについて URL: https://blogs.technet.microsoft.com/exchangeteamjp/2015/03/23/ip/   送信元を組織のメール サーバーとするコネクタを設定すると、特定の送信元サーバーからのメールをコネクタが作成されている Office 365 テナントへメールをルーティングする動作となります。 このようなコネクタを作成するときには以下の点について予めご留意いただきますようお願い申し上げます。   << Point 1 >> 他テナント宛てのメールも自テナントで受信する 前述のようにコネクタを作成することで対象となるメール サーバーから送信されたメールを Office 365 が受信すると、コネクタのあるテナントへまずメールをルーティングします (後述の Point 2 および 3 でご案内の、コネクタが使用される条件を満たしていることが前提となります)。 そのため、宛先が別の Office…


OWA 上でテキスト形式でメール アイテムを保存すると、メール アイテムの中身が消える事象について

今回は Exchange Server 2013 CU15 以上で発生する、OWA の新規作成アイテム保存時の挙動についてご案内いたします。 詳細な事象および原因は以下になります。   事象 OWA 上でテキスト形式でアイテムを作成し下書き保存すると、以下の流れのように、保存したアイテムの中身が消える事象が発生する場合がございます。 // テキスト形式でアイテムを保存します。   // 下書きフォルダ内のアイテムのビューのみでアイテムの内容が消える事象が発生します。   // その後、上記のように情報が一部欠けている状態でウィンドウを開き、かつ、アイテムを保存すると、内容が上書きされ、アイテムの内容自体も削除されます。 (保存する、または保存される前にウィンドウを閉じ、編集をキャンセルした場合は、アイテムの内容自体は削除されません)   現在確認している本事象の発生するオペレーションは以下になります。 – パターン 1. テキスト形式でアイテムを作成し、下書き保存する。 2. 下書きフォルダに明示的に移動し、対象のアイテムをクリックする。   原因 本事象は、Exchange Server 2013 CU15 以降の OWA の仕様変更によるものであり、Exchange Server 2013 CU15 以降で本事象は発生します。   回避策 Exchange Server の設定などで本事象を回避する方法はございません。 ご迷惑をおかけいたしますが、OWA を利用して下書き保存を行う場合は、テキスト形式ではなく、HTML 形式でメールを作成いただきますようお願いいたします。 なお、本事象は現時点では Exchange Server 2013 の今後リリースされる…


トランスポート ルールで日本語の免責事項を追加する場合の注意点

今回は [リッチ テキスト] 形式のメールに対してトランスポート ルールで日本語 (ダブルバイト文字) の免責事項を追加した場合に文字化けが発生する問題の対処策についてご紹介いたします。 本内容は現行の Exchange Server (Exchange 2010 / Exchange 2013 / Exchange 2016 や Exchange Online) のいずれでも同様となります。 Exchange Server ではトランスポート ルールを使用して条件に合致するメールに免責事項を追加する機能が提供されています。 以下の TechNet にも記載されている通り、免責事項に追加するテキストは HTML やインラインの CSS スタイルを使用して書式を構成することもできます。 Title: 組織全体の免責事項、署名、フッター、またはヘッダー URL: https://technet.microsoft.com/ja-jp/library/dn600437(v=exchg.150).aspx ここでトランスポート ルールを使用して免責事項として以下を追加するように構成した場合を考えます。   *******************************************************************************</br> この電子メールおよびメールと共に送信されるすべてのファイルは機密情報です。</br> これらは宛先に指定された個人または組織のみが使用できます。</br> この電子メールを誤って受け取った場合、システム マネージャーにお知らせください。</br> *******************************************************************************   上記の免責事項を [テキスト] 形式のメールや [HTML] 形式のメールに対して追加する場合は問題ございませんが、[リッチ テキスト] 形式のメールに対して追加する場合には免責事項の日本語部分が文字化けして表示されてしまいます。 この問題は以下のように…


送信サイズ制限を 0 バイトにしているにもかかわらずメッセージが送信される

こんにちは、Exchange Server サポートの小間です。 今回は、Exchange Online のメールボックスで送信サイズ制限を 0 バイトにしているにもかかわらずメッセージが送信される事象を紹介します。 業務要件に応じて、特定のメールボックスからの送信を禁止したいシナリオが生じた際に、メールボックスの設定で送信サイズ制限を 0 バイトに設定をすることで実現ができます。 以下のように設定を行うことができます。 – 設定箇所 Exchange 管理センターでメールボックスのプロパティを開き、[メールボックスの機能] – [メッセージサイズの制限] – [詳細の表示] をクリックします。 [送信メッセージ] の [最大メッセージ サイズ] を 0 にします。 しかしながら現在、送信サイズ制限を 0 バイトに設定してメッセージを送信すると NDR が返されるにもかかわらず、宛先にメッセージが送信される事象が確認されています。 この動作については、弊社開発部門で修正を検討中となります。 また、この事象は Exchange Online の内部実装についての長期的かつ段階的な変更を進めている中で発生している問題となっております。 なお、一般的な方法としてトランスポート ルールで差出人などを条件にブロックすることで、この問題を回避できることが確認されています。 トランスポート ルールによる代替策があることから、内部実装の変更を優先して開発が進められており、本事象の対応検討には今後も時間を要する状況となっております。 大変恐れ入りますが何卒ご理解いただきますようお願い申し上げます。 進展があり次第このブログで最新情報をご報告します。 ご不便をおかけしますが、なにとぞよろしくお願いいたします。 ※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。


Exchange 2010 サーバーにてハイブリッド構成ウィザードを実行する際の注意

本記事では、主に Exchange 2010 サーバーがインストールされたコンピューター上で Office 365 ハイブリッド構成ウィザードを動作させる場合の注意点を紹介します。 Exchange Online に移行する方法の 1 つとして、Exchange Online とオンプレミスの Exchange サーバーの間でのハイブリッド展開の構成を用いた段階的移行を行うことができます。 ハイブリッド展開の構成を行う際には、http://aka.ms/HybridWizard よりダウンロード可能な新しい Office 365 ハイブリッド構成ウィザードを用いることで、常に最新版の機能を実行できるようになりました。 この新しい Office 365 ハイブリッド構成ウィザードは Exchange 2016、Exchange 2013 だけでなく、 Exchange 2010 Service Pack 3 (SP3) を実行しているコンピューターでも実行することが可能です。 本記事を記載している 2017 年 10 月時点では、Office 365 ハイブリッド構成ウィザードを実行する端末には .NET Framework 4.5 がインストールされている必要があります。 .NET Framework 4.5 がインストールされていない環境で Office 365 ハイブリッド構成ウィザードを実行しようとした際には、下記のようなエラーが表示されて Office…


日本語組織名を持つ Exchange サーバーのハイブリッド構成について

Exchange 2003 より長らく Exchange Server をご利用頂いているお客様においては、Exchange 組織名を “最初の組織” などと日本語で指定されている場合がございます。(Exchange 2007 以降で Exchange 組織を作成された場合は日本語名の指定はできません。) このような Exchange 組織を Exchange 2010 以降で継続してご利用頂いており、Exchange Online とハイブリッド構成を展開される際に 「日本語組織名であってもハイブリッド構成を行うことはサポートされるか」 とご質問を頂くことがございます。 これまでは、日本語のようなダブルバイト組織名でのハイブリッド構成について十分な検証が行われていなかったために、何らかの予期せぬ問題が発生した場合に修正などの対応が困難であるリスクをご案内致しておりました。弊社内で開発部門との確認や検討を続け、日本語組織名を持つ Exchange 組織にてハイブリッド構成ウィザードを使用する展開がこの度サポートされることとなりました。現状、日本語組織名を持つことによるハイブリッド構成の不具合や問題等は確認されておりません。前述の通り、最新の Exchange ではこのようなダブルバイトの組織名を前提としていないため、今後何らかの制限が生じる可能性もございますが、サポートでは可能な限りご支援を行ってまいります。 今後とも Exchange サーバーならびに Exchange Online のご愛顧のほど何卒よろしくお願い申し上げます。