display top 6 recent blogpost


Feature Upgrade AWS Workspace


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.

WaaS – Overview of WaaS the Wolverine Way

, , , ,

I remember the first attempt I made at upgrading a group of devices at work.  It was the Autumn of 2017 and I was trying to upgrade a group of roughly 20 Build 1511 devices since support was running out on that build.  I had been to the Midwest Management Summit (MMS) earlier that Spring and believed I had a pretty good handle on how it should be done.  I had attended a number of sessions and listened to the merits of using an In-Place Upgrade (IPU) task sequence as opposed to Servicing Plans.  I created my IPU sequence and submitted the deployment to our Change Management process.  I was so confident that I didn’t balk at the decision to schedule the deployment during the week when I was going to be in Florida attending Microsoft Ignite.  The evening of the deployment arrived…

Read more

WaaS -IPU Progress Tracking Spreadsheet

As I write this post we are just days away from beginning the mass In-Place Upgrades (IPUs) of the entire enterprise (~35,000 devices).  Of course everyone is going to want to know how the numbers are looking.  To better show how the IPUs are progressing, I’ve created a tracking spreadsheet.

Read more