デバイスの更新プログラムのモバイルデバイス管理 (MDM)

[アーティクル]
08/10/2023
適用対象:

✅ Windows 11, ✅ Windows 10

ヒント

開発者や管理者ではない場合は、「Windows Update: よくあるご質問」でさらに役立つ情報を確認できます。

PC、タブレット、電話、IoT デバイスでは、モバイルデバイス管理 (MDM) ソリューションが軽量デバイス管理テクノロジとして普及しています。 Windows では、MVM で使用できる管理機能の拡張に多額の投資を行っています。追加する主な機能の 1 つは、MDM が最新の Microsoft 更新プログラムでデバイスを最新の状態に保つことです。

特に、Windows には、MDM で次の機能を有効にする API が用意されています。

自動更新ポリシーを構成して、コンピューターを最新の情報に保つ。
特定のデバイスに対して承認される更新プログラムを構成することで、小規模なマシンセットで更新プログラムをテストします。次に、エンタープライズ全体のロールアウトを行います。
マネージドデバイスのコンプライアンス状態を取得します。 IT は、まだセキュリティパッチが必要なマシン、または現在のマシンが特定のマシンであることを理解できます。
デバイスを最新の状態に保つよう自動更新ポリシーを構成します。
デバイスコンプライアンス情報 (必要だがまだインストールされていない更新プログラムのリスト) を取得する。
デバイスごとの更新の承認リストを入力します。一覧では、承認およびテストされた更新プログラムのみがデバイスにインストールされます。
エンドユーザーのエンドユーザーライセンス契約 (EULA) を承認して、EULA を使用した更新プログラムでも更新プログラムの展開を自動化できるようにします。

この記事では、独立系ソフトウェアベンダー (ISV) に、Windows で更新管理を実装するために必要な情報を提供します。詳細については、「ポリシー CSP - 更新」を参照してください。

注

更新プログラムの承認を指定し、コンプライアンス状態を取得するための OMA DM API は、Update ID を使用した更新を参照します。 Update ID は、特定の更新プログラムを識別する GUID です。 MDM では、更新プログラムのタイトル、説明、KB、更新プログラムの種類 (セキュリティ更新プログラムや Service Pack など) を含む未加工の GUID ではなく、更新に関する IT フレンドリな情報を表示する必要があります。詳細については、「[MS-WSUSSS]: Windows Update Services: Server-Server Protocol」を参照してください。

次の図に、この機能の概要を概念的に示します。

モバイルデバイスの更新管理。

この図は、次の 3 つの領域に分けることができます。

デバイス管理サービスは、サーバー間同期プロトコルを使用して、Microsoft Update から更新情報 (タイトル、説明、適用性) を同期します (図の上部)。
デバイス管理サービスは、自動更新ポリシーを設定し、更新プログラムのコンプライアンス情報を取得して、OMA DM を介して承認を設定します (図の左側)。
デバイスは、クライアント/サーバープロトコルを使用して Microsoft Update から更新プログラムを取得します。デバイスに適用され、IT (図の右側) によって承認される更新プログラムのみをダウンロードしてインストールします。

サーバー間同期プロトコルを使用して更新プログラムのメタデータを取得する

Microsoft Update Catalog には、MDM で管理されるデバイスでは必要のない多くの更新プログラムが含まれています。これには、サーバーの更新プログラム、ダウンレベルのデスクトップオペレーティングシステム、& レガシアプリ、多数のドライバーなど、レガシソフトウェアの更新プログラムが含まれています。 MDM では、Server-Server 同期プロトコルを使用して、クライアントから報告された更新プログラムの更新メタデータを取得することをお勧めします。

このセクションでは、このセットアップについて説明します。次の図に、サーバー間同期プロトコルのプロセスを示します。

MSDN では、サーバー間同期プロトコルに関するさまざまな情報を提供しています。主な例:

これは SOAP ベースのプロトコルであり、サーバー同期 Web サービスで WSDL を取得できます。 WSDL を使用して、多くのプログラミング環境の呼び出しプロキシを生成し、開発を簡略化できます。
コードサンプルについては、「プロトコルの例」を参照してください。このサンプルコードは未加工の SOAP コマンドで、そのまま使用することもできます。 .NET などのプログラミング言語からの呼び出しを行う方が簡単ですが (WSDL で生成されたプロキシを呼び出します)。サーバー同期 WSDL によって生成されたスタブによって、不適切なバインド URL が生成されます。このバインド URL は、https://fe2.update.microsoft.com/v6/ServerSyncWebService/serversyncwebservice.asmx に設定する必要があります。

重要な特徴:

このプロトコルには認可フェーズがあります (GetAuthConfig、GetAuthorizationCookie、および GetCookie を呼び出します)。 [プロトコルの例] のサンプル 1: 承認コードは、承認の実行方法を示しています。承認フェーズと呼ばれますが、プロトコルは完全に開いています (プロトコルのこのフェーズを実行するために資格情報は必要ありません)。同期プロトコルのメイン部分の Cookie を取得するには、この一連の呼び出しを実行する必要があります。最適化として、その Cookie をキャッシュし、Cookie の有効期限が切れている場合にのみこのシーケンスを再び呼び出すようにすることができます。
このプロトコルを使用すると、GetUpdateData を呼び出すことにより、MDM で特定の更新プログラムのメタデータを同期できます。詳細については、MSDN の「GetUpdateData」を参照してください。リビジョン番号で該当する更新プログラムを取得する LocURI はです <LocURI>./Vendor/MSFT/Update/InstallableUpdates?list=StructData</LocURI>。 S2S 同期を使用してすべての更新プログラムを入手できるわけではないので、SOAP エラーを処理する必要があります。
モバイルデバイスの場合は、GetUpdateData を呼び出すことで、特定の更新プログラムのメタデータを同期できます。または、ローカルのオンプレミスソリューションの場合は、Windows Server Update Services (WSUS) を使用し、Microsoft Update Catalog サイトからモバイル更新プログラムを手動でインポートできます。詳細については、「サーバー同期プロセスのプロセスフロー図とスクリーンショット」を参照してください。

注

Microsoft Update は、特定の更新プログラムのメタデータを変更します。たとえば、説明情報の更新、適用ルールのバグの修正、ローカライズの変更などです。更新自体に影響しない変更が発生するたびに、新しい更新リビジョンが作成されます。更新リビジョンの ID キーを構成する UpdateID (GUID) と RevisionNumber (int) の複合。 MDM では、IT に対する更新プログラムのリビジョンは表示されません。代わりに、UpdateID (GUID) ごとに、MDM はその更新プログラムの後のリビジョン (リビジョン番号が最も多い更新プログラム) のメタデータを保持します。

更新プログラムのメタデータの XML 構造と要素の説明の例

GetUpdateData 呼び出しの応答は、XmlUpdateBlob 要素の更新プログラムのメタデータを含む ServerSyncUpdateData の配列を返します。更新プログラムの XML のスキーマについては、「プロトコルの例」を参照してください。重要な要素の一部を次に示します。

UpdateID - 更新プログラムの一意の識別子
RevisionNumber - 更新プログラムが変更された場合の更新プログラムのリビジョン番号。
CreationDate - この更新プログラムが作成された日付。
UpdateType - 次のような更新プログラムの種類。
- Detectoid - この更新 ID が互換性ロジックを表す場合
- Category - この要素は、次のいずれかを表します。
  - 更新プログラムが属する製品カテゴリ。たとえば、Windows、MS Office などです。
  - 更新プログラムが属する分類。たとえば、ドライバー、セキュリティなどです。
- ソフトウェア - 更新プログラムがソフトウェア更新プログラムの場合。
- ドライバー - 更新プログラムがドライバーの更新プログラムである場合。
LocalizedProperties - 更新プログラムが利用可能な言語、タイトル、更新プログラムの説明を表します。次のフィールドがあります。
- 言語 - 言語コード識別子 (LCID)。 en、es など。
- タイトル - 更新プログラムのタイトル。たとえば、"Windows SharePoint Services 3.0 Service Pack 3 x64 Edition (KB2526305)"
- 説明 - 更新プログラムの説明。たとえば、"Windows SharePoint Services 3.0 Service Pack 3 (KB2526305) では、Windows SharePoint Services 3.0 の最新の更新プログラムが提供されます。この項目のインストール後、コンピューターの再起動が必要になる場合があります。この項目をインストールした後は、削除できません。
KBArticleID - 特定の更新プログラムに関する詳細を含む、この更新プログラムの KB アーティクル番号。例: https://support.microsoft.com/kb/2902892。

サーバー間同期プロトコルを使用する場合の推奨フロー

このセクションでは、サーバー間同期プロトコルを使用して更新プログラムのメタデータを MDM に取り込む際に使用できるアルゴリズムについて説明します。

背景的情報:

マルチテナント MDM がある場合、更新メタデータはすべてのテナントに共通であるため、共有パーティションに保持できます。
その後、メタデータ同期サービスを実装できます。サービスは定期的にサーバーとサーバーの同期を呼び出して、IT が考慮する更新プログラムのメタデータをプルします。
OMA DM を使用してデバイスを制御する MDM コンポーネント (次のセクションで説明します) は、メタデータ同期サービスに、各クライアントから取得した必要な更新プログラムの一覧を送信する必要があります (これらの更新プログラムがまだデバイスに認識されていない場合)。

以下の手順で、メタデータ同期サービスの基本的なアルゴリズムについて説明します。

"障害が発生するために必要な更新 ID" の空の一覧を作成します。この一覧は、OMA DM を使用する MDM サービスコンポーネントによって更新されます。定義の更新は一時的なものであるため、この一覧に追加しないことをお勧めします。たとえば、Defender は 1 日に何度も新しい定義更新プログラムをリリースでき、それぞれが累積的です。
定期的に同期する (2 時間に 1 回、多くても 1 時間に 1 回以下をお勧めします)。
1. 期限切れでない Cookie をまだ持っていない場合は、プロトコルの承認フェーズを実装して Cookie を取得します。「プロトコルの例」の「サンプル 1: 認可」を参照してください。
2. プロトコルのメタデータ部分を実装します。「サンプル 2: プロトコルの例でのメタデータとデプロイの同期」を参照し、更新メタデータがまだ DB にプルされていない場合は、「障害が発生するために必要な更新 ID」の一覧のすべての更新について GetUpdateData を呼び出します。
  - 更新プログラムが既存の更新プログラムの新しいリビジョン (UpdateID が同じで、リビジョン番号が大きいもの) である場合は、以前の更新プログラムのメタデータを新しい更新プログラムのメタデータに置き換えます。
  - "障害が発生するために必要な更新 ID" の一覧から更新プログラムを削除します。

これらの手順では、IT 部門が管理する必要がある Microsoft 更新のセットに関する情報を取得し、さまざまな更新管理シナリオで情報を使用できるようにします。たとえば、更新プログラムの承認時に情報を取得して、IT が承認している更新プログラムを確認できます。または、コンプライアンスレポートの場合は、必要な更新プログラムがまだインストールされていない更新プログラムを確認します。

OMA DM を使用して更新プログラムを管理する

MDM では、OMA DM を介して更新プログラムを管理できます。 MDM を使用して Windows OMA DM プロトコルと統合する方法と、MDM 管理用にデバイスを登録する方法の詳細については、「モバイルデバイス管理」を参照してください。このセクションでは、更新プログラムの管理をサポートするためにその統合を拡張する方法について説明します。更新管理の主な側面には、次の情報が含まれます。

デバイスを最新の状態に保つよう自動更新ポリシーを構成します。
デバイスコンプライアンス情報 (必要だがまだインストールされていない更新プログラムのリスト) を取得する。
デバイスごとの更新承認リストを指定します。一覧では、承認およびテストされた更新プログラムのみがデバイスにインストールされます。
EULA を使用した更新であっても、更新プログラムのデプロイを自動化できるように、エンドユーザーの EULA を承認します。

更新プログラムを適用する際に推奨されるモデルについて、次にまとめて説明します。

"テストグループ" と "すべてのグループ" がある。
[テスト] グループで、すべての更新プログラムをフローさせます。
[すべてのグループ] で、品質更新プログラムの遅延を 7 日間設定し、品質更新は 7 日後に自動承認されます。 Quality Update の遅延では定義更新が除外されるため、定義更新は使用可能になると自動的に承認されます。 Update/DeferQualityUpdatesPeriodInDays を 7 に設定して、定義更新のスケジュールを品質更新プログラムの遅延スケジュールと一致させます。 7 日後に更新を実行するか、問題が発生した場合は一時停止します。

更新は、Update Policy CSP を使用して構成されます。

更新プログラムの管理のユーザーエクスペリエンスを示すスクリーンショット

管理者コンソールの次のスクリーンショットは、更新タイトル、承認状態、およびその他のメタデータフィールドの一覧を示しています。

mdm 更新管理のスクリーンショット。

mdm 更新管理メタデータのスクリーンショット。

SyncML の例

通知と延期を行うように自動更新を設定します。

<SyncML xmlns="SYNCML:SYNCML1.1">
    <SyncBody>
        <Replace xmlns="">
            <CmdID>1</CmdID>
            <Item>
                <Meta>
                    <Format>int</Format>
                    <Type>text/plain</Type>
                </Meta>
                <Target>
                    <LocURI>./Vendor/MSFT/Policy/Config/Update/AllowUpdateService</LocURI>
                </Target>
                <Data>0</Data>
            </Item>
            <CmdID>2</CmdID>
            <Item>
                <Meta>
                    <Format>int</Format>
                    <Type>text/plain</Type>
                </Meta>
                <Target>
                    <LocURI>./Vendor/MSFT/Policy/Config/Update/RequireDeferUpgrade </LocURI>
                </Target>
                <Data>0</Data>
            </Item>
            <CmdID>3</CmdID>
            <Item>
                <Meta>
                    <Format>int</Format>
                    <Type>text/plain</Type>
                </Meta>
                <Target>
                    <LocURI>./Vendor/MSFT/Policy/Config/Update/RequireUpdateApproval </LocURI>
               </Target>
                <Data>0</Data>
            </Item>
        </Replace>
       <Final/>
    </SyncBody>
</SyncML>