可用性管理Managed Availability

適用対象: Exchange Server 2013 SP1Applies to: Exchange Server 2013 SP1

ユーザーの電子メール エクスペリエンスの向上は常に、メッセージング システム管理者の主要な目的です。Ensuring that users have a good email experience has always been the primary objective for messaging system administrators. Microsoft Exchange Server 2013 組織の可用性と信頼性を確保するために、システムのすべての側面を積極的に監視し、検出された問題を迅速に解決する必要があります。To help ensure the availability and reliability of your Microsoft Exchange Server 2013 organization, all aspects of the system must be actively monitored, and any detected issues must be resolved quickly. 以前のバージョンの Exchange では、重要なシステムコンポーネントを監視することで、通常は、Microsoft System Center 2012 Operations Manager などの外部アプリケーションを使用してデータを収集し、その結果として検出された問題に対する回復アクションを提供していました。収集されたデータを分析する。In previous versions of Exchange, monitoring critical system components typically involved using an external application such as Microsoft System Center 2012 Operations Manager to collect data, and to provide recovery action for problems detected as a result of analyzing the collected data. Exchange 2010 および以前のバージョンには、管理パックの形式で正常性マニフェストと関連付けエンジンが含まれていました。Exchange 2010 and previous versions included health manifests and correlation engines in the form of management packs. これらのコンポーネントは、Operations Manager を有効にして、特定のコンポーネントが正常であったかどうかを判断します。These components enabled Operations Manager to make a determination as to whether a particular component was healthy or unhealthy. また、Operations Manager では、Exchange 2010 に組み込まれている診断コマンドレットインフラストラクチャを使用して、システムのさまざまな側面に対して代理トランザクションを実行することもできます。In addition, Operations Manager also used the diagnostic cmdlet infrastructure built into Exchange 2010 to run synthetic transactions against various aspects of the system.

Exchange 2013 は、組み込みの監視と回復アクションを提供する可用性管理と呼ばれる機能を使用して、エンドユーザーの操作を監視および保持するための新しいアプローチを採用しています。Exchange 2013 takes a new approach to monitoring and preserving the end user experience natively using a feature called Managed Availability that provides built-in monitoring and recovery actions.

可用性管理Managed Availability

可用性管理 (アクティブな監視またはローカルのアクティブな監視とも呼ばれる) は、組み込みの監視と回復の操作を Exchange の高可用性プラットフォームと統合することです。Managed availability, also known as Active Monitoring or Local Active Monitoring, is the integration of built-in monitoring and recovery actions with the Exchange high availability platform. 可用性管理は、問題が発生してシステムで発見されると、すぐにそれを検出して回復するように設計されています。It's designed to detect and recover from problems as soon as they occur and are discovered by the system. Exchange での以前の外部監視向けソリューションやテクニックとは異なり、可用性管理は、問題の根本原因の識別や通知を試みません。Unlike previous external monitoring solutions and techniques for Exchange, managed availability doesn't try to identify or communicate the root cause of an issue. その代わりに、次に示すユーザー エクスペリエンスの主要な 3 つの領域に対応する回復局面に力を集中します。It's instead focused on recovery aspects that address three key areas of the user experience:

  • 可用性: ユーザーがサービスにアクセスできるかどうか。Availability: Can users access the service?

  • 遅延: ユーザーにとってどのような状況がありますか。Latency: How is the experience for users?

  • エラー: ユーザーは必要な情報を得ることができますか。Errors: Are users able to accomplish what they want?

Exchange 2013 のサーバーの役割の統合およびその他のアーキテクチャ上の変更には、以前のバージョンの Exchange で使用されていた監視方法論と正常性モデルに対する新しいアプローチが必要です。The server role consolidation and other architectural changes in Exchange 2013 require a new approach to the monitoring methodologies and health model used in previous versions of Exchange. 可用性管理は、ネイティブの正常性監視および復旧ソリューションを提供することによって、これらの変更に対応するように設計されています。Managed availability is designed to address these changes by providing a native health monitoring and recovery solution. これは、切り離されたシステム個々の断片を監視するのではなく、エンド ツー エンドのユーザー エクスペリエンスを監視し、回復指向のアクションを通してエンドユーザーのエクスペリエンスを保護します。It moves away from monitoring individual separate slices of the system to monitoring the end-to-end user experience, and protecting the end user's experience through recovery-oriented actions.

可用性管理は、すべての Exchange 2013 サーバー上で実行される内部プロセスです。Managed availability is an internal process that runs on every Exchange 2013 server. 1 秒ごとに数百もの正常性メトリックをポーリングし、分析します。It polls and analyzes hundreds of health metrics every second. 異常が検出されても、ほとんどの場合は自動的に修正されます。If something is found to be wrong, most of the time it will be fixed automatically. しかし、可用性管理のみでは修正できない問題が発生する場合もあります。But there will always be issues that managed availability won't be able to fix on its own. そのような問題が起きた場合、可用性管理はイベント ログを介して問題を管理者にエスカレートします。In those cases, managed availability will escalate the issue to an administrator by means of event logging.

2つのサービスの形式で実装された可用性管理。Managed availability implemented in the form of two services:

  • Exchange Health Manager サービス (msexchangehmhost.exe): これは、ワーカープロセスの管理に使用されるコントローラプロセスです。Exchange Health Manager Service (MSExchangeHMHost.exe): This is a controller process used to manage worker processes. これを使ってワーカー プロセスを必要に応じて構築、実行、開始、および停止します。It's used to build, execute, and start and stop the worker process, as needed. また、ワーカー プロセスが停止した場合の回復や、ワーカー プロセスが単一障害点になることを防ぐためにも使用されます。It's also used to recover the worker process in case that process fails, to prevent the worker process from being a single point of failure.

  • Exchange Health Manager ワーカープロセス (msexchangehmworker.exe): これは、管理された可用性フレームワーク内で実行時タスクを実行する作業を担当するワーカープロセスです。Exchange Health Manager Worker process (MSExchangeHMWorker.exe): This is the worker process responsible for performing run-time tasks within the managed availability framework.

可用性管理では、永続的なストレージを使用してその機能を実行します。Managed availability uses persistent storage to perform its functions:

  • \Bin\監視\config フォルダー内の XML ファイルを使用して、いくつかのプローブおよび監視作業項目の構成設定を格納します。XML files in the \bin\Monitoring\config folder are used to store configuration settings for some of the probe and monitor work items.

  • Active Directory を使って、グローバル オーバーライドを格納します。Active Directory is used to store global overrides.

  • Windows レジストリを使って、ブックマークなどのランタイム データ、ローカル (サーバー固有の) オーバーライドを格納します。The Windows registry is used to store run-time data, such as bookmarks, and local (server-specific) overrides.

  • Windows クリムゾン チャネル イベント ログ インフラストラクチャを使用して、作業項目の結果を格納します。The Windows crimson channel event log infrastructure is used to store the work item results.

  • 正常性メールボックスは、プローブ アクティビティに使われます。複数の正常性メールボックスが、サーバーに存在する各メールボックス データベースに作成されます。Health mailboxes are used for probe activity. Multiple health mailboxes will be created on each mailbox database that exists on the server.

次の図に示すように、可用性管理は、常時稼働する 3 つの主要非同期コンポーネントを含みます。As illustrated in the following drawing, managed availability includes three main asynchronous components that are constantly doing work.

可用性管理のコンポーネントManaged Availability Components

Exchange Server 2013 における可用性管理Managed Availability in Exchange Server 2013

1 つ目のコンポーネントはプローブと呼ばれています。The first component is called a Probe. プローブは、サーバー上の測定とデータの収集を行います。Probes are responsible for taking measurements on the server and collecting data. これらの測定結果は、2番目のコンポーネントであるモニターに送られます。The results of those measurements flow into the second component, the Monitor. モニターには、収集されたデータの正常な状態に基づいて、システムによって使用されるすべてのビジネスロジックが含まれています。The monitor contains all of the business logic used by the system based on what is considered healthy on the data collected. モニターは、パターン認識エンジンと同様に、収集したすべての測定値についてさまざまなパターンを探し出し、対象が正常かどうかの決定を下すことができます。Similar to a pattern recognition engine, the monitor looks for the various different patterns on all the collected measurements, and then it decides whether something is considered healthy. 最後に、回復とエスカレーションの操作を実行するレスポンダーがあります。Finally, there are Responders, which are responsible for recovery and escalation actions. 問題がある場合は、最初の処理として、そのコンポーネントの回復を試みます。When something is unhealthy, the first action is to attempt to recover that component. これには、複数段階の回復操作が含まれることがあります。たとえば、最初の試行では、アプリケーションプールを再起動する必要があります。2番目は、サービスを再起動する必要があります。その後、サーバーを再起動する必要があり、その後、トラフィックを受け付けないようにサーバーをオフラインにします。This could include multi-stage recovery actions; for example, the first attempt may be to restart the application pool, the second may be to restart the service, the third attempt may be to restart the server, and the subsequent attempt may be to take the server offline so that it no longer accepts traffic. 回復操作が失敗した場合、この問題は、システムによってイベントログ通知を介してユーザーにエスカレートされます。If the recovery actions are unsuccessful, the system escalates the issue to a human through event log notifications.

プローブには、定期的なプローブ、通知、チェックという3つの主要なカテゴリがあります。There are three primary categories of probes: recurrent probes, notifications, and checks. 繰り返しプローブとは、エンドツーエンドのユーザー環境をテストするためにシステムによって実行される代理トランザクションのことです。Recurrent probes are synthetic transactions performed by the system to test the end-to-end user experience. チェックは、ユーザーのトラフィックを含む、パフォーマンスデータの収集を実行するインフラストラクチャで、ユーザー障害のスパイクを決定するために設定されたしきい値に対して収集されたデータを測定します。Checks are the infrastructure that perform the collection of performance data, including user traffic, and measure the collected data against thresholds that are set to determine spikes in user failures. これにより、ユーザーに問題が発生した場合に、チェックインフラストラクチャが認識されるようになります。This enables the checks infrastructure to become aware when users are experiencing issues. 最後に、通知ロジックにより、システムは、プローブによって収集されたデータの結果を待つことなく、重要なイベントに基づいて直ちにアクションを実行できます。Finally, the notification logic enables the system to take action immediately based on a critical event, without having to wait for the results of the data collected by a probe. 通常、これらの例外または条件は、大きなサンプルセットを使用せずに検出および認識することができます。These are typically exceptions or conditions that can be detected and recognized without a large sample set.

繰り返しプローブは、数分おきに実行され、サービス正常性のいくつかの側面をチェックします。Recurrent probes run every few minutes and check some aspect of service health. このプローブは、Exchange ActiveSync 経由の電子メールを監視対象メールボックスに送信したり、RPC エンドポイントに接続したり、メールボックスに対するクライアント アクセスの接続を確認したりします。These probes might transmit an email via Exchange ActiveSync to a monitoring mailbox, they might connect to an RPC endpoint, or they might verify Client Access-to-Mailbox connectivity.

すべてのプローブは、the the the the the the the the the the the the the the\the ProbeDefinition/the the the the the the the the the the the the the the the the the the the the the theAll probes are defined on Health Manager service startup in the Microsoft.Exchange.ActiveMonitoring\ProbeDefinition crimson channel. 各プローブ定義にはさまざまなプロパティが含まれていますが、最も重要なプロパティは次のとおりです。Each probe definitions has many properties, but the most relevant properties are:

  • Name: プローブの名前。プローブのモニターのSampleMaskで始まります。Name: The name of the probe, which begins with a SampleMask of the probe's monitor.

  • TypeName: プローブのロジックを含むプローブのコードオブジェクトの種類です。TypeName: The code object type of the probe that contains the probe's logic.

  • ServiceName: このプローブを含む正常性セットの名前。ServiceName: The name of the health set that contains this probe.

  • TargetResource: プローブが検証しているオブジェクト。TargetResource: The object the probe is validating. これはプローブの名前に追加され、プローブ結果のResultnameとなるために実行されます。This is appended to the name of the probe when it is executed to become a probe result ResultName

  • RecurrenceIntervalSeconds: プローブが実行される頻度。RecurrenceIntervalSeconds: How often the probe executes.

  • Timeoutseconds: 障害が発生するまでプローブが待機する時間。TimeoutSeconds: How long the probe will wait before failing.

何百もの反復プローブがあります。これらのプローブの多くはデータベース単位のため、データベースの数が増えるほど、プローブの数も増えます。ほとんどのプローブは、コード内で定義されるため、直接検出することはできません。There are hundreds of recurrent probes. Many of these probes are per-database, so as the number of databases increases, so does the number of probes. Most probes are defined in code and are therefore not directly discoverable.

繰り返しプローブの基本事項は次のとおりです。すべてのRecurrenceIntervalSecondsを開始して、正常性のいくつかの側面をチェック (またはプローブ) します。The basics of a recurrent probe are as follows: start every RecurrenceIntervalSeconds and check (or probe) some aspect of health. コンポーネントが正常な状態であれば、プローブが合格し、\ProbeResult チャネルに情報イベントを書き込み、 ResultTypeは3になります。If the component is healthy, the probe passes and writes an informational event to the Microsoft.Exchange.ActiveMonitoring\ProbeResult channel with a ResultType of 3. チェックに失敗するかタイムアウトした場合、プローブは失敗し、同じチャネルにエラーイベントを書き込みます。If the check fails or times out, the probe fails and writes an error event to the same channel. Resulttypeが4の場合はチェックに失敗し、 resulttypeが1の場合はタイムアウトになったことを意味します。多くのプローブは、タイムアウトした場合に、 Maxretryattemptsプロパティの値まで再実行されます。A ResultType of 4 means the check failed and a ResultType of 1 means that it timed out. Many probes will re-run if they timeout, up to the value of the MaxRetryAttempts property.


メモProbeResult の提供チャネルチャネルは、数分の数百のプローブを使用してイベントをログに記録することができます。そのため、運用環境でイベントログに対してコストのかかるクエリを実行しようとすると、Exchange サーバーのパフォーマンスが実際に影響を受ける可能性があります。Note The ProbeResult crimson channel can get very busy with hundreds of probes running every few minutes and logging an event, so there can be a real impact on the performance of your Exchange server if you try expensive queries against the event logs in a production environment.

通知は、Health Manager フレームワークによってではなく、サーバー上の他のサービスによって実行されるプローブです。このサービスは、独自の監視を実施してから、プローブ結果を直接書き込むことによって、そのデータを可用性管理フレームワークにフィードします。このプローブは ProbeDefinition チャネルに表示されません。これは、このチャネルには可用性管理フレームワークによって実行されるプローブしか表示されないためです。たとえば、ServerOneCopyMonitor モニターは、MSExchangeDAGMgmt サービスによって書き込まれたプローブ結果によってトリガーされます。このサービスは、独自の監視を実施して、問題があるかどうかを判断し、プローブ結果をログに記録します。ほとんどの通知プローブは、モニター異常を引き起こす赤色のイベントとモニターを正常に戻す緑色のイベントの両方をログに記録する機能を備えています。Notifications are probes that are not run by the health manager framework, but by some other service on the server. These services perform their own monitoring, and then feed their data into the Managed Availability framework by directly writing probe results. You won't see these probes in the ProbeDefinition channel, as this channel only describes probes that will be run by the Managed Availability framework. For example, the ServerOneCopyMonitor Monitor is triggered by probe results written by the MSExchangeDAGMgmt service. This service performs its own monitoring, determines whether there is a problem, and logs a probe result. Most notification probes have the capability to log both a red event that turns the monitor unhealthy and a green event that makes the monitor healthy again.

チェックは、パフォーマンス カウンターが定義済みのしきい値を上回ったまたは下回ったイベントのみをログに記録するプローブです。実際には、このプローブは通知プローブの特殊なケースであり、サーバー上のパフォーマンス カウンターを監視して、構成済みのしきい値を超えたときに ProbeResult チャネルにイベントを書き込むサービスが存在します。Checks are probes that only log events when a performance counter passes above or below a defined threshold. They are really a special case of notification probes, as there is a service monitoring the performance counters on the server and logging events to the ProbeResult channel when the configured threshold is met.

異常と見なされるカウンターとしきい値を見つけるには、このチェック用のモニターを参照します。To find the counter and threshold that is considered unhealthy, you can look at the monitor for this check. OverallConsecutiveSampleValueAboveThresholdMonitorまたはOverallConsecutiveSampleValueBelowThresholdMonitorの種類のモニターは、監視しているプローブがチェックプローブであることを意味していることを意味しています。Monitors of the type Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor or Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor mean that the probe they watch is a check probe

監視はプローブによって収集されたデータを照会し、事前定義されたルールセットに基づいてアクションを実行する必要があるかどうかを判断します。Monitors query the data collected by probes to determine if action needs to be taken based on a predefined rule set. モニターは、ルールまたは問題の特性に基づいて、レスポンダーを起動するか、問題をイベント ログのエントリを介して人的対応レベルにエスカレートできます。Depending on the rule or the nature of the issue, a monitor can either initiate a responder or escalate the issue to a human via an event log entry. また、モニターは障害発生後のレスポンダーの実行時間や回復操作のワークフローを定義します。In addition, monitors define how much time after a failure that a responder is executed, as well as the workflow of the recovery action. モニターにはさまざまな状態があります。Monitors have various states. システム状態の観点から見ると、モニターの状態は次の 2 つです。From a system state perspective, monitors have two states:

  • 正常: モニターは正常に動作し、収集されたすべての測定値は通常の動作パラメーターの範囲内にあります。Healthy: The monitor is operating properly and all collected metrics are within normal operating parameters

  • 異常: モニターが正常に機能しておらず、レスポンダーを介して回復を開始したか、エスカレーションによって管理者に通知されました。Unhealthy: The monitor isn't healthy and has either initiated recovery through a responder or notified an administrator through escalation.

管理の観点から見ると、上記の状態に加え、シェルに表示されるモニターの状態もあります。From an administrative perspective, monitors have additional states that appear in the Shell:

  • Degraded: モニターが異常な状態 (0 ~ 60 秒) の場合は、低下していると見なされます。Degraded: When a monitor is in an unhealthy state from 0 through 60 seconds, it's considered Degraded. モニターの正常でない状態が 60 秒を超えると、モニターは異常と見なされます。If a monitor is unhealthy for more than 60 seconds, it is considered Unhealthy.

  • Disabled: モニターは管理者によって明示的に無効にされています。Disabled: The monitor has been explicitly disabled by an administrator.

  • 使用不可: Microsoft Exchange Health service は、各モニターの状態を定期的に照会します。Unavailable: The Microsoft Exchange Health service periodically queries each monitor for its state. クエリに対する応答がない場合、モニターの状態は "使用不可能" になります。If it doesn't get a response to the query, the monitor state becomes Unavailable.

  • 修復しています。管理者は、是正措置が人的によって処理されていることをシステムに示すように、修復の状態を設定します。これにより、システムとユーザーは、データベースコピー再シード操作などの、同時に発生する可能性のある他のエラーとの間で、問題を特定できます。Repairing: An administrator sets the Repairing state to indicate to the system that corrective action is in process by a human, which allows the system and humans to differentiate between other failures that may occur at the same time corrective action is being taken (such as a database copy reseed operation).

各モニターの定義には、 SampleMaskプロパティがあります。Every monitor has a SampleMask property in its definition. モニターが実行されると、ProbeResult チャネルで、モニターのSampleMaskに一致するresultnameを持つイベントが検索されます。As the monitor executes, it looks for events in the ProbeResult channel that have a ResultName that matches the monitor's SampleMask. これらのイベントは、反復プローブ、通知、またはチェックで検出されたものです。These events could be from recurrent probes, notifications, or checks. モニターのしきい値に到達すると、異常と見なされます。If the monitor's thresholds are achieved, it becomes Unhealthy. モニターの観点では、3 つすべてのプローブの種類が ProbeResult チャネルに書き込まれる種類と一致します。From the monitor's perspective, all three probe types are the same as they each log to the ProbeResult channel.

1 つのプローブ エラーが必ずしもサーバーに問題があることを示しているわけではないことは注目に値します。It is worth noting that a single probe failure does not necessarily indicate that something is wrong with the server. 修正が必要な実際の問題の存在を正しく特定できるかどうかはモニターの設計にかかっています。It is the design of monitors to correctly identify when there is a real problem that needs fixing. これが、異常と判断するには、多くのモニターで複数のプローブ エラーのしきい値がモニターされる理由です。This is why many monitors have thresholds of multiple probe failures before becoming Unhealthy. さらに、これらの問題の多くは、レスポンダーによって自動的に修正することができます。手動による介入が必要になる問題を探すため\の最適な場所は、「Microsoft office server 管理の監視」の「チャネル」に記載されています。Even then, many of these problems can be fixed automatically by responders, so the best place to look for problems that require manual intervention is in the Microsoft.Exchange.ManagedAvailability\Monitoring crimson channel. このチャネルには、最新のプローブ エラーが含まれています。This will include the most recent probe error.

その名前が示すとおり、レスポンダーは、モニターによって生成された通知に対して何らかの応答を実行します。As their name implies, responders execute some sort of response to an alert that was generated by a monitor. レスポンダーは、アプリケーションのワーカープールをリセットしてサーバーを再起動するなど、さまざまな回復操作を実行します。Responders take a variety of recovery actions, such as resetting an application worker pool to restarting a server. レスポンダーには、さまざまな種類があります。There are several types of responders:

  • 応答側を再起動する: サービスを終了して再起動するRestart Responder: Terminates and restarts a service

  • AppPool のリセットレスポンダー: インターネットインフォメーションサービス (IIS) でアプリケーションプールを停止および再起動します。Reset AppPool Responder: Stops and restarts an application pool in Internet Information Services (IIS)

  • フェールオーバーレスポンダー: データベースまたはサーバーのフェールオーバーを開始します。Failover Responder: Initiates a database or server failover

  • バグチェックレスポンダー: サーバーのバグチェックを開始し、サーバーの再起動を発生させます。Bugcheck Responder: Initiates a bugcheck of the server, thereby causing a server reboot

  • オフラインレスポンダー: サーバー上のプロトコルをサービスから除外する (クライアント要求を拒否する)Offline Responder: Takes a protocol on a server out of service (rejects client requests)

  • オンラインレスポンダー: サーバー上のプロトコルを運用環境に戻します (クライアント要求を受け入れます)。Online Responder: Places a protocol on a server back into production (accepts client requests)

  • エスカレーションレスポンダー: イベントログを介して管理者に問題をエスカレートします。Escalate Responder: Escalates the issue to an administrator via event logging

上記のレスポンダーに加えて、一部のコンポーネントには、コンポーネントに固有の特殊なレスポンダーがあります。In addition to the above listed responders, some components also have specialized responders that are unique to their component.

すべてのレスポンダーには、調整機能が含まれています。この調整機能は、組み込みの優先順位メカニズムを提供してレスポンダーのアクションを制御します。調整機能は、レスポンダーが実行した回復操作の結果として、システムの障害やパフォーマンスの低下が生じないようにするための機能です。すべてのレスポンダーには、何らかの方法で調整が行われます。調整が行われると、レスポンダーのアクションに応じて、回復アクションがスキップされたり、遅延する場合があります。たとえば、バグ チェック レスポンダーで調整が行われると、レスポンダーのアクションはスキップされます。遅延されることはありません。All responders include throttling behavior, which provide a built-in sequencing mechanism for controlling responder actions. The throttling behavior is designed to ensure that the system isn't compromised or made worse as a result of responder recovery actions. All responders are throttled in some fashion. When throttling occurs, the responder recovery action may be skipped or delayed, depending on the responder action. For example, when the Bugcheck Responder is throttled, its action is skipped, and not delayed.

正常性セットHealth Sets

可用性管理をレポートの観点から見ると、正常性には 2 つのビューがあります。1 つは内部ビューで、もう 1 つは外部ビューです。From a reporting perspective, managed availability has two views of health, one internal and one external. 内部ビューでは、正常性セットを使います。The internal view uses health sets. Exchange 2013 の各コンポーネント (たとえば、Outlook Web App、Exchange ActiveSync、インフォメーションストアサービス、コンテンツインデックス、トランスポートサービスなど) は、プローブ、モニター、およびレスポンダーを使用して可用性管理によって監視されます。Each component in Exchange 2013 (for example, Outlook Web App, Exchange ActiveSync, the Information Store service, content indexing, transport services, etc.) is monitored by managed availability using probes, monitors, and responders. 特定のコンポーネントのプローブ、モニター、レスポンダーから成るグループを正常性セットと呼びます。A group of probes, monitors and responders for a given component is called a health set. 正常性セットは、一連のプローブ、モニター、レスポンダーであり、そのコンポーネントが正常かどうかを判断します。A health set is a group of probes, monitors, and responders that determine if that component is healthy. 正常性セットの現在の状態 (たとえば、正常または異常) は、正常性セットのモニターの状態によって判断されます。The current state of a health set (e.g., whether it is healthy or unhealthy) is determined by using the state of the health set's monitors. 正常性セットのすべてのモニターが正常であれば、正常性セットの状態は正常です。If all of a health set's monitors are healthy, then the health set is in a healthy state. いずれかのモニターが異常な状態を示す場合、正常性セットの状態は、最も大きな異常を示すモニターによって判断されます。If any monitor is not in a healthy state, then the health set state will be determined by its least healthy monitor.

サーバーの正常性または正常性セットの状態を表示する詳細な手順については、「Manage health sets and server health」を参照してください。For detailed steps to view server health or health sets state, see Manage health sets and server health.

正常性グループHealth Groups

可用性管理の外部ビューは、正常性グループで構成されます。The external view of managed availability is composed of health groups. Health group は、System Center Operations Manager 2007 R2 および System Center Operations Manager 2012 に公開されます。Health groups are exposed to System Center Operations Manager 2007 R2 and System Center Operations Manager 2012.

主要な正常性グループは、以下の 4 つです。There are four primary health groups:

  • お客様のタッチポイント: プロトコル、インフォメーションストアなど、リアルタイムのユーザー操作に影響を与えるコンポーネントCustomer Touch Points: Components that affect real-time user interactions, such as protocols, or the Information Store

  • サービスコンポーネント: Microsoft Exchange Mailbox Replication サービス、オフラインアドレス帳生成処理 (OABGen) など、直接的なリアルタイムのユーザー操作を伴わないコンポーネント。Service Components: Components without direct, real-time user interactions, such as the Microsoft Exchange Mailbox Replication service, or the offline address book generation process (OABGen)

  • サーバーコンポーネント: サーバーの物理リソース (ディスク領域、メモリ、ネットワークなど)Server Components: The physical resources of the server, such as disk space, memory and networking

  • 依存関係の可用性: Active DIRECTORY、DNS などの必要な依存関係にアクセスするサーバーの機能。Dependency Availability: The server's ability to access necessary dependencies, such as Active Directory, DNS, etc.

Exchange 管理パックをインストールした場合、System Center Operations Manager (SCOM) は、Exchange 環境に関連する情報を参照する正常性ポータルとして機能します。SCOM ダッシュ ボードでは、Exchange サーバーの状態を以下の 3 つのビューで確認できます。When the Exchange Management Pack is installed, System Center Operations Manager (SCOM) acts as a health portal for viewing information related to the Exchange environment. The SCOM dashboard includes three views of Exchange server health:

  • アクティブなアラート: エスカレーションレスポンダーは、SCOM 内でモニターによって使用される Windows イベントログにイベントを書き込みます。Active Alerts: Escalation Responders write events to the Windows event log that are consumed by the monitor within SCOM. これらは [アクティブなアラート] ビューにアラートとして表示されます。These appear as alerts in the Active Alerts view.

  • 組織の正常性: このビューには、Exchange 組織の正常性の全体的な状態のロールアップの概要が表示されます。Organization Health: A rollup summary of the overall health of the Exchange organization health is displayed in this view. これらのロールアップには、個々のデータベース可用性グループの正常性、および特定の Active Directory サイト内の正常性が表示されます。These rollups include displaying health for individual database availability groups, and health within specific Active Directory sites.

  • サーバーの正常性: 関連する正常性セットが正常性グループに統合され、このビューで要約されます。Server Health: Related health sets are combined into health groups and summarized in this view.


管理者はオーバーライドを使って、可用性管理のプローブ、モニター、レスポンダーのいくつかの側面を構成できます。オーバーライドにより、可用性管理で使用するしきい値の一部を調整できます。また、予想外のイベントが発生して既定値とは異なる構成設定が必要となった場合、緊急の処置をとるために使用することもできます。Overrides provide an administrator with the ability to configure some aspects of the managed availability probes, monitors, and responders. Overrides can be used to fine tune some of the thresholds used by managed availability. They can also be used to enable emergency actions for unexpected events that may require configuration settings that are different from the out-of-box defaults.

オーバーライドを作成し、単一のサーバーに適用する (サーバー オーバーライド)、またはサーバーのグループに適用する (グローバル オーバーライド) ことができます。Overrides can be created and applied to a single server (this is known as a server override), or they can be applied to a group of servers (this is known as a global override). サーバー オーバーライドの構成データは、オーバーライドを適用するサーバー上の Windows レジストリに格納されます。Server override configuration data is stored in the Windows registry on the server on which the override is applied. グローバル オーバーライドの構成データは、Active Directory に格納されます。Global override configuration data is stored in Active Directory.

有効期間に制限のないオーバーライド、または特定の期間を対象とするオーバーライドを構成できます。グローバル オーバーライドは、すべてのサーバーに適用するか、特定のバージョンの Exchange を実行しているサーバーのみに適用するように構成できます。Overrides can be configured to last indefinitely, or they can be configured for a specific duration. In addition, global overrides can be configured to apply to all servers, or only servers running a specific version of Exchange.

オーバーライドを構成しても、すぐには有効になりません。Microsoft Exchange Health Manager サービスは、10 分ごとに構成データが更新されたかどうかをチェックします。さらに、グローバル オーバーライドは、Active Directory のレプリケーションの待機時間にも左右されます。When you configure an override, it will not take effect immediately. The Microsoft Exchange Health Manager service checks for updated configuration data every 10 minutes. In addition, global overrides will be dependent on Active Directory replication latency.

サーバーオーバーライドまたはグローバルオーバーライドを表示または構成する詳細な手順については、「 configure managed availability overrides」を参照してください。For detailed steps to view or configure server or global overrides, see Configure managed availability overrides.

管理タスクおよびコマンドレットManagement Tasks and Cmdlets

管理者は通常、可用性管理に関連する 3 つの主要な運用タスクを実行します。There are three primary operational tasks that administrators will typically perform with respect to managed availability:

  • システム正常性の抽出または表示。Extracting or viewing system health

  • 正常性セットの表示、プローブ、モニター、レスポンダーの詳細の表示。Viewing health sets, and details about probes, monitors and responders

  • オーバーライドの管理。Managing overrides

可用性管理の 2 つの主な管理ツールは、Windows イベント ログとシェルです。可用性管理は、Exchange ActiveMonitoring および ManagedAvailability クリムゾン チャネルのイベント ログに、膨大な情報を記録します。次に例を示します。The two primary management tools for managed availability are the Windows Event Log and the Shell. Managed availability logs a large amount of information in the Exchange ActiveMonitoring and ManagedAvailability crimson channel event logs, such as:

  • プローブ、モニター、レスポンダーの定義は、それぞれの *Definition イベント ログに記録されます。Probe, monitor, and responder definitions, which are logged in the respective *Definition event logs.

  • プローブ、モニター、レスポンダーの結果は、それぞれの *Results イベント ログに記録されます。Probe, monitor, and responder results, which are logged in the respective *Results event logs.

  • レスポンダーの回復操作の開始時刻、操作が完了したと見なされる時刻 (成功したかどうかにかかわらず) などを含む回復操作の詳細は、RecoveryActionResults イベント ログに記録されます。Details about responder recovery actions, including when the recovery action is started, and it is considered complete (whether successful or not), which are logged in the RecoveryActionResults event log.

次の表に、可用性管理で使用される 12 個のコマンドレットを示します。There are 12 cmdlets used for managed availability, which are described in the following table.

コマンドレットCmdlet 説明Description


正常性セットとその現在の状態 (正常または異常)、正常性セットのモニター、サーバー コンポーネント、プローブのターゲット リソース、プローブまたはモニターの開始と終了の時間に関するタイムスタンプ、状態遷移時間など、生のサーバーの正常性に関する情報の取得に使用します。Used to get raw server health information, such as health sets and their current state (healthy or unhealthy), health set monitors, server components, target resources for probes, and timestamps related to probe or monitor start or stop times, and state transition times.


正常性セットとその現在の状態を含む正常性の表示の概要を取得に使用します。Used to get a summary health view that includes health sets and their current state.


特定の正常性セットに関連するプローブ、モニター、レスポンダーの表示に使用します。Used to view the probes, monitors, and responders associated with a specific health set.


プローブ、モニター、レスポンダーの一部のプロパティについての説明の表示に使用します。Used to view descriptions about some of the properties of probes, monitors, and responders.


プローブ、モニター、またはレスポンダーのローカルのサーバー固有のオーバーライドの作成に使用します。Used to create a local, server-specific override of a probe, monitor, or responder.


指定されたサーバーのローカル オーバーライドの一覧の表示に使用します。Used to view a list of local overrides on the specified server.


特定のサーバーからのローカル オーバーライドの削除に使用します。Used to remove a local override from a specific server.


サーバー グループのグローバル オーバーライドの作成に使用します。Used to create a global override for a group of servers.


組織内で構成されたグローバル オーバーライドの一覧の表示に使用します。Used to view a list of global overrides configured in the organization.


グローバル オーバーライドの削除に使用します。Used to remove a global override.


1 つ以上のサーバー コンポーネントの状態の構成に使用します。Used to configure the state of one or more server components.


1 つ以上のサーバー コンポーネントの状態の表示に使用します。Used to view the state of one or more server components.