Windows 10 Updates

[ChrisJ]

Hi TC

The short answer is yes you should be able to hide (or gray out) updates unless their prerequisites are in place -- a needed update is installed or a particular file version is already installed. It will likely require a bit of investigation on your part to pick the most reliable details with these large rollups but it should be doable to hide or better gray out an update if it needs last months rollup to be in place first.

BTW, the dates also act to install updates in order if multiple updates can be run one after the other -- the older dates go first so 20170901 goes first, 20170902 next, 20170903 will run last - kinda cool.

TheApGuy will have more specific details I'm sure, I don't know how much of the old functionality has been changed or removed but you can have a look at the old docs here -->> viewtopic.php?f=27&t=1277&start=20#p5539

Hope this helps some.

[The Crow]

Hi,

I'm aware that Autopatcher currently installs in date order, it's down to users visually seeing the unneeded install within the GUI selection, if a user already has a superseded update installed, the previous update would still show as installable within Autopatcher.

But what actually happens in the background is it silently fails (some generic error like this update is not applicable to your system, which a user wouldn't see with the update running through the /quiet switch) to install as there's a newer cumulative version installed, but the user is stuck in a constant loop everytime Autopatcher Is run that it's available for selection to install again

The most reliable data for me would be the minor build version itself as this wouldn't change until a newer update is installed in this case.

I noticed on a forum that the update I'm having issues with isn't compatible with Windows 10 Home, it might be the rare instance that I just need a way for it to show to non home edition users only

Not sure if this can be done with the current version of Autopatcher, by adding in the checks for greater and less builds, same builds or show just to home or pro users would give me more flexibility for these rare occasions

It would be up to TheAPGuy if it's something he can do or consider doing, not sure of Autopatchers capabilities or possible drawbacks

Maybe using something like the greater or less than suggestions to "manage" the Cumulative Update aspect of things, and the other stuff like flash player update is more relaxed like it currently is now

[TheAPGuy]

hmm... it should be simple enough to get it to accept minor build revision numbers. expect it in a few days.

[The Crow]

@TheAPGuy

Just a quick question How are you currently detecting the latest Windows Malicious Software Removal Tool for Windows 8, 8.1 and 10 - September 2017 (KB890830) within Windows 8.1?

I couldn't seem to find a viable option within the CatRoot folder as searching for KB890830 turns up no search results

It's the first time I've added extra updates into the scripts from the Standalone Updates as I'm still fairly new to Autopatcher Script Development

I also searched the registry for KB890830 which also turned up 0 results. The update is definitely installed as I can see it in the Uninstall Updates section within My Computer section

[TheAPGuy]

Any system that has it installed "should" be installed at this location.
C:\Windows\System32\mrt.exe <-- this will get you a file version as well as install date. We don't detect it this way though... we do it with the registry...

[DetectionRegistry]
RegistryPath=HKLM\SOFTWARE\Microsoft\RemovalTools\MRT
KeyName=Version
KeyValue=507CBE5F-7915-416A-9E0E-B18FEA08237D

FE854017-795E-4685-95CE-3CCB1FFD743D <-- is Septembers version ID (at least for my Windows 7 and 10 x64)

Give your apm a different unique name since the current one for this is
UniqueID=KB890830_X64
So call yours "UniqueID=KB890830_X64_winX" or something like that. We don't want them colliding in the update tree generation section.

[TheAPGuy]

<shameful face> I seem to have forgotten about this.

I have just looked around and it "seems" that the only way to check windows 10 minor build is to actually check registry.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR = 0x000006b3 = 1715

see if it works for you.

[The Crow]

The windows 10 updates are virtually finalised apart from this showing issue

It appears Windows 10 Home Build 10240 last supported cumulative update was June / July

Where as the Windows 10 Professional Build 10240 has a higher dated cumulative update

Is there a way I can make certain updates show for home or professional only?

I'm not 100% sure if this can be done solely via registry, or if you can query the wmi for home / professional and add a new switch like BN10240H and BN10240P etc

If we can narrow this down quickly or create a method the scripts should be good to go

Would just require a minor edit of the affected. apm files and a quick test for install and detection on my vmware

If this cannot be achieved, the worst case is I may have to split the modules up and have a home only and professional only selection for users only

So maybe 4 standalone builds 2 x 32bit for home and pro and 2x 64bit for home and pro

Or still contain in a single 32bit and a single 64bit with an additional heading / section within Autopatcher

[TheAPGuy]

Hmm Yes I can do something similar to that... hold on.
edit: hmm found an interesting old way to detect pro/home version. testing
Late edit:
Ok so I got something here for you to try on your different version of windows 10s. It "should" detect the pro or home status via reading OperatingSystemSKU from WMI. Old way is kinda silly so hoping the new way is better.



Read the text file this program generates. You should see PRO or Home or not in the tag line.
Here is mine
TEN|TEN_X64|TEN_SP0|TEN_SP0_X64|TEN_PRO|TEN_PRO_X64|TEN_PRO_SP0|TEN_PRO_SP0_X64|TEN_|TEN__X64|TEN__SP0|TEN__SP0_X64|TEN__PRO|TEN__PRO_X64|TEN__PRO_SP0|TEN__PRO_SP0_X64|TEN_BN14393PRO|TEN_X64_BN14393PRO|TEN_SP0_BN14393PRO

Do NOT build this into your detections yet as this might change yet.

OSFinderWMI.zip

(19.67 KiB) Downloaded 715 times

[The Crow]

I'm only able to test on my laptop at work atm, as I don't have access to my laptop with the VMware installs

Here is a copy of what was found on my works laptop

Calling WMI Service...

WMI Contacted. Reading...
Environment.operatingSystem.OSSKU = 101
Here's what AutoPatcher found:

English (1033) Microsoft Windows 10 Home X64 (10.0.10240)
Architecture: X64
TEN|TEN_X64|TEN_SP0|TEN_SP0_X64|TEN_|TEN__X64|TEN__SP0|TEN__SP0_X64|TEN_|TEN__X64|TEN__SP0|TEN__SP0_X64|TEN__|TEN___X64|TEN___SP0|TEN___SP0_X64|TEN_BN10240|TEN_X64_BN10240|TEN_SP0_BN10240

It seems to be detecting things fine in regards to (English (1033) Microsoft Windows 10 Home X64 (10.0.10240)
Architecture: X64), although I have noticed in the tags (|TEN_SP0_BN10240 etc) that it's missing the home or pro status

Not sure if this is a bug specific only to build 10240 version 1511 or everything in general until I can get on my laptop at home and test further

It maybe the way you have programmed it, so you use the normal BN10240 for a home install and BN14393PRO for pro

Just quoting what I see as I'm not sure if there should be 3 instances, a normal to accept updates for both, then 2 singles for each type home or pro

If it should be 3 separate types, in my instance it's not flagging up I have home installed on this current laptop

[TheAPGuy]

OS SKU 101 hmm... that is... not listed in my reference chart. Ohh I see. The chart has not been updated in a good while so... ya. There are even higher numbers then 71 now. Time to add a few new definitions to the chart.

edit:
hmm... you have the professional student version, correct?