diff --git a/windows/deployment/update/waas-configure-wufb.md b/windows/deployment/update/waas-configure-wufb.md index 4b1673fbe0..7aebbab370 100644 --- a/windows/deployment/update/waas-configure-wufb.md +++ b/windows/deployment/update/waas-configure-wufb.md @@ -220,7 +220,7 @@ The following are quick-reference tables of the supported policy values for Wind | GPO Key | Key type | Value | | --- | --- | --- | -| BranchReadinessLevel | REG_DWORD | 2: systems take Feature Updates for the Windows Insider build - Fast (added in Windows 10, version 1709)
4: systems take Feature Updates for the Windows Insider build - Slow (added in Windows 10, version 1709)
8: systems take Feature Updates for the Release Windows Insider build (added in Windows 10, version 1709)
16: for Windows 10, version 1703: systems take Feature Updates for the Current Branch (CB); for Windows 10, version 1709, 1803 and 1809: systems take Feature Updates from Semi-annual Channel (Targeted) (SAC-T); for Windows 10, version 1903 or later: systems take Feature Updates from Semi-annual Channel
32: systems take Feature Updates from Semi-annual Channel
Note: Other value or absent: receive all applicable updates | +| BranchReadinessLevel | REG_DWORD | 2: systems take Feature Updates for the Windows Insider build - Fast (added in Windows 10, version 1709)
4: systems take Feature Updates for the Windows Insider build - Slow (added in Windows 10, version 1709)
8: systems take Feature Updates for the Release Windows Insider build (added in Windows 10, version 1709)
16: for Windows 10, version 1703: systems take Feature Updates for the Current Branch (CB); for Windows 10, version 1709, 1803 and 1809: systems take Feature Updates from Semi-Annual Channel (Targeted) (SAC-T); for Windows 10, version 1903 or later: systems take Feature Updates from Semi-Annual Channel
32: systems take Feature Updates from Semi-Annual Channel
Note: Other value or absent: receive all applicable updates | | DeferQualityUpdates | REG_DWORD | 1: defer quality updates
Other value or absent: don’t defer quality updates | | DeferQualityUpdatesPeriodinDays | REG_DWORD | 0-35: defer quality updates by given days | | PauseQualityUpdatesStartTime | REG_DWORD | 1: pause quality updates
Other value or absent: don’t pause quality updates | @@ -234,7 +234,7 @@ The following are quick-reference tables of the supported policy values for Wind | MDM Key | Key type | Value | | --- | --- | --- | -| BranchReadinessLevel | REG_DWORD |2: systems take Feature Updates for the Windows Insider build - Fast (added in Windows 10, version 1709)
4: systems take Feature Updates for the Windows Insider build - Slow (added in Windows 10, version 1709)
8: systems take Feature Updates for the Release Windows Insider build (added in Windows 10, version 1709)
16: for Windows 10, version 1703: systems take Feature Updates for the Current Branch (CB); for Windows 10, version 1709, 1803 and 1809: systems take Feature Updates from Semi-annual Channel (Targeted) (SAC-T); for Windows 10, version 1903 or later: systems take Feature Updates from Semi-annual Channel
32: systems take Feature Updates from Semi-annual Channel
Note: Other value or absent: receive all applicable updates | +| BranchReadinessLevel | REG_DWORD |2: systems take Feature Updates for the Windows Insider build - Fast (added in Windows 10, version 1709)
4: systems take Feature Updates for the Windows Insider build - Slow (added in Windows 10, version 1709)
8: systems take Feature Updates for the Release Windows Insider build (added in Windows 10, version 1709)
16: for Windows 10, version 1703: systems take Feature Updates for the Current Branch (CB); for Windows 10, version 1709, 1803 and 1809: systems take Feature Updates from Semi-Annual Channel (Targeted) (SAC-T); for Windows 10, version 1903 or later: systems take Feature Updates from Semi-Annual Channel
32: systems take Feature Updates from Semi-Annual Channel
Note: Other value or absent: receive all applicable updates | | DeferQualityUpdatesPeriodinDays | REG_DWORD | 0-35: defer quality updates by given days | | PauseQualityUpdatesStartTime | REG_DWORD | 1: pause quality updates
Other value or absent: don’t pause quality updates | | DeferFeatureUpdatesPeriodinDays | REG_DWORD | 0-365: defer feature updates by given days | diff --git a/windows/deployment/update/waas-integrate-wufb.md b/windows/deployment/update/waas-integrate-wufb.md index ac66d0b697..2dc3cc3ff3 100644 --- a/windows/deployment/update/waas-integrate-wufb.md +++ b/windows/deployment/update/waas-integrate-wufb.md @@ -68,7 +68,7 @@ For Windows 10, version 1607, devices can now be configured to receive updates f - Device is configured to defer Quality Updates using Windows Update for Business and to be managed by WSUS - Device is configured to “receive updates for other Microsoft products” along with updates to Windows (**Update/AllowMUUpdateService** = enabled) -- Admin has also placed Microsoft Update, third-paprty, and locally-published update content on the WSUS server +- Admin has also placed Microsoft Update, non-Microsoft, and locally published update content on the WSUS server In this example, the deferral behavior for updates to Office and other non-Windows products is slightly different than if WSUS were not enabled. - In a non-WSUS case, these updates would be deferred just as any update to Windows would be. diff --git a/windows/deployment/update/waas-servicing-strategy-windows-10-updates.md b/windows/deployment/update/waas-servicing-strategy-windows-10-updates.md index a4e91744b3..1ee1fa50de 100644 --- a/windows/deployment/update/waas-servicing-strategy-windows-10-updates.md +++ b/windows/deployment/update/waas-servicing-strategy-windows-10-updates.md @@ -30,9 +30,9 @@ In the past, traditional Windows deployments tended to be large, lengthy, and ex Windows 10 spreads the traditional deployment effort of a Windows upgrade, which typically occurred every few years, over smaller, continuous updates. With this change, you must approach the ongoing deployment and servicing of Windows differently. A strong Windows 10 deployment strategy begins with establishing a simple, repeatable process for testing and deploying each feature update. Here’s an example of what this process might look like: - **Configure test devices.** Configure test devices in the Windows Insider Program so that Insiders can test feature updates before they’re available to the Semi-Annual Channel. Typically, this would be a small number of test devices that IT staff members use to evaluate pre-release builds of Windows. Microsoft provides current development builds to Windows Insider members approximately every week so that interested users can see the functionality Microsoft is adding. See the section Windows Insider for details on how to enroll in the Windows Insider Program on a Windows 10 device. -- **Identify excluded devices.** For some organizations, special-purpose devices such as those used to control factory or medical equipment or run ATMs require a stricter, less frequent feature update cycle than the Semi-annual Channel can offer. For those machines, you must install Windows 10 Enterprise LTSB to avoid feature updates for up to 10 years. Identify these devices, and separate them from the phased deployment and servicing cycles to help remove confusion for your administrators and ensure that devices are handled correctly. +- **Identify excluded devices.** For some organizations, special-purpose devices such as those used to control factory or medical equipment or run ATMs require a stricter, less frequent feature update cycle than the Semi-Annual Channel can offer. For those machines, you must install Windows 10 Enterprise LTSB to avoid feature updates for up to 10 years. Identify these devices, and separate them from the phased deployment and servicing cycles to help remove confusion for your administrators and ensure that devices are handled correctly. - **Recruit volunteers.** The purpose of testing a deployment is to receive feedback. One effective way to recruit pilot users is to request volunteers. When doing so, clearly state that you’re looking for feedback rather than people to just “try it out” and that there could be occasional issues involved with accepting feature updates right away. With Windows as a service, the expectation is that there should be few issues, but if an issue does arise, you want testers to let you know as soon as possible. When considering whom to recruit for pilot groups, be sure to include members who provide the broadest set of applications and devices to validate the largest number of apps and devices possible. -- **Update Group Policy.** Each feature update includes new group policies to manage new features. If you use Group Policy to manage devices, the Group Policy Admin for the Active Directory domain will need to download a .admx package and copy it to their [Central Store](https://support.microsoft.com/help/929841/how-to-create-the-central-store-for-group-policy-administrative-templa) (or to the [PolicyDefinitions](https://msdn.microsoft.com/library/bb530196.aspx) directory in the SYSVOL of a domain controller if not using a Central Store). Always manage new group polices from the version of Windows 10 they shipped with by using the Remote Server Administration Tools. The ADMX download package is created at the end of each development cycle and then posted for download. To find the ADMX download package for a given Windows build, search for “ADMX download for Windows build xxxx”. For details about Group Policy management, see [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra) +- **Update Group Policy.** Each feature update includes new group policies to manage new features. If you use Group Policy to manage devices, the Group Policy Admin for the Active Directory domain will need to download a .admx package and copy it to their [Central Store](https://support.microsoft.com/help/929841/how-to-create-the-central-store-for-group-policy-administrative-templa) (or to the [PolicyDefinitions](https://msdn.microsoft.com/library/bb530196.aspx) directory in the SYSVOL folder of a domain controller if not using a Central Store). Always manage new group polices from the version of Windows 10 they shipped with by using the Remote Server Administration Tools. The ADMX download package is created at the end of each development cycle and then posted for download. To find the ADMX download package for a given Windows build, search for “ADMX download for Windows build xxxx”. For details about Group Policy management, see [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra) - **Choose a servicing tool.** Decide which product you’ll use to manage the Windows updates in your environment. If you’re currently using Windows Server Update Services (WSUS) or Microsoft Endpoint Configuration Manager to manage your Windows updates, you can continue using those products to manage Windows 10 updates. Alternatively, you can use Windows Update for Business. In addition to which product you’ll use, consider how you’ll deliver the updates. With Windows 10, multiple peer-to-peer options are available to make update distribution faster. For a comparison of tools, see [Servicing tools](waas-overview.md#servicing-tools). - **Prioritize applications.** First, create an application portfolio. This list should include everything installed in your organization and any webpages your organization hosts. Next, prioritize this list to identify those that are the most business critical. Because the expectation is that application compatibility with Windows 10 will be high, only the most business critical applications should be tested before the pilot phase; everything else can be tested afterwards. For more information about identifying compatibility issues withe applications, see [Manage Windows upgrades with Upgrade Analytics](../upgrade/manage-windows-upgrades-with-upgrade-readiness.md). @@ -44,7 +44,7 @@ Windows 10 spreads the traditional deployment effort of a Windows upgrade, which Each time Microsoft releases a Windows 10 feature update, the IT department should use the following high-level process to help ensure that the broad deployment is successful: 1. **Validate compatibility of business critical apps.** Test your most important business-critical applications for compatibility with the new Windows 10 feature update running on your Windows Insider machines identified in the earlier “Configure test machines” step of the Predeployment strategy section. The list of applications involved in this validation process should be small because most applications can be tested during the pilot phase. For more information about device and application compatibility in Windows 10, see the section Compatibility. -2. **Target and react to feedback.** With Windows 10, Microsoft expects application and device compatibility to be high, but it’s still important to have targeted groups within both the IT department and business units to verify application compatibility for the remaining applications in your application portfolio. Because only the most business-critical applications are tested beforehand, this will represent the majority of application compatibility testing in your environment. This should not necessarily be a formal process but rather user validation through the use of a particular application. So, the next step is to deploy the feature update to early-adopting IT users and your targeted groups running in the Semi-annual channel that you identified in the “Recruit volunteers” step of the Predeployment strategy section. Be sure to communicate clearly that you’re looking for feedback as soon as possible, and state exactly how users can submit feedback to you. Should an issue arise, have a remediation plan in place to address it. +2. **Target and react to feedback.** With Windows 10, Microsoft expects application and device compatibility to be high, but it’s still important to have targeted groups within both the IT department and business units to verify application compatibility for the remaining applications in your application portfolio. Because only the most business-critical applications are tested beforehand, this will represent the majority of application compatibility testing in your environment. This should not necessarily be a formal process but rather user validation through the use of a particular application. So, the next step is to deploy the feature update to early-adopting IT users and your targeted groups running in the Semi-Annual channel that you identified in the “Recruit volunteers” step of the Predeployment strategy section. Be sure to communicate clearly that you’re looking for feedback as soon as possible, and state exactly how users can submit feedback to you. Should an issue arise, have a remediation plan in place to address it. 3. **Deploy broadly.** Finally, focus on the large-scale deployment using deployment rings, like the ones discussed in Table 1. Build deployment rings that target groups of computers in your selected update-management product. To reduce risk as much as possible, construct your deployment rings in a way that splits individual departments into multiple rings. This way, if you were to encounter an issue, you don’t prevent any critical business from continuing. By using this method, each deployment ring reduces risk as more and more people have been updated in any particular department. diff --git a/windows/deployment/update/waas-wufb-group-policy.md b/windows/deployment/update/waas-wufb-group-policy.md index bd7614abe8..9c1f05c751 100644 --- a/windows/deployment/update/waas-wufb-group-policy.md +++ b/windows/deployment/update/waas-wufb-group-policy.md @@ -138,7 +138,7 @@ When you set these policies, installation happens automatically at the specified We recommend that you use **Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify deadline for automatic updates and restarts** for feature and quality updates to ensure that devices stay secure on Windows 10, version 1709 and later. This works by enabling you to specify the number of days that can elapse after an update is offered to a device before it must be installed. Also you can set the number of days that can elapse after a pending restart before the user is forced to restart. -This policies also offers an option to opt out of automatic restarts until a deadline is reached by presenting an "engaged restart experience" until the deadline has actually expired. At that point the device will automatically schedule a restart regardles of active hours. +This policies also offers an option to opt out of automatic restarts until a deadline is reached by presenting an "engaged restart experience" until the deadline has actually expired. At that point the device will automatically schedule a restart regardless of active hours. These notifications are what the user sees depending on the settings you choose: