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

こんにちは、Exchange/Forefront サポート チームの伯谷です。 今年も残り一カ月となり、遂に一部の Forefront 製品のサポートが今月で終了となります。12 月に入ってから数日ですが、サポートには Forefront を停止したい/Forefront をアンインストールしたいというお問い合わせを複数いただいおります。特に最近は for SharePoint の Forefront 製品のお問い合わせが多いため、今回のブログでは、前回に引き続き for SharePoint の製品に関してアンインストール手順をご紹介します。 なお、これまでもご紹介している以下の Blog の “よく寄せられる質問” は for SharePoint の Forefront 製品も同様ですのでご一読ください。 Title: Forefront Protection 2010 for Exchange Server をご利用中のお客様へ移行準備開始のお願いURL: http://blogs.technet.com/b/exchangeteamjp/archive/2015/01/29/still-using-forefront-protection-2010-exchange-server-make-move-soon.aspx – 手順1. Forefront Security for SharePoint (以下 FSSP) をアンインストールする対象のサーバーにログオンし、以下の 3 つのサービスを停止します。    FSCController   IIS Admin Service   World Wide Web Publishing Service 2. コマンド プロンプトにて、FSSP…


EWS Managed API の GetUserAvailability 実行時に NullReferenceException の例外が発生する現象について

今回は EWS Managed API の ExchangeService.GetUserAvailability メソッドを使用して空き時間情報の取得を試みた際に System.NullReferenceException の例外が発生する現象についてご紹介いたします。本現象は Exchange Web Service を直接使用しているアプリケーションでは発生いたしませんが、EWS Managed API を使用しているアプリケーションでは取得対象が Exchange 2007 / 2010 / 2013 / 2016 や Exchange Online のいずれの場合でも発生することを確認しておりますのでご注意ください。 現象EWS Managed API ではユーザーの空き時間情報を取得する方法として ExchangeService.GetUserAvailability メソッドが提供されています。本メソッドにて大部分のユーザーについては空き時間情報を正常に取得出来ていますが、特定のユーザーに対して実行すると毎回以下の例外が発生して空き時間情報の取得に失敗します。 ・System.NullReferenceException Message: オブジェクト参照がオブジェクト インスタンスに設定されていません。Source : Microsoft.Exchange.WebServicesStackTrace:    場所 Microsoft.Exchange.WebServices.Data.EwsUtilities.ParseEnumValueList[T](IList`1 list, String value, Char[] separators)    場所 Microsoft.Exchange.WebServices.Data.WorkingPeriod.TryReadElementFromXml(EwsServiceXmlReader reader)    場所 Microsoft.Exchange.WebServices.Data.ComplexProperty.InternalLoadFromXml(EwsServiceXmlReader reader, XmlNamespace xmlNamespace,…


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

こんにちは。Exchange サポートの竹本です。 今回は意外と知っているようで見落としがちな Edge サーバーについてのおさらいです。Exchange 2013 で HUB の役割がなくなり、2016 では CAS の役割もなくなりました。しかし!エッジ トランスポート サーバーは未だ顕在している、重要な役割です。 – そもそも エッジ トランスポート サーバーとは~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~これは皆さまご存知かと思いますが、エッジ トランスポート サーバーは Exchange 役割の中で唯一、境界ネットワーク (DMZ) に置くことができるサーバーであり、Exchange 組織とインターネット間で発生するすべての受信および送信メッセージ (メールフロー) を処理します。また、メッセージ保護やセキュリティ向上を目的としたトランスポート エージェントも組み込まれているため、内部 Exchange 組織がインターネット上の脅威 (ウィルスやスパムなど) にさらされるリスクを最小限に抑えることが可能です。主な機能概要は以下でも紹介しておりますので、ご参照ください。* エッジ トランスポート サーバーには、リバース プロキシ サーバーや CAS サーバーのように、クライアントからの HTTP リクエストを処理する機能はありません。あくまでもトランスポート サーバーとして機能します。  Title : エッジ トランスポート サーバー URL : https://technet.microsoft.com/ja-jp/library/bb124701.aspx なおエッジ トランスポート サーバーは、組織の Exchange サーバーと一切特別な関係を持たないスタンドアロン…


Exchange Online でマルウェアを受信した場合の対策について

2017 年 8 月からマルウェア検体の提出に利用するサービスが Windows Defender Security Inteligence に変更されております。 Windows Defender Security Inteligence を使用した検体の提出方法はこちらのブログをご参考ください。 こんにちは、Exchange Server サポートの杉山 卓弥です。Exchange Online または Exchange Online Protection をご利用のお客様で、ウイルス メールを受信した際の推奨のプロセスについてご紹介します。 Exchange Online では、提携パートナーを含む複数のマルウェア対策エンジンを使用しており、各サーバーは 1 時間間隔でマルウェア対策パートナーから最新のマルウェア定義の有無を確認し、更新しています。 そのため、Exchange Online をご利用いただいているお客様は、複数のマルウェア対策エンジンによって自動的にマルウェアの攻撃から保護されておりますが、昨今ゼロデイ攻撃などによる未知のマルウェアも増加しつつあります。 ※ Exchange Online で使用しているマルウェア対策エンジンはセキュリティの観点から非公開とさせていただいております。 そのため疑わしいメッセージを受信した場合には、早急に対策を講じさせていただくために、Microsoft Malware Protection Center (MMPC) へのマルウェア検体提出のご協力をお願いしております。 検体提出いただいた後、弊社マルウェア対策チームにて詳細な調査を行い、検体にマルウェアが含まれていると判断した場合には個別に Exchange Online で受信しないようにするための修正措置を実施いたします。 また、解析が完了次第、調査結果は検体提出時のメールアドレスに配信されるため、お客様は早急に Exchange Online でのマルウェア検知可否を把握することができます。 以下に MMPC において検体提出をいただく手順についてご案内いたします。 ※…


DAG メンバー停止時の OAB 生成について

こんにちは。Exchange サポート チームの上地です。 今回は、DAG メンバーの一部のメールボックス サーバーが停止すると、OAB が生成できなくなる事象について、ご紹介させていただきます。 以下の記事でご紹介しております通り、Exchange 2013 CU5 以降では、従来の OAB 生成とは異なり、OAB 生成用の調停メールボックスのあるサーバーで OAB が生成されます。   Title: Exchange Server 2013 で OAB を管理する  Url: http://blogs.technet.com/b/exchange_jp/archive/2013/01/31/exchange-server-2013-oab-managing-oab-in-exchange-server-2013.aspx 調停メールボックスが DAG のコピーを持つデータベース内に存在する場合は、データベースがアクティブとなっているサーバーが、OAB 生成サーバーとなります。     ここで、以下のような構成を想定します。OAB 生成を行うサーバーが停止して、サーバーのフェールオーバーが発生すると、調停メールボックスのあるデータベースも別のサーバーでマウントされ、OAB が生成されるサーバーも切り替わります。    この時、多くの場合では、OAB の生成サーバーが 上図の Server3 に切り替わったので、Update-OfflineAddressBook コマンドの実行を行うことで、引きつづき Server3 上で OAB が生成されることが期待されます。 しかしながら、実際にこの状態で Update-OfflineAddressBook コマンドを実行しましても、OAB は生成されません。また、イベント ログなどにも OAB 生成に失敗するエラーなどは記録されません。 これは、Exchange のワークロード調整機能による動作で、DAG…


Exchange サーバーで BitLocker を有効化する方法

(この記事は 2015 年 10 月 20 日に Exchange Team Blog に投稿された記事 Enabling BitLocker on Exchange Servers の翻訳です。最新情報については、翻訳元の記事をご参照ください。)   Exchange Server 2013 と Exchange Server 2016 の推奨アーキテクチャでは、Exchange データベース ファイルが保存されている固定データ ドライブで BitLocker を有効化することが推奨されています。一方で、サーバーに対して BitLocker を有効化する方法について、過去何年にもわたって多数のご質問が寄せられています。 今回の記事ではその方法をご紹介したいと思いますが、このテクノロジについてあまりご存じでない方に向けて、まずは BitLocker の概要をご説明します。 BitLocker とは BitLocker は、Microsoft Windows に標準で搭載されているボリューム暗号化ソリューションであり、コンピューターまたはハード ディスクの盗難時や紛失時にデータが盗まれないように保護を強化するものです。 Windows Vista と Windows Server 2008 で初めて導入されて以来、データ ボリュームの暗号化、使用中のディスク領域のみの暗号化、柔軟性の向上など、BitLocker には多数の機能強化が行われてきました。 既定では、BitLocker は Cipher Block Chaining…


メールボックス監査ログの活用

こんにちは。Exchange サポートの山木です。 オンプレミス Exchange、Exchange Online をご利用のお客様よりメールが勝手に削除されたとか知らない内に意図しない変更がアイテム対して行われたというお問合せをよく頂きます。原因が特定できないままになるケースが多いですが、一般的には該当ユーザーが意図せず削除してしまった、第三者ユーザーが削除していたり、あるアプリケーションがメールボックスにアクセスして変更を行っていたりということが考えられますが、このような事象の調査に有益な情報としてメールボックス監査ログというものがあります。今回は実際にこのメールボックス監査ログの採取手順から出力方法、ログの確認方法を皆さまにご案内したいと思います。 なお、メールが意図せず削除される事象の調査方針やメールボックス監査ログの使用については下記ブログでも案内しておりますので併せてご参照下さい。 Title : 突然アイテムが消えた!場合の対策URL : http://blogs.technet.com/b/exchangeteamjp/archive/2015/04/15/3648071.aspx メールボックス監査ログは既定で出力が無効になっておりますが、設定変更によってメールボックス単位で出力することが可能です。メールボックス監査ログを有効化することによって文字通り、そのメールボックスに行われた操作 (移動、変更、削除など) を監査することが可能です。メールボックス監査ログのメリットとしてメールボックスの所有者が行った操作だけではなく、該当メールボックスにアクセス権限のある第 3 者ユーザー (代理ユーザーと言います。) の操作についてもログ上で確認することができる点が挙げられます。所有者の操作であればエンド ユーザー様にヒアリングすることで原因が分かることもありますが、代理ユーザーが大勢いた場合はだれがメールボックスに対して操作を行ったかをヒアリングだけで調査することはとても大変な作業となります。 ログの採取手順では早速ログの採取手順を見ていきましょう。下記例はアイテムが勝手に削除されたシチュエーションを想定し、代理ユーザーおよび所有者の削除関連の操作 (HardDelete, SoftDelete, MoveToDeletedItems) をログに記録するように設定しています。ログの保存期間は既定 (90 日) のままでもかまいませんが、下記例では 3 日 (03.00:00:00) を指定しています。ログを長く保管しておく必要がなければサーバー リソースの観点からも保存期間を短めに変更頂くことをお勧めいたします。 <設定例>Set-Mailbox -Identity test01 -AuditEnabled $true -AuditLogAgeLimit 03.00:00:00 -AuditOwner HardDelete, SoftDelete, MoveToDeletedItems -AuditDelegate HardDelete, SoftDelete, MoveToDeletedItems パラメーターの意味はそれぞれ以下の通りです。 AuditEnabled : メールボックス監査ログの有効 / 無効 (既定は無効)AuditLogAgeLimit…


Exchange 2013 ハイブリッド サーバーの証明書更新における注意事項

こんにちは。Exchange サポートの河本です。 Exchange Server 2013 がリリースされてから 3 年程が経過している現在、Exchange 2013 をハイブリッド サーバーとして利用されているお客様でハイブリッド サーバーの証明書の更新方法についてお問い合わせが入ってきています。ハイブリッド サーバーの証明書の更新についていくつか注意事項がありますので、以下にご案内します。 証明書更新の前提 ハイブリッド サーバーに使用する証明書は信頼できる第三者証明機関 (CA)  から発行された公的証明書を取得します。その際に以下の 2 点について注意ください。 A. 使用する公的証明書は以下の証明書要件を満たしている Title: ハイブリッド展開の証明書要件 Url: https://technet.microsoft.com/ja-jp/library/hh563848(v=exchg.150).aspx B.  証明書の Subject プロパティに CN が含まれている。 Exchange Server 2013 をハイブリッド サーバーとして使用する場合は、Exchange Server 2013 と Exchange Online 間で使用する送信コネクタ、受信コネクタには TLS のセキュリティで保護された接続を確立するために、ハイブリッド サーバーに使用される証明書名 (TlsCertificateName) が指定されます(注)。この際、指定される証明書のサブジェクト名 (Subject) には CN が含まれている必要があるため、公的証明書を取得する場合は、CN が含まれたサブジェクト名であることをご確認下さい。 注) ハイブリット構成ウィザードによって自動的に構成されるため、手動で設定する必要はありません…


Kerberos 認証を使用する場合の Exchange 2016 の共存

(この記事は 2015 年 10 月 22 日に Exchange Team Blog に投稿された記事 Exchange 2016 Coexistence with Kerberos Authentication の翻訳です。最新情報については、翻訳元の記事をご参照ください。)   Exchange Server 2016 がリリースされましたので、今回は MAPI クライアントに Kerberos 認証を使用する場合のガイダンスについてご説明しようと思います。Exchange 2010、2013 と同様、Exchange 2016 でも代替サービス アカウント (ASA) 資格情報を展開することで、ドメインに参加またはドメインに接続している Outlook クライアントやその他の MAPI クライアントで Kerberos 認証を使用できるようになります。 共存期間中に ASA を 1 つのみ利用するか複数利用するかは、ご利用の環境によって異なります。   Exchange 2016 と Exchange 2010 の共存環境 この環境では、2 つの ASA 資格情報を使用します。1 つ目の…


Exchange 2016 でコマンドレット リファレンス トピックの配信および更新方法を刷新

(この記事は 2015 年 8 月 24 日に Exchange Team Blog に投稿された記事 A brave new world for Exchange 2016 cmdlet reference topic delivery and updates の翻訳です。最新情報については、翻訳元の記事をご参照ください。)   Update-ExchangeHelp は Exchange コマンドレットの 1 つであり、これを使用することで、Exchange サーバー上に Exchange コマンドレット リファレンスの最新版のヘルプ トピックをインストールして、Exchange 管理シェル (Get-Help <コマンドレット>) で利用できるようになります。Windows PowerShell コマンドレットにも一見、同様の処理を行うもの (Update-Help (英語) および Save-Help (英語)) がありますが、これらは Exchange 管理シェルでは使用することができません。 Update-ExchangeHelp は Exchange 2013 で提供されていたものの、フル活用されるまでには至らず、その真価が発揮されていませんでした。しかし、Exchange 2016…