Edit:

26.11.2024

- Uploaded files for Windows 11 24H2 upgrade

- Since Microsoft changed their way of doing inplace upgrades, the builtin Feature Upgrade in SMA can not be used anymore for 24H2 upgrades.

02.12.2019

- Uploaded the files for upgrade to 1909

- HINT: If the upgrade is failing in your environment, please check the process timeout in "Settings / Provisioning / Communication Settings". There is a process timeout that is normally set to 30 minutes. That means, that if a script need more then 30 minutes, it run in a timeout and will stop the execution. Set it to 2 hours and then the upgrade script will run successfully.

- For the 1909 upgrade we need to change the report filters from "equal" to "contains":

Hello Community,

Here is my final article of my mini series covering a strategy for the Windows 10 inplace upgrades. This series contain 3 blog posts:

1.) a precheck to detect upgrade issues or blocker in advance

      https://www.itninja.com/blog/view/kace-sma-windows-10-inplace-upgrade-precheck

2.) the preseeding of the binaries so that clients outside your network will smoothly download the gigabytes

      https://www.itninja.com/blog/view/kace-sma-windows-10-preseeding-large-files

3.) the upgrade itself

At this place I want to thank chrpetri for being a great help for developing this strategy and these scripts.

Here you can download the exported script as well as the report and the custom inventory rule.

1903 - DOWNLOAD

1909 - DOWNLOAD

Win 11 24H2 - DOWNLOAD

As dependencies we have some scripts and files. Keyfreeze is used to prevent user interaction on a client on which the upgrade is performed. The script "LaunchKeyFreeze.cmd" only distinguishes between x64 and x86 and executes the correct EXE.

The script "setupcomplete.cmd" writes the string “SUCCESS” to a file. This script is only executed if the setup.exe was successfully.

The script "UpgradeWinX.cmd" contains the command to execute the inplace upgrade and the error handling if something should fail.

This KACE script is based on the same ISO as the PreCheck script. The first three tasks are similar to those in the PreCheck script. Here we check if the system is upgrade-able and if our temporary folders exist. If these are available, we clean the folders.

The only difference here is that we check the language code in the first task. This is important because we need an ISO file that contains the same language as the base image of the operating system. This means that if a client was installed from an English image and German was installed as additional (or even default) language afterwards, we still need the English ISO file for the upgrade. Otherwise the upgrade will fail.

You must change the language code if you have a different language installed on your clients. I have set the Language Code for English (en_US).

You can find the possible language codes here:

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/available-language-packs-for-windows

Recommendation: If you have several languages in your company, it makes sense to roll out an English basic image on all clients. After the deployment, you can install any language package. You will then only need the English ISO file going forward.

The fourth task in this script is about the upgrade. First, we write the status of the upgrade to a file, which will be checked in the inventory run right after creation.

Then the script "setupcomplete.cmd" is copied. This script is then called by the "setup.exe" as soon as the upgrade was successful. After copying the file, we execute the Keyfreeze. This can be removed if necessary.

As the last step in Verify we run the upgrade script, with the path to the ISO file (can also be local if the files were previously stored) and the path to the log files.

You have to edit the path to the ISO file to your environment similar to the PreCheck script.

If the setup was successful, the log files are collected and uploaded to the SMA. In addition, a restart is initiated to continue the upgrade.

If the setup fails, the log files are also collected and uploaded to the SMA. At the end the Keyfreeze is still terminated, so that an interaction with the client is possible again.

Important: This script must be executed in a task chain. Since the script performs a restart, it would not complete in a normal execution as a script after a successful upgrade. However, the task chain continues to execute the script even after a restart.

In the following window, assign a name for the Task Chain and assign Clients. In addition, you must deselect the MacOSX and Linux operating systems if they are present in your network.

Then you can define a schedule and a new task can be created.

Now we select the Windows 10 Upgrade script. If the script is not in the list, you must activate the imported Windows 10 Upgrade script in our script module.

Finally, save the task chain. Now you can deploy the upgrade.

During the execution of the script we will write several states to a file. The states within the file will be reported to SMA by a custom inventory rule.

The CIR have a different ID in your environment, so you need to edit the filter in the report.

To customize the report, navigate to "Reporting / Reports" and search for "Windows 10 Build 1903 Upgrade Status". Then click the report and navigate to "Filters". In the filter you need to choose the CIR and set the operator to equal and type the states in as values.

The following is an example of this report:

I hope this mini series will help you with your inplace upgrades so that you have time again for the important things in life. If there are any questions or problems, do not hesitate to use the comment function and let me know.