Methods for Windows Servicing

[John Yoakum]

I know that there are a couple different methods for servicing windows, both with servicing and IPUs. I am curious as if the process for servicing has gotten better to the point that it will maintain personal settings during the servicing process? And as a follow-up, what things may or may not be carried over during the servicing process? I am working on designing the best plan for servicing our environment, and need the best advice. I know that IPU gives us more control, but we don't need that much.

Thanks

[#2]

@John Yoakum 

Hey John, the Windows Setup Engine rarely removes personal settings.  It removes system settings if your organization overwrote system registry keys, or windows files, but overall, Windows Upgrades (Servicing) is very friendly to end users, and less friendly to corporate processes that might have relied on things like Active Setup.

The best way to know, take a test machine, and run the upgrade.   Windows 10 is AMAZING at reverting.  Run the upgrade, poke around, see if something broke, and work on remediation scripts, and in the mean time, you can easily revert.

Do you have any examples of settings you've experienced being lost during upgrades that you are looking to find solutions for?

[#3]

@gwblok Hey Gary. We are just beginning the process. We barely got through our 7 to 10 migration and that was our big focus. Now it is starting to focus on keeping windows 10 updated. We really don't have many settings we apply within our org. And most of those are minimal customizations that can go away without any headache. With our desktop team trying to keep work going while we are in this new world, they are wanting me to look at a process for this.

[#4]

@gwblok @John Yoakum What I tend to find with Windows 10 Servicing with ConfigMgr is that they don't always show up on the clients for the upgrade to take place. If I push a Upgrade TS to the same clients, it's seen and applicable. What gives with Servicing? 

[#5]

@John Yoakum , In the past we were not graceful about it however those issues were addressed by 1709. For a feature update to Win10, user settings are migrated.  This happens either through an IPU via WU/WUfB/ConfigMgr Software Updates, etc… or a traditional media based upgrade. If you see migration failures, direct message me so we can explore. That said, there is a known issue with on-prem upgrades and migrating languages and FODs. These are mitigated by ensuring dynamic updates are enabled. When enabled, the setup stack will acquire these automatically from Windows Update, however, it will also pull in the latest LCU. See Setup Command Line Parameters for more details on Dynamic Update and /InstallLangPacks (another option to point setup to local languages and language FODs).

[#6]

@John Yoakum 

Great work on getting off Windows 7, that is no small feat to do upgrades from Windows 7.  Thankfully, while the process of going from Win10 build to newer Win10 build is basically the same, the pain levels are much less.

The biggest thing will be testing, loading up CM with 1909 and running it on your 1709/1809 machine and see what happens.  Once you've done your own testing, start your testing rings, hit a few of your trusted IT folks, and then a few of your business technology evangelists, and wait for awhile to see if anything else shakes out. 

For us, it's always been app issues, and typically they are rare apps that were written poorly, and it's the same usual suspects each upgrade.  Desktop Analytics will be helpful in finding these, but you won't know it all until you upgrade some folks.  

Remind testers that upgrading risk is very small, thanks to the ability to Revert has allowed us to accelerate early deployment for testing.

Hope that was helpful. - Gary

[#7]

@Kevin Mineweaser We only have one language and no FODs, which makes it even easier. None of that to worry about.