mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 21:37:22 +00:00
resolved Acrolinx check failure
This commit is contained in:
parent
575edbd89e
commit
fc90ef4fd0
@ -28,27 +28,27 @@ Because a device may not always be connected to the internet, WNS supports cachi
|
|||||||
|
|
||||||
The following restrictions are related to push notifications and WNS:
|
The following restrictions are related to push notifications and WNS:
|
||||||
|
|
||||||
- Push for device management uses raw push notifications. This restriction means that these raw push notifications do not support or utilize push notification payloads.
|
- Push for device management uses raw push notifications. This restriction means that these raw push notifications don't support or utilize push notification payloads.
|
||||||
- Receipt of push notifications are sensitive to the Battery Saver and Data Sense settings on the device. For example, if the battery drops below certain thresholds, the persistent connection of the device with WNS will be terminated. Additionally, if the user is utilizing Data Sense and has exceeded their monthly allotment of data, the persistent connection of the device with WNS will also be terminated.
|
- Receipt of push notifications is sensitive to the Battery Saver and Data Sense settings on the device. For example, if the battery drops below certain thresholds, the persistent connection of the device with WNS will be terminated. Additionally, if the user is utilizing Data Sense and has exceeded their monthly allotment of data, the persistent connection of the device with WNS will also be terminated.
|
||||||
- A ChannelURI provided to the management server by the device is only valid for 30 days. The device automatically renews the ChannelURI after 15 days and triggers a management session on successful renewal of the ChannelURI. It is strongly recommended that, during every management session, the management server queries the ChannelURI value to ensure that it has received the latest value. This will ensure that the management server will not attempt to use a ChannelURI that has expired.
|
- A ChannelURI provided to the management server by the device is only valid for 30 days. The device automatically renews the ChannelURI after 15 days and triggers a management session on successful renewal of the ChannelURI. It's strongly recommended that, during every management session, the management server queries the ChannelURI value to ensure that it has received the latest value. This will ensure that the management server won't attempt to use a ChannelURI that has expired.
|
||||||
- Push is not a replacement for having a polling schedule.
|
- Push isn't a replacement for having a polling schedule.
|
||||||
- WNS reserves the right to block push notifications to your PFN if improper use of notifications is detected. Any devices being managed using this PFN will cease to have push initiated device management support.
|
- WNS reserves the right to block push notifications to your PFN if improper use of notifications is detected. Any devices being managed using this PFN will cease to have push initiated device management support.
|
||||||
- On Windows 10, version 1511 as well as Windows 8 and 8.1, MDM Push may fail to renew the WNS Push channel automatically causing it to expire. It can also potentially hang when setting the PFN for the channel.
|
- On Windows 10, version 1511 as well as Windows 8 and 8.1, MDM Push may fail to renew the WNS Push channel automatically causing it to expire. It can also potentially hang when setting the PFN for the channel.
|
||||||
|
|
||||||
To work around this issue, when a 410 is returned by the WNS server when attempting to send a Push notification to the device the PFN should be set during the next sync session. To prevent the push channel from expiring on older builds, servers can reset the PFN before the channel expires (~30 days). If they’re already running Windows 10, there should be an update available that they can install that should fix the issue.
|
To work around this issue, when a 410 is returned by the WNS server when attempting to send a Push notification to the device the PFN should be set during the next sync session. To prevent the push channel from expiring on older builds, servers can reset the PFN before the channel expires (~30 days). If they’re already running Windows 10, there should be an update available that they can install that should fix the issue.
|
||||||
|
|
||||||
- On Windows 10, version 1511, we use the following retry logic for the DMClient:
|
- On Windows 10, version 1511, we use the following retry logic for the DMClient:
|
||||||
- If ExpiryTime is greater than 15 days a schedule is set for when 15 days are left.
|
- If ExpiryTime is greater than 15 days, a schedule is set for when 15 days are left.
|
||||||
- If ExpiryTime is between now and 15 days a schedule set for 4 +/- 1 hours from now.
|
- If ExpiryTime is between now and 15 days, a schedule set for 4 +/- 1 hours from now.
|
||||||
- If ExpiryTime has passed a schedule is set for 1 day +/- 4 hours from now.
|
- If ExpiryTime has passed, a schedule is set for 1 day +/- 4 hours from now.
|
||||||
|
|
||||||
|
|
||||||
- On Windows 10, version 1607, we check for network connectivity before retrying. We do not check for internet connectivity. If network connectivity is not available we will skip the retry and set schedule for 4+/-1 hours to try again.
|
- On Windows 10, version 1607, we check for network connectivity before retrying. We don't check for internet connectivity. If network connectivity isn't available, we'll skip the retry and set schedule for 4+/-1 hours to try again.
|
||||||
|
|
||||||
|
|
||||||
## Get WNS credentials and PFN for MDM push notification
|
## Get WNS credentials and PFN for MDM push notification
|
||||||
|
|
||||||
To get a PFN and WNS credentials, you must create an Microsoft Store app.
|
To get a PFN and WNS credentials, you must create a Microsoft Store app.
|
||||||
|
|
||||||
1. Go to the Windows [Dashboard](https://dev.windows.com/en-US/dashboard) and sign in with your developer account.
|
1. Go to the Windows [Dashboard](https://dev.windows.com/en-US/dashboard) and sign in with your developer account.
|
||||||
|
|
||||||
@ -68,8 +68,8 @@ To get a PFN and WNS credentials, you must create an Microsoft Store app.
|
|||||||
6. Click **Live Services site**. A new window opens for the **Application Registration Portal** page.
|
6. Click **Live Services site**. A new window opens for the **Application Registration Portal** page.
|
||||||
|
|
||||||

|

|
||||||
7. In the **Application Registration Portal** page, you will see the properties for the app that you created, such as:
|
7. In the **Application Registration Portal** page, you'll see the properties for the app that you created, such as:
|
||||||
- Application Id
|
- Application ID
|
||||||
- Application Secrets
|
- Application Secrets
|
||||||
- Microsoft Store Package SID, Application Identity, and Publisher.
|
- Microsoft Store Package SID, Application Identity, and Publisher.
|
||||||
|
|
||||||
@ -80,6 +80,6 @@ To get a PFN and WNS credentials, you must create an Microsoft Store app.
|
|||||||
11. From the left nav, expand **App management** and then click **App identity**.
|
11. From the left nav, expand **App management** and then click **App identity**.
|
||||||
|
|
||||||

|

|
||||||
12. In the **App identity** page, you will see the **Package Family Name (PFN)** of your app.
|
12. In the **App identity** page, you'll see the **Package Family Name (PFN)** of your app.
|
||||||
|
|
||||||
|
|
||||||
|
@ -33,11 +33,11 @@ The root node.
|
|||||||
<a href="" id="requirenetworkinoobe"></a>**RequireNetworkInOOBE**
|
<a href="" id="requirenetworkinoobe"></a>**RequireNetworkInOOBE**
|
||||||
Specifies whether to require a network connection during the out-of-box experience (OOBE) at first sign in.
|
Specifies whether to require a network connection during the out-of-box experience (OOBE) at first sign in.
|
||||||
|
|
||||||
When RequireNetworkInOOBE is true, when the device goes through OOBE at first sign in or after a reset, the user is required to choose a network before proceeding. There is no "skip for now" option.
|
When RequireNetworkInOOBE is true, when the device goes through OOBE at first sign in or after a reset, the user is required to choose a network before proceeding. There's no "skip for now" option.
|
||||||
|
|
||||||
Value type is bool. Supported operations are Get and Replace.
|
Value type is bool. Supported operations are Get and Replace.
|
||||||
|
|
||||||
- True - Require network in OOBE
|
- True - Require network in OOBE
|
||||||
- False - No network connection requirement in OOBE
|
- False - No network connection requirement in OOBE
|
||||||
|
|
||||||
Example scenario: Henry is the IT admin at Contoso. He deploys 1000 devices successfully with RequireNetworkInOOBE set to true. When users accidentally or intentionally reset their device, they are required to connect to a network before they can proceed. Upon successful connection, users see the Contoso branded sign-in experience where they must use their Azure AD credentials. There is no option to skip the network connection and create a local account.
|
Example scenario: Henry is the IT admin at Contoso. He deploys 1000 devices successfully with RequireNetworkInOOBE set to true. When users accidentally or intentionally reset their device, they're required to connect to a network before they can proceed. Upon successful connection, users see the Contoso branded sign-in experience where they must use their Azure AD credentials. There's no option to skip the network connection and create a local account.
|
||||||
|
Loading…
x
Reference in New Issue
Block a user