WaaS – Phase 0 [Scrutineering]

, , , ,
Troubleshooting and Upgrading AD FS Farms

In part 1 I talked about the overall design of my WaaS implementation and some background on how I got there.

WaaS – Overview of WaaS the Wolverine Way

Here I’ll go into details on the “Phase 0” portion of the process, the Reference or “scrutineering” phase.  The purpose is to ensure that our pool of client devices is adhering to the rules and are eligible to be potential upgrade targets.

What is the Goal?

The goal, like scrutineering at the start of a race weekend, is to verify that all of the devices being fed into the WaaS process meet the fundamental rules for eligibility.  During this phase we attempt to catch devices that we will never want to attempt the In-Place Upgrade (IPU) on.  We want to catch the “rule breakers” as you would.

What “Rules” are We Enforcing?

The rules in this phase are broad strokes that catch devices with “issues” that you cannot change.  Essentially there is no exception for a failure at this phase, nor is there a way to “fix” the issues.

Currently we have three rules in this stage:

  1. No Windows 7
  2. No “current” Windows 10
  3. No unsupported hardware

The WaaS process is geared towards the ability to continuously feed devices in, blindly if you will, and let the process take care of itself.

No Windows 7

While on paper you can IPU a Windows 7 device to Windows 10, the Windows 7 devices in our environment make that impossible.  We have a sizable population of 32bit installations, older devices that need to be re-partitioned due to using an outdated partitioning scheme, and use a 3rd party encryption solution.  Plus, we are very near to completing our migration to Windows 10.

Because of that all Windows 7 devices are blocked during this phase.

We have not deployed Windows 8 or 8.1 so we do not have any devices in our environment running those OSes.  If we had, we would use the same process that we are using to filter out Windows 7 to filter these out as well.

No “current” Windows 10

If a device is already running the currently deployed build of Windows 10, or a build that is newer than what we are deploying in Production, then we block those and prevent them from moving forward in the process.

No unsupported hardware

Lastly we wanted the ability to control what hardware is permitted to be upgraded.  We can block hardware that was purchased outside of the official channels as well as block hardware that the manufacturer no longer supports.

How are We Enforcing those Rules?

Phase Organization

We are using a series of collections to sort the various devices as they flow through this phase.  In each phase there is a collection for all devices starting that phase and another collection for all devices that have passed that phase.  The goal is to get from the start to the finish successfully.  In between those two we will have various collections to catch problematic devices.  These collections are used in our reporting.

Operating System Data Collection

We do not necessarily want to rely on Hardware Inventory data for all of this, just in case there is a problem with that.  To get up to date operating system data we enable “Active Directory System Discovery” and include the attributes “operatingSystem” and “operatingSystemVersion” as shown below.

This will get us the OS data quicker than waiting on Hardware inventory to process.

Collection Structure

There are 6 collections that are in play during this phase.

  1. WaaS_DEV_1903_Phase0-Reference_00_StartingPoint
  2. WaaS_DEV_1903_Phase0-Reference_01_Ineligible-OS-Windows7
  3. WaaS_DEV_1903_Phase0-Reference_02_Ineligible-OS-Windows10-CurrentBuild
  4. WaaS_DEV_1903_Phase0-Reference_03_Ineligible-UnsupportedHardware
  5. WaaS_DEV_1903_Phase0-Reference_98_AllSupportedHardware
  6. WaaS_DEV_1903_Phase0-Reference_99_PassedScrutineering

 


WaaS_DEV_1903_Phase0-Reference_00_StartingPoint

Limiting Collection:        All Client Systems

This is the entry point into this phase as well as the overall WaaS process.  The ultimate intent is to potentially “back the truck up” and funnel everything into this collection.  During our various pilots and our first production run we have been much more selective in what is fed into the process though.


WaaS_DEV_1903_Phase0-Reference_01_Ineligible-OS-Windows7

Limiting Collection:        WaaS_DEV_1903_Phase0-Reference_00_StartingPoint

This collection is used to gather up all of the devices from the “StartingPoint” collection that are running Windows 7.

Query:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.operatingSystemVersion = “6.1 (7601)”

 


WaaS_DEV_1903_Phase0-Reference_02_Ineligible-OS-Windows10-CurrentBuild

Limiting Collection:        WaaS_DEV_1903_Phase0-Reference_00_StartingPoint

This collection will gather all of the devices from the “StartingPoint” collection that are running the currently deployed Windows 10 build and any newer builds.

Query (Multiple, one per Windows 10 build):
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.operatingSystemVersion = “10.0 (18362)”

 


WaaS_DEV_1903_Phase0-Reference_03_Ineligible-UnsupportedHardware

Limiting Collection:        WaaS_DEV_1903_Phase0-Reference_00_StartingPoint

Here is where things get a little more interesting.  This collection works in conjunction with the “AllSupportedHardware” collection detailed next.  Its purpose is to collect all of the devices that are running on unsupported hardware.  These could be devices that were purchased outside of the normal channels, hardware that is no longer supported by the manufacturer, or hardware that we have decided to no longer support for any reason.

Query:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.ResourceId not in (select ResourceID from SMS_CM_RES_COLL_PS1000C6)

 

In this example, the collection ID PS1000C6 points to the “AllSupportedHardware” collection.

This query pulls in all devices that are NOT a member of the “AllSupportedHardware” collection.  This results in a collection of those devices that are running on unsupported hardware.  This query functions in a similar fashion to using an “Exclude Collection” rule but does not carry the restriction and overhead of the collection reference.


WaaS_DEV_1903_Phase0-Reference_98_AllSupportedHardware

Limiting Collection:        WaaS_DEV_1903_Phase0-Reference_00_StartingPoint

This is a collection of all devices that are running on hardware that we support.

Query (Multiple, one per hardware model):
Example – Microsoft Surface Book:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.Model = “Surface Book”

For HP hardware we reference the baseboard number instead of the model name.

Example – HP Z840 Workstation:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_BASEBOARD on SMS_G_System_BASEBOARD.ResourceId = SMS_R_System.ResourceId where SMS_G_System_BASEBOARD.Product = “2129”

WaaS_DEV_1903_Phase0-Reference_99_PassedScrutineering

Limiting Collection:        WaaS_DEV_1903_Phase0-Reference_00_StartingPoint

This is the collection that marks the end-point of this phase.  Machines that have not been filtered out by the above “Ineligible” collections will fall into this one and will be ready to move on to the next phase of the process.

Query:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.ResourceId not in (select ResourceID from SMS_CM_RES_COLL_PS1000C2) and SMS_R_System.ResourceId not in (select ResourceID from SMS_CM_RES_COLL_PS1000C3) and SMS_R_System.ResourceId not in (select ResourceID from SMS_CM_RES_COLL_PS1000C4)

 

In this example, the following collection IDs map to these collections:

  • PS1000C2 => Ineligible Windows 7
  • PS1000C3 => Ineligible Windows 10 Current
  • PS1000C4 => Ineligible Unsupported Hardware

This query pulls in all of the devices that are NOT members of those 3 “Ineligible” collections.  Since those “Ineligible” collections gather up machines that have failed those respective tests, the end result is a collection of devices that successfully passed all three tests.

The End Result

In the above example I have 3 client VMs funneled into the process.  Of those, none are running Windows 7, but 2 of them are running Windows 10 Build 1903 or 1909, and all three are supported hardware (Hyper-V VMs).

Starting Point Collection:

Ineligible Windows 10 Current Collection:

Passed Scrutineering Collection:

Why so many Verbose Collections?

We use the collections as a tool to help guide our support teams when troubleshooting WaaS issues.  To do this we have created a simple web report that a support tech can enter in a computer name and the report will show what WaaS related collections it is a member of.

For example, let us say that the field tech wants to know why 2 of the PCs they are responsible for are not upgrading (i.e. PC0102 and PC0104).  They enter those computer names into our web report and it will show that they are members of the “WaaS_DEV_1903_Phase0-Reference_02_Ineligible-OS-Windows10-CurrentBuild” collection.  This tells them that those two PCs are already running a current build of Windows 10 and do not need to be upgraded.

Here is an example:

During the next phase we will get into many more troubleshooting collections that may better illustrate this.  There we will begin filtering out devices running software that has not been approved for the upgrade, or have failed to keep in contact with ConfigMgr, or have insufficient disk space, etc.

We’ll get to that in the post detailing Phase 1 – Pre-Assessment.

What’s Next?

We now have a collection of devices that have passed our scrutineering rules.  We are left with a collection of devices that are running on supported hardware and running an OS that we are willing to upgrade to the next Windows 10 build.

In the next post I’ll detail the Phase 1 – Pre-Assessment portion of the process.

 

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

six + five =

This site uses Akismet to reduce spam. Learn how your comment data is processed.