StoreFront™ のアップグレード
アップグレードでは、StoreFront の構成が保持され、ユーザーのお気に入りはそのまま残ります。対照的に、StoreFront のアンインストールでは、StoreFront と関連サービス、サイト、お気に入り（スタンドアロンサーバーの場合）、および関連構成が削除されます。
サポートされるアップグレードパス
StoreFront 2203 の最新の累積更新プログラム（CU）には、以下のバージョンからアップグレードできます。
- StoreFront 2203 LTSR（初回リリースまたは任意のCU）
- StoreFront 1912 LTSR（任意のCU）
- StoreFront 3.12 LTSR CU9
3.12 CU9 より前のバージョンからアップグレードする場合は、まず StoreFront 3.12 CU9 にアップグレードする必要があります。
警告：
1912 より前のバージョンからアップグレードすると、展開内のデスクトップアプライアンスサイトは自動的に削除されます。代替策として、Citrix では、ドメインに参加していないすべてのユースケースで Citrix Workspace アプリ Desktop Lock を使用することをお勧めします。
知っておくべきこと
- StoreFront は、異なる製品バージョンを含む複数のサーバー展開をサポートしていません。そのため、展開へのアクセスを許可する前に、サーバーグループ内のすべてのサーバーを同じバージョンにアップグレードする必要があります。
- StoreFront は、異なるサーバーOSを含む複数のサーバー展開をサポートしていません。そのため、サーバーグループ内のすべてのサーバーは同じ Windows Server OS 上にある必要があります。
- 複数のサーバー展開での同時アップグレードはサポートされていません。サーバーは順次アップグレードする必要があります。
- StoreFront のアップグレードが実行される前に、いくつかのアップグレード前チェックが実行されます。アップグレード前チェックが失敗した場合、アップグレードは開始されず、失敗が通知されます。StoreFront のインストールは変更されません。失敗の原因を修正した後、アップグレードを再実行してください。
- StoreFront のアップグレード自体が失敗した場合、既存の StoreFront インストールが初期構成を失う可能性があります。StoreFront のインストールを機能する状態に復元してから、アップグレードを再実行してください。StoreFront を機能する状態に復元するには、次のアプローチを検討してください。
- アップグレード前に作成した VM スナップショットを復元する、
- アップグレード前にエクスポートした StoreFront 構成をインポートする（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 の管理者ログで、前述の例外エラーメッセージを含むエラーがないか確認します。対応するアドバイスに従ってください。
ログファイルの詳細は、インストールログを参照してください。