アラートおよび通知

アラートは、Directorのダッシュボードおよびそのほかの概要ビューに、警告および重大アラートシンボルと共に表示されます。アラートは、Premiumライセンスを持つユーザーが使用できます。アラートは、1分ごとに自動的に更新されます。オンデマンドで更新することもできます。

Directorのアラート

警告アラート(黄色の三角形)は、条件の警告しきい値以上になっていることを示します。

重大アラート(赤の円)は、条件の重大しきい値以上になっていることを示します。

サイドバーでアラートを選択して下部にある [アラートに移動] リンクをクリックするか、[Director]ページの上部にある [アラート] を選択すると、アラートに関するさらに詳細な情報を表示できます。

[アラート]ビューで、アラートをフィルターおよびエクスポートできます。たとえば、先月特定のデリバリーグループで失敗したサーバーOSマシンや、特定のユーザーに対するすべてのアラートを特定することができます。詳しくは、「レポートのエクスポート」を参照してください。

アラートのフィルタリング

Citrixアラート

Citrixアラートは、Citrixコンポーネントで発生し、Directorで監視されるアラートです。Citrixアラートは、Director内で[アラート]>[Citrixアラートポリシー]の順に選択して構成できます。この構成では、設定したしきい値を超過した場合のアラートに関して、ユーザーおよびグループにメール送信する通知を設定できます。通知は、Octoblu webhookまたはSNMPトラップとしても構成できます。Citrixアラートのセットアップについて詳しくは、「アラートポリシーの作成」を参照してください。

スマートアラートポリシー

定義済みのしきい値を持つ組み込みアラートポリシーのセットは、デリバリーグループおよびサーバーOS VDAスコープで使用できます。この機能には、Delivery Controllerバージョン7.18以降が必要です。[アラート]>[Citrixアラートポリシー] で、組み込みアラートポリシーのしきい値パラメーターを変更できます。 これらのポリシーは、少なくとも1つのアラートターゲット(サイト内に定義されているデリバリーグループまたはサーバーOS VDA)が存在する場合に作成されます。さらに、これらの組み込みアラートは、新しいデリバリーグループまたはサーバーOS VDAに自動的に追加されます。

Directorとサイトをアップグレードする場合、以前のDirectorインスタンスのアラートポリシーが引き継がれます。対応するアラートルールが監視データベースに存在しない場合にのみ、組み込みアラートポリシーが作成されます。

組み込みアラートポリシーのしきい値については、「アラートポリシーの条件」を参照してください。

組み込みアラート

SCOMアラート

SCOMアラートには、Microsoft System Center 2012 Operations Manager(SCOM)からのアラート情報が表示されます。これにより、Director内のデータセンターの稼働状態およびパフォーマンスがより包括的に示されます。詳しくは、「SCOMアラート統合の構成」を参照してください。

サイドバーを展開する前にアラートアイコンの隣に表示されているアラートの数は、CitrixアラートとSCOMアラートの合計数です。

アラートポリシーの作成

Directorのアラートポリシー

特定のセッション数基準のセットを満たした場合にアラートを生成するなどの目的で、新しいアラートポリシーを作成するには、以下の手順に従います:

  1. [アラート]>[Citrixアラートポリシー]の順に選択し、[サーバーOSポリシー]などを選択します。
  2. [作成] をクリックします。
  3. ポリシーの名前と説明を入力し、アラートをトリガーするために満たす必要がある条件を設定します。たとえば、最大接続済みセッション数、最大切断セッション数、および最大同時セッション数に対して、警告とする数および重大とする数を指定します。警告値を重大値よりも大きくすることはできません。詳しくは、「アラートポリシーの条件」を参照してください。
  4. 再アラート間隔を設定します。アラートの条件が引き続き満たされている場合、アラートはこの間隔で再トリガーされます。アラートポリシーで設定されている場合は、メール通知が生成されます。クリアされたアラートの場合、再アラート間隔でメール通知が生成されることはありません。
  5. スコープを設定します。たとえば、特定のデリバリーグループに対して設定します。
  6. お知らせ設定で、アラートがトリガーされたときのメール通知の送信先を指定します。アラートポリシーでメールお知らせ設定を行うには、[メールサーバーの構成] タブでメールサーバーを指定する必要があります。
  7. [保存] をクリックします。

Octoblu webhook構成について詳しくは、「Octoblu webhookによるアラートポリシーの構成」を参照してください。

SNMPトラップ構成について詳しくは、「SNMPトラップによるアラートポリシーの構成」を参照してください。

スコープに20件以上のデリバリーグループが定義されているポリシーを作成すると、構成が完了するまでにおよそ30秒かかる場合があります。完了するまで、スピナーアイコンが表示されます。

最大20の一意のデリバリーグループに対して、50以上のポリシー(合計で1000デリバリーグループターゲット)を作成すると、応答時間が遅くなることがあります(5秒以上)。

アクティブなセッションがあるマシンをデリバリーグループから別のデリバリーグループに移動すると、マシンパラメーターで定義されたデリバリーグループアラートが誤って発信されることがあります。

アラートポリシーの条件

アラートカテゴリ、アラートを緩和するための推奨アクション、および定義されている場合は組み込みポリシーの条件を以下に示します。組み込みアラートポリシーは、60分のアラートおよび再アラートの間隔で定義されています。

最大接続セッション数

  • Directorセッションの傾向ビューで、最大接続済みセッション数をチェックします。
  • セッションの負荷に対応するのに十分な処理能力があることを確認します。
  • 必要に応じ、マシンを追加します。

最大切断セッション数

  • Directorセッションの傾向ビューで、最大切断セッション数をチェックします。
  • セッションの負荷に対応するのに十分な処理能力があることを確認します。
  • 必要に応じ、マシンを追加します。
  • 必要に応じ、切断されたセッションからログオフします。

最大同時セッション数

  • Directorセッションの傾向ビューで、最大同時セッション数をチェックします。
  • セッションの負荷に対応するのに十分な処理能力があることを確認します。
  • 必要に応じ、マシンを追加します。
  • 必要に応じ、切断されたセッションからログオフします。

CPU使用率の割合

  • CPUを消費しているプロセスやリソースを特定します。
  • 必要に応じてプロセスを終了します。
  • プロセスを終了すると、保存されていないデータは失われます。
  • すべてが想定どおりに機能している場合は、将来的にCPUリソースを追加します。

    注:

    ポリシー設定 [リソースの監視を有効にします] はデフォルトで有効で、VDAがインストールされているマシンのCPUとメモリパフォーマンスカウンターを監視できます。このポリシー設定が無効にされると、CPUとメモリの条件に関するアラートはトリガーされません。詳しくは、「監視のポリシー設定」を参照してください。

    スマートポリシーの条件:

    • スコープ: デリバリーグループ、サーバーOSスコープ
    • しきい値: 警告 - 80%、重大 - 90%

メモリ

メモリ使用率の割合。

  • メモリを消費しているプロセスやリソースを特定します。
  • 必要に応じてプロセスを終了します。プロセスを終了すると、保存されていないデータは失われます。
  • すべてが想定どおりに機能している場合は、将来的にメモリを追加します。

    注:

    ポリシー設定 [リソースの監視を有効にします] はデフォルトで有効で、VDAがインストールされているマシンのCPUとメモリパフォーマンスカウンターを監視できます。このポリシー設定が無効にされると、CPUとメモリの条件に関するアラートはトリガーされません。詳しくは、「監視のポリシー設定」を参照してください。

    スマートポリシーの条件:

    • スコープ: デリバリーグループ、サーバーOSスコープ
    • しきい値: 警告 - 80%、重大 - 90%

接続エラー率

過去1時間の接続エラーの率。

  • 接続の合計試行回数に対する合計エラー数の割合に基づいて計算されます。
  • Director接続エラーの傾向ビューで、構成ログから記録されたイベントをチェックします。
  • アプリケーションまたはデスクトップにアクセスできるかどうかを確認します。

接続エラー数

過去1時間の接続エラー数。

  • Director接続エラーの傾向ビューで、構成ログから記録されたイベントをチェックします。
  • アプリケーションまたはデスクトップにアクセスできるかどうかを確認します。

ICA RTT(平均)

平均ICA往復時間

  • Citrix ADMでICA RTTのブレークダウンをチェックして、原因を特定します。詳しくは、Citrix ADMのドキュメントを参照してください。
  • Citrix ADMが利用可能でない場合は、[Directorのユーザー詳細]ビューでICA RTTおよび遅延をチェックして、これがネットワークの問題か、それともアプリケーションやデスクトップの問題かを特定します。

ICA往復時間(セッション数)

ICA往復時間を超過しているセッションの数。

  • Citrix ADMで、ICA RTTが高いセッションの数をチェックします。詳しくは、Citrix ADMのドキュメントを参照してください。
  • Citrix ADMが利用可能でない場合は、ネットワークチームと協力して原因を特定してください。

    スマートポリシーの条件:

    • スコープ: デリバリーグループ、サーバーOSスコープ
    • しきい値: 警告 - 5つ以上のセッションで300ms、重大 - 10以上のセッションで400ms

ICA RTT(セッションの割合)

平均ICA往復時間を超過しているセッションの割合。

  • Citrix ADMで、ICA RTTが高いセッションの数をチェックします。詳しくは、Citrix ADMのドキュメントを参照してください。
  • Citrix ADMが利用可能でない場合は、ネットワークチームと協力して原因を特定してください。

ICA RTT(ユーザー)

特定のユーザーによって開始されたセッションに適用されたICA往復時間。1つ以上のセッションでICA RTTがしきい値よりも高い場合は、アラートがトリガーされます。

失敗したマシン(デスクトップOS)

失敗したデスクトップOSマシンの数。Directorの[ダッシュボード]ビューおよび[フィルター]ビューに表示されるように、失敗はさまざまな理由で発生することがあります。

  • Citrix Scout診断を実行して、原因を特定します。詳しくは、「ユーザーの問題のトラブルシューティング」を参照してください。

    スマートポリシーの条件:

    • スコープ: デリバリーグループスコープ
    • しきい値: 警告 - 1、重大 - 2

失敗したマシン(サーバーOS)

失敗したサーバーOSマシンの数。Directorの[ダッシュボード]ビューおよび[フィルター]ビューに表示されるように、失敗はさまざまな理由で発生することがあります。

  • Citrix Scout診断を実行して、原因を特定します。

    スマートポリシーの条件:

    • スコープ: デリバリーグループ、サーバーOSスコープ
    • しきい値: 警告 - 1、重大 - 2

平均ログオン処理時間

過去1時間に行われたログオンの平均ログオン処理時間。

  • Directorのダッシュボードをチェックし、ログオン処理時間に関する最新の測定基準を取得します。短時間のうちに多数のユーザーがログインするとログオン処理時間が長引くことがあります。
  • 原因を絞り込むため、ログオンのベースラインおよび内訳をチェックします。詳しくは、「ユーザーログオンの問題の診断」を参照してください。

    スマートポリシーの条件:

    • スコープ: デリバリーグループ、サーバーOSスコープ
    • しきい値: 警告 - 45秒、重大 - 60秒

ログオン処理時間(ユーザー)

過去1時間に行われた指定されたユーザーのログオンに関するログオン処理時間。

負荷評価基準インデックス

過去5分間の負荷評価基準インデックスの値。

  • Directorで、ピーク負荷(最大負荷)に達している可能性があるサーバーOSマシンをチェックします。ダッシュボード(失敗)および負荷評価基準インデックス傾向レポートを表示します。

    スマートポリシーの条件:

    • スコープ: デリバリーグループ、サーバーOSスコープ
    • しきい値: 警告 - 80%、重大 - 90%

ハイパーバイザーアラートの監視

Directorでは、 ハイパーバイザーの正常性を監視するアラートが表示されます。Citrix HypervisorとVMware vSphereのアラートは、ハイパーバイザーのパラメーターと状態を監視するのに役立ちます。ハイパーバイザーへの接続状態も監視され、クラスターまたはホストのプールが再起動された場合、または使用できなくなった場合にアラートが出されます。

ハイパーバイザーアラートを受信するには、Citrix Studioでホスト接続が作成されている必要があります。詳しくは、「接続およびリソース」を参照してください。ハイパーバイザーアラートではこれらの接続のみが監視されます。次の表に、ハイパーバイザーアラートのさまざまなパラメーターと状態を示します。

アラート サポートされるハイパーバイザー トリガー元 条件 構成
CPU使用率 Citrix Hypervisor、VMware vSphere ハイパーバイザー CPU使用率アラートしきい値に達しているか、超過している アラートしきい値は、ハイパーバイザーで設定する必要があります。
メモリ使用率 Citrix Hypervisor、VMware vSphere ハイパーバイザー メモリ使用率アラートしきい値に達しているか、超過している アラートしきい値は、ハイパーバイザーで設定する必要があります。
ネットワーク使用状況 Citrix Hypervisor、VMware vSphere ハイパーバイザー ネットワーク使用率アラートしきい値に達しているか、超過している アラートしきい値は、ハイパーバイザーで設定する必要があります。
ディスク使用率 VMware vSphere ハイパーバイザー ディスク使用率アラートしきい値に達しているか、超過している アラートしきい値は、ハイパーバイザーで設定する必要があります。
ホスト接続や電源の状態 VMware vSphere ハイパーバイザー ハイパーバイザーホストが再起動されたか、または利用できない アラートはVMware vSphereにあらかじめ組み込まれています。追加の構成は必要ありません。
使用不可のハイパーバイザー接続 Citrix Hypervisor、VMware vSphere Delivery Controller ハイパーバイザー(プールまたはクラスター)への接続が失われるか、電源がオフになるか、再起動されます。このアラートは、接続が利用できない間、1時間ごとに生成されます。 アラートはDelivery Controllerにあらかじめ組み込まれています。追加の構成は必要ありません。

注:

アラートの構成について詳しくは、「XenCenterアラート」または「VMware vCenterアラート」を参照してください。

メール通知設定は、[Citrixアラートポリシー]>[サイトポリシー]>[ハイパーバイザーの正常性]から設定できます。Hypervisorのアラートポリシーのしきい値条件は、Directorからではなくハイパーバイザーからのみ設定、編集、無効化、または削除できます。ただし、メール設定の変更とアラートの解除はDirectorで行うことができます。

重要:

  • アラートはHypervisorにより取得され、Directorに表示されます。ただし、Hypervisorのアラートのライフサイクルや状態に対する変更は、Directorには反映されません。
  • 正常状態のアラートやHypervisorコンソールで破棄または無効化したアラートであっても、Directorには表示され続けるため、Directorで明示的に破棄する必要があります。
  • アラートをDirectorで破棄しても、Hypervisorコンソールで自動的に破棄されることはありません。

ハイパーバイザーアラートフィルター

ハイパーバイザーアラートのみをフィルタリングできるように、「ハイパーバイザーの正常性」という新しいアラートカテゴリが追加されました 。これらのアラートは、しきい値に達するか超過すると表示されます。ハイパーバイザーのアラートには次のものがあります:

  • 重大—ハイパーバイザーアラームポリシーの重大しきい値に達したか超過した
  • 警告—ハイパーバイザーアラームポリシーの警告しきい値に達したか超過した
  • 解除—アラートはアクティブなアラートとして表示されなくなる

ハイパーバイザーのアラート表示

この機能の使用には、Delivery Controllerバージョン7 1811以降が必要です。サイトの7 1811以降で古いバージョンのDirectorを使用している場合は、ハイパーバイザーアラート数のみが表示されます。アラートを表示するには、Directorをアップグレードする必要があります。

Octoblu webhookによるアラートポリシーの構成

注:

2017年11月29日で、Citrixは無料のOctoblu.comクラウドサービスを終了しました。そのため、OctobluとDirectorの統合を中止することをお勧めします。Octoblu.comの終了に関するCitrixの発表について詳しくは、ブログ「The Future of Octoblu and Citrix Workspace IoT」を参照してください。

IoTサービスを開始するためのOctoblu webhookを使用するアラートポリシーの構成この機能の使用には、Delivery Controllerバージョン7.11以降が必要です。

アラートを使用したIoTサービスの例としては、SMS通知の送信によるスタッフのサポートや、カスタムインシデント解決プラットフォームとの統合による追跡通知の支援などがあります。

PowerShellコマンドレットを使用して、HTTPコールバックまたはHTTP POSTでアラートポリシーを構成できます。webhooksのサポートのために拡張されます。

新しいOctobluワークフローの作成および対応するwebhook URLの取得について詳しくは、『Octoblu Developer Hub』を参照してください。

新しいアラートポリシーや既存のポリシーに対してOctoblu webhook URLを構成するには、次のPowerShellコマンドレットを使用します。

webhook URLで新しいアラートポリシーを作成する場合:

$policy = New-MonitorNotificationPolicy -Name <Policy name> -Description <Policy description> -Enabled $true -Webhook <Webhook URL>

既存のアラートポリシーにwebhook URLを追加する場合:

Set-MonitorNotificationPolicy - Uid <Policy id> -Webhook <Webhook URL>

PowerShellコマンドのヘルプについては、たとえば次のようにPowerShellヘルプを使用します:

Get-Help  <Set-MonitorNotificationPolicy>

PowerShellを使用した通知ポリシーの構成について詳しくは、「Director 7.7: PowerShellを使用したアラートと通知の管理と構成」を参照してください。

アラートポリシーから生成された通知によって、webhook URLへのPOSTコールでwebhookがトリガーされます。POSTメッセージには通知の情報がJSON形式で含まれます:

{"NotificationId" : <Notification Id>,

"Target" : <Notification Target Id>,

"Condition" : <Condition that was violated>,

"Value" : <Threshold value for the Condition>,

"Timestamp": <Time in UTC when notification was generated>,

"PolicyName": <Name of the Alert policy>,

"Description": <Description of the Alert policy>,

"Scope" : <Scope of the Alert policy>,

"NotificationState": <Notification state critical, warning, healthy or dismissed>,

"Site" : <Site name>}

SNMPトラップによるアラートポリシーの構成

SNMPトラップを構成されたアラートがトリガーされると、対応するSNMPトラップメッセージが構成済みのネットワークリスナーに転送され、さらに処理されます。Citrixアラートは、SNMPバージョン2以降のトラップをサポートします。現時点では、トラップメッセージを1つのリスナーに転送できます。

注:

この機能には、Delivery Controllerバージョン7.12 以降が必要です。

SNMPトラップを構成するには、以下のPowerShellコマンドレットを使用します:

  • 現時点のSNMPサーバー構成を取得する:

    Get-MonitorNotificationSnmpServerConfiguration
    
  • SNMPバージョン2のサーバー構成を設定する:

    Set-MonitorNotificationSnmpServerConfiguration -ServerName <Server IP> -PortNumber <Port ID> -SnmpSender <Sender name> -CommunityString public -Protocol V2
    
  • SNMPバージョン3のサーバー構成を設定する:

     $authpass = "<authentication password>" | ConvertTo-SecureString -AsPlainText -Force
     $privpass = "<Privacy password>" | ConvertTo-SecureString -AsPlainText -Force
     Set-MonitorNotificationSnmpServerConfiguration -ServerName <Server IP> -PortNumber <Port ID> -SnmpSender <Sender name> -EngineId <Engine Id> -AuthPassword $authpass -PrivPassword $privpass -PrivPasswordProtocol <Privacy password protocol> -AuthPasswordProtocol <Authentication password protocol> -Protocol V3
    
  • 既存のアラートポリシーにSNMPトラップを有効化する:

    Set-MonitorNotificationPolicy -IsSnmpEnabled $ true -Uid <PolicyID>
    
  • SNMPトラップ構成を持つ新しいアラートポリシーを作成する:

    $policy = New-MonitorNotificationPolicy -Name <Policy name> -IsSnmpEnabled $true -Description <Policy description> -Enabled $true
    

DirectorからのSNMPトラップメッセージ内のOIDの構造は以下のようになります: 1.3.6.1.4.1.3845.100.1.<UID> <UID>はDirectorに定義されたすべてのアラートポリシーに対して順次生成されます。そのため、OIDはユーザー環境ごとに一意です。

  • 1.3.6.1.4.1.3845.100.1 を使用すると、Directorからのすべてのトラップメッセージがフィルタリングされます。
  • 1.3.6.1.4.1.3845.100.1.<UID>を使用すると、特定のアラートのトラップメッセージがフィルタリングされ、処理されます。

以下のコマンドレットを使用すると、ご使用の環境に定義されたアラートポリシーのUIDを取得できます:

Get-MonitorNotificationPolicy

SNMPトラップはSCOMに転送できます。それには、SCOMをDelivery Controllerとともに構成してトラップメッセージをリスンします。

SCOMアラート統合の構成

DirectorとのSCOM統合により、SCOMからのアラート情報を、Directorのダッシュボードおよびそのほかの概要ビューで表示できるようになります。

SCOMアラートは、Citrixアラートと共に画面上に表示されます。SCOMアラートには、サイドバーの[SCOM]タブからアクセスしてドリルダウンすることができます。

1か月前までの過去のアラートを表示し、情報を並べ替えてフィルターし、フィルターされた情報をCSV、Excel、およびPDFレポート形式にエクスポートすることができます。詳しくは、「レポートのエクスポート」を参照してください。

SCOM統合では、リモートPowerShell 3.0以降を使用してSCOM管理サーバーのデータをクエリし、ユーザーのDirectorセッションで永続的な実行空間接続を維持します。DirectorおよびSCOMサーバーのPowerShellバージョンが同じである必要があります。

SCOMコンポーネント図

SCOM統合の要件は、以下のとおりです:

  • Windows Server 2012 R2
  • System Center 2012 R2 Operations Manager
  • PowerShell 3.0以上(DirectorおよびSCOMサーバーのPowerShellバージョンは一致する必要があります)
  • クアッドコアCPUと16GBのRAM(推奨)
  • SCOMのプライマリ管理サーバーは、Directorのweb.configファイルで構成する必要があります。この処理は、DirectorConfigツールを使用して実行できます。

注:

  • Director管理者アカウントをSCOMオペレーターの役割として構成することをお勧めします。これにより、管理者がDirectorで完全なアラート情報を取得できるようになります。そのように構成できない場合、DirectorConfigツールを使用してSCOM管理者アカウントをweb.configファイルに構成できます。
  • 最適なパフォーマンスのために、構成するDirector管理者の数は、1つのSCOM管理サーバーにつき10人以下とすることをお勧めします。

Directorサーバーで、以下を実行します:

  1. コマンド Enable-PSRemoting を実行して、PowerShellリモート処理を有効にします。

  2. SCOM管理サーバーをTrustedHosts一覧に追加します。PowerShellプロンプトを開いて、次のコマンドを実行します:

    • 最新のTrustedHosts一覧を取得します。

      Get-Item WSMAN:\localhost\Client\TrustedHosts

    • SCOM管理サーバーのFQDNを、TrustedHostsの一覧に追加します。<Old Values>は、Get-Itemコマンドレットから返された既存エントリのセットを表します。

      Set-Item WSMAN:\localhost\Client\TrustedHosts -Value “<FQDN SCOM Management Server>,<Old Values>”

  3. DirectorConfigツールを使用して、SCOMを構成します。

    C:\inetpub\wwwroot\Director\tools\DirectorConfig.exe /configscom

SCOM管理サーバーで、以下を実行します:

  1. SCOM管理者の役割に、Director管理者を割り当てます。

    1. SCOM管理コンソールを開き、[管理]>[セキュリティ]>[ユーザーロール] の順に選択します。

    2. [ユーザーロール]では、新しいユーザー役割を作成するか、または既存のユーザー役割を変更することができます。SCOMデータへのアクセス方法を定義するSCOMオペレーターの役割には4つのカテゴリがあります。たとえば、読み取り専用の役割には、[管理]ペインが表示されず、規則、マシン、アカウントを検出または管理することができません。オペレーターの役割は、すべての管理権限を実行できる管理者の役割です。

      注:

      Director管理者がオペレーター以外の役割に割り当てられている場合、以下の操作を実行できません:

      • 複数の管理サーバーが構成されており、プライマリ管理サーバーを利用できない場合、Director管理者はセカンダリ管理サーバーに接続できません。プライマリ管理サーバーはDirectorのweb.configファイルで構成されるサーバーであり、前述の手順3でDirectorConfigツールで指定されたサーバーです。セカンダリ管理サーバーは、プライマリサーバーのピア管理サーバーです。
      • アラートのフィルター時に、Director管理者はアラートソースを検索できません。検索するには、オペレーターレベルの権限が必要です。
    3. ユーザー役割を変更するには、役割を右クリックし、[プロパティ]をクリックします。

    4. [ユーザーロールのプロパティ]ダイアログで、指定したユーザー役割にDirector管理者を追加するか、またはそこからDirector管理者を削除することができます。

  2. Director管理者を、SCOM管理サーバーの[Remote Management Users]グループに追加します。これにより、Director管理者がリモートPowerShell接続を確立できるようになります。

  3. コマンド Enable-PSRemoting を実行して、PowerShellリモート処理を有効にします。

  4. WS-Managementプロパティ制限を設定します:

    1. MaxConcurrentUsersの変更:

      CLI:

      winrm set winrm/config/winrs @{MaxConcurrentUsers = "20"}

      PS:

      Set­-Item WSMan:\localhost\Shell\MaxConcurrentUsers 20

    2. MaxShellsPerUserの変更:

      CLI:

      winrm set winrm/config/winrs @{MaxShellsPerUser="20"}

      PS:

    Set-Item WSMan:\localhost\Shell\MaxShellsPerUser 20

    1. MaxMemoryPerShellMBの変更:

      CLI:

      winrm set winrm/config/winrs @{MaxMemoryPerShellMB="1024"}

      PS:

    Set­-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1024

  5. SCOM統合が混在ドメイン環境で機能するよう、以下のレジストリエントリを設定します。

パス:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

値の名前:LocalAccountTokenFilterPolicy

種類:REG_DWord

値のデータ:1

注意: レジストリエディターの使用を誤ると、深刻な問題が発生する可能性があり、Windowsの再インストールが必要になる場合もあります。レジストリエディターの誤用による障害に対して、シトリックスでは一切責任を負いません。レジストリエディターは、お客様の責任と判断の範囲でご使用ください。また、レジストリファイルのバックアップを作成してから、レジストリを編集してください。

SCOM統合がセットアップされると、メッセージ「Cannot get the latest SCOM alerts. View the Director server event logs for more information」が表示されることがあります。サーバーイベントログを使用して問題を特定し、解決することができます。次の原因が考えられます。

  • DirectorまたはSCOMマシンで、ネットワーク接続が失われた。
  • SCOMサービスが利用できないか、ビジー状態のため応答していない。
  • 構成したユーザーの権限が変更されていたため、認証に失敗した。
  • SCOMデータの処理中に、Directorでエラーが発生した。
  • DirectorとSCOMサーバーのバージョンが不一致。