deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-18 11:53:37 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/MicrosoftDocs/windows-docs-pr into dep-1903

Browse Source
This commit is contained in:
Greg Lindsay
2019-05-14 11:08:43 -07:00
parent b5b1054f90 2a48e19222
commit 0db3593b60
60 changed files with 2637 additions and 857 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
windows/deployment/update/waas-delivery-optimization-reference.md
View File

@ -79,7 +79,7 @@ Additional options available that control the impact Delivery Optimization has o
- [Max Upload Bandwidth](#max-upload-bandwidth) controls the Delivery Optimization upload bandwidth usage.
- [Monthly Upload Data Cap](#monthly-upload-data-cap) controls the amount of data a client can upload to peers each month.
- [Minimum Background QoS](#minimum-background-qos) lets administrators guarantee a minimum download speed for Windows updates. This is achieved by adjusting the amount of data downloaded directly from Windows Update or WSUS servers, rather than other peers in the network.
- [Maximum Foreground Download Bandwidth](#maximum-foreground-download-bandwidth) specifies the maximum background download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth.
- [Maximum Foreground Download Bandwidth](#maximum-foreground-download-bandwidth) specifies the maximum foreground download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth.
- [Maximum Background Download Bandwidth](#maximum-background-download-bandwidth) specifies the maximum background download bandwidth that Delivery Optimization uses across all concurrent download activities as a percentage of available download bandwidth.
- [Set Business Hours to Limit Background Download Bandwidth](#set-business-hours-to-limit-background-download-bandwidth) specifies the maximum background download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.
- [Set Business Hours to Limit Foreground Download Bandwidth](#set-business-hours-to-limit-foreground-download-bandwidth) specifies the maximum foreground download bandwidth that Delivery Optimization uses during and outside business hours across all concurrent download activities as a percentage of available download bandwidth.

6
windows/deployment/update/waas-restart.md
View File

@ -42,6 +42,9 @@ When **Configure Automatic Updates** is enabled in Group Policy, you can enable
- **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**.
> [!NOTE]
> When using Remote Desktop Protocol connections, only active RDP sessions are considered as logged on users. Devices that do not have locally logged on users, or active RDP sessions, will be restarted.
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.
For a detailed description of these registry keys, see [Registry keys used to manage restart](#registry-keys-used-to-manage-restart).
@ -159,8 +162,9 @@ In the Group Policy editor, you will see a number of policy settings that pertai
>[!NOTE]
>You can only choose one path for restart behavior.
>
>If you set conflicting restart policies, the actual restart behavior may not be what you expected.
>When using RDP, only active RDP sessions are considered as logged on users.
## Registry keys used to manage restart
The following tables list registry values that correspond to the Group Policy settings for controlling restarts after updates in Windows 10.

2
windows/deployment/update/windows-analytics-FAQ-troubleshooting.md
View File

@ -86,7 +86,7 @@ If you have devices that appear in other solutions, but not Device Health (the D
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).
4. Confirm that devices have opted in to provide diagnostic data by checking in the registry that **AllowTelemetry** is set to 2 (Enhanced) or 3 (Full) in **HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\DataCollection** (or **HKLM\Software\Policies\Microsoft\Windows\DataCollection**, which takes precedence if set).
5. Verify that devices can reach the endpoints specified in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md). Also check settings for SSL inspection and proxy authentication; see [Configuring endpoint access with SSL inspection](https://docs.microsoft.com/windows/deployment/update/windows-analytics-get-started#configuring-endpoint-access-with-ssl-inspection) for more information.
6. Remove the Device Health (appears as DeviceHealthProd on some pages) from your Log Analytics workspace
6. Add the Device Health solution back to your Log Analytics workspace.
7. Wait 48 hours for activity to appear in the reports.
8. If you need additional troubleshooting, contact Microsoft Support.

6
windows/deployment/upgrade/upgrade-readiness-data-sharing.md
View File

@ -29,10 +29,10 @@ In order to use the direct connection scenario, set the parameter **ClientProxy=
This is the first and most simple proxy scenario. The WinHTTP stack was designed for use in services and does not support proxy autodetection, PAC scripts or authentication.
In order to set the WinHTTP proxy system-wide on your computers, you need to
•Use the command netsh winhttp set proxy \<server\>:\<port\>
•Set ClientProxy=System in runconfig.bat
- Use the command netsh winhttp set proxy \<server\>:\<port\>
- Set ClientProxy=System in runconfig.bat
The WinHTTP scenario is most appropriate for customers who use a single proxy or f. If you have more advanced proxy requirements, refer to Scenario 3.
The WinHTTP scenario is most appropriate for customers who use a single proxy. If you have more advanced proxy requirements, refer to Scenario 3.
If you want to learn more about proxy considerations on Windows, see [Understanding Web Proxy Configuration](https://blogs.msdn.microsoft.com/ieinternals/2013/10/11/understanding-web-proxy-configuration/).

4
windows/deployment/volume-activation/activate-using-key-management-service-vamt.md
View File

@ -133,11 +133,9 @@ If you have already established a KMS infrastructure in your organization for an
1. Download and install the correct update for your current KMS host operating system. Restart the computer as directed.
2. Request a new KMS host key from the Volume Licensing Service Center.
3. Install the new KMS host key on your KMS host.
4. Activate the new KMS host key by running the slmrg.vbs script.
4. Activate the new KMS host key by running the slmgr.vbs script.
For detailed instructions, see [Update that enables Windows 8.1 and Windows 8 KMS hosts to activate a later version of Windows](https://go.microsoft.com/fwlink/p/?LinkId=618265) and [Update that enables Windows 7 and Windows Server 2008 R2 KMS hosts to activate Windows 10](https://go.microsoft.com/fwlink/p/?LinkId=626590).
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)