Purpose

To outline the process for deploying Windows 10 build upgrades in Patch for Windows Servers (PWS) - build upgrades up through build 1809 are currently supported.

Deployment of Windows 10 build 1511, 1607, 1703, 1709, 1803, or 1809 applies to systems with a Windows 10 OS already installed. The deployment will not work for systems with an OS previous to Windows 10.

Description

What considerations must be taken into account prior to deploying Windows 10 build upgrades?

• Encryption such as BitLocker must be disabled for the deployment to be successful.  The machine must be able to fully reboot on its own to complete the deployment properly.
• The deployment of the Windows 10 build upgrade is effectively a full operating system install, which includes all of the potential risks of a traditional OS upgrade. This can include, but are not limited to:
  • Blue screens (BSOD)
  • Data loss
  • Loss of existing settings
  • Program incompatibility
• Driver incompatibility can cause the update to fail. The Windows 10 app can help find some of these problematic drivers. If this is not available on the endpoint, see here for assistance.
• There are multiple versions of the 1511 ISOs. Older versions are more likely to cause blue screens, or otherwise fail. It is strongly recommended to use the most recent published version of the ISO.
  • The first release ISOs from November 2015 caused a BSOD or install failures on a number of systems. The install will then revert the machine to RTM. None of the defective ISO files made the machine unusable.
• Both the endpoint receiving the update and the console deploying it need to have sufficient hard drive space.
  • The PWS console needs to have at least 5GB  free to download the ISO
  • The endpoint that is receiving the update needs to have at least 10GB free, but 20GB is recommended
• When patching from a unpatched RTM version of Windows 10 to 1607, our internal QA found that there is a high chance of a BSOD occurring and the update reverting to the RTM state. This can be avoided by fully patching the Windows 10 RTM machine, rebooting, and then applying the 1607 update.
• This deployment method only works to upgrade an existing Windows 10 installation.  PWS cannot upgrade an older OS to Windows 10 (e.g., Windows 7 > Windows 10).

Step 1: Obtain the ISO

• The most recently published ISO that is needed for the build upgrade deployment can be found in two places, depending on which edition needs to be deployed:
  • For Home and Pro endpoints, download the Media Creation Tool from Microsoft Tech Bench and follow the directions under "Using the tool to create installation media". Select the option to download the ISO file. "Windows 10" is the Edition for Windows 10 Professional, "Windows 10 Home Single Language" is the Edition for Windows 10 Home. This will download the most recent ISO available.

• For Enterprise and Education, obtain the correct ISO from MSDN or Microsoft Volume Licensing
  

Step 2: Prepare the ISO

• The ISO must be renamed to match the Shavlik naming scheme which includes the OS architecture, the edition, locale (if not en-us), and version. See below for examples:
  • Windows10x64Enterprise1703.iso
  • Windows10x64Enterprise1709.iso
  • Windows10x64Professional1709.iso
  • Windows10x86Education1709.iso
  • Windows10x64ProfessionalN1709.iso
  • Windows10x64Enterprise1803.iso
  • Windows10x64Professional1803.iso
  • Windows10x64Enterprise1809.iso
  • Windows10x64Professional1809.iso
• To find out exactly which naming scheme to use, scan the endpoint that will be receiving the update with the PWS console or you can look up the update in View > Patches. Under "Bulletin Details", the File Name will show what the ISO needs to be renamed to. See below for an example:

• The renamed ISO must now be placed in the patch repository on the PWS console. The default location for this is: "C:\ProgramData\LANDESK\Shavlik Protect\Console\Patches", but you can find where your patch repository location is set in Tools > Options > Downloads.
• For customers using distribution servers or agent-based patching, move the renamed ISO to the according Patch Store location
  

Step 3: Deploy the ISO

• Perform a patch scan of the desired machines. Once the scan is complete, go to the scan results and expand the Service Pack Missing list. For example:

• Select the 1809 (or 1511/1607/1703/1709/1803 depending on which version is being deployed) option to deploy the update (do not select TH2). If the TH2 option is selected, or if the necessary ISO file for the build you are pushing is not named correctly or is not placed in the Patch Store, then errors will occur. For example:

• The PWS deployment will verify different aspects of the deployment before staging it on the endpoint. It will verify that:
  • The language of the ISO dropped into that Patch Store matches the language of the endpoint's OS
  • The remote registry setting is saved
  • The status of the built-in Admin account (enabled or disabled) is saved
  • The endpoint receives all necessary scripts and files for the deployment
• The deployment of one of these updates can take up to and possibly longer than 3 hours. During this time the endpoint will boot to an installation environment after the ISO is successfully staged. PWS has no way of interacting with this environment. If something goes wrong, the Windows 10 installer will attempt to roll back to the previous OS state, but this is not guaranteed.
• Once the deployment has been initiated, PWS will show the screen below. Since the deployment of these updates boots into a OS install environment, PWS cannot get any feedback from it. If the description field returns 0, then all pre-deployment checks have passed and the target machine has rebooted into the OS install environment.

Step 4: Verifying the Deployment was Successful

• Once the endpoint has finished the install, use the console to re-scan the target. If the update deployment was successful, the re-scan will not show any missing service packs. See image below:

• The 1511/1607/1703/1709/1803/1809 deployment can also be verified by going to the target and running the "winver" command. The "About Windows" pop up should show Version 1511, 1607, 1703, 1709, 1803, or 1809 depending on which was deployed.

Affected Products

Ivanti Patch for Windows Servers 9.3.x