Win10 Software Delivery Feature upgrade with OSIM data

[Michael Treichler]

This is a process to deploy Windows 10 Feature upgrade/update using Software Delivery and OSIM OS data.

 

Theory behind process is if use OSIM with WINDOWS10 or WINDOWS10X64 image types the data to upgrade Win10 is already available in OSIM on Scalability Servers. 

If don’t use OSIM the process of setting OSIM data for Win10 OS upgrades on Domain Manager and Scalability Servers with OSIM IPS wizard & SD is easy.

 

If already using OSIM with WINDOWS10 or WINDOWS10X64 I would highly recommend updating OSIM image files to newer Win10 versions as Microsoft releases new versions certified within specific environment.   Having new or re-imaged assets image with Win10v<new> saves task of a lengthy update.

 

OSIM already includes processes for updating and distributing image files from DM to SS so as new Win10 versions are released the OSIM data can simply be updated and distributed to SS.

 

Software delivery package detailed here is not tied to specific Win10 version, package compares local OS version to OSIM image version to determine if can upgrade.  If an environment is limited to v1709 package will work as v1709 upgrade process.  I’ve tested this extensively with upgrades from 1507, 1511, 1607, 1703, 1709 to 1709, 1803, 1809*. 

*1809 tests limited before 1809 halted by Microsoft.

 

Requirements:

Domain Manager:

• OSIM with WINDOWS10 or WINDOWS10X64 image type

Scalability Server:

• Boot Server share enabled (Procedure = CA DSM Scalability Server 14.0.xxxx.***/Enable Boot Server share). OSIM images may not deploy to SS in TFTP mode.
• MSILIB share enabled (Procedure = CA DSM Scalability Server 14.0.xxxx.***/Enable MSILIB share)
• Windows OS (Script in package use net.exe & mklink.exe to create NTFS junctions to make OSIM’s Win10 files available in MSILIB share, Linux based SS will work but would require script to create symbolic links via ln command or a manual SS setup)
• Default location for MSILIB & OSIM (Scripts in package assume default location for MSILIB & OSIM data, but if data has been moved scripts can be updated to reflect proper file system locations. CA variables used as possible)

Agents:

• Access to Scalability Server MSILIB\SDMSILIB share (NOS-less & DTS not supported)

 

Environment setup steps:

Some DM & SS environment setup is needed before deployment of this package.  As noted steps will vary depending on MSILIB & OSIM current usage.

Step 1- 5 may already be complete if using OSIM with WINDOWS10 or WINDOWS10X64 image types.

1. OSIM IPS Setup Win10 OSIM image on DM
2. Register OS Image in DM as Software package
3. Enable Boot Share on SS via procedure “Enable Boot Server share”
4. Enable MSILIB on SS via procedure “Enable MSILIB share”
5. Deploy OSIM Win10 image to SS via SD package created in step #2 via procedure “Add to BootServer”
6. Import “Windows 10 Feature Upgrade/Update 10.0” package into EM or DM
7. Unseal “Windows 10 Feature Upgrade/Update 10.0” package to modify script variables.
   1. CMD – PIMAGE= Set this to name of OSIM image from step #1
   2. SHARE-SETUP.CMD – SSIMAGE= Set this to name of OSIM image from step #1
8. Seal “Windows 10 Feature Upgrade/Update 10.0” package
9. <Optional> Stage “Windows 10 Feature Upgrade/Update 10.0” package to SS
10. Deploy procedure = Windows 10 Feature Upgrade/Update 10.0/Scalability Server SDMSILIB Share Setup” to SS agents are registered to.

 

 

Deployment:

There are 2 parts to upgrade Win10 upgrade. 

 

Online Portion of Upgrade –This portion of upgrade consists of setup.exe and multiple processes running.  In my tests CPU utilization ranges from 15% - 40%.  Users can continue to work while this portion of upgrade is running.  Online update times for this have been between 20min & 60min.  The SD package will log the Online time of upgrade as shown in output screenshot below as Start & Completion time.   Additionally the SD package you can chose to deploy at Low or High priority as shown in deployment procedures screenshot.  Low priority will further minimize the CPU impact of online portion of upgrade at the cost of longer Online upgrade time.  High Priority will complete Online portion of upgrade slightly faster at the cost of higher CPU.  SD package will capture exitcode of  Online portion of upgrade.  SD package utilizes a condition reboot, if package fails to install or current OS is already updated no reboot.  If update is successful reboot via DSM agent reboot behavior.

Offline Portion of Upgrade – Occurs after the reboot.   This is portion of upgrade user cannot work.  The Offline portion of upgrade is where v1803+ shines compared to 1709 and lower.  Offline portion averages between 10 – 20 minutes for v1803+ & 20 - 40 minutes for v1709.

 

 

 

To identify Win10 assets requiring upgrade recommend query or in this case a set of linked queries to ID the unsupported Win10 versions. Dynamic group based on previous query and structure in place for deployment via SD or SD policy.  Example query.

 

Deployment to Win10 assets is achieved like any other SD package.  SD procedures commented.

 

Limitations:

• SD package is designed for upgrading single Win10 OS bitness/edition; Win10x64. If multiple OS types or editions in use within an environment additional scripting could be added to setup shares and address those upgrade scenarios.   
• SD Procedures are limited to Win8+, not tested upgrade below Win10. Package may work on Win8 or Win7.
• Even though Online portion of upgrade may run fine (exitcode 0) upgrade can fail during offline portion of upgrade. Considered method to have SD job check status POST Offline upgrade completion, but never implemented.  POST Offline upgrade check could be achieved via “sd_acmd.exe Signal reboot rerun” in scripting to have SD job continue POST Offline upgrade, functionality may need reboot counter to prevent failed upgrade reboot/retry loop.  

 

Technical Synopsis:

Win10 setup CLI options.

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-command-line-options 

 

Both batch files used in package INSTALL.CMD & SHARE-SETUP.CMD are well commented.

SHARE-SETUP is creating an NTFS junction in SS’s MSILIB share to OSIM Win10 image data using %SDROOT% variable.   Script checks for MSILIB share & OSIM data.

INSTALL.CMD checks if SS’s MSILIB have Win10 OSIM NTFS junction files present (setup.exe & \sources\install.wim).   Compare Win10 version on agent to SS’s Win10 \sources\install.wim, if version newer quit, otherwise continue. 

Both scripts supports /DEBUG:Y command line option in procedure to enable debugging.

 

Win10v1803 added some options for scripts to run POST feature upgrade.  Options to run script during a  feature upgrade or every future feature upgrade.

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-enable-custom-actions

 

Also see these posts for additional information:

https://communities.ca.com/thread/241810619-sd-package-for-w10-feature-upgrade

https://communities.ca.com/thread/241811984-how-to-upgrade-windows-10-1709-to-1803

Attachment(s)

Windows-Feature-Upgrade_10.0.zip   3 KB 1 version

[Claus Haberzettel]

Worked perfect for me. Great job !

I only had to add "/english" to the "Dism /Get-ImageInfo ...." command for a german OS. There the german dism output has "Version:" without the blank for both version infos (dism tool and wim file). The english output has "Version :" with the blank for the wim info.

Regards

Claus

[Hans Dieter Moethrath]

Worked perfect for me too. 
Works with 1903.

Thx, Claus for supporting me.
Use Package "CA DSM Scalability Server" procedure "Enable MSILIB share" to enable MSLIB Share.

What i see is install Date in inventory was renew.

Regards Dieter