mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-18 20:03:40 +00:00
Merge branch 'master' of https://cpubwin.visualstudio.com/_git/it-client into DOreno3
This commit is contained in:
jaimeo
@ -22,13 +22,14 @@ This topic will show you how to take your reference image for Windows 10, and d
|
||||
|
||||
For the purposes of this topic, we will use three machines: DC01, MDT01, and PC0005. DC01 is a domain controller, MDT01 is a Windows Server 2012 R2 standard server, and PC0005 is a blank machine to which you deploy Windows 10. MDT01 and PC0005 are members of the domain contoso.com for the fictitious Contoso Corporation.
|
||||
|
||||
**Note**
|
||||
For important details about the setup for the steps outlined in this article, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
|
||||
|
||||
|
||||
|
||||
Figure 1. The machines used in this topic.
|
||||
|
||||
>[!NOTE]
|
||||
>For important details about the setup for the steps outlined in this article, please see [Deploy Windows 10 with the Microsoft Deployment Toolkit](deploy-windows-10-with-the-microsoft-deployment-toolkit.md).
|
||||
|
||||
|
||||
## <a href="" id="sec01"></a>Step 1: Configure Active Directory permissions
|
||||
|
||||
These steps will show you how to configure an Active Directory account with the permissions required to deploy a Windows 10 machine to the domain using MDT. These steps assume you have downloaded the sample [Set-OUPermissions.ps1 script](https://go.microsoft.com/fwlink/p/?LinkId=619362) and copied it to C:\\Setup\\Scripts on DC01. The account is used for Windows Preinstallation Environment (Windows PE) to connect to MDT01. In order for MDT to join machines into the contoso.com domain you need to create an account and configure permissions in Active Directory.
|
||||
@ -41,11 +42,10 @@ These steps will show you how to configure an Active Directory account with the
|
||||
5. User cannot change password: Select
|
||||
6. Password never expires: Select
|
||||
3. In an elevated Windows PowerShell prompt (run as Administrator), run the following commands and press **Enter** after each command:
|
||||
``` syntax
|
||||
```powershell
|
||||
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
|
||||
Set-Location C:\Setup\Scripts
|
||||
.\Set-OUPermissions.ps1 -Account MDT_JD
|
||||
-TargetOU "OU=Workstations,OU=Computers,OU=Contoso"
|
||||
.\Set-OUPermissions.ps1 -Account MDT_JD -TargetOU "OU=Workstations,OU=Computers,OU=Contoso"
|
||||
```
|
||||
4. The Set-OUPermissions.ps1 script allows the MDT\_JD user account permissions to manage computer accounts in the Contoso / Computers OU. Below you find a list of the permissions being granted:
|
||||
1. Scope: This object and all descendant objects
|
||||
@ -92,9 +92,10 @@ In these steps, we assume that you have completed the steps in the [Create a Win
|
||||
6. On the **Destination** page, in the **Destination directory name** text box, type **W10EX64RTM**, click **Next** twice, and then click **Finish**.
|
||||
7. After adding the operating system, double-click the added operating system name in the **Operating Systems / Windows 10** node and change the name to match the following: **Windows 10 Enterprise x64 RTM Custom Image**.
|
||||
|
||||
**Note**
|
||||
The reason for adding the setup files has changed since earlier versions of MDT. MDT 2010 used the setup files to install Windows. MDT uses DISM to apply the image; however, you still need the setup files because some components in roles and features are stored outside the main image.
|
||||
>[!NOTE]
|
||||
>The reason for adding the setup files has changed since earlier versions of MDT. MDT 2010 used the setup files to install Windows. MDT uses DISM to apply the image; however, you still need the setup files because some components in roles and features are stored outside the main image.
|
||||
|
||||
|
||||
|
||||
|
||||
Figure 2. The imported operating system after renaming it.
|
||||
@ -128,8 +129,8 @@ In order to deploy Windows 10 with MDT successfully, you need drivers for the b
|
||||
- Microsoft Surface Pro
|
||||
For boot images, you need to have storage and network drivers; for the operating system, you need to have the full suite of drivers.
|
||||
|
||||
**Note**
|
||||
You should only add drivers to the Windows PE images if the default drivers don't work. Adding drivers that are not necessary will only make the boot image larger and potentially delay the download time.
|
||||
>[!NOTE]
|
||||
>You should only add drivers to the Windows PE images if the default drivers don't work. Adding drivers that are not necessary will only make the boot image larger and potentially delay the download time.
|
||||
|
||||
### Create the driver source structure in the file system
|
||||
|
||||
@ -150,8 +151,8 @@ The key to successful management of drivers for MDT, as well as for any other de
|
||||
- Microsoft Corporation
|
||||
- Surface Pro 3
|
||||
|
||||
**Note**
|
||||
Even if you are not going to use both x86 and x64 boot images, we still recommend that you add the support structure for future use.
|
||||
>[!NOTE]
|
||||
>Even if you are not going to use both x86 and x64 boot images, we still recommend that you add the support structure for future use.
|
||||
|
||||
### Create the logical driver structure in MDT
|
||||
|
||||
@ -285,8 +286,9 @@ This section will show you how to create the task sequence used to deploy your p
|
||||
2. Configure the **Inject Drivers** action with the following settings:
|
||||
1. Choose a selection profile: Nothing
|
||||
2. Install all drivers from the selection profile
|
||||
**Note**
|
||||
The configuration above indicates that MDT should only use drivers from the folder specified by the DriverGroup001 property, which is defined by the "Choose a selection profile: Nothing" setting, and that MDT should not use plug and play to determine which drivers to copy, which is defined by the "Install all drivers from the selection profile" setting.
|
||||
|
||||
>[!NOTE]
|
||||
>The configuration above indicates that MDT should only use drivers from the folder specified by the DriverGroup001 property, which is defined by the "Choose a selection profile: Nothing" setting, and that MDT should not use plug and play to determine which drivers to copy, which is defined by the "Install all drivers from the selection profile" setting.
|
||||
|
||||
3. State Restore. Enable the **Windows Update (Pre-Application Installation)** action.
|
||||
4. State Restore. Enable the **Windows Update (Post-Application Installation)** action.
|
||||
@ -359,8 +361,10 @@ In this section, you will learn how to configure the MDT Build Lab deployment sh
|
||||
- In the **Lite Touch Boot Image Settings** area:
|
||||
1. Image description: MDT Production x86
|
||||
2. ISO file name: MDT Production x86.iso
|
||||
**Note**
|
||||
Because you are going to use Pre-Boot Execution Environment (PXE) later to deploy the machines, you do not need the ISO file; however, we recommend creating ISO files because they are useful when troubleshooting deployments and for quick tests.
|
||||
|
||||
>[!NOTE]
|
||||
|
||||
>Because you are going to use Pre-Boot Execution Environment (PXE) later to deploy the machines, you do not need the ISO file; however, we recommend creating ISO files because they are useful when troubleshooting deployments and for quick tests.
|
||||
|
||||
7. In the **Drivers and Patches** sub tab, select the **WinPE x86** selection profile and select the **Include all drivers from the selection profile** option.
|
||||
8. In the **Windows PE** tab, in the **Platform** drop-down list, select **x64**.
|
||||
@ -372,8 +376,8 @@ In this section, you will learn how to configure the MDT Build Lab deployment sh
|
||||
11. In the **Monitoring** tab, select the **Enable monitoring for this deployment share** check box.
|
||||
12. Click **OK**.
|
||||
|
||||
**Note**
|
||||
It will take a while for the Deployment Workbench to create the monitoring database and web service.
|
||||
>[!NOTE]
|
||||
>It will take a while for the Deployment Workbench to create the monitoring database and web service.
|
||||
|
||||
|
||||
|
||||
@ -479,8 +483,8 @@ Like the MDT Build Lab deployment share, the MDT Production deployment share nee
|
||||
1. Right-click the **MDT Production** deployment share and select **Update Deployment Share**.
|
||||
2. Use the default options for the Update Deployment Share Wizard.
|
||||
|
||||
**Note**
|
||||
The update process will take 5 to 10 minutes.
|
||||
>[!NOTE]
|
||||
>The update process will take 5 to 10 minutes.
|
||||
|
||||
## <a href="" id="sec08"></a>Step 8: Deploy the Windows 10 client image
|
||||
|
||||
@ -588,8 +592,9 @@ To filter what is being added to the media, you create a selection profile. When
|
||||
In these steps, you generate offline media from the MDT Production deployment share. To filter what is being added to the media, you use the previously created selection profile.
|
||||
|
||||
1. On MDT01, using File Explorer, create the **E:\\MDTOfflineMedia** folder.
|
||||
**Note**
|
||||
When creating offline media, you need to create the target folder first. It is crucial that you do not create a subfolder inside the deployment share folder because it will break the offline media.
|
||||
|
||||
>[!NOTE]
|
||||
>When creating offline media, you need to create the target folder first. It is crucial that you do not create a subfolder inside the deployment share folder because it will break the offline media.
|
||||
|
||||
2. Using Deployment Workbench, in the **MDT Production / Advanced Configuration** node, right-click the **Media** node, and select **New Media**.
|
||||
3. Use the following settings for the New Media Wizard:
|
||||
|
||||
@ -45,7 +45,10 @@ These steps assume that you have the MDT01 member server installed and configure
|
||||
3. On the **Select the features you want to change** page, select the features below and complete the wizard using the default settings:
|
||||
1. Deployment Tools
|
||||
2. Windows Preinstallation Environment (Windows PE)
|
||||
3. User State Migration Tool (UMST)
|
||||
3. User State Migration Tool (USMT)
|
||||
|
||||
>[!IMPORTANT]
|
||||
>Starting with Windows 10, version 1809, Windows PE is released separately from the AFK. See [Download and install the Windows ADK](https://docs.microsoft.com/windows-hardware/get-started/adk-install) for more information.
|
||||
|
||||
## <a href="" id="sec03"></a>Install MDT
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 8.0 KiB After Width: | Height: | Size: 8.4 KiB |
@ -6,7 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: plan
|
||||
ms.pagetype: appcompat
|
||||
ms.sitesec: library
|
||||
author: eross-msft
|
||||
author: jdeckerms
|
||||
ms.date: 04/19/2017
|
||||
ms.topic: article
|
||||
---
|
||||
|
||||
@ -25,14 +25,14 @@ ms.topic: article
|
||||
|
||||
You must deploy your customized database (.sdb) files to other computers in your organization before your compatibility fixes, compatibility modes, and AppHelp messages are applied. You can deploy your customized database files in several ways, including by using a logon script, by using Group Policy, or by performing file copy operations.
|
||||
|
||||
After you deploy and store the customized databases on each of your local computers, you must register the database files. Until you register the database files, the operating system is unable to identify the available compatibility fixes when starting an application.
|
||||
After you deploy and store the customized databases on each of your local computers, you must register the database files. Until you register the database files, the operating system is unable to identify the available compatibility fixes when starting an application.
|
||||
|
||||
## Command-Line Options for Deploying Customized Database Files
|
||||
|
||||
|
||||
The command-line options use the following conventions.
|
||||
|
||||
Sdbinst.exe \[-q\] \[-u filepath\] \[-g *GUID*\] \[-n *"name"*\] \[-?\]
|
||||
Sdbinst.exe \[-q\] \[-?\] \[-u\] \[-g\] \[-p\] \[-u filepath\] \[-g *GUID*\] \[-n *"name"*\]
|
||||
|
||||
The following table describes the available command-line options.
|
||||
|
||||
@ -78,8 +78,14 @@ The following table describes the available command-line options.
|
||||
<p>For example,</p>
|
||||
<p><code>sdbinst.exe -?</code></p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>-p</p></td>
|
||||
<td align="left"><p>Allows SDBs installation with Patches</p>
|
||||
<p>For example,</p>
|
||||
<p><code>sdbinst.exe -p C:\Windows\AppPatch\Myapp.sdb</code></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Related topics
|
||||
[Compatibility Administrator User's Guide](compatibility-administrator-users-guide.md)
|
||||
[Compatibility Administrator User's Guide](compatibility-administrator-users-guide.md)
|
||||
|
||||
@ -51,4 +51,4 @@ If you have feedback about the proposed replacement of any of these features, yo
|
||||
|Phone Companion|Use the **Phone** page in the Settings app. In Windows 10, version 1709, we added the new **Phone** page to help you sync your mobile phone with your PC. It includes all the Phone Companion features.|
|
||||
|IPv4/6 Transition Technologies (6to4, ISATAP, and Direct Tunnels)|6to4 has been disabled by default since Windows 10, version 1607 (the Anniversary Update), ISATAP has been disabled by default since Windows 10, version 1703 (the Creators Update), and Direct Tunnels has always been disabled by default. Please use native IPv6 support instead.|
|
||||
|[Layered Service Providers](https://msdn.microsoft.com/library/windows/desktop/bb513664)|Layered Service Providers have been deprecated since Windows 8 and Windows Server 2012. Use the [Windows Filtering Platform](https://msdn.microsoft.com/library/windows/desktop/aa366510) instead. When you upgrade from an older version of Windows, any layered service providers you're using aren't migrated; you'll need to re-install them after upgrading.|
|
||||
|Business Scanning, also called Distributed Scan Management (DSM) **(Added 05/03/2018)**|The [Scan Management functionality](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd759124\(vs.11\)) was introduced in Windows 7 and enabled secure scanning and the management of scanners in an enterprise. We're no longer investing in this feature, and there are no devices available that support it.|
|
||||
|Business Scanning, also called Distributed Scan Management (DSM) **(Added 05/03/2018)**|The [Scan Management functionality](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd759124(v=ws.11)) was introduced in Windows 7 and enabled secure scanning and the management of scanners in an enterprise. We're no longer investing in this feature, and there are no devices available that support it.|
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -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 doesn’t 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 doesn’t 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.
|
||||
|
||||
@ -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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -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! We’re 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! We’re 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
|
||||
|
||||
[](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:
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -26,7 +26,8 @@ The compatibility update that sends diagnostic data from user computers to Micro
|
||||
|
||||
If you need to update user computers to Windows 7 SP1 or Windows 8.1, use Windows Update or download and deploy the applicable package from the Microsoft Download Center.
|
||||
|
||||
Note: Upgrade Readiness is designed to best support in-place upgrades. In-place upgrades do not support migrations from BIOS to UEFI or from 32-bit to 64-bit architecture. If you need to migrate computers in these scenarios, use the wipe-and-reload method. Upgrade Readiness insights are still valuable in this scenario, however, you can ignore in-place upgrade specific guidance.
|
||||
> [!NOTE]
|
||||
> Upgrade Readiness is designed to best support in-place upgrades. In-place upgrades do not support migrations from BIOS to UEFI or from 32-bit to 64-bit architecture. If you need to migrate computers in these scenarios, use the wipe-and-reload method. Upgrade Readiness insights are still valuable in this scenario, however, you can ignore in-place upgrade specific guidance.
|
||||
|
||||
See [Windows 10 Specifications](https://www.microsoft.com/en-US/windows/windows-10-specifications) for additional information about computer system requirements.
|
||||
|
||||
|
||||
@ -9,6 +9,8 @@ ms.sitesec: library
|
||||
ms.pagetype: mdt
|
||||
author: greg-lindsay
|
||||
ms.collection: M365-modern-desktop
|
||||
search.appverid:
|
||||
- MET150
|
||||
ms.topic: article
|
||||
---
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ A [glossary](#glossary) of abbreviations used in this topic is provided at the e
|
||||
| How does a customer authorize an OEM or Channel Partner to register Autopilot devices on the customer’s behalf? | Before an OEM or Channel Partner can register a device for Autopilot on behalf of a customer, the customer must first give them consent. The consent process begins with the OEM or Channel Partner sending a link to the customer, which directs the customer to a consent page in Microsoft Store for Business. The steps explaining this process are [here](registration-auth.md). |
|
||||
| Are there any restrictions if a business customer has registered devices in MSfB and later wants those devices to be managed by a CSP via the Partner Center? | The devices will need to be deleted in MSfB by the business customer before the CSP can upload and manage them in the Partner Center. |
|
||||
| Does Windows Autopilot support removing the option to enable a local administrator account? | Windows Autopilot doesn’t support removing the local admin account. However, it does support restricting the user performing AAD domain join in OOBE to a standard account (versus admin account by default).|
|
||||
| How can I test the Windows Autopilot CSV file in the Partner Center? | Only CSP Partners have access to the Partner Center portal. If you are a CSP, you can create a Sales agent user account which has access to “Devices” for testing the file. This can be done today in the Partner Center. <br><br>Go [here](https://msdn.microsoft.com/partner-center/createuseraccounts-and-set-permissions) for more information. |
|
||||
| How can I test the Windows Autopilot CSV file in the Partner Center? | Only CSP Partners have access to the Partner Center portal. If you are a CSP, you can create a Sales agent user account which has access to “Devices” for testing the file. This can be done today in the Partner Center. <br><br>Go [here](https://msdn.microsoft.com/partner-center/create-user-accounts-and-set-permissions) for more information. |
|
||||
| Must I become a Cloud Solution Provider (CSP) to participate in Windows Autopilot? | Top volume OEMs do not, as they can use the OEM Direct API. All others who choose to use MPC to register devices must become CSPs in order to access MPC. |
|
||||
| Do the different CSP levels have all the same capabilities when it comes to Windows Autopilot? | For purposes of Windows Autopilot, there are three different types of CSPs, each with different levels of authority an access: <br><br>1. <b>Direct CSP</b>: Gets direct authorization from the customer to register devices. <br><br>2. <b>Indirect CSP Provider</b>: Gets implicit permission to register devices through the relationship their CSP Reseller partner has with the customer. Indirect CSP Providers register devices through Microsoft Partner Center. <br><br>3. <b>Indirect CSP Reseller</b>: Gets direct authorization from the customer to register devices. At the same time, their indirect CSP Provider partner also gets authorization, which mean that either the Indirect Provider or the Indirect Reseller can register devices for the customer. However, the Indirect CSP Reseller must register devices through the MPC UI (manually uploading CSV file), whereas the Indirect CSP Provider has the option to register devices using the MPC APIs. |
|
||||
|
||||
|
||||
@ -32,6 +32,7 @@ To perform a user-driven hybrid AAD joined deployment using Windows Autopilot:
|
||||
- The device must be connected to the Internet and have access to an Active Directory domain controller.
|
||||
- The Intune Connector for Active Directory must be installed.
|
||||
- Note: The Intune Connector will perform an on-prem AD join, therefore users do not need on-prem AD-join permission, assuming the Connector is [configured to perform this action](https://docs.microsoft.com/intune/windows-autopilot-hybrid#increase-the-computer-account-limit-in-the-organizational-unit) on the user's behalf.
|
||||
- If using Proxy, WDAP Proxy settings option must be enabled and configured.
|
||||
|
||||
**AAD device join**: The hybrid AAD join process uses the system context to perform device AAD join, therefore it is not affected by user based AAD join permission settings. In addition, all users are enabled to join devices to AAD by default.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user