mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-20 21:03:42 +00:00
Fixes of "Window" to "Windows"
This commit is contained in:
@ -1075,7 +1075,7 @@ This article lists new and updated articles for the Mobile Device Management (MD
|
||||
<li>Defender/EnableGuardMyFolders to Defender/EnableControlledFolderAccess</li>
|
||||
</ul>
|
||||
<p>Added links to the additional <a href="policy-csp-bitlocker.md" data-raw-source="[ADMX-backed BitLocker policies](policy-csp-bitlocker.md)">ADMX-backed BitLocker policies</a>.</p>
|
||||
<p>There were issues reported with the previous release of the following policies. These issues were fixed in Window 10, version 1709:</p>
|
||||
<p>There were issues reported with the previous release of the following policies. These issues were fixed in Windows 10, version 1709:</p>
|
||||
<ul>
|
||||
<li>Privacy/AllowAutoAcceptPairingAndPrivacyConsentPrompts</li>
|
||||
<li>Start/HideAppList</li>
|
||||
|
@ -15,7 +15,7 @@ ms.topic: conceptual
|
||||
The eSIM Profile Management Solution puts the Mobile Device Management (MDM) Provider in the front and center. The whole idea is to use an already existing solution that customers are familiar with and that they use to manage devices. The expectations from an MDM are that it will use the same sync mechanism that it uses for device policies to push any policy to the eSIM profile, and be able to use Groups and Users the same way. This way, the eSIM profile download and the installation happen in the background without impacting the end user. Similarly, the IT admin would use the same method of managing the eSIM profiles (Assignment/de-assignment, etc.) the same way as they currently do device management.
|
||||
If you are a Mobile Device Management (MDM) Provider and want to support eSIM Management on Windows, perform the following steps:
|
||||
- Onboard to Azure Active Directory
|
||||
- Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Window OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Window OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. As an MDM provider, if you are looking to integrate/onboard to a mobile operator on a 1:1 basis, contact them and learn more about their onboarding. If you would like to integrate and work with only one MDM provider, contact that provider directly. If you would like to offer eSIM management to customers using different MDM providers, contact an orchestrator provider. Orchestrator providers act as proxy handling MDM onboarding as well as mobile operator onboarding. Their role is to make the process as painless and scalable as possible for all parties. Potential orchestrator providers you could contact include:
|
||||
- Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Windows OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Windows OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. As an MDM provider, if you are looking to integrate/onboard to a mobile operator on a 1:1 basis, contact them and learn more about their onboarding. If you would like to integrate and work with only one MDM provider, contact that provider directly. If you would like to offer eSIM management to customers using different MDM providers, contact an orchestrator provider. Orchestrator providers act as proxy handling MDM onboarding as well as mobile operator onboarding. Their role is to make the process as painless and scalable as possible for all parties. Potential orchestrator providers you could contact include:
|
||||
- [HPE’s Device Entitlement Gateway](https://www.hpe.com/emea_europe/en/solutions/digital-communications-services.html)
|
||||
- [IDEMIA’s The Smart Connect - Hub](https://www.idemia.com/smart-connect-hub)
|
||||
- Assess solution type that you would like to provide your customers
|
||||
|
@ -148,7 +148,7 @@ The following are the explicit requirements for the server.
|
||||
|
||||
- The <DiscoveryResponse><AuthenticationServiceUrl> element must support HTTPS.
|
||||
- The authentication server must use a device trusted root certificate. Otherwise, the WAP call will fail.
|
||||
- WP doesn’t support Window Integrated Authentication (WIA) for ADFS during WAB authentication. ADFS 2012 R2 if used needs to be configured to not attempt WIA for Windows device.
|
||||
- WP doesn’t support Windows Integrated Authentication (WIA) for ADFS during WAB authentication. ADFS 2012 R2 if used needs to be configured to not attempt WIA for Windows device.
|
||||
|
||||
The enrollment client issues an HTTPS request as follows:
|
||||
|
||||
|
@ -29,7 +29,7 @@ The following actions are supported:
|
||||
> - Azure AD Hybrid joined devices.
|
||||
> - Devices that use both GPO and CSP at the same time.
|
||||
>
|
||||
> The minimum operating system requirement for this CSP is Windows 10, version 2004. This CSP is supported only in Microsoft Surface Hub prior to Window 10, version 2004.
|
||||
> The minimum operating system requirement for this CSP is Windows 10, version 2004. This CSP is supported only in Microsoft Surface Hub prior to Windows 10, version 2004.
|
||||
|
||||
The following shows the NetworkQoSPolicy configuration service provider in tree format.
|
||||
```
|
||||
|
@ -2141,7 +2141,7 @@ Do not allow update deferral policies to cause scans against Windows Update. If
|
||||
|
||||
For more information about dual scan, see [Demystifying "Dual Scan"](/archive/blogs/wsus/demystifying-dual-scan) and [Improving Dual Scan on 1607](/archive/blogs/wsus/improving-dual-scan-on-1607).
|
||||
|
||||
This is the same as the Group Policy in Windows Components > Window Update "Do not allow update deferral policies to cause scans against Windows Update."
|
||||
This is the same as the Group Policy in Windows Components > Windows Update "Do not allow update deferral policies to cause scans against Windows Update."
|
||||
|
||||
Value type is integer. Supported operations are Add, Get, Replace, and Delete.
|
||||
|
||||
|
@ -19,7 +19,7 @@ Starting in Windows 10 version 1703, Mobile Device Management (MDM) policy confi
|
||||
|
||||
## <a href="" id="background"></a>Background
|
||||
|
||||
In addition to standard MDM policies, the Policy CSP can also handle selected set of ADMX policies. In an ADMX policy, an administrative template contains the metadata of a Window Group Policy and can be edited in the Local Group Policy Editor on a PC. Each administrative template specifies the registry keys (and their values) that are associated with a Group Policy and defines the policy settings that can be managed. Administrative templates organize Group Policies in a hierarchy in which each segment in the hierarchical path is defined as a category. Each setting in a Group Policy administrative template corresponds to a specific registry value. These Group Policy settings are defined in a standards-based, XML file format known as an ADMX file. For more information, see [Group Policy ADMX Syntax Reference Guide](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753471(v=ws.10)).
|
||||
In addition to standard MDM policies, the Policy CSP can also handle selected set of ADMX policies. In an ADMX policy, an administrative template contains the metadata of a Windows Group Policy and can be edited in the Local Group Policy Editor on a PC. Each administrative template specifies the registry keys (and their values) that are associated with a Group Policy and defines the policy settings that can be managed. Administrative templates organize Group Policies in a hierarchy in which each segment in the hierarchical path is defined as a category. Each setting in a Group Policy administrative template corresponds to a specific registry value. These Group Policy settings are defined in a standards-based, XML file format known as an ADMX file. For more information, see [Group Policy ADMX Syntax Reference Guide](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753471(v=ws.10)).
|
||||
|
||||
ADMX files can either describe operating system (OS) Group Policies that are shipped with Windows or they can describe settings of applications, which are separate from the OS and can usually be downloaded and installed on a PC.
|
||||
Depending on the specific category of the settings that they control (OS or application), the administrative template settings are found in the following two locations in the Local Group Policy Editor:
|
||||
|
Reference in New Issue
Block a user