クラウドネイティブ エンドポイントに移行するための高レベルの計画ガイド

ヒント

クラウド ネイティブ エンドポイントについて読むと、次の用語が表示されます:

  • エンドポイント: エンドポイントは、携帯電話、Tablet PC、ノート PC、デスクトップ コンピューターなどのデバイスです。 "エンドポイント" と "デバイス" は同じ意味で使用されます。
  • マネージド エンドポイント: MDM ソリューションまたは グループ ポリシー オブジェクトを使用して組織からポリシーを受け取るエンドポイント。 通常、これらのデバイスは組織所有ですが、BYOD または個人所有のデバイスでもかまいません。
  • クラウド ネイティブ エンドポイント: Azure AD に参加しているエンドポイント。 これらはオンプレミス AD に参加していません。
  • ワークロード: 任意のプログラム、サービス、またはプロセス。

この高レベルの計画ガイドには、クラウドネイティブ エンドポイントへの導入と移行に考慮する必要があるアイデアと提案が含まれています。 デバイスの管理、レビュー、および既存のワークロードの移行、組織の変更、Windows Autopilot の使用などです。

この機能は、以下に適用されます。

  • Windows クラウドネイティブ エンドポイント

Windows エンドポイントをクラウドネイティブに移行するには、長期的な利点を含む多くの利点があります。 これは一夜で完了するプロセスではなく、問題、停止、およびユーザーへの悪影響を回避するために計画する必要があります。

組織とユーザーにとってのメリットの詳細については、「クラウドネイティブ エンドポイントとは」を参照してください。

成功させるため、この記事で説明する計画と展開のキーとなる領域について検討します。 適切な計画、通信、プロセスの更新により、組織はクラウドネイティブになることができます。

クラウドネイティブ MDM プロバイダーを使用してデバイスを管理する

クラウドネイティブ エンドポイントを含むエンドポイントの管理は、すべての組織にとって重要なタスクです。 クラウドネイティブ エンドポイントを使用すると、使用する管理ツールは、どこからでもエンドポイントを管理できるようになります。

現在モバイル デバイス管理 (MDM) ソリューションを使用していない場合、または Microsoft ソリューションに移行する場合は、次の記事が適切なリソースです。

製品とサービスのMicrosoft Intune ファミリでは、次のエンドポイント管理オプションがあります。

エンドポイントとユーザーのワークロードを確認する

大まかに言うと、クラウドネイティブ エンドポイントを展開するには、ID、ソフトウェア配布、デバイス管理、OS の更新プログラム、およびユーザー データと構成の管理に関する最新の戦略が必要です。 Microsoft には、クラウドネイティブ エンドポイントに対してこれらの領域をサポートするソリューションがあります。

開始するには、各ワークロードを確認し、クラウドネイティブ エンドポイントをサポートできる方法またはサポートする方法を決定します。 一部のワークロードでは、クラウドネイティブ エンドポイントが既にサポートされている場合があります。 ネイティブ サポートは、特定のワークロード、組織がワークロード サービスを実装する方法、およびユーザーがサービスを使用する方法によって異なります。

ワークロードがクラウドネイティブ エンドポイントをサポートしているかどうかを判断するには、これらのサービスを調査して検証する必要があります。

サービスまたはソリューションがクラウドネイティブ エンドポイントをサポートしていない場合は、その影響と、ユーザーと組織に対する重要度を判断します。 この情報がある場合は、次のステップを決定できます。これには以下のようなものがあります。

  • サービス ベンダーとの連携
  • 新しいバージョンへの更新
  • 新しいサービスの使用
  • クラウドネイティブ エンドポイントからそのサービスにアクセスして使用するための回避策を実装する
  • サービス要件の検証
  • サービスがクラウドネイティブ フレンドリではないことを受け入れます。これは、ユーザーと組織にとっては受け入れることができる可能性があります

どちらの方法でも、クラウドネイティブ エンドポイントをサポートするようにワークロードを更新することを計画する必要があります。

ワークロードは、次のような特性を備えている必要があります。

  • ユーザーの場所を問わず、アプリとデータに安全にアクセスできます。 アクセスには、企業または内部ネットワークへの接続は必要ありません。
  • クラウド サービスによってホストされます。
  • 特定のデバイスを必要としたり、それに依存したりすることはありません。

一般的なワークロードとソリューション

クラウドネイティブ エンドポイントには、エンドポイントをサポートするサービスとワークロードも含まれます。

次のワークロードは、ユーザーの生産性とエンドポイント管理を有効にするための構成、ツール、プロセス、サービスです。

正確なワークロード、詳細、およびクラウドネイティブ エンドポイントのワークロードを更新する方法は異なる場合があります。 また、すべてのワークロードを移行する必要はありません。 ただし、各ワークロード、ユーザーの生産性への影響、デバイス管理機能を考慮する必要があります。 クラウドネイティブ エンドポイントを使用するように一部のワークロードを変換するには、他のワークロードよりも時間がかかる場合があります。 ワークロードは相互に相互依存の関係を持つ場合もあります。

  • デバイス ID

    デバイスの ID は、デバイスの知識とデバイスとのセキュリティ信頼を持つ ID プロバイダー (IdP) によって決定されます。 Windows エンドポイントの場合、最も一般的な IdP は オンプレミスの Active Directory (AD) とMicrosoft Entra IDです。 これらの IdP のいずれかからの ID を持つエンドポイントは、通常 1 つに参加するか、両方に参加します。

    • クラウドネイティブ エンドポイントの場合は、Microsoft Entra参加がデバイスの ID に最適な選択です。 オンプレミスのネットワーク、リソース、またはサービスへの接続は必要ありません。
    • オンプレミスの AD 参加とハイブリッド Microsoft Entra参加には、オンプレミス ドメイン コントローラーへの接続が必要です。 最初のユーザー サインイン、グループ ポリシーの配信、パスワードの変更には接続が必要です。 これらのオプションは、クラウドネイティブ エンドポイントには適していません。

    注:

    Microsoft Entra登録 (職場参加とも呼ばれます) は、独自のデバイス (BYOD) シナリオ専用です。 組織所有の Windows エンドポイントには使用しないでください。 一部の機能は、登録されている Windows エンドポイントでサポートされていないか、期待どおりに動作Microsoft Entra可能性があります。

  • エンドポイントをプロビジョニングする

    新しくデプロイされたMicrosoft Entra参加エンドポイントの場合は、Windows Autopilot を使用してデバイスを事前構成します。 Microsoft Entraの参加は通常、ユーザー主導のタスクであり、Windows Autopilot はユーザーを念頭に置いて設計されています。 Windows Autopilot を使用すると、インターネット上のどこからでも、任意のユーザーがクラウドを使用してプロビジョニングできるようになります。

    詳細については、

  • ソフトウェアとアプリケーションを展開する

    ほとんどのユーザーは、コア オペレーティング システムに含まれていないソフトウェアとアプリケーションを必要とし、それを使用します。 多くの場合、IT 担当者は特定のアプリ要件を認識または理解していません。 ただし、これらのアプリケーションの配信と管理は、引き続き IT チームの責任です。 ユーザーは、使用しているエンドポイントや使用元のエンドポイントに関係なく、ジョブを実行するために必要なアプリケーションを要求してインストールできる必要があります。

    • ソフトウェアとアプリケーションを展開するには、(CMG共同管理を使用して) Intune や構成マネージャーなどのクラウドベースのシステムを使用します。

    • Microsoft Outlook や Teams など、エンドポイントに必要なアプリのベースラインを作成します。 他のアプリの場合は、ユーザーが自分のアプリをインストールできるようにします。

      エンドポイントでは、アプリ リポジトリとしてポータル サイト アプリを使用できます。 または、インストールできるアプリをリスト表示するユーザー向けポータルを使用します。 このセルフサービス オプションにより、新しいデバイスと既存のデバイスのプロビジョニング時間が短縮されます。 また、IT への負担も軽減され、ユーザーが必要としないアプリをデプロイする必要はありません。

    詳細については、

  • ポリシーを使用してデバイス設定を構成する

    ポリシーとセキュリティの管理は、エンドポイント管理の中核です。 エンドポイント ポリシーを使用すると、組織はマネージド エンドポイントに特定のセキュリティ ベースラインと標準構成を適用できます。 エンドポイントで管理および制御できる設定は多数あります。 ベースラインで必要なもののみを構成するポリシーを作成します。 一般的なユーザー設定を制御するポリシーを作成しないでください

  • セキュリティ、機能、アプリの更新プログラムを展開します

    多くのオンプレミス ソリューションでは、クラウドネイティブ エンドポイントに更新プログラムを展開したり、効率的に展開したりすることはできません。 セキュリティの観点からは、このワークロードが最も重要な場合があります。 これは、クラウドネイティブの Windows エンドポイントをサポートするために移行する最初のワークロードである必要があります。

  • ユーザー データと設定の管理

    ユーザー データには、次の項目が含まれます。

    • ユーザー ドキュメント
    • メール アプリの構成
    • Web ブラウザーのお気に入り
    • 基幹業務 (LOB) アプリケーション固有のデータ
    • 基幹業務 (LOB) アプリケーション固有の構成設定

    ユーザーは、任意のエンドポイントからデータを作成してアクセスする必要があります。 このデータも保護する必要があり、他のユーザーと共有する必要がある場合があります。

    • Microsoft OneDrive などのクラウド ストレージ プロバイダーにユーザー データと設定を格納します。 クラウド ストレージ プロバイダーは、データ同期、共有、オフライン アクセス、競合の解決などを処理できます。

      詳細については、「企業向けの OneDrive ガイド」を参照してください。

    重要

    OS の基本設定やアプリケーション固有の設定など、一部のユーザー設定はレジストリに格納されます。 これらの設定にどこからでもアクセスすることは現実的ではなく、異なるエンドポイントとの同期が禁止されている可能性があります。

    これらの設定をエクスポートし、別のデバイスにインポートすることができます。 たとえば、Outlook、Word、その他の Office アプリからユーザー設定をエクスポートできます。

  • オンプレミス リソースへのアクセス

    一部の組織では、一部のワークロードをクラウドネイティブ ソリューションに移行できません。 唯一のオプションは、クラウドネイティブ エンドポイントから既存のオンプレミスのリソースまたはサービスにアクセスすることです。 このようなシナリオでは、ユーザーにはアクセス権が必要です。

    これらのオンプレミスのサービス、リソース、アプリケーションについては、次のタスクを検討してください。

    注:

    Microsoft Entraは Kerberos 認証プロトコルをサポートしていません。 オンプレミス AD では、Kerberos 認証プロトコルがサポートされています。 計画では、Microsoft Entra Kerberos の詳細を確認できます。 構成すると、ユーザーはMicrosoft Entra アカウントを使用してクラウドネイティブ エンドポイントにサインインし、Kerberos 認証を使用するオンプレミスのアプリまたはサービスにアクセスできます。

    Microsoft Entra Kerberos:

    • クラウド ネイティブ ソリューションでは使用されません。
    • Microsoft Entraによる認証を必要とするリソースの接続の問題は解決されません。
    • Microsoft Entraによるドメイン認証の要件に対する回答や回避策ではありません。
    • 既知の問題と重要な情報に記載されているマシン認証の課題には対処しません。

    Kerberos Microsoft Entraと対処できるシナリオについて詳しくは、次のブログをご覧ください。

ワークロードを段階的に切り替える

ワークロードを最新化し、クラウドネイティブ エンドポイントを採用するには、運用プロセスと手順を変更する必要があります。 例:

  • 管理者は、既存のワークロードに対する変更によってプロセスがどのように変更されるかを理解する必要があります。
  • サービス デスクは、サポートされる新しいシナリオを理解する必要があります。

エンドポイントとワークロードを確認するときは、切り替えをフェーズに分割します。 このセクションでは、組織で使用できるいくつかの推奨フェーズの概要について説明します。 これらのフェーズは、必要な回数だけ繰り返すことができます。

✅ フェーズ 1: ワークロードに関する情報を取得する

このフェーズは、情報収集フェーズです。 これは、組織がクラウドネイティブに移行するために考慮する必要がある範囲を確立するのに役立ちます。 環境内の各ワークロードに関係するサービス、製品、アプリケーションを正確に定義する必要があります。

このフェーズでは、次の操作を行います。

  1. 現在のワークロードの情報と詳細をインベントリします。 たとえば、現在の状態、提供する内容、サービスを提供するユーザー、管理するユーザー、クラウドネイティブにとって重要な場合、ホスト方法を把握します。

    この情報があれば、最終的な目標を理解して定義できます。これは次のようになります。

    • クラウドネイティブ エンドポイントをサポートするには
    • 各ワークロードで使用されるサービス、製品、アプリケーションを把握するには

    さまざまなサービス、製品、アプリケーションの所有者と調整する必要があります。 接続や場所の制約なしに、クラウドネイティブ エンドポイントがユーザーの生産性をサポートすることを確認する必要があります。

    一般的なサービスとアプリケーションの例としては、基幹業務 (LOB) アプリケーション、内部 Web サイト、ファイル共有、認証要件、アプリケーションと OS の更新メカニズム、アプリケーション構成などがあります。 基本的には、ユーザーが自分の仕事を完全に行うために必要なものがすべて含まれます。

  2. 各ワークロードの終了状態を確認します。 この終了状態へのアクセスを妨げる既知の阻害要因を特定するか、クラウドネイティブ エンドポイントをサポートしないようにします。

    一部のワークロードとそのサービスとアプリケーションは既にクラウドに対応しているか、有効になっている可能性があります。 そうでないものもあります。 各ワークロードの最終状態に進むには、organization投資 & 労力が必要になる場合があります。 これには、ソフトウェアの更新、新しいプラットフォームへの "リフトアンドシフト"、新しいソリューションへの移行、または構成の変更が含まれます。

    ワークロードごとに必要なステップは、組織ごとに異なります。 ユーザーがサービスまたはアプリケーションをホストおよびアクセスする方法によって異なります。 この終了状態は、場所や内部ネットワークへの接続に関係なく、ユーザーがクラウドネイティブ エンドポイントで作業できるようにする、という主な課題に対処する必要があります。

    定義された各終了状態に基づいて、サービスまたはアプリケーションのクラウド対応が困難またはブロックされていることを検出または定義できます。 この状況は、技術的または財務上の制限など、さまざまな理由で発生する可能性があります。 これらの制限を明確にし、理解する必要があります。 それらの影響を確認し、各ワークロードをクラウドネイティブに対応させる方法を決定する必要があります。

✅ フェーズ 2: ブロック要因に優先順位を付ける

主要なワークロードとその終了状態のブロック要因を特定したら、次の手順を実行します。

  1. 各ブロック要因に優先順位を付け、解決のために評価します。

    すべてのブロック要因に対処したくない場合や、対処する必要がない場合があります。 たとえば、organizationには、クラウドネイティブ エンドポイントをサポートしていないワークロードやワークロードの一部が含まれている場合があります。 このサポートがないことは、組織またはユーザーにとって重要な場合とそうでない場合があります。 お客様と組織は、この決定を行うことができます。

  2. テストと概念実証 (POC) をサポートするには、ワークロードの最小セットから始めます。 目標は、ワークロードのサンプルをテストして検証することです。

    POC の一部として、パイロットのユーザーとデバイスのセットを特定して、実際の運用シナリオを実行します。 この手順は、エンド ステートがユーザーの生産性を有効にするかどうかを証明するのに役立ちます。

    多くの組織では、移行が容易なロールまたはビジネス グループがあります。 たとえば、POC で次のシナリオをターゲットにすることができます。

    • 生産性ツールとオンラインの顧客関係管理ソリューションを主な要件とする、モバイル性の高い営業チーム
    • クラウドに既に存在し、Microsoft 365 アプリに大きく依存しているコンテンツに主にアクセスするナレッジ ワーカー
    • モバイル性が高い、または組織のネットワークにアクセスできない環境にある現場担当者のデバイス

    これらのグループについては、ワークロードを確認します。 ID、ソフトウェア配布、デバイス管理など、これらのワークロードを最新の管理に移行する方法を決定します。

    パイロットの各領域で、項目またはタスクの数が少なくなっています。 この初期パイロットは、より多くのグループに必要なプロセスと手順を作成するのに役立ちます。 また、長期的な戦略の作成にも役立ちます。

    その他のガイダンスとヒントについては、「Microsoft Intune 計画ガイド」を参照してください。 Intune に適用されますが、パイロット グループを使用してロールアウト計画を作成する場合のガイダンスも含まれています。

✅ フェーズ 3: ワークロードを移行する

このフェーズでは、変更を実装する準備ができました。

  1. ブロック解除されたワークロードを、計画されたクラウドネイティブ ソリューションまたは終了状態に移動します。 理想的には、この手順はより小さな作業項目に分割されます。 目標は、中断を最小限に抑えて業務を継続することです。

  2. ワークロードの最初のセットがクラウドネイティブ エンドポイントをサポートされると、より多くのワークロードを特定し、プロセスを続行します。

✅ フェーズ 4: ユーザーを準備する

ユーザーは、デバイスで受け取り、展開、およびサポートされるさまざまなエクスペリエンスを持っています。 管理者は次の操作を行う必要があります。

  • 既存のプロセスとドキュメントを確認して、変更がユーザーに表示される場所を特定します。
  • ドキュメントを更新します。
  • ユーザーが経験する変更と利点を共有するための教育戦略を作成します。

組織を段階的に移行する

次のフェーズは、組織がクラウドネイティブの Windows エンドポイントをサポートするように環境を移行するための大まかなアプローチです。 これらのフェーズは、エンドポイントとユーザー ワークロードの移行と並行して行われます。 クラウドネイティブの Windows エンドポイントをサポートするために、一部または完全に移行されている特定のワークロードに依存する場合があります。

✅ フェーズ 1: エンドポイント、依存関係、マイルストーンを定義する

このフェーズは、組織の移行を完全にクラウドネイティブにする最初のステップです。 現在の内容を確認し、成功条件を定義し、デバイスをMicrosoft Entraに追加する方法の計画を開始します。

  1. クラウド ID を必要とするエンドポイントを定義する

    • インターネット アクセスを使用するエンドポイントには、クラウド ID が必要です。 これらのエンドポイントをMicrosoft Entraに追加します。
    • インターネットを使用しないエンドポイント、またはオンプレミスでのみ使用されるエンドポイントは、クラウド ID を持つことはできません。 これらのシナリオをクラウドネイティブに移行しないでください。
  2. 依存関係を定義する

    ワークロード、ユーザー、デバイスには、技術的および技術的でない依存関係があります。 ユーザーと組織への影響を最小限に抑えて移行するには、これらの依存関係を考慮する必要があります。

    たとえば、依存関係は次のようになります。

    • ビジネス プロセスと継続性
    • セキュリティ標準
    • 地域の法律と規制
    • ユーザーの知識とワークロードの使用
    • 資本、運用コスト、予算

    ワークロードごとに、「このワークロードによって提供されるサービスについて何かを変更した場合、影響を受けるものは何か」と尋ねます。 この変更の影響を考慮する必要があります。

  3. 各ワークロードのマイルストーンと成功基準を定義する

    各ワークロードには、独自のマイルストーンと成功基準があります。 これらは、組織によるワークロードの使用と、特定のエンドポイントとユーザーへの適用性に基づく場合があります。

    移行の進行状況を理解して定義するには、この情報を追跡および監視します。

  4. Windows Autopilot の展開を計画する

    • デバイスを組織に登録する方法とタイミングを決定します。
    • Windows Autopilot ポリシーをターゲットにするために必要なグループ タグを決定して作成します。
    • 構成設定を使用して Windows Autopilot プロファイルを作成し、プロファイルを受け取るデバイスをターゲットにします。

    詳細については、

✅ フェーズ 2: エンドポイント クラウド ハイブリッド ID を有効にする (オプション)

完全にクラウドネイティブにするには、ハードウェア更新サイクルの一環として既存の Windows エンドポイントをリセットすることをお勧めします。 リセットすると、エンドポイントが出荷時の設定に戻ります。 デバイス上のすべてのアプリ、設定、個人データが削除されます。

エンドポイントをリセットする準備ができていない場合は、ハイブリッド Microsoft Entra参加を有効にすることができます。 ハイブリッド Microsoft Entra 参加エンドポイント用にクラウド ID が作成されます。 ハイブリッド Microsoft Entra 参加には、引き続きオンプレミス接続が必要であることに注意してください。

ハイブリッド Microsoft Entra 結合はクラウドネイティブへの移行ステップであり、最終的な目標ではないことに注意してください。 最終的な目標は、すべての既存のエンドポイントを完全にクラウドネイティブにすることです。

エンドポイントが完全にクラウドネイティブの場合、ユーザー データは OneDrive などのクラウド ストレージ プロバイダーに格納されます。 そのため、エンドポイントがリセットされると、ユーザー アプリケーション、構成、およびデータに引き続きアクセスでき、新しくプロビジョニングされたエンドポイントにレプリケートできます。

詳細については、次を参照してください:

注:

Microsoft には、既存のエンドポイントをオンプレミスドメイン参加済みまたはハイブリッド Microsoft Entra参加済みから参加済みMicrosoft Entraに変換する移行ユーティリティはありません。 Microsoft では、ハードウェア更新の一環として、これらのデバイスをリセットして再デプロイすることをお勧めします。

✅ フェーズ 3: クラウド アタッチ 構成マネージャー (省略可能)

構成マネージャーを使用する場合は、環境を Microsoft Intune にクラウド接続します。 構成マネージャーを使用しない場合は、このステップをスキップします。

クラウド接続時に、クライアント エンドポイントをリモートで管理し、Intune (クラウド) とConfiguration Manager (オンプレミス) でエンドポイントを共同管理し、Intune管理センターにアクセスできます。

詳細については、「Cloud attach your Configuration Manager environment」および「Microsoft Intune 管理センターのチュートリアル」を参照してください。

✅フェーズ 4: Microsoft Entra参加済みの概念実証をCreateする

この重要なフェーズはいつでも開始できます。 潜在的な問題、不明な問題を特定し、それらの問題に対する全体的な機能と解決策を検証するのに役立ちます。 すべての POC と同様に、目標は、ラボ環境ではなく、実際のエンタープライズ環境で機能を証明して検証することです。

このフェーズの重要な手順は次のとおりです。

  1. Intune を使用した最小ベースライン構成の実装

    この手順は重要です。 ネットワークまたは運用環境に次のエンドポイントを導入したくありません。

    • 組織のセキュリティ標準に従わない
    • ユーザーが作業を実行するように構成されていません。

    この最小構成では、すべての可能な構成が適用されるわけではありません。 この目的は、ユーザーが成功するために必要な構成をさらに検出することです。

  2. Microsoft Entra参加済みエンドポイント用に Windows Autopilot を構成する

    Windows Autopilot を使用して新しいエンドポイントをプロビジョニングし、既存のエンドポイントを再プロビジョニングすることは、Microsoft Entra参加済みシステムをorganizationに導入する最速の方法です。 これは POC の重要な部分です。

  3. Microsoft Entra参加済みシステムの POC をデプロイする

    • さまざまな構成とユーザーを表すエンドポイントの組み合わせを使用します。 この新しいシステム状態をできるだけ多く検証する必要があります。

    • 実際の運用ユーザーのみが、ワークロードとその機能を完全に検証します。 ユーザーは、POC Microsoft Entra エンドポイントを日常的に自然に使用して、ワークロードを有機的にテストして検証します。

    • ビジネス クリティカルな機能とシナリオのチェックリストを作成し、POC ユーザーにこれらのリストを提供します。 チェックリストは各組織に固有であり、ワークロードがクラウドネイティブのわかりやすいワークロードに移行されると、変更される可能性があります。

  4. 機能の検証

    検証は繰り返し実行されるプロセスです。 これは、組織内のワークロードとその構成に基づいています。

    • POC エンドポイント、ワークロード、およびその機能に関するユーザー のフィードバックを収集します。 このフィードバックは、クラウドネイティブ エンドポイントを使用したユーザーからのフィードバックである必要があります。

      その他のブロック要因、および以前は不明だったか、ワークロードやシナリオが考慮されていなかったことが検出される場合があります。

    • 各ワークロードに対して以前に確立されたマイルストーンと成功基準を使用します。 POC の進行状況と範囲を決定するのに役立ちます。

✅フェーズ 5: 既存の Windows エンドポイントMicrosoft Entra参加する

このフェーズでは、新しい Windows エンドポイント プロビジョニングが参加Microsoft Entraに移行されます。 すべてのブロック要因と問題が解決されたら、既存のデバイスを完全にクラウドネイティブに移行できます。 以下のオプションがあります。

  • オプション 1: デバイスを交換します。 デバイスの寿命が切れている場合、または最新のセキュリティがサポートされていない場合は、デバイスを替えることをお勧めします。 最新のデバイスでは、トラステッド プラットフォーム モジュール (TPM) テクノロジを含む、新しい強化されたセキュリティ機能がサポートされています。

  • オプション 2: Windows デバイスをリセットします。 既存のデバイスが新しいセキュリティ機能をサポートしている場合は、デバイスをリセットできます。 既定のエクスペリエンス (OOBE) 中、またはユーザーがサインインするときに、デバイスに参加してMicrosoft Entraできます。

    既存の Windows エンドポイントをリセットする前に、次の操作を行ってください。

    1. Intune でデバイスを削除します
    2. Windows Autopilot デバイスの登録を削除します
    3. 既存のMicrosoft Entraデバイス オブジェクトを削除します

    次に、デバイスをリセットし、エンドポイントを再プロビジョニングします。

デバイスの準備ができたら、organizationに最適なオプションを使用して、これらのデバイスを参加Microsoft Entraします。 詳細については、「参加済みデバイスMicrosoft Entra」と「方法: Microsoft Entra参加の実装を計画する」を参照してください。

グループ ポリシー オブジェクト (GPO) から移動する

多くの組織では、GPO を使用して Windows エンドポイントを構成および管理しています。

時間の経過と共に、ドキュメントの不足、ポリシーの目的または要件の明確さ、レガシ ポリシーまたは機能的でないポリシーの使用、複雑な機能の使用により、複雑になります。 たとえば、WMI フィルターを含み、複雑な OU 構造を持ち、継承ブロック、ループバック、またはセキュリティ フィルターを使用するポリシーがある場合があります。

Intune を使用して設定を管理する

Microsoft Intune には、クラウドネイティブ エンドポイントに構成および展開できる多くの組み込み設定があります。 ポリシー管理のために Intune に移行する場合、いくつかのオプションがあります。

これらのオプションは、必ずしも相互に排他的であるとは限りません。 ポリシーのサブセットを移行し、他のユーザー向けに新規に開始できます。

  • オプション 1: 新規開始 (推奨): Intune には、エンドポイントを構成および管理するための多くの設定があります。 ポリシーを作成し、ポリシーに設定を追加して構成してから、ポリシーを展開できます。

    既存のグループ ポリシーの多くには、クラウドネイティブ エンドポイントに適用されない可能性があるポリシーが含まれています。 新たに開始すると、組織は既存の適用されたポリシーを検証して簡素化しながら、従来のポリシー、忘れられたポリシー、または有害なポリシーを排除できます。 Intune には、VPN、Wi-Fi、エンドポイント保護などの一般的な設定をグループ化する組み込みのテンプレートがあります。

  • オプション 2: 移行: このオプションでは、既存のポリシーを解除し、Intune ポリシー エンジンに移行します。 面倒で時間がかかる場合があります。 たとえば、既存のグループ ポリシーが多数ある場合があり、オンプレミスとクラウドの設定に違いがあります。

    このオプションを選択した場合は、既存のグループ ポリシーを確認して分析し、クラウドネイティブ エンドポイントで引き続き必要なのか、または有効なのかを判断する必要があります。 オーバーヘッドを引き起こしたり、システム パフォーマンスやユーザー エクスペリエンスを低下させたりする可能性のあるポリシーなど、不要なポリシーを排除する必要があります。 グループ ポリシーが何を行うかが分かるまで、グループ ポリシーを Intune に移動しないでください。

知っておくべき Intune の機能

Intune には、クラウドネイティブ エンドポイントの構成に役立つ機能も組み込まれています。

Windows Autopilot を使用して新規または既存の Windows エンドポイントをプロビジョニングする

OEM またはパートナーからエンドポイントを購入する場合は、Windows Autopilot を使用する必要があります。

次のような利点があります。

  • 組み込みの Windows セットアップ プロセス: ブランド化され、ガイド付きで簡素化されたエンドユーザー エクスペリエンスが提供されます。

  • エンドユーザーにエンドポイントを直接送信する: ベンダーと OEM は、エンドポイントをユーザーに直接送付できます。 ユーザーはエンドポイントを受信し、組織アカウント (user@contoso.com) でサインインすると、Windows Autopilot がエンドポイントを自動的にプロビジョニングします。

    この機能は、高度な内部 IT プロセスと出荷に伴うオーバーヘッドとコストを制限するのに役立ちます。

    最適な結果を得るには、OEM またはベンダーにエンドポイントを事前登録します。 事前登録は、エンドポイントを手動で登録するときに発生する可能性がある遅延を回避するのに役立ちます。

  • ユーザーは、既存のエンドポイントを自分でリセットできます: ユーザーが既存の Windows エンドポイントを持っている場合は、デバイス自体をリセットできます。 リセットされると、エンドポイントが最小ベースラインと管理された状態に復元されます。 コストの高い IT 介入やエンドポイントへの物理的なアクセスは必要ありません。

注:

Windows Autopilot を使用してハイブリッド Microsoft Entra新しくプロビジョニングされたエンドポイントに参加することはお勧めしません。 動作しますが、いくつかの課題があります。 新しくプロビジョニングされたエンドポイントでは、Windows Autopilot を使用して (ハイブリッド Microsoft Entra参加ではなく) 参加をMicrosoft Entraします。

organizationに適した結合方法を判断するには、参加済みMicrosoft Entraとハイブリッド Microsoft Entra参加済みに関するページに移動します。

Windows Autopilot の詳細については、次を参照してください。

クラウドネイティブ エンドポイントのガイダンスに従う

  1. 概要: クラウド ネイティブなエンドポイントとは
  2. チュートリアル: クラウド ネイティブ Windows エンドポイントの利用を開始する
  3. 概念: Microsoft Entra参加済みとハイブリッド Microsoft Entra参加済み
  4. 概念: クラウド ネイティブなエンドポイントとオンプレミス リソース
  5. 🡺 高度な計画ガイド (こちら)
  6. 既知の問題と重要な情報