Windows Server 2008 DC 下で発生するアドレス帳に関する既知の不具合について

Exchange をご利用いただいている環境において、ドメイン コントローラー (DC) をホストする OS が Windows Server 2008 (R2 ではありません) である場合に、下記のようなアドレス帳に関する不具合が発生します。   現象 以下のような現象が発生します。 1. アドレス帳よりユーザを選択し、宛先に追加しようとしても追加できない。アドレス帳よりユーザを検索し、宛先を追加する場合は正常に追加できる。     2. アドレス帳を開くと、適当なユーザが選択 (グレーになっている) されている。   3. 配布グループを表示するとユーザ情報が正しく表示できない。   これまでに、本現象は少なくとも Exchange 2013 の OWA において発生することが確認されています。また、関連が想定される現象が Exchange 2007 環境でも報告されています。   原因 本事象の原因は Windows Server 2008 RTM/SP1/SP2 における Active Directory の不具合であることを確認しています。アプリケーションから NspiGetProps と呼ばれる関数を用いてオブジェクト情報の問い合わせを行った際に、Windows 2008 Active Directory が正常な値をアプリケーション側に返さない事により本事象が発生します。  …


複数 AD サイト環境での eDiscovery の注意点

こんにちは。Exchange サポート チームの小間です。 今回は、複数 AD サイトの Exchange 2013 や Exchange 2016 環境でインプレースの電子情報開示 (eDiscovery) を使用する場合の注意点をご紹介します。 結論としては、複数のサイトに eDiscovery のプレビューを使用する管理者が存在する場合、以下のどちらかの構成を行う必要があります。 ・管理者のメールボックスを保持しているサイトの OWA / ECP 仮想ディレクトリの ExternalUrl を削除 (Null に設定) する ・すべてのサイトの OWA / ECP 仮想ディレクトリの ExternalUrl を統一する これは、システム メールボックス (SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}) と別のサイトにいる管理者が eDiscovery のプレビューを表示できない制限への対処策となります。 まずは説明のため、以下の環境を想定します。 この環境で、管理者 A が eDiscovery のプレビューを表示するため、サイト A の Exchange 管理センター (EAC) にサインインし、プレビューのリンクをクリックすると、問題なく eDiscovery のプレビューが表示されます。 eDiscovery…


Exchange Online の Safety Tip 機能による “なりすまし” 判定について

最近、お客様より受信メールに対して以下の警告がメッセージ閲覧時に表示されるようになったというお問い合わせを多くいただきます。 ——————————————————————————————— この送信者は不正検出チェックに合格しませんでした。なりすましの可能性があります。 スプーフィングの詳細については、http://aka.ms/LearnAboutSpoofing をご覧ください。 ———————————————————————————————   これは、Safety Tip と呼ばれる Exchange Online Protection (EOP) が自動的に受信メッセージに対して安全性のチェックを行った結果を表示する機能の一部です。 なりすましチェックの判定ロジックの概要については、英語となりますが以下の blog にてご案内しております。 Title: How antispoofing protection works in Office 365 URL: https://blogs.msdn.microsoft.com/tzink/2016/02/23/how-antispoofing-protection-works-in-office-365/ 要約すると、EOP は以下のロジックにより Safety Tip の機能によるなりすましの判定を行います。 1. 送信者のメール アドレスのドメインが、受信者のテナント内に設定された承認済みドメインであるか 2. ステップ 1 に合致する場合、送信メッセージは外部を経由せず受信者のテナント内で認証されたものであるか (組織内の送受信か) 3. ステップ 2 に合致しない場合、送信者は評価されるか (※) 4. ステップ 3 に合致しない場合、なりすましの可能性があるメッセージとして判定する   ※評価項目は以下の通りです。 – 送信ドメイン認証による評価 (SPF、DKIM、DMARC…


英国国防省、Office 365 Advanced Threat Protection を利用してクラウドベースのデータ保護の最前線に

(この記事は 2016 年 11 月 9 日に Office Blogs に投稿された記事 UK Ministry of Defence on the frontline of cloud-based data protection with Office 365 Advanced Threat Protection の翻訳です。最新情報については、翻訳元の記事をご参照ください。) 今回は、マイクロソフトのコーポレート バイス プレジデントを務める Ron Markezich の記事をご紹介します。 今日、セキュリティを提供するうえでは、業界を問わず、最先端のテクノロジを積極的に採用していく姿勢が求められます。英国国防省 (MOD) が率先してマイクロソフトのクラウドを採用し、マイクロソフトの英国のデータ センターが提供する Office 365 Advanced Threat Protection とカスタマー ロックボックスを導入するという決定を下したのはすばらしいことです。 国防省の最高デジタル情報責任者 (CDIO) を務める Mike Stone 氏によると、マイクロソフトのクラウド サービスは、同省のデジタル トランスフォーメーションの計画に最適な方法で、業務に世界トップレベルの信頼性とパフォーマンスをもたらすと言います。 「MOD がマイクロソフトのクラウド…


下書き保存したメールを送信する場合の注意事項

Exchange 2013/2016 の環境で、Outlook をオンラインモード (非キャッシュモード) でご利用の場合は以下のようなシナリオにおいてメールが配信できない問題が発生します。   – 現象 メールの作成途中で下書きに保存し、その下書きに保存したメールを送信すると以下のエラーとなり配信されず差出人に配信不能通知 (NDR) が返される。  MCEAINVALID-<不正なSMTPアドレス>  Remote Server returned ‘550 5.1.0 RESOLVER.ADR.InvalidInSmtp; encapsulated INVALID address inside an SMTP address (IMCEAINVALID-)’ この問題は宛先が組織内外にかかわらず発生します。   – 原因 下書き保存の際に、宛先の “名前解決” をせずに保存した場合、名前解決済みの宛先情報と識別され宛先の SMTP アドレスが不正となり、配信処理に失敗します。   – 回避策 以下いずれかの方法で回避することができます。  ・下書き保存する前に、宛先 (CC:/BCC: も含む) の入力後に手動で名前解決をしてから保存する (Ctrl + K の押下で名前解決できます)  ・下書き保存したメールから送信する場合は、送信前に宛先情報を入れなおす  ・Outlook キャッシュモードを利用する //名前解決していない状態 (SMTP アドレスに下線がない) //名前解決した状態…


Exchange Server 2016 の Active Directory フォレストの機能レベルについて

(この記事は 2016 年 10 月 27 日に Exchange Team Blog に投稿された記事 Active Directory Forest Functional Levels for Exchange Server 2016 の翻訳です。最新情報については、翻訳元の記事をご参照ください。) 2016 年 9 月のリリースに関するブログ記事 (英語) の中で、Windows Server 2016 で Exchange Server 2016 を使用する際の記述についてわかりづらい点がありました。「Windows Server 2016 で実行されるドメイン コントローラーは、フォレストの機能レベルが Windows Server 2008R2 またはそれ以降の場合にサポートされる」という箇所です。誤解を防ぐためにこの記事の詳細を明確にお伝えします。 質問 1: Exchange Server 2016 をデプロイする場合、フォレストの機能レベルが 2008R2 またはそれ以降の Active Directory 環境が必要なのですか。 回答: いいえ。Exchange…


Exchange Online の Outlook on the web で他の組織のユーザーの予定表を開く

Exchange Online では、組織上の関係や共有ポリシーの機能を使用して、オンプレミスの Exchange 組織や別の Office365 組織やユーザーと、予定表や空き時間情報を共有することができます。 ユーザーは、Outlook や Outlook on the web (OotW) で予定表にアクセスしますが、今回は OotW で予定表を開く際のお話しです。 OotW の予定表から他の組織のメールボックスにアクセスする時、組織上の関係の設定を使用した開き方と、共有ポリシー (共有の招待) を使用した開き方があります。 組織上の関係や共有ポリシーの詳細や設定手順は、以下の “Exchange Online での共有” にまとめられていますのでご参考ください。 Title: Exchange Online での共有 URL: https://technet.microsoft.com/ja-jp/library/jj916670(v=exchg.150).aspx   ・組織上の関係の設定を使用した開き方 組織上の関係の設定を使用して、ハイブリッド組織内のユーザーの予定表を開き、空き時間情報を確認できます。 しかし、他の Exchange Online テナントやハイブリッド環境でない他のオンプレミスの Exchange 組織のユーザーの予定表は、アクセス権限が付与されるまで OotW の予定表画面から開けません。これは、参照先メール アドレスが、参照元の Exchange Online テナントで Exchangeメールボックスとして認識されていないためです。これらのユーザーの予定表を予定表画面で開く場合は、Outlook を使用するか後述の共有ポリシー (共有の招待) を使用し、アクセス権限を付与する必要があります。なお、スケジュール アシスタントでは、これらのユーザーの空き時間情報を表示できます。 – 手順 1….


REST API を使用するためのオンプレミス アーキテクチャ要件

Igniteで発表された最新情報をはじめ、Microsoft の今をお伝えするイベント「Tech Summit」が11月に日本で開催! ぜひ皆様のご参加を楽しみにお待ち申し上げております! 「Microsoft Tech Summit」 日時:11月1日・2日 場所:ヒルトン東京お台場 お申込みURL: http://microsoft-events.jp/mstechsummit/   (この記事は 2016 年 9 月 26 日に Exchange Team Blog に投稿された記事 On-Premises Architectural Requirements for the REST API の翻訳です。最新情報については、翻訳元の記事をご参照ください。) ハイブリッド環境をご利用のお客様は、近日中に Office 365 とオンプレミスの両方にあるメールボックスに対して REST API を使用することが可能になります。 REST API (メール、予定表、連絡先の API) の構文はオープン性 (たとえば、JSON、OAUTH、ODATA などのオープン規格をサポート) と柔軟性 (たとえば、ユーザー データへのアクセス許可をきめ細かく設定可能) を兼ね備え、親しみやすく、Exchange のプログラミングを簡単に行えます。開発者は API を使用して、Web、PC、モバイル デバイスなど、あらゆるプラットフォームから接続できます。.NET、iOS、Android、NodeJS、Ruby、Python、Cordova、および CORS 向けの…


Exchange Server 2016 の MSExchangeApplicationLogic / 3018 イベントについて

Exchange Server 2013 をご利用の方で、下記の「MSExchangeApplicationLogic / 3018 イベントについて」の記事をご存知の方もいらっしゃるかと思いますが、Exchange Server 2016 では、同じ対処を実施いただいても CU3 以前では引き続きイベントログにエラー ID:3018 が記録され、解消できない場合がございます。 Exchange Server 2013 への対処については下記の Blog を参照ください。 Titel:MSExchangeApplicationLogic / 3018 イベントについて URL:https://blogs.technet.microsoft.com/exchangeteamjp/2014/10/22/msexchangeapplicationlogic-3018/ 現象 Proxy サーバーを経由してインターネットへアクセスする環境で、Exchange Server 2016 に Proxy の設定を行っているにも関わらず、イベントログに ID:3018 のエラーが 1 時間に 2 回の頻度で記録されます。 この場合、WinHTTP Proxy の設定や、Internet Explorer の Proxy 設定、Set-ExchangeServer での Proxy のいずれを設定しても状況は変化しません。 ———- ログの名前: Application ソース: MSExchangeApplicationLogic イベント…


Exchange 2013 以降の検索フォルダーのカスタム条件

こんにちは。Exchange サポート チームの小間です。 今回は Outlook で利用できる検索フォルダーの条件についてご紹介します。 Outlook で検索フォルダーを作成する際に、カスタム条件の検索フォルダーを作成できます。 また、条件として以下のようにメール アドレス チェックを使用することができます。 Outlook をオンライン モードで利用しており、かつ Exchange 2013 以上 (Exchange 2013 / Exchange 2016 / Exchange Online) に接続している場合、上記条件の [[宛先] に自分とほかの人の名前がある] と [[CC] に自分とほかの人の名前がある] のどちらかを使用すると、意図したとおりに結果が返されない動作となります。 これは Exchange 2013 で検索に関する動作が変更されたためです。 具体的には、これらの条件での検索を行うためには、検索フォルダー作成時に、Exchange サーバー上のインデックスを使用することを示すフラグの設定が必要になりましたが、Outlook で上記の条件の検索フォルダーを作成すると、インデックスを使用しない検索フォルダーが作成されるため、結果として検索フォルダーに検索結果が表示されない状態になります。 なお、インデックスを使用する検索を行う場合はこれらの条件についても検索を行うことができます。 インデックスを使用しない検索のほうがよりパフォーマンス負荷が高いため、負荷が低いインデックスを使用した検索が必要とされるよう変更されました。 現時点でこれらの条件が使用できないことは製品の制限となりますが、条件を変更することで同様の検索結果を得ることができます。 Outlook で [高度な検索] を使用する検索フォルダーを作成する方法と、MFCMAPI を使用してインデックスを使用した検索を行うように変更する方法をご紹介いたします。   Outlook で [高度な検索] を使用する検索フォルダーを作成する ========================================================== 条件の [[宛先]…