新しい Self-Service ポータルの展開とインストールに関する問題のトラブルシューティングについて説明します
重要
このバージョンのService Managerはサポート終了に達しました。 Service Manager 2022 にアップグレードすることをお勧めします。
新しい Self-Service ポータルは、MVC Razor ベースの HTML5 Web アプリ ASP.NET です。 インストール中、Web アプリは、Service Manager サーバー ブラウザーで実行されている SDK サービスに直接接続するように構成されます。 新しく構成された基本的なセルフサービス ポータルの設定は、次の図に示すように動作します。
コンポーネント間のデータ フローのシーケンスを次に示します。
ユーザーはブラウザーで Web アプリの URL を入力して、Self-Service ポータルにアクセスします。
ASP.NET は、ユーザーの新しいインスタンスを作成し、インストール時にユーザーのコンテキストで提供される SDK Service へのコンテンツを試みます。
SDK サービスは、Service Manager データベースのデータの読み取り、書き込みを行います。
展開を準備する
展開の準備を行うには、次のセクションを確認してください。
注意
プライマリ管理サーバーと同じサーバーに Self-Service ポータルをインストールすることはお勧めしません。
ハードウェア要件
Service Manager サーバー | プロセッサ (最小値) | プロセッサ (推奨値) | RAM (最小値) | RAM (推奨値) | ハード ドライブの領域 (最小値) | ハード ドライブの領域 (推奨値) |
---|---|---|---|---|---|---|
Self-Service ポータル + セカンダリ 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 人のユーザーへの同時アクセスを提供します。 大規模なデプロイについては、以下の 「Web ファームのデプロイ 」セクションを参照してください。
サポートされるオペレーティング システム
Windows Server 2016
Windows Server 2012 R2
Windows Server 2019
Windows Server 2016
Windows Server 2022
Windows Server 2019
サポートされている Web ブラウザー
Self-Service ポータルには、1024 x 768 を超える画面解像度が必要です。 これは、次のブラウザーでサポートされています。
Microsoft Edge
Microsoft Internet Explorer 10 および 11
Mozilla Firefox 42 以降
Google Chrome 46 以降
新しい Self-Service ポータルをデプロイする
新しい Self-Service ポータルをデプロイする方法の詳細については、「新しい Self-Service ポータルをデプロイする」の記事を参照してください。 次のセクションでは、展開に関する重要な考慮事項について概説します。
ポータルを既定の Web サイトとしてインストールする
ポート 80 に新しい Self-Service ポータルをインストールする場合は、最初に IIS の既定の Web サイトを別のポートに移動する必要があります。たとえば、ポート 8080-、ポータル Self-Service ポート 80 に移動します。
SSL を使用する
SSL は、特にユーザー名とパスワードがプレーン テキストでネットワーク経由で転送される場合に基本認証を使用する場合に、セキュリティで保護された通信を確保するために推奨されます。
展開トポロジ
Self-Service ポータルには、次のデプロイ トポロジを使用できます。
単一サーバー (推奨) - セルフサービス ポータルと同じサーバー上のService Manager サーバー
このトポロジでは、新しい Self-Service ポータルと管理サーバーの役割の両方が同じサーバーにインストールされます。 ポータルと SDK サービスの間のネットワーク遅延が発生しないため、これは推奨トポロジです。 さらに、プライマリ サーバーで実行されているワークフローによるパフォーマンスの低下を回避するために、セカンダリ サービス管理サーバーに Self-Service ポータルをインストールすることをお勧めします。
このトポロジでは、Windows 認証 (既定で構成済み) を使って、SSL 使用のオーバーヘッドなしでセキュリティで保護された認証を提供します。
スタンドアロン セルフサービス ポータルのデプロイ
このトポロジでは、Self-Service ポータルにService Manager管理サーバーの役割がインストールされていないサーバーがインストールされます。
この構成では、新しい Self-Service ポータルとセカンダリ Service Manager サーバーが異なるサーバーにインストールされ、Web アプリから SDK サービスへの接続を作成するにはダブルホップが必要です。 この場合は Windows 認証を使用できないため、 基本認証を使用するようにポータルを構成する必要があります。 基本認証は本質的にセキュリティで保護されていないので、ファイアウォールやプロキシ サーバー以外のリソースへのアクセスなど、デプロイのセキュリティの問題を回避するために SSL を使用することをお勧めします。 ダブルホップ シナリオについては、「基本認証」の詳細を参照してください。
SSL を使用すると、ポータルと SDK サービスの間にネットワーク遅延が発生します。したがって、この構成は、1 台のサーバーの展開トポロジに比べると低速ですが、 ただし、この構成は、ダブルホップを回避できない展開シナリオに役立ちます。
Web ファームのデプロイ
新しい Self-Service ポータルの主な利点の 1 つは、Web アプリにキャッシュ以外のローカル データ ストレージが存在しない点です。 このサービスでは、Service Manager データベースで読み取りと書き込みを直接行います。 これにより、Web サーバーの複数のインスタンスを並列にデプロイしやすくなります。 大規模なデプロイでは、1,000 人を超えるユーザーがポータルに並列でアクセスする場合は、次の構成と同様に、新しい Self-Service ポータルを Web ファーム としてデプロイできます。
Web ファームでは、セルフサービス ポータルに対する高可用性が実現します。 内部的には、Web アプリによって SDK サービスへの WCF 接続が確立されます。 初期接続の作成には時間がかかるため、理想的なシナリオは、ユーザーが最初に接続する WebServer が後続のすべての要求を処理して、ターンアラウンドを高速化することです。 IIS でこのように構成するには、ARR 設定で クライアント アフィニティ を有効にする必要があります。
セットアップに関する問題のトラブルシューティング
次のトラブルシューティング セクションは、一般的な問題を解決するのに役立ちます。
IIS がインストールされていません
サーバーで IIS が有効になっていても、[構成] ページには、IIS の役割エラーが表示されます。
これは、管理者の資格情報を使用せずにインストーラーを起動したときに発生します。 その結果、インストーラーは IIS 構成設定にアクセスできません。
解決方法: SetupWizard.exe を管理者として実行します。 [SetupWizard] を右クリックし、[管理者として実行] を選択できます。
新しい Self-Service ポータルのトラブルシューティング
このセクションでは、新しい Self-Service ポータルをインストールした後に発生する可能性がある問題のトラブルシューティング方法について説明します。
IIS 設定
次のポータルの既定の設定は、インストール中に構成されます。
アプリケーション プール
クラシック モードで .NET CLR バージョン 4 で実行するように構成されています。
詳細設定では、アプリケーション プールは、インストール時に指定されるサービス アカウントで実行されるように構成されます。 そのユーザーには、Service Manager と、それが実行されるローカル コンピューターにおける管理者特権が必要です。
Web サイト構成
偽装 と Windows 認証 のみを有効にする必要があります。 他の設定はすべて無効にします。
偽装については、 [認証されたユーザー] を選択します。
Windows 認証の設定:
Web サイトの既定のドキュメントは index.cshtmlにします。
[基本認証]
ダブルホップのシナリオでは、Windows 認証は機能しません。そのため、無効にする必要があります。 基本認証を有効にして構成します。
トレースを有効にする
次の手順を使用して、トレースを有効にします。
手順 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 ログの概要」を参照してください。
デプロイに関する問題のトラブルシューティング
次のセクションを使用して、影響を受ける可能性のあるデプロイの問題のトラブルシューティングを行います。
定義の変更 (お知らせ/要求オファリング/サービスオファリング/ナレッジ記事) は表示されません
新しい Self-Service ポータルでは、キャッシュ メカニズムを使用して静的データを格納し、応答時間を短縮します。 キャッシュ タイムアウトは、既定では 30 分に設定されていますが、この時間は変更できます。 詳細については、「 Deploy the New Self-Service Portal 」の基本的なカスタマイズに関するセクションを参照してください。 キャッシュがクリアされるまで、アナウンス、要求オファリング、サービス オファリング、ナレッジ記事の定義に対する変更は表示されません。
メモリ キャッシュは .NET Framework の MemoryCacheに基づいて使用されます。 キャッシュされたコンテンツは、IIS ワーカー プロセスが終了するまでメモリに残ります。 IIS は古いプロセスを削除してから新しいプロセスを開始しないため、IIS を再起動しても役に立ちません。 代わりに IIS は、既存のプロセスを再利用します。 読み取りを強制的に更新し、キャッシュ データを削除するには、インスタンスに関連付けられている IIS ワーカー プロセスを特定し、IIS を再起動する前に [タスクの終了] を選択します。
[自分の要求] セクションと [マイ アクティビティ] セクションが空です
新しい型プロジェクションは、インストーラーの一部である Portal.mpb ファイルに含まれており、Service Manager にインポートする必要があります。 インポートするには、次の手順を使用します。
管理サーバー上に Portal.mpb ファイルをインポートします。
ポータルが接続されている管理サーバーで、SDK サービスを再起動します。
外部リンクをブロックするポップアップ
Internet Explorer の [セキュリティ強化の構成] 設定が有効になっている場合、ポータルの参照中に、各ページで次のポップアップが表示されます。
上記のポップアップは、テレメトリ データを収集するために Self-Service ポータルに統合されている App Insights JavaScript SDK に対して表示されます。 製品利用統計情報データの送信を無効にするには、EnableTelemetry 構成パラメーターの値を変更します。これにより、ポップアップが表示されなくなります。 詳細については、「 Deploy the New Self-Service Portal 」の基本的なカスタマイズに関するセクションを参照してください。
IIS をホストするコンピューター上のポータルにはアクセスできますが、リモート コンピューターからはアクセスできません
この問題は、ポータルと SDK サービスが異なるコンピューター (スタンドアロン Self-Service ポータルの展開) にある場合に発生する可能性があります。 これは、リモート コンピューターからポータルにアクセスしようとする際に、ダブル ホップ シナリオの原因になります。 そのため、 Windows 認証 で説明されている既定のポータル構成は機能しません。 この問題を解決するには、代わりに 基本認証 構成を使用します。
ポータルに一部のサービス オファリングまたは公開されたサービス オファリングが表示されない
これは、サービス オファリングが次のいずれかの条件を満たす場合にのみ表示されるためです。
サービス内容が、ブラウザーの言語、またはポータル言語セレクター一致で選択された言語と一致する。
サービス内容で、言語が選択されていない。
ポータルでサポートされている言語コードを含む言語の一覧を次に示します。
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
次の手順
- Self-Service ポータルをデプロイしてカスタマイズするには、「 Self-Service ポータルをデプロイする」を参照してください。
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示