I’ve recently supported a customers environment where they had a split environment. This environment consisted of both physical and virtual assets managed by MemCM, or WS1. The virtual assets were Amazon Windows 10 BYOL Workspaces which come with their own pre-reqs to be able to upgrade devices, and support is very limited to do so. For example on a regular windows workstation you can have many profiles on a single device successfully upgraded, on a AWS BYOL Win 10 Workspace if you have more than 1 profile the AWS Scripts does not know how to handle multiple profiles. In my suggested approach we perform weekend migrations locking the end user out of the system. In this scenario the devices are 1709 w/ user profiles on the D drive.
Step 1: Lock Device to End User
We lock out the end user from accessing the workspace b/c there will be temporary user profile created after key scripts are ran. This is in effort to prevent any errors related to temp profile from happening.
Step 2: Set Registry Keys + Restart System
The in-place upgrade process uses two registry scripts (enable-inplace-upgrade.ps1 and update-pvdrivers.ps1) to make the necessary changes to your WorkSpace that enable the Windows Update process to run. These changes involve creating a (temporary) user profile on drive C instead of drive D.
We first manually set the registry how we need it to be set to perform the upgrade and we then export those keys. Those keys are kept in a legacy package that is referenced in our task sequence. The task sequence does a reg import for both keys from the package and then performs the restart of the system.
NOTE: Previously we had this as part of our CompatScan TS, however the AWS Environment at this customers site is more standardized than physical devices so there was no known errors except for space. We can easily identify space concerns in advance w/ native sccm sql queries.
The enable-inplace-upgrade.ps1 script will run after the reboot and backup the user profile and remove the path to the D: preventing errors related to that drive not being present during the IPU process. The script re-runs after each reboot looking for a completed update, and when it is detected it will restore the correct user profile path, and then disable itself afterwards.
The enable-inplace-upgrade.ps1 and update-pvdrivers.ps1 scripts is located in the C:\Program Files\Amazon\WorkspacesConfig\Scripts
Once the Keys are imported and the devices is restarted the systems look this below. The keys are now set how we want them, and the profile is backed up.
Step 3: Start Feature Upgrade
This will be a required deployment just like any other feature upgrade. Below we see the system upgraded to 1909.
Quick Reporting Screenshot:
We are tattooing the registry and absorbing that information via HW inventory. You can do the same, and use SQL Case statements to display in the report how a system got to version 1909.
Things to make sure of….
No profiles on C:\ check HKLM\SOFTWARE\Microsoft\WINDOWS NT\CurrentVersion\ProfileList check the SSID for the profile location.
Reg Keys properly set per your specific environments configuration. You MUST enable the scripts and perform a restart. If the profile is not backed up in the reg location shown earlier in this post you will likely have an error for access violation where windows update cannot read the profile location. I’ll cover troubleshooting and exact errors I faced in a future blogpost.
Key Reading: https://docs.aws.amazon.com/workspaces/latest/adminguide/upgrade-windows-10-byol-workspaces.html
In a future blogpost we will cover how to troubleshoot AWS Upgrades going in depth into log files, and exact errors I encountered trying to get this to a reliable and automated state.
Add comment