次の方法で共有

新しいセルフサービス ポータルのデプロイとインストールに関する問題のトラブルシューティングについて説明します

  • [アーティクル]

新しいセルフサービス ポータルは、MVC Razor ベースの HTML5 Web アプリ ASP.NET です。 インストール中、Web アプリは、Service Manager サーバー ブラウザーで実行されている SDK サービスに直接接続するように構成されます。 新しく構成された基本的なセルフサービス ポータルの設定は、次の図に示すように動作します。

sm-ssp-scenario-01 の図。

コンポーネント間のデータ フローのシーケンスを次に示します。

  1. ユーザーはブラウザーで Web アプリの URL を入力して、セルフサービス ポータルにアクセスします。

  2. ASP.NET は、ユーザーの新しいインスタンスを作成し、インストール時にユーザーのコンテキストで提供される SDK サービスへのコンテンツを試みます。

  3. SDK サービスは、Service Manager データベースのデータの読み取り、書き込みを行います。

展開の準備をする

展開の準備を行うには、次のセクションを確認してください。

Note

プライマリ管理サーバーと同じサーバーにセルフサービス ポータルをインストールすることはお勧めしません。

ハードウェア要件

Service Manager サーバー プロセッサ (最小値) プロセッサ (推奨値) RAM (最小値) RAM (推奨値) ハード ドライブの領域 (最小値) ハード ドライブの領域 (推奨値)
セルフサービス ポータル + セカンダリ Service Manager (推奨*) 8 コア 2.66 GHz CPU 8 コア 2.66 GHz CPU 16 GB 32 GB 80 GB 80 GB
セルフサービス ポータル (スタンドアロン) 4 コア 2.66 GHz CPU 8 コア 2.66 GHz CPU 8 GB 16 GB 80 GB 80 GB

*上記の要件は、許容される応答時間内 (平均読み取り操作 3 秒未満、書き込み操作 5 秒未満で、読み取り/書き込み比率は 80:20) で 500 人のユーザーへの同時アクセスを提供します。 さらに大規模な展開については、次の「 Deploying a Web Farm 」セクションを参照してください。

サポートされるオペレーティング システム

  • Windows Server 2016

  • Windows Server 2012 R2

  • Windows Server 2019

  • Windows Server 2016

  • Windows Server 2022

  • Windows Server 2019

サポートされている Web ブラウザー

セルフサービス ポータルには、1024 x 768 を超える画面解像度が必要です。 これは、次のブラウザーでサポートされています。

  • Microsoft Edge

  • Microsoft Internet Explorer 10 および 11

  • Mozilla Firefox 42 以降

  • Google Chrome 46 以降

新しいセルフサービス ポータルをデプロイする

新しいセルフサービス ポータルをデプロイする方法の詳細については新しいセルフサービス ポータルのデプロイに関する記事を参照してください。 次のセクションでは、展開に関する重要な考慮事項について概説します。

ポータルを既定の Web サイトとしてインストールする

新しいセルフサービス ポータルをポート 80 にインストールする場合は、最初に IIS の既定の Web サイトを別のポートに移動する必要があります。たとえば、ポート 8080 を使用し、セルフサービス ポータルをポート 80 に移動します。

SSL を使用する

SSL は、特にユーザー名とパスワードがプレーンテキストでネットワーク経由で転送される場合に基本認証を使用する場合に、セキュリティで保護された通信を確保するために推奨されます。

展開トポロジ

セルフサービス ポータルには、次のデプロイ トポロジを使用できます。

単一サーバー (推奨) - セルフサービス ポータルと同じサーバー上の Service Manager サーバー

このトポロジでは、新しいセルフサービス ポータルと管理サーバーの役割の両方が同じサーバーにインストールされます。 ポータルと SDK サービスの間のネットワーク遅延が発生しないため、これは推奨トポロジです。 さらに、プライマリ サーバーで実行されているワークフローによるパフォーマンスの低下を回避するために、セカンダリ サービス管理サーバーにセルフサービス ポータルをインストールすることをお勧めします。

sm-ssp-scenario-02 の図。

このトポロジでは、Windows 認証 (既定で構成済み) を使って、SSL 使用のオーバーヘッドなしでセキュリティで保護された認証を提供します。

スタンドアロン のセルフサービス ポータルのデプロイ

このトポロジでは、セルフサービス ポータルに Service Manager 管理サーバーの役割がインストールされていないサーバーがインストールされます。

sm-ssp-scenario-03 の図。

この構成では、新しいセルフサービス ポータルとセカンダリ サービス マネージャー サーバーが異なるサーバーにインストールされ、Web アプリから SDK サービスへの接続を作成するにはホップが必要です。 この場合、Windows 認証は使用できません。また、 Basic 認証を使用するようにポータルを構成する必要があります。 基本認証は本質的に安全ではないので、ファイアウォールやプロキシ サーバー以外のリソースへのアクセスなど、デプロイのセキュリティの問題を回避するために SSL を使用することをお勧めします。 ダブルホップ シナリオ 基本認証の追加の詳細を参照してください。

SSL を使用すると、ポータルと SDK サービスの間にネットワーク遅延が発生します。したがって、この構成は、1 台のサーバーの展開トポロジに比べると低速ですが、 ただし、この構成は、ダブルホップを回避できないデプロイ シナリオに役立ちます。

Web ファームのデプロイ

新しいセルフサービス ポータルの主な利点の 1 つは、Web アプリにキャッシュ以外のローカル データ ストレージがないという点です。 このサービスでは、Service Manager データベースで読み取りと書き込みを直接行います。 これにより、Web サーバーの複数のインスタンスを並列にデプロイしやすくなります。 ポータルに並列でアクセスするユーザーが 1,000 人を超える大規模なデプロイの場合は、次の構成と同様に新しいセルフサービス ポータルを Web ファームとしてデプロイできます。

sm-ssp-scenario-04 の図。

Web ファームでは、セルフサービス ポータルに対する高可用性が実現します。 内部的には、Web アプリによって SDK サービスへの WCF 接続が確立されます。 初期接続の作成には時間がかかるため、理想的なシナリオは、ユーザーが最初に接続する WebServer が後続のすべての要求を処理して、より迅速に対応することです。 IIS でこのように構成するには、ARR 設定で クライアント アフィニティ を有効にする必要があります。

セットアップに関する問題のトラブルシューティング

次のトラブルシューティング セクションは、一般的な問題を解決するのに役立ちます。

IIS がインストールされていない

サーバーで IIS が有効になっていても、[構成] ページには、IIS の役割エラーが表示されます。

sm-ssp-scenario-05 の図。

これは、管理者の資格情報を使用せずにインストーラーを起動したときに発生します。 その結果、インストーラーは IIS 構成設定にアクセスできません。

解決方法: SetupWizard.exe を管理者として実行します。 SetupWizard を右クリックし、[管理者として実行] を選択できます。

新しいセルフサービス ポータルのトラブルシューティング

このセクションでは、新しいセルフサービス ポータルをインストールした後に発生する可能性がある問題のトラブルシューティング方法について説明します。

IIS 設定

次のポータルの既定の設定は、インストール中に構成されます。

アプリケーション プール

クラシック モードで .NET CLR バージョン 4 で実行するように構成されています。

sm-ssp-scenario-06 の図。

詳細設定では、アプリケーション プールは、インストール時に指定されるサービス アカウントで実行されるように構成されます。 そのユーザーには、Service Manager と、それが実行されるローカル コンピューターにおける管理者特権が必要です。

sm-ssp-scenario-07 の図。

Web サイトの構成

偽装 と Windows 認証 のみを有効にする必要があります。 他の設定はすべて無効にします。

sm-ssp-scenario-08 の図。

偽装については、 [認証されたユーザー] を選択します。

sm-ssp-scenario-09 の図。

Windows 認証の設定:

sm-ssp-scenario-10 の図。

Web サイトの既定のドキュメントは index.cshtmlにします。

sm-ssp-scenario-11 の図。

基本認証

ダブルホップ シナリオでは、Windows 認証は機能しません。無効にする必要があります。 基本認証を有効にして構成します。

sm-ssp-scenario-12 の図。

トレースを有効にする

次の手順を使用して、トレースを有効にします。

手順 1. web.config ファイルに次の設定を追加して、イベント ログの生成を有効にします。

<system.web>  
   .....  
   <trace enabled="true"/>  
   ...  
</system.web>

手順 2. web.config ファイルに次のセクションを追加して、ファイルに出力を転送します。

<system.diagnostics>  
    <trace autoflush="true">  
      <listeners>  
        <add name="myListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="c:\logs\SSPOutput.log" />    
      </listeners>  
    </trace>  
</system.diagnostics>

Web アプリはログオンしているユーザーのコンテンツで実行されるため、ログ フォルダー内のすべてのユーザーに書き込みアクセス許可を付与してください。 たとえば、上の例の中の c:\logs です。

IIS のデバッグ

IIS では、IIS の問題をデバッグするための効率的なログ機能がサポートされています。 詳細については、「 IIS Logging Overview」を参照してください。

デプロイに関する問題のトラブルシューティング

次のセクションを使用して、影響を受ける可能性のあるデプロイの問題をトラブルシューティングします。

定義の変更 (お知らせ/要求内容/サービス内容/ナレッジ記事) は表示されません

新しいセルフサービス ポータルでは、キャッシュ メカニズムを使用して静的データを格納し、高速な応答時間を提供します。 キャッシュ タイムアウトは、既定では 30 分に設定されていますが、この時間は変更できます。 詳細については、「 Deploy the New Self-Service Portal 」の基本的なカスタマイズに関するセクションを参照してください。 キャッシュがクリアされるまで、アナウンス、要求オファリング、サービスオファリング、ナレッジ記事の定義に対する変更は表示されません。

メモリ キャッシュは .NET Framework の MemoryCacheに基づいて使用されます。 キャッシュされたコンテンツは、IIS ワーカー プロセスが終了するまでメモリに残ります。 IIS は古いプロセスを削除し、新しいプロセスを開始しないため、IIS を再起動しても役に立ちません。 代わりに IIS は、既存のプロセスを再利用します。 読み取りを強制的に更新し、キャッシュ データを削除するには、インスタンスに関連付けられている IIS ワーカー プロセスを特定し、IIS を再起動する前に [タスクの終了] を選択します。

IIS ワーカー プロセスを示すスクリーンショット。

[自分の要求] セクションと [個人用アクティビティ] セクションが空です

新しい型プロジェクションは、インストーラーの一部である Portal.mpb ファイルに含まれており、Service Manager にインポートする必要があります。 インポートするには、次の手順を使用します。

  1. 管理サーバー上に Portal.mpb ファイルをインポートします。

  2. ポータルが接続されている管理サーバーで、SDK サービスを再起動します。

Internet Explorer の [セキュリティ強化の構成] 設定が有効になっている場合、ポータルの参照中に、各ページで次のポップアップが表示されます。

Internet Explorer のポップアップを示すスクリーンショット。

上記のポップアップは、テレメトリ データを収集するためにセルフサービス ポータルに統合された App Insights JavaScript SDK 用に表示されます。 製品利用統計情報データの送信を無効にするには、EnableTelemetry 構成パラメーターの値を変更します。これにより、ポップアップが表示されなくなります。 詳細については、「 Deploy the New Self-Service Portal 」の基本的なカスタマイズに関するセクションを参照してください。

IIS をホストするコンピューター上のポータルにアクセスできますが、リモート コンピューターからはアクセスできません

この問題は、ポータルと SDK サービスが異なるコンピューター (スタンドアロンのセルフサービス ポータルの展開) にある場合に発生する可能性があります。 これは、リモート コンピューターからポータルにアクセスしようとする際に、ダブル ホップ シナリオの原因になります。 そのため、 Windows 認証 で説明されている既定のポータル構成は機能しません。 この問題を解決するには、代わりに Basic Authentication 構成を使用します。

ポータルに一部のサービス オファリングまたは公開されたサービス オファリングが表示されない

これは、サービス オファリングが次のいずれかの条件を満たしている場合にのみ表示されるためです。

  • サービス内容が、ブラウザーの言語、またはポータル言語セレクター一致で選択された言語と一致する。

  • サービス内容で、言語が選択されていない。

    空白の言語を示すスクリーンショット。

    英語を示すスクリーンショット。

ポータルでサポートされている言語コードを含む言語の一覧を次に示します。

  • en-US: 英語

  • fr-FR: français

  • de-DE: Deutsch

  • cs-CZ: čeština

  • da-DK: Dansk

  • el-GR: Ελληνιεά

  • es-ES: español

  • fi-FI: suomi

  • hu-HU: magyar

  • it-IT: italiano

  • ja-JP: 日本語

  • ko-KR: 한국어

  • nb-NO: norsk

  • nl-NL: Nederlands

  • pl-PL: polski

  • pt-BR: português (Brasil)

  • pt-PT: português (ポルトガル)

  • ru-RU: русский

  • sv-SE: svenska

  • tr-TR: Türkçe

  • zh-CHS: 中文(简体)

  • zh-TW: 中文(简体)

  • zh-HK: 中文 (香港特別行政區)

アイテムの時刻表示は常に AM を示します

この問題を解決するには、次のファイルで「utc-date」タグを見つけ、DateTime.Parse(xyz).ToString("yyyy,M,d,h,m,s") を DateTime.Parse(xyzToString("yyyy,M,d,H,m,s") に置き換えます。

  • Views\KnowledgeBase\Article.cshtml

  • Views\MyActivities\ActivityDetails.cshtml

  • Views\MyRequests\RequestDetails.cshtml

  • Views\Shared\_Layout.cshtml

次のステップ