Windows 10 Inplace Update History Inventory

We were tasked at our company to get some statistics around machines which went through inplace upgrades, vs. machines which were on an 'original image' (or bare metal image, or whatever phrase you would like to give that).

With the assistance of --> Gary Blok <-- he suggested using the subkeys in the registry under 'HKLM:\System\Setup', which start with "Source OS ..."  Of course the problem was each and every computer which would go through an upgrade, would have a different key name.  That meant that in order to inventory that information, it would need to be a script.

Sample output; for example...what does it look like to see 'history' of machines which have gone through an upgrade? (and reported back the info from this script + mof edit)

select s1.netbios_name0 as 'ComputerName',
so.CurrentBuild0 as 'CurrentBuild'
,so.EditionID0 as 'EditionID'
,so.InstallDate0 as 'InstallDate'
,so.LatestOS0 as 'LatestOS'
,so.PathName0 as 'PathName'
,so.ReleaseID0 as 'ReleaseID'
,so.UBR0 as 'UBR'
from v_GS_SourceOS0 so
join v_r_system s1 on s1.resourceid=so.resourceid
Where so.resourceid in (
       select so.ResourceID
       from v_GS_SourceOS0 so
       Group by so.resourceid
       HAVING count(so.resourceid) > 1
       )
order by s1.netbios_name0, so.LatestOS0 desc, so.InstallDate0 desc

Sample output; for example...if someone were to ask you... Despite machines going to several upgrades, when was the machine originally imaged with a base image?

select s1.netbios_name0 as 'ComputerName', Min(InstallDate0) as 'Install Date'
from v_GS_SourceOS0 so
join v_r_system s1 on s1.resourceid=so.resourceid
Where s1.netbios_name0 = 'Computer1'
group by s1.netbios_name0


Attached --> Here <-- is a .zip file, containing three things.
- a .cab file if you just want to import the Configuration Item into your SCCM console
- 'SourceOS-IntoWMI.RenametoPS1.txt', the powershell script which is inside that CI.  Sometimes for some unknown reason, people are unable to import a .cab file into their environment.  You could create a new CI in your environment, using that .ps1 information, and the "what means compliant" would simply be existential, that any value is returned at all.
- 'SourceOS.mof' (for inventory import)

If you think this might be interesting to implement in your environment; here's the steps.

1) Either import the .cab file into your Configuration Items in your CM console
2) If importing of the .cab doesn't work, instead create a new Configuration Item, call it whatever you like, and the Setting will be a script type, string.  Paste in the contents of the 'RenametoPS1...' file.  the CI "test for compliance' will be Existential, that any value is returned at all.  
3) Add that CI to a Baseline of your choosing, and deploy the baseline to the machines you want to report on this information.  Perhaps it's only your Windows 10 devices.  I'd suggest having the baseline re-run 'every 7 days'--it really doesn't need to be more frequently, unless you have a lot of people hovering over your shoulder needing this info 'yesterday, and then every day forever'.  Frequency is up to you, but certainly not more frequently than daily.  More frequently than daily for this is overkill.
4) In your Console, Administration, Client Settings, Default Client Settings, right-click properties, Hardware Inventory, import the "SourceOS.mof".  Monitor your server's dataldr.log to confirm all is well.
5)  Wait.  Wait some more.  Wait a bit longer than that, up to a week.  <grin>  what you're waiting for is

a) the clients who got the baseline to run the baseline, and locally populate the completely-custom-wmi class of root\cimv2\cm_SourceOS. 

b) Then you're waiting for machines which have done that, to submit hardware inventory with that new, custom information.  Depending upon your environment, this could be hours... to days/over a week.  It all depends upon your environment, there is no one size fits all answer for how long you need to wait for most targets to report this information. 

c) After you've waited a bit, try out one or both of the sql queries above, to see if you have information.

Notes: in the 'SourceOS.mof'; I only set some of the values to TRUE for reporting.  If you think some of the other values which could be reported would be interesting for you to have, simply enable them in your console, so the clients start reporting those additional values.