StoreFront™ のアップグレード
アップグレードにより、StoreFront の構成が保持され、ユーザーのお気に入りはそのまま残ります。対照的に、StoreFront のアンインストールでは、StoreFront および関連サービス、サイト、お気に入り（スタンドアロンサーバーの場合）、および関連する構成が削除されます。
サポートされているアップグレードパス
StoreFront 2511 には、以下のバージョンからアップグレードできます。
- StoreFront 1912 LTSR CU10
- StoreFront 2203 LTSR (任意の CU)
- StoreFront 2402 LTSR (任意の CU)
- StoreFront 2407
- StoreFront 2411
- StoreFront 2503
- StoreFront 2503.1
- StoreFront 2507 LTSR (任意の CU)
2402 CU2 以降の CU から 2407 または 2411 へのアップグレードはできません。
ご注意
- StoreFront は、異なる製品バージョンを含む複数サーバー展開をサポートしていません。そのため、展開へのアクセスを許可する前に、サーバーグループ内のすべてのサーバーを同じバージョンにアップグレードする必要があります。
- 複数サーバー展開では同時アップグレードはサポートされていません。サーバーは順次アップグレードする必要があります。
- StoreFront のアップグレードが実行される前に、いくつかの事前アップグレードチェックが実行されます。いずれかの事前アップグレードチェックが失敗した場合、アップグレードは開始されず、失敗が通知されます。StoreFront のインストールは変更されません。失敗の原因を修正した後、アップグレードを再実行してください。
- StoreFront のアップグレード自体が失敗した場合、既存の StoreFront インストールはその初期構成を失う可能性があります。StoreFront のインストールを機能する状態に復元してから、アップグレードを再実行してください。StoreFront を機能する状態に復元するには、次のアプローチを検討してください。
- アップグレード前に作成した VM スナップショットの復元
- アップグレード前にエクスポートした StoreFront 構成のインポート。詳細については、「StoreFront 構成のエクスポートとインポート」を参照してください。
- アップグレードの問題のトラブルシューティングに記載されているトラブルシューティングアドバイスの実行
- Citrix Virtual Apps and Desktops メタインストーラーから発生する StoreFront のアップグレード失敗は、関連する失敗ログへのリンクとともにダイアログで報告されます。
アップグレードの準備
アップグレードを開始する前に、アップグレードの失敗を防ぐために次の手順を実行することをお勧めします。
- アップグレードする前に、バックアップ戦略を計画します。
- サポートされているバージョンからアップグレードしていることを確認します。
- Citrix Web サイトから StoreFront インストーラーをダウンロードします。
単一の StoreFront サーバーのアップグレード
- VM スナップショットを作成してサーバーをバックアップします。
- 既存の StoreFront 構成をエクスポートします。サーバーグループに複数のサーバーがある場合は、1 つのサーバーからのみサーバーグループ構成をエクスポートします。すべての変更がそれらの間で伝播されている場合、サーバーグループ内のすべてのサーバーは構成の同一のコピーを保持します。このバックアップにより、新しいサーバーグループを簡単に構築できます。これにより、問題が発生した場合に構成を簡単に復元できます。このバックアップは、エクスポート元のバージョンと同じバージョンを実行しているサーバーにのみ復元できることに注意してください。
-
C:\inetpub\wwwroot\Citrix\<StoreName>\App_DataまたはC:\inetpub\wwwroot\Citrix\<StoreName>Auth\App_Data内のファイル（default.icaやusernamepassword.tfrmなど）に変更を加えた場合は、ストアごとにそれらをバックアップします。アップグレード後、それらを復元して変更を元に戻すことができます。 - ロードバランサーからサーバーを削除するか、接続をブロックして、ユーザーが接続できないようにします。
- サーバーを再起動します。
- StoreFront 管理コンソール、コマンドライン、PowerShell ウィンドウ、または StoreFront ファイルをロックする可能性のあるその他のアプリケーションなど、実行中のアプリケーションがないことを確認します。これにより、アップグレード中にすべての StoreFront ファイルがインストーラーによってアクセス可能になります。インストーラーがファイルにアクセスできない場合、それらは置き換えられず、アップグレードは失敗し、既存の StoreFront 構成が削除されます。
- StoreFront ファイルを含むディレクトリで Windows エクスプローラーまたはコマンドプロンプトが開いていないことを確認します。
- すべてのウイルス対策アプリケーションを無効にします。
- 必要なバージョンの StoreFront のインストールファイルを実行します。
計画されたメンテナンスダウンタイム中の StoreFront サーバーグループのアップグレード
計画されたダウンタイム中に複数のサーバーで構成される StoreFront サーバーグループをアップグレードするには、次の手順を実行します。
- ロードバランシング URL を無効にして、サーバーグループへのユーザーアクセスを無効にします。これにより、アップグレードプロセス中にユーザーが展開に接続するのを防ぎます。
- 単一の StoreFront サーバーのアップグレードの手順に従って、各サーバーをアップグレードします。
- すべてのサーバーが正しく機能していることを確認します。
- ロードバランシング URL を有効にして、アップグレードされたサーバーグループへのユーザーアクセスを有効にします。
計画されたダウンタイムなしでの StoreFront サーバーグループのアップグレード
稼働中の StoreFront サーバーグループ内のサーバーを同時にアップグレードすることはサポートされていません。ただし、同一の構成を持つ新しいサーバーグループを作成し、それをアップグレードしてから、ユーザー接続を新しいサーバーグループに移行することで、ライブアップグレードを実現できます。ユーザーは、サーバーグループ間で転送されるときに StoreFront に再認証する必要があります。
たとえば、3 台のサーバー A、B、C で構成される StoreFront サーバーグループをアップグレードするには、次の手順を実行します。
-
Export-STFConfigurationを使用して StoreFront 構成をエクスポートします。このバックアップは、プロセス後半でサーバーが工場出荷時の設定にリセットされ、構成データが削除されるため必要です。 -
Export-STFStoreSubscriptionsを使用してサーバー A からサブスクリプションデータをエクスポートします。このバックアップは、プロセス後半でサーバーが工場出荷時の設定にリセットされ、サブスクリプションデータが削除されるため必要です。「ストアのサブスクリプションデータの管理」を参照してください。 - ロードバランサーからサーバー C を削除して、サーバー C へのユーザーアクセスを無効にします。これにより、アップグレードプロセス中にユーザーがサーバー C に接続するのを防ぎます。ロードバランサーは引き続きサーバー A と B に要求を送信します。
- サーバー A を使用して、サーバー C をグループから削除します。 サーバー A と B は引き続きユーザーのリソースへのアクセスを提供します。サーバー C はサーバーグループから切り離され、工場出荷時の設定にリセットされます。
-
Clear-STFDeploymentを使用して、切り離されたサーバー C を工場出荷時の設定にリセットします。 - 以前にエクスポートした StoreFront 構成を
Import-STFConfigurationを使用してサーバー C にインポートします。サーバー C は、古いサーバーグループと同一の構成を持つようになります。この手順を後で繰り返す必要はありません。構成データをグループに参加する他のサーバーに伝播するには、1 台のサーバーに構成データのコピーがあれば十分です。 - 単一の StoreFront サーバーのアップグレードの手順に従って、サーバー C をアップグレードします。サーバー C は、古いサーバーグループと同一の構成を持ち、新しいバージョンの StoreFront にアップグレードされます。
- 以前にエクスポートした サブスクリプションデータをサーバー C にインポートします。この手順を後で繰り返す必要はありません。サブスクリプションデータをグループに参加する他のサーバーに伝播するには、1 台のサーバーにサブスクリプションデータのコピーがあれば十分です。
- サーバー B を使用して、手順 3、4、5、7 を繰り返します（手順 6 は繰り返さないでください）。この間、サーバー A のみがユーザーにリソースへのアクセスを提供します。したがって、この手順は、StoreFront サーバーグループへの負荷が最小限になると予想される静かな作業時間中に実行することをお勧めします。
- 既存のサーバーグループへの参加プロセスを使用して、サーバー B をサーバー C に参加させます。これにより、現在のバージョンの StoreFront 上の単一サーバー展開（サーバー A）と、新しい StoreFront バージョン上の新しい 2 ノードサーバーグループ（サーバー B と C）が作成されます。
- サーバー B と C をロードバランシングサービスに追加して、サーバー A から引き継ぐことができるようにします。
- ロードバランサーからサーバー A を削除して、ユーザーが新しくアップグレードされたサーバー B と C に誘導されるようにします。
- サーバー A を使用して、手順 5、7、10、11 を繰り返します（手順 6 は繰り返さないでください）。これでサーバーグループのアップグレードプロセスが完了しました。サーバー A、B、C は、元のグループと同一の構成およびサブスクリプションデータを持っています。
注:
サーバー A が唯一アクセス可能なサーバーである短い期間（手順 9）に、お気に入りが失われる可能性があります。これにより、新しいサーバーグループがアップグレード後にサブスクリプションデータベースの少し古いコピーを持つことになり、新しいお気に入りが失われる可能性があります。
お気に入りデータはユーザーがログオンしてリソースを起動するために不可欠ではないため、これによる機能的な影響はありません。ただし、サーバー A が工場出荷時の設定にリセットされ、新しくアップグレードされたグループに参加した後、ユーザーはリソースを再度お気に入りに追加する必要があります。数件のお気に入りレコードが失われる可能性は低いですが、ダウンタイムなしで稼働中の StoreFront 本番環境をアップグレードした場合に発生する可能性のある結果です。
アップグレードの問題のトラブルシューティング
-
C:\Windows\Temp\StoreFrontで、最新のCitrixMsi\*.logを開き、例外エラーを検索します。Thumbs.db Access 例外：
C:\inetpub\wwwroot\citrixまたはそのサブディレクトリ内のthumbs.dbファイルが原因です。見つかったthumbs.dbファイルをすべて削除します。Cannot get exclusive file access \in use 例外：利用可能な場合はスナップショット/バックアップを復元するか、サーバーを再起動し、StoreFront サービスを手動で停止します。
Service cannot be started 例外：利用可能な場合はスナップショット/バックアップを復元するか、.NET Framework 4.5 のフルバージョン（クライアントプロファイルではない）をインストールします。
-
CitrixMsi\*.logに例外エラーがない場合は、サーバーの Event Viewer > Delivery Services で、上記の例外エラーメッセージを含むエラーがないか確認します。対応するアドバイスに従ってください。 - イベントビューアーに例外エラーがない場合は、
C:\Program Files\Citrix\Receiver StoreFront\logsの管理者ログで、上記の例外エラーメッセージを含むエラーがないか確認します。対応するアドバイスに従ってください。
ログファイルの詳細は、「インストールログ」を参照してください。