StoreFront™ のアップグレード
アップグレードすると、StoreFront の構成が保持され、ユーザーのお気に入りはそのまま残ります。対照的に、StoreFront をアンインストールすると、StoreFront および関連サービス、サイト、お気に入り（スタンドアロンサーバーの場合）、関連構成が削除されます。
サポートされているアップグレードパス
StoreFront 2507 へは、以下のバージョンからアップグレードできます。
- StoreFront 2503.1
- StoreFront 2503
- StoreFront 2407
- StoreFront 2402 LTSR (任意の CU)
- StoreFront 2203 LTSR (任意の CU)
- StoreFront 1912 LTSR CU10
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 を工場出荷時の設定にリセットします。
- Import-STFConfiguration を使用して、以前にエクスポートしたStoreFront 構成をサーバー C にインポートします。サーバー C は、古いサーバーグループと同一の構成を持つようになります。この手順を後で繰り返す必要はありません。構成データのコピーは、グループに参加する他のサーバーに伝播するために、1 台のサーバーのみで必要です。
- 単一の StoreFront サーバーのアップグレードの手順に従って、サーバー C をアップグレードします。サーバー C は、古いサーバーグループと同一の構成を持つようになり、StoreFront の新しいバージョンにアップグレードされます。
- 以前にエクスポートしたサブスクリプションデータをサーバー C にインポートします。この手順を後で繰り返す必要はありません。サブスクリプションデータのコピーは、グループに参加する他のサーバーに伝播するために、1 台のサーバーのみで必要です。
- サーバー B を使用して、手順 3、4、5、7 を繰り返します（手順 6 は繰り返さないでください）。この間、サーバー A のみがユーザーにリソースへのアクセスを提供します。したがって、StoreFront サーバーグループへの負荷が最小限になると予想される、静かな作業期間中にこの手順を実行することをお勧めします。
- 既存のサーバーグループへの参加プロセスを使用して、サーバー B をサーバー C に参加させます。これにより、StoreFront の現在のバージョン（サーバー A）での単一サーバー展開と、StoreFront の新しいバージョン（サーバー B と C）での新しい 2 ノードサーバーグループが作成されます。
- サーバー 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 アクセス例外：C:\inetpub\wwwroot\citrix またはそのサブディレクトリ内の thumbs.db ファイルが原因です。見つかった thumbs.db ファイルをすべて削除します。
排他ファイルアクセスを取得できません <使用中>例外：利用可能な場合はスナップショット/バックアップを復元するか、サーバーを再起動し、StoreFront サービスを手動で停止します。
サービスを開始できません例外：利用可能な場合はスナップショット/バックアップを復元するか、.NET Framework 4.5 のフルバージョン（クライアントプロファイルではない）をインストールします。
- CitrixMsi*.log に例外エラーがない場合は、サーバーの イベントビューアー > Delivery Services で、前述の例外エラーメッセージを含むエラーがないか確認します。対応する助言に従ってください。
- イベントビューアーに例外エラーがない場合は、C:\Program Files\Citrix\Receiver StoreFront\logs の管理者ログで、前述の例外エラーメッセージを含むエラーがないか確認します。対応する助言に従ってください。
ログファイルの詳細は、インストールログを参照してください。