EWSEditor で OAuth を使用する

こんにちは、Exchange サポート チームの小間です。以下のブログ記事でご紹介しているように、オープン ソースで開発されている EWSEditor 1.14 で OAuth を使用できるようになりました。 TITLE: EWSEditor 1.14 ReleasedURL: https://blogs.msdn.microsoft.com/webdav_101/2016/04/02/ewseditor-1-14-released/ Exchange Online では EWS 接続に OAuth を使用することができますので、独自開発した EWS アプリケーションのトラブル シューティングなどに EWSEditor も活用できるようになります。しかしながら、OAuth を使用するには Azure Active Directory にアプリケーションを登録する必要があります。そのため、今回の記事ではアプリケーションの登録方法と、EWSEditor の設定方法をご紹介します。 なお、Azure Active Directory を使用するため、今回の記事は Office 365 (Exchange Online) のテナントをお持ちで、かつ管理者アカウントで Microsoft Azure のサブスクリプションも有効化されている方を対象にしています。 アプリケーションの登録 1. 以下の URL から、Office 365 の管理者アカウントで Microsoft Azure の旧ポータルにサインインします。https://manage.windowsazure.com/ 2. 左ペインから [ACTIVE…


Exchange 2013 にて、オンライン モードの Outlook でアドレス帳のフリガナ検索を有効化する方法

Exchange 2013 CU12 がリリースされました。多数の修正が含まれていますが、日本のお客様にとって重要な修正がありますのでご紹介します。これまで Exchange 2013 は、Outlook をオンライン モードで使用したときに、アドレス帳の中でフリガナを使用した検索が利用できませんでした。キャッシュ モードでオフライン アドレス帳を利用している場合、OAB に追加されているアドレス帳ではフリガナを利用した検索が可能です。その場合でも、OAB に追加されていないアドレス帳ではフリガナは使用できません。それらのアドレス一覧へのアクセス時は、ダウンロードした OAB ではなく Exchange 2013 を経由してグローバル カタログにアクセスするため、オンライン モードと同じ動作になるからです。 日本の人名は同じ漢字でも複数の読み方がありますので、お客様によっては、漢字の表示名順に並んでいるアドレス帳の並びを制御するために、表示名の先頭に「あいうえお」などの文字を挿入して運用する場合もあるかと思います。その問題を解決するため、Exchange 2010 では Active Directory ユーザーとコンピューターのフリガナプロパティページ set-userコマンドの-phoneticdisplaynameオプション でAD の msDS-PhoneticDisplayName 属性にフリガナを設定することでアドレス帳のエントリーをフリガナ順に表示できていましたが、Exchange 2013 では利用できなくなっていました。 Exchange 2013 CU12 でこの問題が修正され、日本語の Outlook をお使いの場合はアドレス帳がフリガナ昇順に並ぶようになりました。しかし、CU12 をインストールしただけではアドレス帳の表示はこれまでと同様に表示名順のままで、フリガナでの検索も有効化されません。機能を有効化するためには、日本語の Outlook を利用するユーザーのメールボックスがあるメールボックスサーバーにて以下の手順でレジストリを設定し、Microsoft Exchange RPC Client Access サービスを再起動します。 レジストリの設定とフリガナ機能の有効化 1. CU12 をインストールしたメールボックス サーバーでレジストリ エディターを開きます。2. 以下のキーまで移動します。 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeAB…


異なる Exchange 組織間での空き時間及び予定表参照について

いつも Exchange Server をご利用いただきありがとうございます。最近では多くのお客様でオンプレミス Exchange Server  (OnPrem Exchange)から Office 365 Exchange Online (EXO) への移行が進められており、移行関連のお問い合わも増えております。 OnPrem Exchange と EXO  のハイブリッド構成を組んで移行されるお客様ではハイブリッド構成に特化したトラブルも多くお寄せ頂いた頂いており、ハイブリッド環境のトラブルシューティング方法を以下のブログとして公開しておりおます。 Title: ハイブリッド構成について ~ まとめ編 ~Url: http://blogs.technet.com/b/exchangeteamjp/archive/2014/10/03/3638722.aspx 上記のブログでも紹介しておりますが、ハイブリッド環境を構築する場合は、OnPrem Exchange にてハイブリッド構成ウィザードを実行することで自動的にハイブリッド構成に必要な設定が行えるため、非常に便利です。ただしお客様の利用用途としては OnPrem Exchange と EXO (または別の OnPrem Exchange ) がそれぞれ別の Exchange 組織である場合はハイブリッド構成ウィザードによる自動設定が適切ではないシナリオがあります。このような場合に、OnPrem Exchange と EXO (または別の OnPrem Exchange ) とで空き時時間参照や予定表参照を実現した場合は、どのようにするのでしょうか?ハイブリッド構成ウィザードが実行できないので、手動で設定する必要があるのですが、その手順は公開されているのですが、一つの手順として纏まっていなく設定方法に苦慮します。そのため今回のブログではハイブリッド構成ウィザードを実行せずに、OnPrem Exchange と EXO (または別の OnPrem Exchange ) との間で空き時間参照や予定表参照を実現したい場合の手順やそもそもの空き時間参照や予定表参照がどういった機能なのかについて紹介させて頂きます。ハイブリッド環境のお客様でも十分有益な情報だと思いますので、ご活用頂ければ幸いです。 2 種類の共有機能について==================まずはじめに空き時間情報の共有と予定表の共有はそれぞれ参照方法が全く異なっており、空き時間情報の共有は 組織の関係ベースの予定表参照そして予定表の共有は共有ポリシー…


Exchange Server 2016 自習書シリーズを新たに公開

昨年リリースしたExchange Serverの最新版、Exchange Server 2016の自習書シリーズを本日Technetで公開しました。 自習書のダウンロードはこちらからどうぞ ➡ https://technet.microsoft.com/ja-jp/mt691869.aspx     本シリーズでは 1.アーキテクチャ編 2.移行・共存編 の2つを公開しています。   1のアーキテクチャ編では、 Exchange Server 2016 で強化・変更されたアーキテクチャ、および、他サーバーとの連携 (具体的には Office Online Server) に関して説明しています。 第 1 部 Exchange Server 2016 の新しいアーキテクチャ 第 2 部 Office Online Server との連携   2の移行・共存編では、、Exchange Server 2016 を社内に導入するために必要な情報を次の章に分けて説明しています。 第 1 部 Exchange Server 2016 の移行共存 第 2 部 既存 Exchange 組織への Exchange…


バッチ移行を使用したパブリック フォルダー移行での注意点

Exchange Server 及び Exchange Online を日々ご利用頂きありがとうございます。 既存の Exchange Server のリプレース作業に伴い、多くのお客様が Exchange Server 2013/2016 への移行やクラウド シフトのために Exchange Online への移行を進められている傾向が見られます。 そのため今回はバッチ移行を使用した従来のパブリック フォルダー移行に関する注意点についてご紹介します。特に大規模 Exchange 組織で従来のパブリック フォルダーを頻繁に利用されるお客様にとっては重要なお知らせとなります。 従来のパブリック フォルダーを Exchange Server 2013/2016 へ移行する場合は、以下の KB  3161916 の問題があることをご留意ください。   ID   : 3161916 Title: Data loss may occur during public folder migration to Exchange 2013, Exchange 2016, and Exchange Online Url: https://support.microsoft.com/en-us/kb/3161916…


バージョン バケットの閾値の変更について (Exchange 2013)

こんにちは。Exchange サポートの山木です。 下記ブログで紹介しているバックプレッシャ機能ですが、Exchange 2013 でも引き続き使用することが可能です。今回はバック プレッシャ機能で監視する一部システム リソースの閾値が Exchange 2013 CU7 より変更となりましたので具体的な閾値とアップグレードにおける注意点などをご案内致します。 – 参考情報Title : 外部からのメールが受信できないURL : http://blogs.technet.com/b/exchangeteamjp/archive/2013/03/14/3558601.aspx バック プレッシャ機能で監視するシステム リソースの一つとして、バージョン バケットがあります。バージョン バケットとは、メッセージ キュー データベースに加えられた変更が一時的に格納されるメモリ空間であり、変更 (トランザクション) がデータベースにコミットされることで解放されます。したがいまして、ディスク I/O に遅延が生じている場合や、長時間実行されるようなトランザクションがある場合は、このバージョン バケットの値も増加することとなります。また、このような状況が発生する具体的な要因といたしましては、一般的に以下のような点が挙げられます。 ・ サイズの大きいメッセージがやり取りされた・ ディスクの処理性能不足・ Antivirus ソフトの影響・ 何らかの要因により意図しないメッセージのループが発生した (または一時的にメッセージの流量が増加した) バージョン バケットの閾値について==========================================このバージョン バケットの閾値が Exchange 2013 CU7 以降では下記の通り見直しが行わております。Exchange 2013 CU6 以前は Exchange 2010 の値を踏襲しておりましたが、Exchange 2013 では Exchange 2010 からアーキテクチャーの大幅な変更が行われ、またパフォーマンスの観点でも大きく向上していることから従来の値では閾値として低すぎると判断し、CU7 にて変更が行われました。…


Edge サーバーを振り返る エピソード 2

こんにちは。Exchange サポートの竹本です。 今回も引き続きエッジ トランスポート サーバーについてです。前回の記事にて、次回は機能紹介を、、、とコメントをしていましたが、書き出してみると注意事項や Tips のご紹介がメインとなりました。 エッジ トランスポート サーバーを管理されている方々、是非ご一読ください。 – エッジ サブスクリプションにより複製されたデータについて~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~前回もご紹介しました通り、エッジ サブスクリプションを作成することにより、組織のディレクトリに保存された Active Directory データがエッジ トランスポート サーバーへ複製されますが、この複製されたデータは AD LDS データベース (adamntds.dit ファイル) に保存されます。既定のパス情報は、以下にある通りです。 Title : AD LDS の構成を変更するURL : https://technet.microsoft.com/ja-jp/library/aa997269(v=exchg.150).aspx補足情報ですが、AD LDS は社外のネットワークにおいてディレクトリの必要最低限のデータを保持することを目的としたサービスであるため、簡易的な情報のみを保存します。DMZ に配置されることを前提としているため、当然ユーザーの資格情報といった重要なデータは保持せず、SMTP アドレスなどの情報はハッシュ データとしてレプリケートされるなど、セキュリティ面での対策が実装されています。 – エッジ サブスクリプションの再購読~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~運用中、何らかの障害が発生し、組織内の Exchange サーバーの回復処理 (RecoverServer) が必要となる場合もあるでしょう。そのようなときにはエッジ サブスクリプションの再購読が必要となりますが、この点については以下の Blog にて紹介しておりますので、是非ご一読ください。  Title : EdgeSync を実施している Exchange 2010 環境下における RecoverServer…


Exchange Server 2010 の TCP / UDP の動的ポート範囲

Exchange Server をご利用のお客様でクライアントと CAS サーバー間のネットワークで特定のポートのみ空けることを検討する場合(注)があります。また Exchange Server 2010 でパブリック フォルダーを利用する場合は、Outlook クライアントは直接パブリック フォルダーを保持する MBX サーバーに対しても通信するため、クライアントと MBX サーバー間のネットワークについても考慮する必要があります。どのポートを空ければよいのかは Exchange Server が使用するポートを把握する必要がありますが、今回は、Exchange Server 2010 の動的ポートの範囲についてご紹介致します。 注)Exchange Server 2010 についての使用する一般的なネットワーク ポート情報を以下にて公開しております。 Title : Exchange ネットワーク ポートのリファレンスURL : https://technet.microsoft.com/ja-jp/library/bb331973(v=EXCHG.141).aspx 上記の公開情報では以下に記載されている通りExchange サーバー間、または MBX あるいは CAS サーバーと Active Directory との間へのファイアウォールのインストールはサポートされないことをご留意下さい。 ———- 抜粋ここから ———–メールボックス サーバーを含む各 Active Directory サイトには、クライアント アクセス サーバーが必要であることに加えて、Exchange サーバー間でトラフィックの制限を避けることが重要です。Exchange が使用する定義済みのすべてのポートが、送信元と送信先のサーバー間で双方向に開いていることを確認します。Exchange サーバー間、または…


Forefront 製品のサポート終了に伴う FPE のアンインストール方法について

Exchange/Forefront サポート チームの伯谷です。 Forefront 製品のサポートも 2 週間を切り、サポートには Forefront のアンインストール手順の確認やアンインストール時のトラブルシューティングのお問い合わせが増えています。アンインストール シリーズの第三弾は Microsoft Forefront Protection 2010 for Exchange です。以下の TechNet でも手順は公開していますが、本ブログではスクリーンショットも併せてご紹介します。 Title: FSC ユーティリティを使用した製品の無効化/有効化URL: https://technet.microsoft.com/ja-jp/library/dd639369.aspx Title: スタンドアロン サーバーからのアンインストールURL: https://technet.microsoft.com/ja-jp/library/cc482969.aspx – 手順1. Microsoft Forefront Protection 2010 for Exchange (以下 FPE) をアンインストールする対象のサーバーにログオンし、以下のサービスを停止します。サービスの停止に伴い、メールボックスへのログオンやメッセージの配信はできなくなりますので、利用するユーザーの少ない時間帯にご実施ください。 ・ハブ トランスポート サーバー   Microsoft Forefront Server Protection コントローラー    Microsoft Exchange Transport ・メールボックス サーバー   Microsoft Forefront Server Protection コントローラー   Microsoft Exchange Information Store 2….


Exchange 2013 DAG データセンター切り替え時の注意点

Exchange 2013 DAG (Database Availability Group) では、DAG を構成したサーバー間で同一メールボックス データベースのコピーを保持し、ディスク、サーバー、ネットワークの障害などのメールボックス データベースに影響を与える障害が発生した際に、自動的に回復する機能を提供します。データセンターに何らかの障害が発生した場合に備え、別のデータセンターに障害時に使用するための Exchange サーバーを構築 (災対サイトとも呼ばれています) いただいているお客様も多くいらっしゃいます。今回はこの別のデータセンターに切り替えた際の注意点についてご紹介します。 説明のため、普段使用するデータセンターを Primary DC、障害時に使用するデータセンターを Secondary DC とします。通常は Primary DC で運用しており、 Secondary DC は Primary DC  の障害時のみ利用することを想定している場合、メールボックス データベースが意図せず Primary DC  から Secondary DC へフェールオーバーされることを防ぐため、Secondary DC にあるメールボックス サーバーの DatabaseCopyAutoActivationPolicy パラメータを Blocked に設定して運用することがあります。この設定はパッチ適用などメンテナンス中にも良く使われています。当該設定をすることで、Primary DC から Secondary DC へデータベースが自動でフェールオーバーされることを防ぐことができます。しかし、DatabaseCopyAutoActivationPolicy パラメータを Blocked に設定したまま、Secondary DC にてメールボックス データベースをアクティブ化した場合、Primary DC…