mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-19 20:33:42 +00:00
Merging changes synced from https://github.com/MicrosoftDocs/windows-docs-pr (branch live)
This commit is contained in:
Learn Build Service GitHub App
@ -2143,9 +2143,9 @@ If the status is set to Not Configured, use of Automatic Updates is not specifie
|
||||
|
||||
| Value | Description |
|
||||
|:--|:--|
|
||||
| 0 | Notify the user before downloading the update. This policy is used by the enterprise who wants to enable the end-users to manage data usage. With this option users are notified when there are updates that apply to the device and are ready for download. Users can download and install the updates from the Windows Update control panel. |
|
||||
| 1 | Auto install the update and then notify the user to schedule a device restart. Updates are downloaded automatically on non-metered networks and installed during "Automatic Maintenance" when the device is not in use and is not running on battery power. If automatic maintenance is unable to install updates for two days, Windows Update will install updates immediately. If the installation requires a restart, the end-user is prompted to schedule the restart time. The end-user has up to seven days to schedule the restart and after that, a restart of the device is forced. Enabling the end-user to control the start time reduces the risk of accidental data loss caused by applications that do not shutdown properly on restart. |
|
||||
| 2 (Default) | Auto install and restart. Updates are downloaded automatically on non-metered networks and installed during "Automatic Maintenance" when the device is not in use and is not running on battery power. If automatic maintenance is unable to install updates for two days, Windows Update will install updates right away. If a restart is required, then the device is automatically restarted when the device is not actively being used. This is the default behavior for unmanaged devices. Devices are updated quickly, but it increases the risk of accidental data loss caused by an application that does not shutdown properly on restart. |
|
||||
| 0 | Notify the user before downloading the update. This policy is used by the enterprise who wants to enable the end-users to manage data usage. With this option, users are notified when there are updates that apply to the device and are ready for download. Users can download and install the updates from the Windows Update control panel. |
|
||||
| 1 | Auto install the update and then notify the user to schedule a device restart. Updates are downloaded automatically on non-metered networks and installed during "Automatic Maintenance" when the device is not in use and is not running on battery power. If automatic maintenance is unable to install updates for two days, Windows Update will install updates immediately. If the installation requires a restart, the end-user is prompted to schedule the restart time. The end-user has up to seven days to schedule the restart and after that, a restart of the device is forced. Enabling the end-user to control the start time reduces the risk of accidental data loss caused by applications that do not shut down properly on restart. |
|
||||
| 2 (Default) | Auto install and restart. Updates are downloaded automatically on non-metered networks and installed during "Automatic Maintenance" when the device is not in use and is not running on battery power. If automatic maintenance is unable to install updates for two days, Windows Update will install updates right away. If a restart is required, then the device is automatically restarted when the device is not actively being used. This is the default behavior for unmanaged devices. Devices are updated quickly, but it increases the risk of accidental data loss caused by an application that does not shut down properly on restart. |
|
||||
| 3 | Auto install and restart at a specified time. The IT specifies the installation day and time. If no day and time are specified, the default is 3 AM daily. Automatic installation happens at this time and device restart happens after a 15-minute countdown. If the user is logged in when Windows is ready to restart, the user can interrupt the 15-minute countdown to delay the restart. |
|
||||
| 4 | Auto install and restart without end-user control. Updates are downloaded automatically on non-metered networks and installed during "Automatic Maintenance" when the device is not in use and is not running on battery power. If automatic maintenance is unable to install updates for two days, Windows Update will install updates right away. If a restart is required, then the device is automatically restarted when the device is not actively being used. This setting option also sets the end-user control panel to read-only. |
|
||||
| 5 | Turn off automatic updates. |
|
||||
@ -3069,6 +3069,15 @@ If the status is set to Not Configured, use of Automatic Updates is not specifie
|
||||
|
||||
<!-- ScheduledInstallFirstWeek-Editable-Begin -->
|
||||
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
|
||||
The ScheduledInstall*week policies operate on numeric days.
|
||||
|
||||
- [ScheduledInstallFirstWeek](#scheduledinstallfirstweek): First week of the month (Days 1-7).
|
||||
- [ScheduledInstallSecondWeek](#scheduledinstallsecondweek): Second week of the month (Days 8-14).
|
||||
- [ScheduledInstallThirdWeek](#scheduledinstallthirdweek): Third week of the month (Days 15-21).
|
||||
- [ScheduledInstallFourthWeek](#scheduledinstallfourthweek): Fourth week of the month (Days 22-31).
|
||||
|
||||
These policies are not exclusive and can be used in any combination. Together with [ScheduledInstallDay](#scheduledinstallday), it defines the ordinal number of a weekday in a month. E.g. [ScheduledInstallSecondWeek](#scheduledinstallsecondweek) + [ScheduledInstallDay](#scheduledinstallday) = 3 is 2nd Tuesday of the month. If the device is unavailable at the scheduled time, it can postpone installation of updates until the next month.
|
||||
|
||||
> [!NOTE]
|
||||
> This policy will only take effect if [Update/AllowAutoUpdate](#allowautoupdate) has been configured to option 3 or 4 for scheduled installation.
|
||||
<!-- ScheduledInstallFirstWeek-Editable-End -->
|
||||
@ -3167,6 +3176,15 @@ If the status is set to Not Configured, use of Automatic Updates is not specifie
|
||||
|
||||
<!-- ScheduledInstallFourthWeek-Editable-Begin -->
|
||||
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
|
||||
The ScheduledInstall*week policies operate on numeric days.
|
||||
|
||||
- [ScheduledInstallFirstWeek](#scheduledinstallfirstweek): First week of the month (Days 1-7).
|
||||
- [ScheduledInstallSecondWeek](#scheduledinstallsecondweek): Second week of the month (Days 8-14).
|
||||
- [ScheduledInstallThirdWeek](#scheduledinstallthirdweek): Third week of the month (Days 15-21).
|
||||
- [ScheduledInstallFourthWeek](#scheduledinstallfourthweek): Fourth week of the month (Days 22-31).
|
||||
|
||||
These policies are not exclusive and can be used in any combination. Together with [ScheduledInstallDay](#scheduledinstallday), it defines the ordinal number of a weekday in a month. E.g. [ScheduledInstallSecondWeek](#scheduledinstallsecondweek) + [ScheduledInstallDay](#scheduledinstallday) = 3 is 2nd Tuesday of the month. If the device is unavailable at the scheduled time, it can postpone installation of updates until the next month.
|
||||
|
||||
> [!NOTE]
|
||||
> This policy will only take effect if [Update/AllowAutoUpdate](#allowautoupdate) has been configured to option 3 or 4 for scheduled installation.
|
||||
<!-- ScheduledInstallFourthWeek-Editable-End -->
|
||||
@ -3265,6 +3283,15 @@ If the status is set to Not Configured, use of Automatic Updates is not specifie
|
||||
|
||||
<!-- ScheduledInstallSecondWeek-Editable-Begin -->
|
||||
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
|
||||
The ScheduledInstall*week policies operate on numeric days.
|
||||
|
||||
- [ScheduledInstallFirstWeek](#scheduledinstallfirstweek): First week of the month (Days 1-7).
|
||||
- [ScheduledInstallSecondWeek](#scheduledinstallsecondweek): Second week of the month (Days 8-14).
|
||||
- [ScheduledInstallThirdWeek](#scheduledinstallthirdweek): Third week of the month (Days 15-21).
|
||||
- [ScheduledInstallFourthWeek](#scheduledinstallfourthweek): Fourth week of the month (Days 22-31).
|
||||
|
||||
These policies are not exclusive and can be used in any combination. Together with [ScheduledInstallDay](#scheduledinstallday), it defines the ordinal number of a weekday in a month. E.g. [ScheduledInstallSecondWeek](#scheduledinstallsecondweek) + [ScheduledInstallDay](#scheduledinstallday) = 3 is 2nd Tuesday of the month. If the device is unavailable at the scheduled time, it can postpone installation of updates until the next month.
|
||||
|
||||
> [!NOTE]
|
||||
> This policy will only take effect if [Update/AllowAutoUpdate](#allowautoupdate) has been configured to option 3 or 4 for scheduled installation.
|
||||
<!-- ScheduledInstallSecondWeek-Editable-End -->
|
||||
@ -3363,6 +3390,15 @@ If the status is set to Not Configured, use of Automatic Updates is not specifie
|
||||
|
||||
<!-- ScheduledInstallThirdWeek-Editable-Begin -->
|
||||
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
|
||||
The ScheduledInstall*week policies operate on numeric days.
|
||||
|
||||
- [ScheduledInstallFirstWeek](#scheduledinstallfirstweek): First week of the month (Days 1-7).
|
||||
- [ScheduledInstallSecondWeek](#scheduledinstallsecondweek): Second week of the month (Days 8-14).
|
||||
- [ScheduledInstallThirdWeek](#scheduledinstallthirdweek): Third week of the month (Days 15-21).
|
||||
- [ScheduledInstallFourthWeek](#scheduledinstallfourthweek): Fourth week of the month (Days 22-31).
|
||||
|
||||
These policies are not exclusive and can be used in any combination. Together with [ScheduledInstallDay](#scheduledinstallday), it defines the ordinal number of a weekday in a month. E.g. [ScheduledInstallSecondWeek](#scheduledinstallsecondweek) + [ScheduledInstallDay](#scheduledinstallday) = 3 is 2nd Tuesday of the month. If the device is unavailable at the scheduled time, it can postpone installation of updates until the next month.
|
||||
|
||||
> [!NOTE]
|
||||
> This policy will only take effect if [Update/AllowAutoUpdate](#allowautoupdate) has been configured to option 3 or 4 for scheduled installation.
|
||||
<!-- ScheduledInstallThirdWeek-Editable-End -->
|
||||
@ -3515,7 +3551,7 @@ If the status is set to Not Configured, use of Automatic Updates is not specifie
|
||||
|
||||
<!-- SetDisablePauseUXAccess-Description-Begin -->
|
||||
<!-- Description-Source-ADMX -->
|
||||
This setting allows to remove access to "Pause updates" feature.
|
||||
This setting allows removal access to "Pause updates" feature.
|
||||
|
||||
Once enabled user access to pause updates is removed.
|
||||
<!-- SetDisablePauseUXAccess-Description-End -->
|
||||
@ -3657,7 +3693,7 @@ The following rules are followed regarding battery power:
|
||||
- Above 40% - allowed to reboot;
|
||||
- Above 20% - allowed to continue work.
|
||||
|
||||
This setting overrides the install deferral behaviour of [AllowAutoUpdate](#allowautoupdate).
|
||||
This setting overrides the install deferral behavior of [AllowAutoUpdate](#allowautoupdate).
|
||||
|
||||
These settings are designed for education devices that remain in carts overnight that are left in sleep mode. It is not designed for 1:1 devices.
|
||||
<!-- SetEDURestart-Editable-End -->
|
||||
@ -4275,7 +4311,7 @@ Enable this policy to control the timing before transitioning from Auto restarts
|
||||
|
||||
You can specify the number of days a user can snooze Engaged restart reminder notifications. The snooze period can be set between 1 and 3 days.
|
||||
|
||||
You can specify the deadline in days before automatically scheduling and executing a pending restart regardless of active hours. The deadline can be set between 2 and 30 days from the time the restart becomes pending. If configured, the pending restart will transition from Auto-restart to Engaged restart (pending user schedule) to automatically executed, within the specified period.
|
||||
You can specify the deadline in days before automatically scheduling and executing a pending restart regardless of active hours. The deadline can be set between 2 and 30 days from the time the restart becomes pending. If configured, the pending restart will transition from Auto-restart to Engaged restart (pending user schedule) to be automatically executed, within the specified period.
|
||||
|
||||
If you do not specify a deadline or if the deadline is set to 0, the PC won't automatically restart and will require the person to schedule it prior to restart.
|
||||
|
||||
@ -4345,7 +4381,7 @@ Enable this policy to control the timing before transitioning from Auto restarts
|
||||
|
||||
You can specify the number of days a user can snooze Engaged restart reminder notifications. The snooze period can be set between 1 and 3 days.
|
||||
|
||||
You can specify the deadline in days before automatically scheduling and executing a pending restart regardless of active hours. The deadline can be set between 2 and 30 days from the time the restart becomes pending. If configured, the pending restart will transition from Auto-restart to Engaged restart (pending user schedule) to automatically executed, within the specified period.
|
||||
You can specify the deadline in days before automatically scheduling and executing a pending restart regardless of active hours. The deadline can be set between 2 and 30 days from the time the restart becomes pending. If configured, the pending restart will transition from Auto-restart to Engaged restart (pending user schedule) to be automatically executed, within the specified period.
|
||||
|
||||
If you do not specify a deadline or if the deadline is set to 0, the PC won't automatically restart and will require the person to schedule it prior to restart.
|
||||
|
||||
@ -4415,7 +4451,7 @@ Enable this policy to control the timing before transitioning from Auto restarts
|
||||
|
||||
You can specify the number of days a user can snooze Engaged restart reminder notifications. The snooze period can be set between 1 and 3 days.
|
||||
|
||||
You can specify the deadline in days before automatically scheduling and executing a pending restart regardless of active hours. The deadline can be set between 2 and 30 days from the time the restart becomes pending. If configured, the pending restart will transition from Auto-restart to Engaged restart (pending user schedule) to automatically executed, within the specified period.
|
||||
You can specify the deadline in days before automatically scheduling and executing a pending restart regardless of active hours. The deadline can be set between 2 and 30 days from the time the restart becomes pending. If configured, the pending restart will transition from Auto-restart to Engaged restart (pending user schedule) to be automatically executed, within the specified period.
|
||||
|
||||
If you do not specify a deadline or if the deadline is set to 0, the PC won't automatically restart and will require the person to schedule it prior to restart.
|
||||
|
||||
@ -4485,7 +4521,7 @@ Enable this policy to control the timing before transitioning from Auto restarts
|
||||
|
||||
You can specify the number of days a user can snooze Engaged restart reminder notifications. The snooze period can be set between 1 and 3 days.
|
||||
|
||||
You can specify the deadline in days before automatically scheduling and executing a pending restart regardless of active hours. The deadline can be set between 2 and 30 days from the time the restart becomes pending. If configured, the pending restart will transition from Auto-restart to Engaged restart (pending user schedule) to automatically executed, within the specified period.
|
||||
You can specify the deadline in days before automatically scheduling and executing a pending restart regardless of active hours. The deadline can be set between 2 and 30 days from the time the restart becomes pending. If configured, the pending restart will transition from Auto-restart to Engaged restart (pending user schedule) to be automatically executed, within the specified period.
|
||||
|
||||
If you do not specify a deadline or if the deadline is set to 0, the PC won't automatically restart and will require the person to schedule it prior to restart.
|
||||
|
||||
|
||||
@ -28,8 +28,8 @@ ms.localizationpriority: medium
|
||||
| TotalBytesDownloaded | The number of bytes from any source downloaded so far |
|
||||
| PercentPeerCaching |The percentage of bytes downloaded from peers versus over HTTP |
|
||||
| BytesFromPeers | Total bytes downloaded from peer devices (sum of bytes downloaded from LAN, Group, and Internet Peers) |
|
||||
| BytesfromHTTP | Total number of bytes received over HTTP. This represents all HTTP sources, which includes BytesFromCacheServer |
|
||||
| Status | Current state of the operation. Possible values are: **Downloading** (download in progress); **Complete** (download completed, but is not uploading yet); **Caching** (download completed successfully and is ready to upload or uploading); **Paused** (download/upload paused by caller) |
|
||||
| BytesfromHTTP | Total number of bytes received over HTTP. This metric represents all HTTP sources, which includes BytesFromCacheServer |
|
||||
| Status | Current state of the operation. Possible values are: **Downloading** (download in progress); **Complete** (download completed, but isn't uploading yet); **Caching** (download completed successfully and is ready to upload or uploading); **Paused** (download/upload paused by caller) |
|
||||
| Priority | Priority of the download; values are **foreground** or **background** |
|
||||
| BytesFromCacheServer | Total number of bytes received from cache server (MCC) |
|
||||
| BytesFromLanPeers | Total number of bytes received from peers found on the LAN |
|
||||
@ -98,9 +98,19 @@ Using the `-Verbose` option returns additional information:
|
||||
- Bytes from CDN (the number of bytes received over HTTP)
|
||||
- Average number of peer connections per download
|
||||
|
||||
**Starting in Windows 10, version 2004**, `Get-DeliveryOptimizationStatus` has a new option `-PeerInfo` which returns a real-time list of the connected peers.
|
||||
**Starting in Windows 10, version 2004**, `Get-DeliveryOptimizationStatus` has a new option `-PeerInfo`, which returns a real-time list of potential peers per file, including which peers are successfully connected and the total bytes sent or received from each peer.
|
||||
|
||||
Starting in Windows 10, version 1803, `Get-DeliveryOptimizationPerfSnapThisMonth` returns data similar to that from `Get-DeliveryOptimizationPerfSnap` but limited to the current calendar month.
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| IP | Peer device IP address |
|
||||
| PeerType | The type of peer used (LAN/Group/Internet/LinkLocal), determined by the Delivery Optimization Service, except for the LinkLocal option, which uses the DNS-SD protocol. |
|
||||
| ConnectionEstablished | True/False to indicate if peer is connected |
|
||||
| BytesSent | Bytes sent to/from the peer on the current connection |
|
||||
| BytesReceived | Bytes received to/from the peer on the current connection |
|
||||
| UploadRateBytes | Average value of upload rates on the current connection, over the past 20 seconds |
|
||||
| DownloadRateBytes | Average value of download rates on the current connection, over the past 20 seconds |
|
||||
|
||||
Starting in Windows 10, version 1803, `Get-DeliveryOptimizationPerfSnapThisMonth` returns data similar to data from `Get-DeliveryOptimizationPerfSnap` but limited to the current calendar month.
|
||||
|
||||
#### Manage the Delivery Optimization cache
|
||||
|
||||
@ -110,7 +120,7 @@ Starting in Windows 10, version 1803, `Get-DeliveryOptimizationPerfSnapThisMonth
|
||||
|
||||
`set-DeliveryOptimizationStatus -ExpireOn [date time] -FileID [FileID]` extends expiration for a single specific file in the cache.
|
||||
|
||||
You can now "pin" files to keep them persistent in the cache. You can only do this with files that are downloaded in modes 1, 2, or 3.
|
||||
You can now "pin" files to keep them persistent in the cache, only with files that are downloaded in modes 1, 2, or 3.
|
||||
|
||||
`set-DeliveryOptimizationStatus -Pin [True] -File ID [FileID]` keeps a specific file in the cache such that it won't be deleted until the expiration date and time (which you set with `set-DeliveryOptimizationStatus -ExpireOn [date time] -FileID [FileID]`). The file is also excluded from the cache quota calculation.
|
||||
|
||||
@ -155,6 +165,6 @@ Using the `-ListConnections` option returns these details about peers:
|
||||
|
||||
`Get-DeliveryOptimizationLog [-Path <etl file path, supports wildcards>] [-Flush]`
|
||||
|
||||
If `Path` is not specified, this cmdlet reads all logs from the DoSvc log directory, which requires administrator permissions. If `Flush` is specified, the cmdlet stops DoSvc before reading logs.
|
||||
If `Path` isn't specified, this cmdlet reads all logs from the DoSvc log directory, which requires administrator permissions. If `Flush` is specified, the cmdlet stops DoSvc before reading logs.
|
||||
|
||||
Log entries are written to the PowerShell pipeline as objects. To dump logs to a text file, run `Get-DeliveryOptimizationLog | Set-Content <output file>` or something similar.
|
||||
|
||||
@ -46,9 +46,9 @@ Windows Autopatch is included with Windows 10/11 Enterprise E3 or higher (user-b
|
||||
|
||||
The following Windows OS 10 editions, 1809+ builds and architecture are supported in Windows Autopatch:
|
||||
|
||||
- Windows 10 (20H2+)/11 Pro
|
||||
- Windows 10 (20H2+)/11 Enterprise
|
||||
- Windows 10 (20H2+)/11 Pro for Workstations
|
||||
- Windows 10 (1809+)/11 Pro
|
||||
- Windows 10 (1809+)/11 Enterprise
|
||||
- Windows 10 (1809+)/11 Pro for Workstations
|
||||
|
||||
> [!NOTE]
|
||||
> Windows Autopatch supports registering [Windows 10 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/) devices that are being currently serviced by the [Windows LTSC](/windows/release-health/release-information). The service only supports managing the [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md) workload for devices currently serviced by the LTSC. Additionally, Windows Autopatch can only manage Windows quality updates for devices that haven't reached the LTSC's [end of servicing date](/windows/release-health/release-information#enterprise-and-iot-enterprise-ltsbltsc-editions).
|
||||
|
||||
Reference in New Issue
Block a user