This commit is contained in:
jaimeo
2019-03-28 09:26:45 -07:00
488 changed files with 3233 additions and 2253 deletions

View File

@ -112,7 +112,7 @@ Also, the pause period is calculated from the set start date. For more details,
## Monitor Windows Updates by using Update Compliance
Update Compliance, now **available in public preview**, provides a holistic view of OS update compliance, update deployment progress, and failure troubleshooting for Windows 10 devices. This new service uses diagnostic data including installation progress, Windows Update configuration, and other information to provide such insights, at no extra cost and without additional infrastructure requirements. Whether used with Windows Update for Business or other management tools, you can be assured that your devices are properly updated.
Update Compliance provides a holistic view of OS update compliance, update deployment progress, and failure troubleshooting for Windows 10 devices. This new service uses diagnostic data including installation progress, Windows Update configuration, and other information to provide such insights, at no extra cost and without additional infrastructure requirements. Whether used with Windows Update for Business or other management tools, you can be assured that your devices are properly updated.
![Update Compliance Dashboard](images/waas-wufb-update-compliance.png)

View File

@ -117,8 +117,7 @@ The concept of servicing channels is new, but organizations can use the same man
### Semi-Annual Channel
In the Semi-Annual servicing channel, feature updates are available as soon as Microsoft releases them. Windows 10, version 1511, had few servicing tool options to delay feature updates, limiting the use of the Semi-Annual servicing channel. Windows 10, version 1607 and onward, includes more servicing tools that can delay feature updates for up to 365 days. This servicing modal is ideal for pilot deployments and testing of Windows 10 feature updates and for users such as developers who need to work with the latest features immediately.
Once the latest release went through pilot deployment and testing, you choose the timing at which it goes into broad deployment.
In the Semi-Annual servicing channel, feature updates are available as soon as Microsoft releases them. Windows 10, version 1511, had few servicing tool options to delay feature updates, limiting the use of the Semi-Annual servicing channel. Windows 10, version 1607 and onward, includes more servicing tools that can delay feature updates for up to 365 days. This servicing model is ideal for pilot deployments and testing of Windows 10 feature updates and for users such as developers who need to work with the latest features immediately. Once the latest release has gone through pilot deployment and testing, you will be able to choose the timing at which it goes into broad deployment.
When Microsoft officially releases a feature update for Windows 10, it is made available to any PC not configured to defer feature updates so that those devices can immediately install it. Organizations that use Windows Server Update Services (WSUS), Microsoft System Center Configuration Manager, or Windows Update for Business, however, can defer feature updates to selective devices by withholding their approval and deployment. In this scenario, the content available for the Semi-Annual Channel will be available but not necessarily immediately mandatory, depending on the policy of the management system. For more details about Windows 10 servicing tools, see [Servicing tools](#servicing-tools).
@ -146,7 +145,7 @@ Microsoft never publishes feature updates through Windows Update on devices that
>[!NOTE]
>Windows 10 LTSB will support the currently released processors and chipsets at the time of release of the LTSB. As future CPU generations are released, support will be created through future Windows 10 LTSB releases that customers can deploy for those systems. For more information, see **Supporting the latest processor and chipsets on Windows** in [Lifecycle support policy FAQ - Windows Products](https://support.microsoft.com/help/18581/lifecycle-support-policy-faq-windows-products).
The Long-term Servicing Channel is available only in the Windows 10 Enterprise LTSB edition. This edition of Windows doesnt include a number of applications, such as Microsoft Edge, Microsoft Store, Cortana (though limited search capabilities remain available), Microsoft Mail, Calendar, OneNote, Weather, News, Sports, Money, Photos, Camera, Music, and Clock. These apps are not supported in Windows 10 Enterprise LTSB edition, even of you install by using sideloading.
The Long-term Servicing Channel is available only in the Windows 10 Enterprise LTSB edition. This edition of Windows doesnt include a number of applications, such as Microsoft Edge, Microsoft Store, Cortana (though limited search capabilities remain available), Microsoft Mail, Calendar, OneNote, Weather, News, Sports, Money, Photos, Camera, Music, and Clock. These apps are not supported in Windows 10 Enterprise LTSB edition, even if you install by using sideloading.
>[!NOTE]
>If an organization has devices currently running Windows 10 Enterprise LTSB that it would like to change to the Semi-Annual Channel, it can make the change without losing user data. Because LTSB is its own SKU, however, an upgrade is required from Windows 10 Enterprise LTSB to Windows 10 Enterprise, which supports the Semi-Annual Channel.

View File

@ -17,15 +17,15 @@ ms.topic: article
**Applies to**
- Windows 10
- Windows 10 Mobile
- Windows 10 Mobile
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
> **Looking for consumer information?** See [Windows Update: FAQ](https://support.microsoft.com/help/12373/windows-update-faq)
You can use Group Policy settings, mobile device management (MDM) or Registry (not recommended) to configure when devices will restart after a Windows 10 update is installed. You can schedule update installation and set policies for restart, configure active hours for when restarts will not occur, or you can do both.
## Schedule update installation
In Group Policy, within **Configure Automatic Updates**, you can configure a forced restart after a specified installation time.
In Group Policy, within **Configure Automatic Updates**, you can configure a forced restart after a specified installation time.
To set the time, you need to go to **Configure Automatic Updates**, select option **4 - Auto download and schedule the install**, and then enter a time in the **Scheduled install time** dropdown. Alternatively, you can specify that installation will occur during the automatic maintenance time (configured using **Computer Configuration\Administrative Templates\Windows Components\Maintenance Scheduler**).
@ -40,7 +40,7 @@ For a detailed description of these registry keys, see [Registry keys used to ma
When **Configure Automatic Updates** is enabled in Group Policy, you can enable one of the following additional policies to delay an automatic reboot after update installation:
- **Turn off auto-restart for updates during active hours** prevents automatic restart during active hours.
- **No auto-restart with logged on users for scheduled automatic updates installations** prevents automatic restart when a user is signed in. If a user schedules the restart in the update notification, the device will restart at the time the user specifies even if a user is signed in at the time. This policy only applies when **Configure Automatic Updates** is set to option **4-Auto download and schedule the install**.
- **No auto-restart with logged on users for scheduled automatic updates installations** prevents automatic restart when a user is signed in. If a user schedules the restart in the update notification, the device will restart at the time the user specifies even if a user is signed in at the time. This policy only applies when **Configure Automatic Updates** is set to option **4-Auto download and schedule the install**.
You can also use Registry, to prevent automatic restarts when a user is signed in. Under **HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU**, set **AuOptions** to **4** and enable **NoAutoRebootWithLoggedOnUsers**. As with Group Policy, if a user schedules the restart in the update notification, it will override this setting.
@ -48,9 +48,9 @@ For a detailed description of these registry keys, see [Registry keys used to ma
## Configure active hours
*Active hours* identify the period of time when you expect the device to be in use. Automatic restarts after an update will occur outside of the active hours.
*Active hours* identify the period of time when you expect the device to be in use. Automatic restarts after an update will occur outside of the active hours.
By default, active hours are from 8 AM to 5 PM on PCs and from 5 AM to 11 PM on phones. Users can change the active hours manually.
By default, active hours are from 8 AM to 5 PM on PCs and from 5 AM to 11 PM on phones. Users can change the active hours manually.
Starting with Windows 10, version 1703, you can also specify the max active hours range. The specified range will be counted from the active hours start time.
@ -89,7 +89,7 @@ For a detailed description of these registry keys, see [Registry keys used to ma
With Windows 10, version 1703, administrators can specify the max active hours range users can set. This option gives you additional flexibility to leave some of the decision for active hours on the user's side, while making sure you allow enough time for updating. The max range is calculated from active hours start time.
To configure active hours max range through Group Policy, go to **Computer Configuration\Administrative Templates\Windows Components\Windows Update** and open the **Specify active hours range for auto-restarts**.
To configure active hours max range through Group Policy, go to **Computer Configuration\Administrative Templates\Windows Components\Windows Update** and open the **Specify active hours range for auto-restarts**.
To configure active hours max range through MDM, use [**Update/ActiveHoursMaxRange**](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider?UpdatePolicies#update-activehoursmaxrange).
@ -103,9 +103,9 @@ In Windows 10, version 1703, we have added settings to control restart notificat
### Auto-restart notifications
Administrators can override the default behavior for the auto-restart required notification. By default, this notification will dismiss automatically.
Administrators can override the default behavior for the auto-restart required notification. By default, this notification will dismiss automatically.
To configure this behavior through Group Policy, go to **Computer Configuration\Administrative Templates\Windows Components\Windows Update** and select **Configure auto-restart required notification for updates**. When configured to **2 - User Action**, a user that gets this notification must manually dismiss it.
To configure this behavior through Group Policy, go to **Computer Configuration\Administrative Templates\Windows Components\Windows Update** and select **Configure auto-restart required notification for updates**. When configured to **2 - User Action**, a user that gets this notification must manually dismiss it.
To configure this behavior through MDM, use [**Update/AutoRestartRequiredNotificationDismissal**](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider?UpdatePolicies#update-AutoRestartRequiredNotificationDismissal)
@ -170,7 +170,7 @@ The following tables list registry values that correspond to the Group Policy se
| Registry key | Key type | Value |
| --- | --- | --- |
| ActiveHoursEnd | REG_DWORD | 0-23: set active hours to end at a specific hour</br>starts with 12 AM (0) and ends with 11 PM (23) |
| ActiveHoursStart | REG_DWORD | 0-23: set active hours to start at a specific hour</br>starts with 12 AM (0) and ends with 11 PM (23) |
| ActiveHoursStart | REG_DWORD | 0-23: set active hours to start at a specific hour</br>starts with 12 AM (0) and ends with 11 PM (23) |
| SetActiveHours | REG_DWORD | 0: disable automatic restart after updates outside of active hours</br>1: enable automatic restart after updates outside of active hours |
**HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU**
@ -179,32 +179,24 @@ The following tables list registry values that correspond to the Group Policy se
| --- | --- | --- |
| AlwaysAutoRebootAtScheduledTime | REG_DWORD | 0: disable automatic reboot after update installation at scheduled time</br>1: enable automatic reboot after update installation at ascheduled time |
| AlwaysAutoRebootAtScheduledTimeMinutes | REG_DWORD | 15-180: set automatic reboot to occur after given minutes |
| AUOptions | REG_DWORD | 2: notify for download and automatically install updates</br>3: automatically download and notify for instllation of updates</br>4: Automatically download and schedule installation of updates</br>5: allow the local admin to configure these settings</br>**Note:** To configure restart behavior, set this value to **4** |
| NoAutoRebootWithLoggedOnUsers | REG_DWORD | 0: disable do not reboot if users are logged on</br>1: do not reboot after an update installation if a user is logged on</br>**Note:** If disabled : Automatic Updates will notify the user that the computer will automatically restarts in 5 minutes to complete the installation |
| AUOptions | REG_DWORD | 2: notify for download and notify for installation of updates</br>3: automatically download and notify for installation of updates</br>4: Automatically download and schedule installation of updates</br>5: allow the local admin to configure these settings</br>**Note:** To configure restart behavior, set this value to **4** |
| NoAutoRebootWithLoggedOnUsers | REG_DWORD | 0: disable do not reboot if users are logged on</br>1: do not reboot after an update installation if a user is logged on</br>**Note:** If disabled : Automatic Updates will notify the user that the computer will automatically restart in 5 minutes to complete the installation |
| ScheduledInstallTime | REG_DWORD | 0-23: schedule update installation time to a specific hour</br>starts with 12 AM (0) and ends with 11 PM (23) |
There are 3 different registry combinations for controlling restart behavior:
- To set active hours, **SetActiveHours** should be **1**, while **ActiveHoursStart** and **ActiveHoursEnd** should define the time range.
- To schedule a specific installation and reboot time, **AUOptions** should be **4**, **ScheduledInstallTime** should specify the installation time, **AlwaysAutoRebootAtScheduledTime** set to **1** and **AlwaysAutoRebootAtScheduledTimeMinutes** should specify number of minutes to wait before rebooting.
- To delay rebooting if a user is logged on, **AUOptions** should be **4**, while **NoAutoRebootWithLoggedOnUsers** is set to **1**.
- To delay rebooting if a user is logged on, **AUOptions** should be **4**, while **NoAutoRebootWithLoggedOnUsers** is set to **1**.
## Related topics
- [Update Windows 10 in the enterprise](index.md)
- [Overview of Windows as a service](waas-overview.md)
- [Manage updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md)
- [Manage updates for Windows 10 Mobile Enterprise and Windows 10 IoT Mobile](waas-mobile-updates.md)
- [Configure Delivery Optimization for Windows 10 updates](waas-delivery-optimization.md)
- [Configure BranchCache for Windows 10 updates](waas-branchcache.md)
- [Configure Windows Update for Business](waas-configure-wufb.md)
- [Integrate Windows Update for Business with management solutions](waas-integrate-wufb.md)
- [Walkthrough: use Group Policy to configure Windows Update for Business](waas-wufb-group-policy.md)
- [Walkthrough: use Intune to configure Windows Update for Business](waas-wufb-intune.md)

View File

@ -42,6 +42,8 @@ If you've followed the steps in the [Enrolling devices in Windows Analytics](win
[Device names not appearing for Windows 10 devices](#device-names-not-appearing-for-windows-10-devices)
[Custom log queries using the AbnormalShutdownCount field of Device Health show zero or lower than expected results](#custom-log-queries-using-the-abnormalshutdowncount-field-of-device-health-show-zero-or-lower-than-expected-results)
[Disable Upgrade Readiness](#disable-upgrade-readiness)
[Exporting large data sets](#exporting-large-data-sets)
@ -54,7 +56,7 @@ In Log Analytics, go to **Settings > Connected sources > Windows telemetry** and
Even though devices can take 2-3 days after enrollment to show up due to latency in the system, you can now verify the status of your devices with a few hours of running the deployment script as described in [You can now check on the status of your computers within hours of running the deployment script](https://blogs.technet.microsoft.com/upgradeanalytics/2017/05/12/wheres-my-data/) on the Windows Analytics blog.
>[!NOTE]
> If you generate the status report and get an error message saying "Sorry! Were not recognizing your Commercial Id," go to **Settings > Connected sources > Windows telemetry** and unsubscribe, wait a minute and then re-subscribe to Upgrade Readiness.
> If you generate the status report and get an error message saying "Sorry! Were not recognizing your Commercial Id," go to **Settings > Connected sources > Windows telemetry** remove the Upgrade Readiness solution, and then re-add it.
If devices are not showing up as expected, find a representative device and follow these steps to run the latest pilot version of the Upgrade Readiness deployment script on it to troubleshoot issues:
@ -78,7 +80,7 @@ If you have deployed images that have not been generalized, then many of them mi
[![Device Reliability tile showing device count highlighted](images/device-reliability-device-count.png)](images/device-reliability-device-count.png)
If you have devices that appear in other solutions, but not Device Health, follow these steps to investigate the issue:
If you have devices that appear in other solutions, but not Device Health (the Device Health overview tile shows "Performing Assessment" or the device count is lower than expected), follow these steps to investigate the issue:
1. Using the Azure portal, remove the Device Health (appears as DeviceHealthProd on some pages) solution from your Log Analytics workspace. After completing this, add the Device Health solution to you workspace again.
2. Confirm that the devices are running Windows 10.
3. Verify that the Commercial ID is present in the device's registry. For details see [https://gpsearch.azurewebsites.net/#13551](https://gpsearch.azurewebsites.net/#13551).
@ -201,6 +203,20 @@ Finally, Upgrade Readiness only collects IE site discovery data on devices that
### Device names not appearing for Windows 10 devices
Starting with Windows 10, version 1803, the device name is no longer collected by default and requires a separate opt-in. For more information, see [Enrolling devices in Windows Analytics](windows-analytics-get-started.md). Allowing device names to be collected can make it easier for you to identify individual devices that report problems. Without the device name, Windows Analytics can only label devices by a GUID that it generates.
### Custom log queries using the AbnormalShutdownCount field of Device Health show zero or lower than expected results
This issue affects custom queries of the Device Health data by using the **Logs > Search page** or API. It does not impact any of the built-in tiles or reports of the Device Health solution. The **AbnormalShutdownCount** field of the **DHOSReliability** data table represents abnormal shutdowns other than crashes, such as sudden power loss or holding down the power button.
We have identified an incompatibility between AbnormalShutdownCount and the Limited Enhanced diagnostic data level on Windows 10, versions 1709, 1803, and 1809. Such devices do not send the abnormal shutdown signal to Microsoft. You should not rely on AbnormalShutdownCount in your custom queries unless you use any one of the following workarounds:
- Upgrade devices to Windows 10, version 1903 when available. Participants in the Windows Insider program can preview this change using Windows Insider builds.
- Change the diagnostic data setting from devices running Windows 10, versions 1709, 1803, and 1809 normal Enhanced level instead of Limited Enhanced.
- Use alternative data from devices to track abnormal shutdowns. For example, you can forward abnormal shutdown events from the Windows Event Log to your Log Analytics workspace by using the Log Analytics agent. Suggested events to forward include:
- Log: System, ID: 41, Source: Kernel-Power
- Log System, ID: 6008, Source: EventLog
### Disable Upgrade Readiness
If you want to stop using Upgrade Readiness and stop sending diagnostic data to Microsoft, follow these steps:

View File

@ -51,4 +51,7 @@ Use Upgrade Readiness to get:
- Application usage information, allowing targeted validation; workflow to track validation progress and decisions
- Data export to commonly used software deployment tools, including System Center Configuration Manager
To get started with any of these solutions, visit the links for instructions to add it to Azure Portal.
To get started with any of these solutions, visit the links for instructions to add it to Azure Portal.
>[!NOTE]
> For details about licensing requirements and costs associated with using Windows Analytics solutions, see [What are the requirements and costs for Windows Analytics solutions?](windows-analytics-FAQ-troubleshooting.md#what-are-the-requirements-and-costs-for-windows-analytics-solutions).