mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 10:53:43 +00:00
alt text
This commit is contained in:
greg-lindsay
@ -21,18 +21,18 @@ ms.topic: article
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
|
||||
This topic will show you how to take your reference image for Windows 10 (that was just [created](create-a-windows-10-reference-image.md)), and deploy that image to your environment using the **Microsoft Deployment Toolkit (MDT)**.
|
||||
This topic will show you how to take your reference image for Windows 10 (that was just [created](create-a-windows-10-reference-image.md)), and deploy that image to your environment using the Microsoft Deployment Toolkit (MDT).
|
||||
|
||||
We will prepare for this by creating an **MDT** deployment share that is used solely for image deployment. Separating the processes of creating reference images from the processes used to deploy them in production allows greater control of both processes. We will configure **Active Directory** permissions, configure the deployment share, create a new task sequence, and add applications, drivers, and rules.
|
||||
We will prepare for this by creating an MDT deployment share that is used solely for image deployment. Separating the processes of creating reference images from the processes used to deploy them in production allows greater control of on both processes. We will configure Active Directory permissions, configure the deployment share, create a new task sequence, and add applications, drivers, and rules.
|
||||
|
||||
For the purposes of this topic, we will use four computers: **DC01**, **MDT01**, **HV01**, and **PC0005**.
|
||||
For the purposes of this topic, we will use four computers: DC01, MDT01, HV01 and PC0005.
|
||||
|
||||
- **DC01** is a domain controller
|
||||
- **MDT01** is a domain member server
|
||||
- **HV01** is a Hyper-V server
|
||||
- **PC0005** is a blank device to which we will deploy Windows 10
|
||||
- DC01 is a domain controller
|
||||
- MDT01 is a domain member server
|
||||
- HV01 is a Hyper-V server
|
||||
- PC0005 is a blank device to which we will deploy Windows 10
|
||||
|
||||
**MDT01** and **PC0005** are members of the domain contoso.com for the fictitious Contoso Corporation. **HV01** is used to test the deployment of **PC0005** in a virtual environment.
|
||||
MDT01 and PC0005 are members of the domain contoso.com for the fictitious Contoso Corporation. HV01 used to test deployment of PC0005 in a virtual environment.
|
||||
|
||||
|
||||
|
||||
@ -45,14 +45,14 @@ These steps will show you how to configure an Active Directory account with the
|
||||
|
||||
On **DC01**:
|
||||
|
||||
1. Download the [Set-OUPermissions.ps1 script](https://go.microsoft.com/fwlink/p/?LinkId=619362) and copy it to the **C:\\Setup\\Scripts** directory on **DC01**. This script configures permissions to allow the **MDT_JD** account to manage computer accounts in the contoso > Computers organizational unit.
|
||||
2. Create the **MDT_JD** service account by running the following command from an elevated **Windows PowerShell prompt**:
|
||||
1. Download the [Set-OUPermissions.ps1 script](https://go.microsoft.com/fwlink/p/?LinkId=619362) and copy it to the **C:\\Setup\\Scripts** directory on DC01. This script configures permissions to allow the MDT_JD account to manage computer accounts in the contoso > Computers organizational unit.
|
||||
2. Create the MDT_JD service account by running the following command from an elevated Windows PowerShell prompt:
|
||||
|
||||
```powershell
|
||||
New-ADUser -Name MDT_JD -UserPrincipalName MDT_JD -path "OU=Service Accounts,OU=Accounts,OU=Contoso,DC=CONTOSO,DC=COM" -Description "MDT join domain account" -AccountPassword (ConvertTo-SecureString "pass@word1" -AsPlainText -Force) -ChangePasswordAtLogon $false -PasswordNeverExpires $true -Enabled $true
|
||||
```
|
||||
|
||||
3. Next, run the **Set-OuPermissions script** to apply permissions to the **MDT\_JD** service account, enabling it to manage computer accounts in the Contoso / Computers OU. Run the following commands from an elevated **Windows PowerShell prompt**:
|
||||
3. Next, run the Set-OuPermissions script to apply permissions to the **MDT\_JD** service account, enabling it to manage computer accounts in the Contoso / Computers OU. Run the following commands from an elevated Windows PowerShell prompt:
|
||||
|
||||
```powershell
|
||||
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
|
||||
@ -76,7 +76,7 @@ The following is a list of the permissions being granted:
|
||||
|
||||
## Step 2: Set up the MDT production deployment share
|
||||
|
||||
Next, create a new **MDT** deployment share. You should not use the same deployment share that you used to create the reference image for a production deployment. Perform this procedure on the **MDT01** server.
|
||||
Next, create a new MDT deployment share. You should not use the same deployment share that you used to create the reference image for a production deployment. Perform this procedure on the MDT01 server.
|
||||
|
||||
### Create the MDT production deployment share
|
||||
|
||||
@ -85,21 +85,21 @@ On **MDT01**:
|
||||
The steps for creating the deployment share for production are the same as when you created the deployment share for creating the custom reference image:
|
||||
|
||||
1. Ensure you are signed on as: contoso\administrator.
|
||||
2. In the **Deployment Workbench** console, right-click **Deployment Shares** and select **New Deployment Share**.
|
||||
2. In the Deployment Workbench console, right-click **Deployment Shares** and select **New Deployment Share**.
|
||||
3. On the **Path** page, in the **Deployment share path** text box, type **D:\\MDTProduction** and click **Next**.
|
||||
4. On the **Share** page, in the **Share name** text box, type **MDTProduction$** and click **Next**.
|
||||
5. On the **Descriptive Name** page, in the **Deployment share description** text box, type **MDT Production** and click **Next**.
|
||||
6. On the **Options** page, accept the default settings and click **Next** twice, and then click **Finish**.
|
||||
7. Using **File Explorer**, verify that you can access the **\\\\MDT01\\MDTProduction$** share.
|
||||
7. Using File Explorer, verify that you can access the **\\\\MDT01\\MDTProduction$** share.
|
||||
|
||||
### Configure permissions for the production deployment share
|
||||
|
||||
To read files in the deployment share, you need to assign **NTFS** and **SMB** permissions to the **MDT Build Account (MDT\_BA)** for the **D:\\MDTProduction** folder.
|
||||
To read files in the deployment share, you need to assign NTFS and SMB permissions to the MDT Build Account (MDT\_BA) for the **D:\\MDTProduction** folder
|
||||
|
||||
On **MDT01**:
|
||||
|
||||
1. Ensure you are signed in as **contoso\\administrator**.
|
||||
2. Modify the **NTFS** permissions for the **D:\\MDTProduction** folder by running the following command in an elevated **Windows PowerShell prompt**:
|
||||
2. Modify the NTFS permissions for the **D:\\MDTProduction** folder by running the following command in an elevated Windows PowerShell prompt:
|
||||
|
||||
``` powershell
|
||||
icacls "D:\MDTProduction" /grant '"CONTOSO\MDT_BA":(OI)(CI)(M)'
|
||||
@ -112,33 +112,33 @@ The next step is to add a reference image into the deployment share with the set
|
||||
|
||||
### Add the Windows 10 Enterprise x64 RTM custom image
|
||||
|
||||
In these steps, we assume that you have completed the steps in the [Create a Windows 10 reference image](create-a-windows-10-reference-image.md) topic, so you have a Windows 10 reference image at **D:\\MDTBuildLab\\Captures\REFW10X64-001.wim** on **MDT01**.
|
||||
In these steps, we assume that you have completed the steps in the [Create a Windows 10 reference image](create-a-windows-10-reference-image.md) topic, so you have a Windows 10 reference image at **D:\\MDTBuildLab\\Captures\REFW10X64-001.wim** on MDT01.
|
||||
|
||||
1. Using the **Deployment Workbench**, expand the **Deployment Shares** node, and then expand **MDT Production**; select the **Operating Systems** node, and create a **folder** named **Windows 10**.
|
||||
1. Using the Deployment Workbench, expand the **Deployment Shares** node, and then expand **MDT Production**; select the **Operating Systems** node, and create a folder named **Windows 10**.
|
||||
2. Right-click the **Windows 10** folder and select **Import Operating System**.
|
||||
3. On the **OS Type** page, select **Custom image file** and click **Next**.
|
||||
4. On the **Image** page, in the **Source file** text box, browse to **D:\\MDTBuildLab\\Captures\\REFW10X64-001.wim** and click **Next**.
|
||||
5. On the **Setup** page, select the **Copy Windows 7, Windows Server 2008 R2, or later setup files from the specified path** option; in the **Setup source directory** text box, browse to **D:\\MDTBuildLab\\Operating Systems\\W10EX64RTM** and click **Next**.
|
||||
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 **Windows 10 Enterprise x64 RTM Custom Image**.
|
||||
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 **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 the **DISM** command 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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Step 4: Add an application
|
||||
|
||||
When you configure your **MDT Build Lab deployment** share, you can also add **applications** to the new deployment share before creating your task sequence. This section walks you through the process of adding an application to the **MDT Production deployment** share using **Adobe Reader** as an example.
|
||||
When you configure your MDT Build Lab deployment share, you can also add applications to the new deployment share before creating your task sequence. This section walks you through the process of adding an application to the MDT Production deployment share using Adobe Reader as an example.
|
||||
|
||||
### Create the install: Adobe Reader DC
|
||||
|
||||
On **MDT01**:
|
||||
|
||||
1. Download the Enterprise distribution version of [**Adobe Acrobat Reader DC**](https://get.adobe.com/reader/enterprise/) (AcroRdrDC2100120140_en_US.exe) to **D:\\setup\\adobe** on MDT01.
|
||||
2. Extract the **.exe** file that you downloaded to a **.msi** (ex: .\AcroRdrDC2100120140_en_US.exe -sfx_o"d:\setup\adobe\install\" -sfx_ne).
|
||||
3. In the **Deployment Workbench**, expand the **MDT Production** node and navigate to the **Applications** node.
|
||||
1. Download the Enterprise distribution version of [Adobe Acrobat Reader DC](https://get.adobe.com/reader/enterprise/) (AcroRdrDC1902120058_en_US.exe) to **D:\\setup\\adobe** on MDT01.
|
||||
2. Extract the .exe file that you downloaded to an .msi (ex: .\AcroRdrDC1902120058_en_US.exe -sfx_o"d:\setup\adobe\install\" -sfx_ne).
|
||||
3. In the Deployment Workbench, expand the **MDT Production** node and navigate to the **Applications** node.
|
||||
4. Right-click the **Applications** node, and create a new folder named **Adobe**.
|
||||
5. In the **Applications** node, right-click the **Adobe** folder and select **New Application**.
|
||||
6. On the **Application Type** page, select the **Application with source files** option and click **Next**.
|
||||
@ -153,7 +153,7 @@ The Adobe Reader application added to the Deployment Workbench.
|
||||
|
||||
## Step 5: Prepare the drivers repository
|
||||
|
||||
In order to deploy Windows 10 with **MDT** successfully, you need drivers for the boot images and for the actual operating system. This section will show you how to add drivers for the boot images and operating system, using the following hardware models as examples:
|
||||
In order to deploy Windows 10 with MDT successfully, you need drivers for the boot images and for the actual operating system. This section will show you how to add drivers for the boot image and operating system, using the following hardware models as examples:
|
||||
- Lenovo ThinkPad T420
|
||||
- Dell Latitude 7390
|
||||
- HP EliteBook 8560w
|
||||
@ -166,19 +166,19 @@ For boot images, you need to have storage and network drivers; for the operating
|
||||
|
||||
### Create the driver source structure in the file system
|
||||
|
||||
The key to successful management of drivers for **MDT**, as well as for any other deployment solution, is to have a really good driver repository. From this repository, you import drivers into MDT for deployment, but you should always maintain the repository for future use.
|
||||
The key to successful management of drivers for MDT, as well as for any other deployment solution, is to have a really good driver repository. From this repository, you import drivers into MDT for deployment, but you should always maintain the repository for future use.
|
||||
|
||||
On **MDT01**:
|
||||
|
||||
> [!IMPORTANT]
|
||||
> In the steps below, it is critical that the folder names used for various computer makes and models exactly match the results of **wmic computersystem get model,manufacturer** on the target system.
|
||||
|
||||
1. Using **File Explorer**, create the **D:\\drivers** folder.
|
||||
1. Using File Explorer, create the **D:\\drivers** folder.
|
||||
2. In the **D:\\drivers** folder, create the following folder structure:
|
||||
1. **WinPE x86**
|
||||
2. **WinPE x64**
|
||||
3. **Windows 10 x64**
|
||||
3. In the new **Windows 10 x64** folder, create the following folder structure:
|
||||
1. WinPE x86
|
||||
2. WinPE x64
|
||||
3. Windows 10 x64
|
||||
3. In the new Windows 10 x64 folder, create the following folder structure:
|
||||
- Dell Inc
|
||||
- Latitude E7450
|
||||
- Hewlett-Packard
|
||||
@ -193,12 +193,12 @@ On **MDT01**:
|
||||
|
||||
### Create the logical driver structure in MDT
|
||||
|
||||
When you import drivers to the **MDT driver repository**, **MDT** creates a single instance folder structure based on driver class names. However, you can, and should, mimic the driver structure of your driver source repository in the Deployment Workbench. This is done by creating logical folders in the Deployment Workbench.
|
||||
1. On **MDT01**, using Deployment Workbench, select the **Out-of-Box Drivers** node.
|
||||
When you import drivers to the MDT driver repository, MDT creates a single instance folder structure based on driver class names. However, you can, and should, mimic the driver structure of your driver source repository in the Deployment Workbench. This is done by creating logical folders in the Deployment Workbench.
|
||||
1. On MDT01, using Deployment Workbench, select the **Out-of-Box Drivers** node.
|
||||
2. In the **Out-Of-Box Drivers** node, create the following folder structure:
|
||||
1. **WinPE x86**
|
||||
2. **WinPE x64**
|
||||
3. **Windows 10 x64**
|
||||
1. WinPE x86
|
||||
2. WinPE x64
|
||||
3. Windows 10 x64
|
||||
3. In the **Windows 10 x64** folder, create the following folder structure:
|
||||
- Dell Inc
|
||||
- Latitude E7450
|
||||
@ -209,7 +209,7 @@ When you import drivers to the **MDT driver repository**, **MDT** creates a sing
|
||||
- Microsoft Corporation
|
||||
- Surface Laptop
|
||||
|
||||
The preceding folder names should match the actual make and model values that MDT reads from devices during deployment. You can find out the model values for your machines by using the following command in an elevated **Windows PowerShell prompt**:
|
||||
The preceding folder names should match the actual make and model values that MDT reads from devices during deployment. You can find out the model values for your machines by using the following command in Windows PowerShell:
|
||||
|
||||
``` powershell
|
||||
Get-WmiObject -Class:Win32_ComputerSystem
|
||||
@ -220,7 +220,7 @@ Or, you can use this command in a normal command prompt:
|
||||
wmic csproduct get name
|
||||
```
|
||||
|
||||
If you want a more standardized naming convention, try the **ModelAliasExit.vbs script** from the Deployment Guys blog post entitled [Using and Extending Model Aliases for Hardware Specific Application Installation](https://go.microsoft.com/fwlink/p/?LinkId=619536).
|
||||
If you want a more standardized naming convention, try the ModelAliasExit.vbs script from the Deployment Guys blog post entitled [Using and Extending Model Aliases for Hardware Specific Application Installation](https://go.microsoft.com/fwlink/p/?LinkId=619536).
|
||||
|
||||
|
||||
|
||||
@ -229,20 +229,20 @@ The Out-of-Box Drivers structure in the Deployment Workbench.
|
||||
### Create the selection profiles for boot image drivers
|
||||
|
||||
By default, MDT adds any storage and network drivers that you import to the boot images. However, you should add only the drivers that are necessary to the boot image. You can control which drivers are added by using selection profiles.
|
||||
The drivers that are used for the boot images (Windows PE) are Windows 10 drivers. If you can’t locate **Windows 10** drivers for your device, a **Windows 7** or **Windows 8.1** driver will most likely work, but Windows 10 drivers should be your first choice.
|
||||
The drivers that are used for the boot images (Windows PE) are Windows 10 drivers. If you can’t locate Windows 10 drivers for your device, a Windows 7 or Windows 8.1 driver will most likely work, but Windows 10 drivers should be your first choice.
|
||||
|
||||
On **MDT01**:
|
||||
|
||||
1. In the **Deployment Workbench**, under the **MDT Production** node, expand the **Advanced Configuration** node, right-click the **Selection Profiles** node, and select **New Selection Profile**.
|
||||
2. In the **New Selection Profile Wizard**, create a **selection profile** with the following settings:
|
||||
1. Selection Profile name: **WinPE x86**
|
||||
2. Folders: Select the **WinPE x86 folder** in **Out-of-Box Drivers**.
|
||||
3. Click **Next**, **Next**, and **Finish**.
|
||||
1. In the Deployment Workbench, under the **MDT Production** node, expand the **Advanced Configuration** node, right-click the **Selection Profiles** node, and select **New Selection Profile**.
|
||||
2. In the New Selection Profile Wizard, create a selection profile with the following settings:
|
||||
1. Selection Profile name: WinPE x86
|
||||
2. Folders: Select the WinPE x86 folder in Out-of-Box Drivers.
|
||||
3. Click **Next**, **Next** and **Finish**.
|
||||
3. Right-click the **Selection Profiles** node again, and select **New Selection Profile**.
|
||||
4. In the **New Selection Profile Wizard**, create a **selection profile** with the following settings:
|
||||
1. Selection Profile name: **WinPE x64**
|
||||
2. Folders: Select the **WinPE x64 folder** in **Out-of-Box Drivers**.
|
||||
3. Click **Next**, **Next**, and **Finish**.
|
||||
4. In the New Selection Profile Wizard, create a selection profile with the following settings:
|
||||
1. Selection Profile name: WinPE x64
|
||||
2. Folders: Select the WinPE x64 folder in Out-of-Box Drivers.
|
||||
3. Click **Next**, **Next** and **Finish**.
|
||||
|
||||
|
||||
|
||||
@ -250,21 +250,22 @@ Creating the WinPE x64 selection profile.
|
||||
|
||||
### Extract and import drivers for the x64 boot image
|
||||
|
||||
**Windows PE** supports all the hardware models that we have, but here you learn how to add boot image drivers to accommodate any new hardware that might require additional drivers. In this example, you add the latest Intel network drivers to the x64 boot image.
|
||||
Windows PE supports all the hardware models that we have, but here you learn to add boot image drivers to accommodate any new hardware that might require additional drivers. In this example, you add the latest Intel network drivers to the x64 boot image.
|
||||
|
||||
On **MDT01**:
|
||||
|
||||
1. Download **PROWinx64.exe** from Intel.com (ex: [PROWinx64.exe](https://downloadcenter.intel.com/downloads/eula/25016/Intel-Network-Adapter-Driver-for-Windows-10?httpDown=https%3A%2F%2Fdownloadmirror.intel.com%2F25016%2Feng%2FPROWinx64.exe)).
|
||||
2. Extract **PROWinx64.exe** to a temporary folder - in this example to the **C:\\Tmp\\ProWinx64** folder. Note that extracting the **.exe** file manually requires an extraction utility. You can also run the .exe and it will self-extract files to the **%userprofile%\AppData\Local\Temp\RarSFX0** directory. This directory is temporary and will be deleted when the **.exe** terminates.
|
||||
3. Using **File Explorer**, create the **D:\\Drivers\\WinPE x64\\Intel PRO1000** folder.
|
||||
2. Extract PROWinx64.exe to a temporary folder - in this example to the **C:\\Tmp\\ProWinx64** folder.
|
||||
a. **Note**: Extracting the .exe file manually requires an extraction utility. You can also run the .exe and it will self-extract files to the **%userprofile%\AppData\Local\Temp\RarSFX0** directory. This directory is temporary and will be deleted when the .exe terminates.
|
||||
3. Using File Explorer, create the **D:\\Drivers\\WinPE x64\\Intel PRO1000** folder.
|
||||
4. Copy the content of the **C:\\Tmp\\PROWinx64\\PRO1000\\Winx64\\NDIS64** folder to the **D:\\Drivers\\WinPE x64\\Intel PRO1000** folder.
|
||||
5. In the **Deployment Workbench**, expand the **MDT Production** > **Out-of-Box Drivers** node, right-click the **WinPE x64** node, select **Import Drivers**, and use the following driver source directory to import drivers: **D:\\Drivers\\WinPE x64\\Intel PRO1000**.
|
||||
5. In the Deployment Workbench, expand the **MDT Production** > **Out-of-Box Drivers** node, right-click the **WinPE x64** node, and select **Import Drivers**, and use the following Driver source directory to import drivers: **D:\\Drivers\\WinPE x64\\Intel PRO1000**.
|
||||
|
||||
### Download, extract, and import drivers
|
||||
|
||||
### For the Lenovo ThinkStation P500
|
||||
|
||||
For the **ThinkStation P500** model, you use the Lenovo ThinkVantage Update Retriever software to download the drivers. With Update Retriever, you need to specify the correct Lenovo Machine Type for the actual hardware (the first four characters of the model name). As an example, the Lenovo ThinkStation P500 model has the 30A6003TUS model name, meaning the Machine Type is 30A6.
|
||||
For the ThinkStation P500 model, you use the Lenovo ThinkVantage Update Retriever software to download the drivers. With Update Retriever, you need to specify the correct Lenovo Machine Type for the actual hardware (the first four characters of the model name). As an example, the Lenovo ThinkStation P500 model has the 30A6003TUS model name, meaning the Machine Type is 30A6.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -81,9 +81,6 @@ This table shows the correct sequence for applying the various tasks to the file
|
||||
|Add .NET and .NET cumulative updates | | | 24 |
|
||||
|Export image | 8 | 17 | 25 |
|
||||
|
||||
> [!NOTE]
|
||||
> Starting in February 2021, the latest cumulative update and servicing stack update will be combined and distributed in the Microsoft Update Catalog as a new combined cumulative update. For Steps 1, 9, and 18 that require the servicing stack update for updating the installation media, you should use the combined cumulative update. For more information on the combined cumulative update, see [Servicing stack updates](https://docs.microsoft.com/windows/deployment/update/servicing-stack-updates).
|
||||
|
||||
### Multiple Windows editions
|
||||
|
||||
The main operating system file (install.wim) contains multiple editions of Windows 10. It’s possible that only an update for a given edition is required to deploy it, based on the index. Or, it might be that all editions need an update. Further, ensure that languages are installed before Features on Demand, and the latest cumulative update is always applied last.
|
||||
|
||||
@ -29,6 +29,8 @@ Servicing stack updates provide fixes to the servicing stack, the component that
|
||||
|
||||
Servicing stack updates improve the reliability of the update process to mitigate potential issues while installing the latest quality updates and feature updates. If you don't install the latest servicing stack update, there's a risk that your device can't be updated with the latest Microsoft security fixes.
|
||||
|
||||
For information about some changes to servicing stack updates, see [Simplifing Deployment of Servicing Stack Updates](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/simplifying-on-premises-deployment-of-servicing-stack-updates/ba-p/1646039) on the Windows IT Pro blog.
|
||||
|
||||
## When are they released?
|
||||
|
||||
Servicing stack update are released depending on new issues or vulnerabilities. In rare occasions a servicing stack update may need to be released on demand to address an issue impacting systems installing the monthly security update. Starting in November 2018 new servicing stack updates will be classified as "Security" with a severity rating of "Critical."
|
||||
@ -42,6 +44,7 @@ Both Windows 10 and Windows Server use the cumulative update mechanism, in which
|
||||
|
||||
Servicing stack updates must ship separately from the cumulative updates because they modify the component that installs Windows updates. The servicing stack is released separately because the servicing stack itself requires an update. For example, the cumulative update [KB4284880](https://support.microsoft.com/help/4284880/windows-10-update-kb4284880) requires the [May 17, 2018 servicing stack update](https://support.microsoft.com/help/4132216), which includes updates to Windows Update.
|
||||
|
||||
|
||||
## Is there any special guidance?
|
||||
|
||||
Microsoft recommends you install the latest servicing stack updates for your operating system before installing the latest cumulative update.
|
||||
@ -55,7 +58,3 @@ Typically, the improvements are reliability and performance improvements that do
|
||||
* Servicing stack update releases are specific to the operating system version (build number), much like quality updates.
|
||||
* Search to install latest available [Servicing stack update for Windows 10](https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV990001).
|
||||
* Once a servicing stack update is installed, it cannot be removed or uninstalled from the machine.
|
||||
|
||||
|
||||
## Simplifying on-premises deployment of servicing stack updates
|
||||
With the Windows Update experience, servicing stack updates and cumulative updates are deployed together to the device. The update stack automatically orchestrates the installation, so both are applied correctly. Starting in February 2021, the cumulative update will include the latest servicing stack updates, to provide a single cumulative update payload to both Windows Server Update Services (WSUS) and Microsoft Catalog. If you use an endpoint management tool backed by WSUS, such as Configuration Manager, you will only have to select and deploy the monthly cumulative update. The latest servicing stack updates will automatically be applied correctly. Release notes and file information for cumulative updates, including those related to the servicing stack, will be in a single KB article. The combined monthly cumulative update will be available on Windows 10, version 2004 and later starting with the 2021 2C release, KB4601382.
|
||||
|
||||
@ -66,9 +66,6 @@ To find your CommercialID within Azure:
|
||||
|
||||
Once you've added Update Compliance to a workspace in your Azure subscription, you'll need to configure any devices you want to monitor. There are two ways to configure devices to use Update Compliance.
|
||||
|
||||
> [!NOTE]
|
||||
> If you use or plan to use [Desktop Analytics](https://docs.microsoft.com/mem/configmgr/desktop-analytics/overview), follow the steps in [Enroll devices in Desktop Analytics](https://docs.microsoft.com/mem/configmgr/desktop-analytics/enroll-devices) to also enroll devices to Update Compliance. You should be aware that the Commercial ID and Log Analytics workspace must be the same for both Desktop Analytics and Update Compliance.
|
||||
|
||||
> [!NOTE]
|
||||
> After configuring devices via one of the two methods below, it can take up to 72 hours before devices are visible in the solution. Until then, Update Compliance will indicate it is still assessing devices.
|
||||
|
||||
|
||||
@ -32,8 +32,8 @@ Delivery Optimization is a cloud-managed solution. Access to the Delivery Optimi
|
||||
For information about setting up Delivery Optimization, including tips for the best settings in different scenarios, see [Set up Delivery Optimization for Windows 10 updates](waas-delivery-optimization-setup.md). For a comprehensive list of all Delivery Optimization settings, see [Delivery Optimization reference](waas-delivery-optimization-reference.md).
|
||||
|
||||
|
||||
> [!NOTE]
|
||||
> WSUS can also use [BranchCache](waas-branchcache.md) for content sharing and caching. If Delivery Optimization is enabled on devices that use BranchCache, Delivery Optimization will be used instead.
|
||||
>[!NOTE]
|
||||
>WSUS can also use [BranchCache](waas-branchcache.md) for content sharing and caching. If Delivery Optimization is enabled on devices that use BranchCache, Delivery Optimization will be used instead.
|
||||
|
||||
## New in Windows 10, version 2004
|
||||
|
||||
@ -68,9 +68,6 @@ For information about setting up Delivery Optimization, including tips for the b
|
||||
- Edge browser installs and updates
|
||||
- [Dynamic updates](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-benefits-of-windows-10-dynamic-update/ba-p/467847)
|
||||
|
||||
> [!NOTE]
|
||||
> Volume-licensed versions of Office 2019, such as Office Professional Plus 2019, can take advantage of Delivery Optimization for background updates. Delivery Optimization isn't available for installation or for foreground updates. The same applies to volume-licensed versions of Project 2019 and Visio 2019.
|
||||
|
||||
## Requirements
|
||||
|
||||
The following table lists the minimum Windows 10 version that supports Delivery Optimization:
|
||||
@ -137,7 +134,7 @@ For more details, check out the [Adopting Windows as a Service at Microsoft](htt
|
||||
|
||||
**Does Delivery Optimization work with WSUS?**: Yes. Devices will obtain the update payloads from the WSUS server, but must also have an internet connection as they communicate with the Delivery Optimization cloud service for coordination.
|
||||
|
||||
**Which ports does Delivery Optimization use?**: Delivery Optimization listens on port 7680 for requests from other peers by using TCP/IP. The service will register and open this port on the device, but you might need to set this port to accept inbound and outbound traffic through your firewall yourself. If you don't allow inbound and outbound traffic over port 7680, you can't use the peer-to-peer functionality of Delivery Optimization. However, devices can still successfully download by using HTTP or HTTPS traffic over port 80 (such as for default Windows Update data).
|
||||
**Which ports does Delivery Optimization use?**: Delivery Optimization listens on port 7680 for requests from other peers by using TCP/IP. The service will register and open this port on the device, but you might need to set this port to accept inbound traffic through your firewall yourself. If you don't allow inbound traffic over port 7680, you can't use the peer-to-peer functionality of Delivery Optimization. However, devices can still successfully download by using HTTP or HTTPS traffic over port 80 (such as for default Windows Update data).
|
||||
|
||||
If you set up Delivery Optimization to create peer groups that include devices across NATs (or any form of internal subnet that uses gateways or firewalls between subnets), it will use Teredo. For this to work, you must allow inbound TCP/IP traffic over port 3544. Look for a "NAT traversal" setting in your firewall to set this up.
|
||||
|
||||
|
||||
@ -47,14 +47,11 @@ Windows Update for Business enables an IT administrator to receive and manage a
|
||||
Windows Update for Business provides management policies for several types of updates to Windows 10 devices:
|
||||
|
||||
- **Feature updates:** Previously referred to as "upgrades," feature updates contain not only security and quality revisions, but also significant feature additions and changes. Feature updates are released semi-annually in the fall and in the spring.
|
||||
- **Quality updates:** Quality updates are traditional operating system updates, typically released on the second Tuesday of each month (though they can be released at any time). These include security, critical, and driver updates.
|
||||
- **Quality updates:** Quality updates are traditional operating system updates, typically released on the second Tuesday of each month (though they can be released at any time). These include security, critical, and driver updates. Windows Update for Business also treats non-Windows updates (such as updates for Microsoft Office or Visual Studio) as quality updates. These non-Windows Updates are known as "Microsoft updates" and you can set devices to receive such updates (or not) along with their Windows updates.
|
||||
- **Driver updates:** Updates for non-Microsoft drivers that are relevant to your devices. Driver updates are on by default, but you can use Windows Update for Business policies to turn them off if you prefer.
|
||||
- **Microsoft product updates:** Updates for other Microsoft products, such as Visual Studio or versions of Microsoft Office that are installed by using Windows Installer (MSI). These updates are treated the same way as quality updates. Microsoft product updates are off by default, but you can turn them on with Windows Update for Business policies.
|
||||
- **Microsoft product updates**: Updates for other Microsoft products, such as versions of Office that are installed by using Windows Installer (MSI). Versions of Office that are installed by using Click-to-Run can't be updated by using Windows Update for Business. Product updates are off by default. You can turn them on by using Windows Update for Business policies.
|
||||
|
||||
|
||||
>[!NOTE]
|
||||
>Versions of Office that are installed by using Click-to-Run can't be updated by using Windows Update for Business.
|
||||
|
||||
## Offering
|
||||
You can control when updates are applied, for example by deferring when an update is installed on a device or by pausing updates for a certain period.
|
||||
|
||||
@ -129,7 +126,7 @@ The large number of different policies offered for Windows 10 can be overwhelmin
|
||||
The Update Baseline toolkit makes it easy by providing a single command for IT Admins to apply the Update Baseline to devices. You can get the Update Baseline toolkit from the [Download Center](https://www.microsoft.com/download/details.aspx?id=101056).
|
||||
|
||||
>[!NOTE]
|
||||
>The Update Baseline toolkit is available only for Group Policy. Update Baseline does not affect your offering policies, whether you’re using deferrals or target version to manage which updates are offered to your devices and when.
|
||||
>The Update Baseline toolkit is available only for Group Policy. Update Baseline does not affect your offering policies, whether you’re using deferrals or target version to manage which updates are offered to your devices when.
|
||||
|
||||
<!--
|
||||
|
||||
|
||||
@ -38,7 +38,7 @@ The following resources provide additional information about using Windows Updat
|
||||
|
||||
## Reset Windows Update components manually
|
||||
|
||||
1. Open a Windows command prompt as Administrator, and then run this command:
|
||||
1. Open a Windows command prompt. To open a command prompt, click **Start > Run**. Copy and paste (or type) the following command and then press ENTER:
|
||||
``` console
|
||||
cmd
|
||||
```
|
||||
|
||||
@ -101,7 +101,7 @@ You can use these variables within sections in the .xml files with `context=User
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>CSIDL_COMMON_STARTUP</strong></p></td>
|
||||
<td align="left"><p>The file-system directory that contains the programs that appear in the <strong>Startup</strong> folder for all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup.</p></td>
|
||||
<td align="left"><p>The file-system directory that contains the programs that appear in the Startup folder for all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>CSIDL_COMMON_TEMPLATES</strong></p></td>
|
||||
@ -116,7 +116,7 @@ You can use these variables within sections in the .xml files with `context=User
|
||||
<td align="left"><p>Refers to the Appdata folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>CSIDL_DEFAULT_LOCAL_APPDATA</strong></p></td>
|
||||
<td align="left"><p>C<strong>SIDL_DEFAULT_LOCAL_APPDATA</strong></p></td>
|
||||
<td align="left"><p>Refers to the local Appdata folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
@ -319,7 +319,7 @@ You can use these variables in the .xml files within sections with `context=User
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>CSIDL_CONTACTS</strong></p></td>
|
||||
<td align="left"><p>This refers to the Contacts folder in <strong>%CSIDL_PROFILE%</strong>.</p></td>
|
||||
<td align="left"><p>This refers to the Contacts folder in %<strong>CSIDL_PROFILE</strong>%.</p></td>
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>CSIDL_CONTROLS</strong></p></td>
|
||||
@ -339,7 +339,7 @@ You can use these variables in the .xml files within sections with `context=User
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>CSIDL_DRIVES</strong></p></td>
|
||||
<td align="left"><p>The virtual folder representing My Computer that contains everything on the local computer: storage devices, printers, and <strong>Control Panel</strong>. The folder may also contain mapped network drives.</p></td>
|
||||
<td align="left"><p>The virtual folder representing My Computer that contains everything on the local computer: storage devices, printers, and Control Panel. The folder may also contain mapped network drives.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>CSIDL_FAVORITES</strong></p></td>
|
||||
@ -379,7 +379,7 @@ You can use these variables in the .xml files within sections with `context=User
|
||||
</tr>
|
||||
<tr class="odd">
|
||||
<td align="left"><p><strong>CSIDL_NETHOOD</strong></p></td>
|
||||
<td align="left"><p>A file-system directory that contains the link objects that may exist in the My Network Places virtual folder. It is not the same as <strong>CSIDL_NETWORK</strong>, which represents the network namespace root. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Network Shortcuts.</p></td>
|
||||
<td align="left"><p>A file-system directory that contains the link objects that may exist in the My Network Places virtual folder. It is not the same as CSIDL_NETWORK, which represents the network namespace root. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Network Shortcuts.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><strong>CSIDL_NETWORK</strong></p></td>
|
||||
@ -467,3 +467,5 @@ You can use these variables in the .xml files within sections with `context=User
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -29,9 +29,6 @@ ms.topic: article
|
||||
>- Windows Server 2012
|
||||
>- Windows Server 2016
|
||||
>- Windows Server 2019
|
||||
>- Office 2013*
|
||||
>- Office 2016*
|
||||
>- Office 2019*
|
||||
|
||||
**Looking for retail activation?**
|
||||
|
||||
@ -100,17 +97,6 @@ When a reactivation event occurs, the client queries AD DS for the activation o
|
||||
1. Activate your KMS host key by phone or online (Figure 15).
|
||||
|
||||
|
||||
|
||||
> [!NOTE]
|
||||
> To activate a KMS Host Key (CSVLK) for Microsoft Office, you need to install the version-specific Office Volume License Pack on the server where the Volume Activation Server Role is installed.
|
||||
|
||||
|
||||
- [Office 2013 VL pack](https://www.microsoft.com/download/details.aspx?id=35584)
|
||||
|
||||
- [Office 2016 VL pack](https://www.microsoft.com/download/details.aspx?id=49164)
|
||||
|
||||
- [Office 2019 VL pack](https://www.microsoft.com/download/details.aspx?id=57342)
|
||||
|
||||
|
||||
**Figure 15**. Choosing how to activate your product
|
||||
|
||||
@ -129,8 +115,6 @@ To verify your Active Directory-based activation configuration, complete the fol
|
||||
|
||||
> [!NOTE]
|
||||
> If you are using both KMS and Active Directory-based activation, it may be difficult to see whether a client has been activated by KMS or by Active Directory-based activation. Consider disabling KMS during the test, or make sure that you are using a client computer that has not already been activated by KMS. The **slmgr.vbs /dlv** command also indicates whether KMS has been used.
|
||||
> To manage individual activations or apply multiple (mass) activations, please consider using the [VAMT](https://docs.microsoft.com/windows/deployment/volume-activation/volume-activation-management-tool).
|
||||
|
||||
|
||||
## See also
|
||||
|
||||
|
||||
@ -91,7 +91,6 @@ For Microsoft customers with Enterprise Agreements (EA) or Microsoft Products &
|
||||
- Windows 10 (Pro or Enterprise) version 1703 or later installed on the devices to be upgraded.
|
||||
- Azure Active Directory (Azure AD) available for identity management.
|
||||
- Devices must be Azure AD-joined or Hybrid Azure AD joined. Workgroup-joined or Azure AD registered devices are not supported.
|
||||
- Windows 10 per user licensing is not available for per device based licensing.
|
||||
|
||||
For Microsoft customers that do not have EA or MPSA, you can obtain Windows 10 Enterprise E3/E5 or A3/A5 through a cloud solution provider (CSP). Identity management and device requirements are the same when you use CSP to manage licenses, with the exception that Windows 10 Enterprise E3 is also available through CSP to devices running Windows 10, version 1607. For more information about obtaining Windows 10 Enterprise E3 through your CSP, see [Windows 10 Enterprise E3 in CSP](windows-10-enterprise-e3-overview.md).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user