Managementのベストプラクティス用語集ドキュメント履歴PDFを表示このコンテンツは動的に機械翻訳されています。放弃このコンテンツは動的に機械翻訳されています。Managementソフトウェアのアップグレード方法と、既存のWindowsユーザープロファイルをCitrixユーザープロファイルに移行する方法について説明しています。ここでの説明に従ってバージョン3.xからバージョン5.xに簡単にアップグレードできます。Management機能および設定がアップグレード前と後のリリースで使用できるかを把握します。Managementのポリシー」を参照してください。INIファイルからグループポリシーへのアップグレードを容易にするため、INIファイルの設定をADMおよびADMXファイルの設定にもマップしています。Managementを構成しないでください。最初に展開をアップグレードし、次に理想的には「構成上の判断」の質問に回答することで必要に応じて設定を構成します。2.1.1以降の環境にHotfixを適用できます。アップグレード後、必要に応じて、あとで任意の機能を有効にできます。Managementが混在する展開の場合、以下を実行します:混在展開となっている期間を最短化します。最新バージョンのADMまたはADMXファイルを、すべてのドメインコントローラーの各グループポリシーオブジェクトに追加します。すべての新機能が無効になっていることを確認し、新しいポリシーが行き渡るまでの時間をとります。Managementにアップグレードします。バージョン5.xと3.2がある混在展開がサポートされます。このような展開は、以前のバージョンから新しいバージョンへ移行する間の一時的な状態として処理します。Preview版またはベータリリース版を含む、バージョン2.1.1以前をバージョン5.xと組み合わせた展開環境はサポートされません。アップグレードを実行できず、展開内にこのようなバージョンを混在させる必要がある場合、このトピックの後述の内容が役に立つ場合があります。3.xまたは5.xの混在に関する情報について説明します。あるバージョンから別のバージョンへの移行方法について、言及しています。このトピックでは、バージョン2およびバージョン5という用語をこれらのバージョンの略語として使用します。別個のOUに各バージョンを分離し、各バージョンを実行するコンピューターに対して別個のユーザーストアを保持します。単一のユーザーストアが両方のバージョンを実行するコンピューターに適用される場合は、すべてのコンピューターでバージョン5へアップグレードされるまでは、すべてのバージョン5の設定を無効にする必要があります。「混在」ユーザーストアでバージョン4設定を有効にした後も、ユーザーはバージョン2を実行するコンピューターにログオンできます。(ネットワーク、Citrixユーザープロファイルではない)一時Windowsユーザープロファイルが適用され、そのプロファイルに追加した変更は保存されません。混在展開を一時的なものとして、アップグレードを完了する前にこの状態である期間を最短にする必要があります。別個のOUおよびユーザーストアの使用は不便です。この問題を避けるため、次の2つの方策のうちの1つを使用できます。Managementの適切なバージョンで構成します。方策1よりも方策2の方がより効果的です。方策2では、バージョン5の処理済みユーザーグループの更新が維持されます。Appsからアプリケーション定義をエクスポートして自動化できる)されます。これには、移行に時間をかけることができるという利点があります。Managementがインストールされているかを判別できます。この方法で、バージョンに合致させるためにどのポリシーを適用するかを自動的に調節できます。方策1:一時移行このシナリオでは、ダウンタイムの受け入れが可能なことが前提となっています。すべてのコンピューターが同時に移行されます。移行方法は、次のとおりです:バージョン2のADMファイルをバージョン5のファイルに置き換えます。バージョン4のADMファイルには前のバージョンとの互換性があるため、バージョン2のコンピューターの操作はそのまま続行されます。バージョン5の設定はすべて無効である必要があります。無効であるとは限りません。すべてのコンピューターでバージョン2からバージョン5へのアップグレードを開始します。これを通常のメンテナンスおよび更新のスケジュールに合わせます。1つを例外として、バージョン5設定を有効にするまでは、バージョン5はバージョン2として動作します。例外は次のとおりです。このアップグレード処理に時間がかかることがまれにあります。複数のサーバーからCitrixユーザープロファイルにアクセスすると、複数のバージョン4セッションが作成されます。ユーザーが最初にワークステーションを使ってあるサーバー上の仮想デスクトップにアクセスし、次にノートブックコンピューターから別のサーバー上の公開アプリケーションにアクセスするとします。Managementは2つ目のノートブックコンピューターセッションに対して保留領域を使用することになります。この時点で、OU全体は(バージョン5機能を構成していないにもかかわらず)バージョン5展開として処理されます。PmCompatibility.iniが更新されて、この変更が反映されます。オプションとして、バージョン5処理済みユーザーグループを設定して、小規模のパイロットグループのメンバーだけを含めるようにします。ADグループポリシーの変更が(週末を経過するなど)ネットワークを介して適用されるのを待ちます。この変更の間、ほかのユーザーによるアクセスをブロックする必要はありません。パイロットグループのプロファイルのバックアップをとります。Managementをテストします。パイロットグループの結果に満足がいく場合は、ほかのユーザーのプロファイルのバックアップをとります。次にスケジュールされているメンテナンス期間を用いて、残りのユーザーをバージョン5処理済みユーザーグループに追加します。ADグループポリシーの変更が適用されるのを待ってから、残りのユーザーによるログオンを許可します。方策2:段階的移行このシナリオでは、すべてのマシンまたはユーザーを一度には新しいバージョンに移動できず、そのためバッチで移行するユーザーのサブセットを選択する前提となっています。この方法は、複数のデータセンターがある展開環境、またはユーザーが地理的にさまざまな場所にいる展開環境に適しています。移行方法は、次のとおりです:バージョン2のADMファイルをバージョン5のファイルに置き換えます。バージョン4のADMファイルには前のバージョンとの互換性があるため、バージョン2のコンピューターの操作はそのまま続行されます。バージョン5の設定はすべて無効である必要があります。無効であるとは限りません。数台のコンピューター(最初のバッチ)でバージョン5へのアップグレードを実行します。バージョン5を新しいコンピューターにインストールします。デフォルトでは、バージョン5の処理済みユーザーグループ含まれているグループは空で、そのためバージョン5のユーザーとして処理されるユーザーはいません。方法1で説明した例外は、段階的移行でコンピューターをアップグレードする場合にも適用されることがあります。Desktopsを使用)を公開します。これらのアプリケーションやデスクトップは、名称以外の点では、バージョン2のコンピューターで以前に公開したものと同じです。名称は、バージョン5のユーザーが使用するためのものと同じです。Interfaceを使用して)アプリケーションまたはデスクトップにログオンします。Interfaceを使ってこの手順を強制的に実行します)。この結果、セッションをバージョン4のコンピューターで実行しますが、セッションはバージョン2の設定で処理されます。すべてのユーザーのプロファイルのバックアップを取る必要があります。バージョン2の処理済みユーザーグループからバージョン4のグループにユーザーを移動します。ADグループポリシーがバージョン5のコンピューターに適用されるのを待ちます。次回ログオン時に、ユーザーのセッションがバージョン5設定で処理されます。前述のように、コンピューターの次のバッチをアップグレードし、ユーザーの次のバッチを移行します。このコンテンツの正式なバージョンは英語で提供されています。Groupドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Groupは機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。Groupとのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。Groupは責任を負わないものとします。提供する翻訳が含まれている可能性があります。翻訳について、明示的か黙示的かを問わず、精度と信頼性に関するあらゆる保証、および商品性、特定目的への適合性、第三者の権利を侵害しないことに関するあらゆる黙示的保証を含め、一切保証しません。Contributors><このコンテンツは動的に機械翻訳されています。reserved.フィードバックを提供フィードバックをありがとうございます。詳細情報が必要な場合、記載のメールアドレスに連絡させていただきます。フィードバックの送信中にエラーが発生しました。