モバイル デバイスの登録と管理の新機能

この記事では、Windows 10およびモバイル デバイス管理 (MDM) のすべてのWindows 10デバイスとWindows 11 デバイスの登録と管理エクスペリエンスWindows 11新機能について説明します。 この記事では、重大な変更や既知の問題、よく寄せられる質問の詳細についても説明します。

Windows 10とWindows 11用の Microsoft モバイル デバイス管理プロトコルの詳細については、「[MS-MDM]: モバイル デバイス管理 プロトコル」および「[MS-MDE2]: モバイル デバイス登録プロトコル バージョン 2」を参照してください。

mdm for Windows 11 バージョン 21H2 の新機能

重大な変更と既知の問題

アトミック コマンド内でコマンドを取得することはサポートされていません

Windows 10およびWindows 11では、アトミック コマンド内の Get コマンドはサポートされていません。

WMI クラスを使用してインストールされたアプリは削除されません

WMI クラスを使用してインストールされたアプリケーションは、MDM アカウントがデバイスから削除されたときに削除されません。

SyncML での CDATA の受け渡しが機能しない

SyncML 内のデータ内の CDATA を ConfigManager および CSP に渡しても、Windows 10とWindows 11では機能しません。

SCEP 用 IIS サーバーの SSL 設定を "無視" に設定する必要があります

SCEP 用 IIS サーバーの [SSL 設定] の証明書設定は、Windows 10とWindows 11で [無視] に設定する必要があります。

トラフィックがプロキシを経由しているときに、Windows デバイスで MDM 登録が失敗する

認証を必要とするプロキシを使用するようにWindows デバイスが構成されている場合、登録は失敗します。 この問題を回避するために、ユーザーは認証を必要としないプロキシを使用したり、接続されたネットワークからプロキシ設定を削除したりできます。

サーバーによって開始された登録解除エラー

職場アカウントを追加して登録されたデバイスに対するサーバーによって開始された登録解除は、MDM アカウントをアクティブのままにできません。 MDM ポリシーとリソースは引き続き設定されており、クライアントは引き続きサーバーと同期できます。

Azure Active Directory Join を使用して登録されたモバイル デバイスでは、リモート サーバーの登録解除が無効になっています。 サーバーにエラー メッセージが返されます。 Azure AD に参加しているモバイル デバイスの登録を削除する唯一の方法は、デバイスをリモートでワイプすることです。

Wi-Fiと VPN に関する問題の原因となっている証明書

Windows 10とWindows 11では、ClientCertificateInstall を使用してデバイス ストアに証明書をインストールし、ユーザー ストアに証明書をインストールすると、両方の証明書が同じ MDM ペイロードでデバイスに送信されると、デバイス ストア用の証明書もユーザー ストアにインストールされます。 このデュアル インストールでは、接続を確立するための正しい証明書を選択するときに、Wi-Fiまたは VPN に関する問題が発生する可能性があります。 この問題の修正に取り組んでいます。

Windows 11のバージョン情報

DevDetail/Ext/Microsoft/OSPlatform のソフトウェア バージョン情報が、System/About の設定のバージョンと一致しません。

複数の証明書により、Wi-Fi Windows 10とWindows 11で接続が不安定になる可能性があります

展開で、デバイスに複数の証明書がプロビジョニングされていて、プロビジョニングされたWi-Fi プロファイルに厳密なフィルター条件がない場合、Wi-Fi に接続するときに接続エラーが発生することがあります。 解決策は、プロビジョニングされたWi-Fi プロファイルに、1 つの証明書のみに一致するように厳密なフィルター条件を持たないようにすることです。

VPN/Wi-Fi 用に証明書ベースの EAP 認証を展開している企業は、認証の既定の条件を満たす複数の証明書がある状況に直面する可能性があります。 この状況では、次のような問題が発生する可能性があります。

• ユーザーに証明書の選択を求めるメッセージが表示される場合があります。
• 間違った証明書が自動的に選択され、認証エラーが発生する可能性があります。

運用環境の準備が整ったデプロイには、展開するプロファイルの一部として適切な証明書の詳細が必要です。 次の情報では、EAP 構成 XML を作成または更新して、余分な証明書をフィルター処理し、適切な証明書を認証に使用できるようにする方法について説明します。

EAP XML は、環境に関連する情報で更新する必要があります。 このタスクは、以下の XML サンプルを編集するか、ステップ バイ ステップ UI ガイドを使用して手動で実行できます。 EAP XML が更新されたら、MDM の手順を参照して、更新された構成を次のようにデプロイします。

• Wi-Fi については、現在の WLAN プロファイル XML の EAPConfig> セクションを探<します (この詳細は、Wi-Fi CSP で WLanXml ノードに指定したものです)。 これらのタグ内には、完全な EAP 構成があります。 EAPConfig> のセクション<を更新された XML に置き換え、Wi-Fi プロファイルを更新します。 新しいWi-Fi プロファイルを展開する方法に関する MDM のガイダンスを参照する必要がある場合があります。
• VPN の場合、EAP 構成は MDM 構成の別のフィールドです。 MDM プロバイダーと連携して、適切なフィールドを特定して更新します。

EAP 設定の詳細については、次を参照してくださいhttps://technet.microsoft.com/library/hh945104.aspx#BKMK_Cfg_cert_Selct。

EAP XML の生成の詳細については、「 EAP 構成」を参照してください。

拡張キーの使用法の詳細については、以下を参照してください https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12。

拡張キー使用法 (EKU) を証明書に追加する方法については、以下を参照してください https://technet.microsoft.com/library/cc731792.aspx。

次の一覧では、EAP で使用する証明書の前提条件について説明します。

• 証明書には、次の EKU (拡張キー使用法) プロパティの少なくとも 1 つが必要です。

  • クライアント認証。
  • RFC 5280 で定義されているように、このプロパティは値 1.3.6.1.5.5.7.3.2 を持つ明確に定義された OID です。
  • 任意の目的。
  • Microsoft によって定義および発行される EKU は、値 1.3.6.1.4.1.311.10.12.1 を持つ明確に定義された OID です。 この OID を含めることは、証明書を任意の目的で使用できることを意味します。 All Purpose EKU よりもこの EKU の利点は、効果的なフィルター処理のために他の重要でない EKU またはカスタム EKU を証明書に追加できることです。
  • すべての目的。
  • RFC 5280 で定義されているように、一部のアプリケーションニーズを満たすために CA に拡張キー使用法が含まれているが、キーの使用を制限したくない場合、CA は拡張キー使用法値 0 を追加できます。 このような EKU を持つ証明書は、あらゆる目的で使用できます。

• 信頼されたルート CA にクライアント チェーン上のユーザーまたはコンピューター証明書。

• ユーザーまたはコンピューター証明書は、CryptoAPI 証明書ストアによって実行されるチェックのいずれにも失敗せず、証明書はリモート アクセス ポリシーの要件に合格します。

• ユーザーまたはコンピューター証明書は、インターネット認証サービス (IAS)/Radius Server で指定されている証明書オブジェクト識別子チェックのいずれも失敗しません。

• 証明書のサブジェクト代替名 (SubjectAltName) 拡張機能には、ユーザーのユーザー プリンシパル名 (UPN) が含まれています。

次の XML サンプルでは、証明書のフィルター処理を含む EAP TLS XML のプロパティについて説明します。

<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
 <EapMethod>
  <Type xmlns="http://www.microsoft.com/provisioning/EapCommon">13</Type>
  <!--The above property defines the Method type for EAP, 13 means EAP TLS -->

  <VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>
  <VendorType xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType>
  <AuthorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId>
  <!--The 3 properties above define the method publishers, this is seen primarily in 3rd party Vendor methods.-->
  <!-- For Microsoft EAP TLS the value of the above fields will always be 0 -->
 </EapMethod>
 <!-- Now that the EAP Method is Defined we will go into the Configuration -->
 <Config xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
  <Eap xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1">
   <Type>13</Type>
   <EapType xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1">
    <CredentialsSource>
     <!-- Credential Source can be either CertificateStore or SmartCard -->
     <CertificateStore>
      <SimpleCertSelection>true</SimpleCertSelection>
      <!--SimpleCertSelection automatically selects a cert if there are mutiple identical (Same UPN, Issuer, etc.) certs.-->
      <!--It uses a combination of rules to select the right cert-->
     </CertificateStore>
    </CredentialsSource>
    <ServerValidation>
     <!-- ServerValidation fields allow for checks on whether the server being connected to and the server cert being used are trusted -->
     <DisableUserPromptForServerValidation>false</DisableUserPromptForServerValidation>
     <ServerNames/>
    </ServerValidation>
    <DifferentUsername>false</DifferentUsername>
    <PerformServerValidation xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</PerformServerValidation>
    <AcceptServerName xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</AcceptServerName>
    <TLSExtensions xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">
     <!-- For filtering the relevant information is below -->
     <FilteringInfo xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV3">
      <CAHashList Enabled="true">
       <!-- The above implies that you want to filter by Issuer Hash -->
       <IssuerHash>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
        <!-- Issuing certs thumbprint goes here-->
       </IssuerHash>
       <!-- You can add multiple entries and it will find the list of certs that have at least one of these certs in its chain-->
      </CAHashList>
      <EKUMapping>
       <!-- This section defines Custom EKUs that you may be adding-->
       <!-- You do not need this section if you do not have custom EKUs -->
       <!-- You can have multiple EKUs defined here and then referenced below as shown -->
       <EKUMap>
        <EKUName>
         <!--Add a friendly Name for an EKU here for example -->ContostoITEKU</EKUName>
        <EKUOID>
         <!--Add the OID Value your CA adds to the certificate here, for example -->1.3.6.1.4.1.311.42.1.15</EKUOID>
       </EKUMap>
        <!-- All the EKU Names referenced in the example below must first be defined here
       <EKUMap>
        <EKUName>Example1</EKUName>
        <EKUOID>2.23.133.8.3</EKUOID>

       </EKUMap>
       <EKUMap>
        <EKUName>Example2</EKUName>
        <EKUOID>1.3.6.1.4.1.311.20.2.1</EKUOID>
       </EKUMap>
       -->
      </EKUMapping>
      <ClientAuthEKUList Enabled="true">
       <!-- The above implies that you want certs with Client Authentication EKU to be used for authentication -->
       <EKUMapInList>
        <!-- This section implies that the certificate should have the following custom EKUs in addition to the Client Authentication EKU -->
        <EKUName>
         <!--Use the name from the EKUMap Field above-->ContostoITEKU</EKUName>
       </EKUMapInList>
       <!-- You can have multiple Custom EKUs mapped here, Each additional EKU will be processed with an AND operand -->
       <!-- For example, Client Auth EKU AND ContosoITEKU AND Example1 etc. -->
       <EKUMapInList>
        <EKUName>Example1</EKUName>
       </EKUMapInList>
      </ClientAuthEKUList>
      <AllPurposeEnabled>true</AllPurposeEnabled>
      <!-- Implies that a certificate with the EKU field = 0 will be selected -->
      <AnyPurposeEKUList Enabled="true"/>
      <!-- Implies that a certificate with the EKU oid Value of 1.3.6.1.4.1.311.10.12.1 will be selected -->
      <!-- Like for Client Auth you can also add Custom EKU properties with AnyPurposeEKUList (but not with AllPurposeEnabled) -->
      <!-- So here is what the above policy implies.
      The certificate selected will have
      Issuer Thumbprint = ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      AND
      ((Client Authentication EKU AND ContosoITEKU) OR (AnyPurposeEKU) OR AllPurpose Certificate)

      Any certificate(s) that match these criteria will be utilised for authentication
      -->
     </FilteringInfo>
    </TLSExtensions>
   </EapType>
  </Eap>
 </Config>
</EapHostConfig>

または、次の手順を使用して EAP 構成 XML を作成することもできます。

1. EAP 構成の手順 1 ~ 7 に従います。

2. [Microsoft VPN SelfHost のプロパティ] ダイアログ ボックスで、ドロップダウン メニューから Microsoft : スマート カードまたはその他の証明書 を選択します (このドロップダウン メニューでは EAP TLS が選択されます)。

   

   注意

   PEAP または TTLS の場合は、適切な方法を選択し、この手順に従い続行します。

3. ドロップダウン メニューの下にある [プロパティ ] ボタンをクリックします。

4. スマート カードまたはその他の [証明書のプロパティ] メニューで、[詳細設定] ボタンを選択します。

   

5. [ 証明書の選択の構成 ] メニューで、必要に応じてフィルターを調整します。

   

6. [ OK] を クリックしてウィンドウを閉じ、メイン rasphone.exe ダイアログ ボックスに戻ります。

7. rasphone ダイアログ ボックスを閉じます。

8. 手順 9 の EAP 構成 の手順に従って、適切なフィルター処理を使用して EAP TLS プロファイルを取得します。

MDM クライアントは、クライアントが WNS チャネル URI を更新した後、MDM サーバーにすぐにチェックインします

MDM クライアントが WNS チャネル URI を自動的に更新すると、MDM クライアントは MDM サーバーとすぐにチェックインします。 そのため、MDM クライアントチェックインごとに、MDM サーバーは "ProviderID/Push/ChannelURI" の GET 要求を送信して最新のチャネル URI を取得し、それを既存のチャネル URI と比較する必要があります。必要に応じてチャネル URI を更新します。

Azure Active Directory参加しているWindows 10デバイスとWindows 11 デバイスでのユーザー プロビジョニングエラー

Azure AD に参加しているWindows 10とWindows 11では、プロビジョニング/.ユーザーが Azure AD ユーザーとしてログインしていない場合、ユーザー リソースは失敗します。 設定 System > About ユーザー インターフェイスから > Azure AD に参加しようとする場合は、必ず Azure AD 資格情報でサインアウトしてサインインし、MDM サーバーから組織の構成を取得してください。 この動作は仕様です。

Kerberos 認証にも使用される VPN 証明書に注意する必要がある要件

Kerberos 認証にも VPN 認証に使用される証明書を使用する場合 (NTLM または Kerberos を使用してオンプレミス リソースにアクセスする必要がある場合は必須)、ユーザーの証明書はスマート カード証明書の要件を満たしている必要があります。サブジェクト フィールドには DN の DNS ドメイン名を含める必要があります。SAN には、DNS 登録から DC を見ることができるように完全修飾 UPN が含まれている必要があります。 これらの要件を満たしていない証明書が VPN に使用されている場合、ユーザーは Kerberos 認証を必要とするリソースにアクセスできない可能性があります。

プッシュ ボタン リセット用のデバイス管理エージェントが機能しない

プッシュ ボタン リセット用の DM エージェントは、OMA DM セッションのレジストリ設定を保持しますが、タスク スケジュールは削除されます。 クライアント登録は保持されますが、MDM サービスと同期されることはありません。

よく寄せられる質問

Windows 10または 11 でデバイスを登録および管理する MDM サーバーが複数存在することはできますか?

いいえ、そうではありません。 MDM は 1 つだけ許可されます。

操作方法ユーザーあたりのAzure Active Directory参加デバイスの最大数を設定しますか?

1. テナント管理者としてポータルにサインインします。 https://portal.azure.com
2. 左側のウィンドウで Active Directory を選択します。
3. テナントを選択します。
4. [ 構成] を選択します。
5. クォータを無制限に設定します。

dmwappushsvc とは

mdm for Windows 10 バージョン 20H2 の新機能

mdm for Windows 10 バージョン 2004 の新機能

mdm for Windows 10 バージョン 1909 の新機能

mdm for Windows 10 バージョン 1903 の新機能

MDM for Windows 10 Version 1809の新機能

MDM ドキュメントの変更履歴

MDM ドキュメントで何が変更されたかについては、MDM の 変更履歴に関するドキュメントを参照してください。