StoreFront™ のアップグレード
アップグレードすると、StoreFront の構成が保持され、ユーザーのお気に入りはそのまま残ります。対照的に、(/ja-jp/storefront/current-release/manage-deployment/uninstall/) StoreFront をアンインストールすると、StoreFront および関連サービス、サイト、お気に入り (スタンドアロンサーバー上)、および関連構成が削除されます。
サポートされているアップグレードパス
StoreFront 2603 へは、以下からアップグレードできます:
- ストアフロント 1912 LTSR CU10
- ストアフロント 2203 LTSR (任意の CU)
- ストアフロント 2402 LTSR (任意の CU)
- ストアフロント 2411
- ストアフロント 2503
- ストアフロント 2503.1
- ストアフロント 2507 LTSR (任意の CU)
- ストアフロント 2511
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サーバーグループをアップグレードするには：
- (/ja-jp/storefront/current-release/manage-deployment/export-import-storefront-config.html)をExport-STFConfigurationを使用してエクスポートします。このバックアップは、後でサーバーが工場出荷時の設定にリセットされ、構成データが削除されるため必要です。
- Export-STFStoreSubscriptionsを使用して、サーバーAからサブスクリプションデータをエクスポートします。このバックアップは、後でサーバーが工場出荷時の設定にリセットされ、サブスクリプションデータが削除されるため必要です。(/ja-jp/storefront/current-release/manage-deployment/subscriptions-database/manage-subscription-data.html)を参照してください。
- ロードバランサーからサーバーCを削除して、ユーザーアクセスを無効にします。これにより、アップグレードプロセス中にユーザーがサーバーCに接続するのを防ぎます。ロードバランサーは引き続きサーバーAとBに要求を送信します。
- サーバーAを使用して、グループからサーバーCを削除します。 サーバーAとBは引き続きユーザーのリソースへのアクセスを提供します。サーバーCは現在サーバーグループから切り離され、工場出荷時の設定にリセットされます。
- 孤立したサーバーCを工場出荷時の設定にリセットするをClear-STFDeploymentを使用して。
- 以前にエクスポートした(/ja-jp/storefront/current-release/manage-deployment/export-import-storefront-config.html)をImport-STFConfigurationを使用してサーバーCにインポートします。サーバーCは、古いサーバーグループと同一の構成を持つようになります。この手順を後で繰り返す必要はありません。構成データをグループに参加する他のサーバーに伝播させるには、1つのサーバーに構成データのコピーがあれば十分です。
- (#upgrade-a-single-storefront-server)の手順に従ってサーバーCをアップグレードします。サーバーCは、古いサーバーグループと同一の構成を持ち、StoreFrontの新しいバージョンにアップグレードされます。
- 以前にエクスポートした(/ja-jp/storefront/current-release/manage-deployment/subscriptions-database/manage-subscription-data.html)をサーバーCにインポートします。この手順を後で繰り返す必要はありません。サブスクリプションデータをグループに参加する他のサーバーに伝播させるには、1つのサーバーにサブスクリプションデータのコピーがあれば十分です。
- サーバーBを使用して、手順3、4、5、7を繰り返します（手順6は繰り返さないでください）。この間、サーバーAのみがユーザーにリソースへのアクセスを提供します。したがって、StoreFrontサーバーグループへの負荷が最小限になると予想される静かな作業期間中にこの手順を実行することをお勧めします。
- (/ja-jp/storefront/current-release/get-started/join-existing-server-group.html)プロセスを使用して、サーバー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 の管理者ログで、前述の例外エラーメッセージを含むエラーがないか確認します。対応するアドバイスに従ってください。
ログファイルの詳細は、インストールログを参照してください。