Patch Lady – KB4088875 more questions

[Susan Bradley]

The following update has been updated KB4088875  but in doing so I’m scratching my head a bit more. Remember our original side effects relate to netwo
[See the full post at: Patch Lady – KB4088875 more questions]

Susan Bradley Patch Lady

4 users thanked author for this post.

JDeC, MrBrian, Elly, woody

Reply | Quote

[alpha128]

The March 13, 2018—KB4088875 (Monthly Rollup) was pulled from Windows Update on my system several days ago. As of today it has yet to reappear.

I will be very interested in reading the answers to your four questions once they are known.

Reply | Quote

[Susan Bradley]

It’s still on WSUS and the catalog so it’s not 100% pulled.  https://www.catalog.update.microsoft.com/Search.aspx?q=4088875  Last I checked on 7 it was “unchecked”, let me see if it’s still that way.

Susan Bradley Patch Lady

1 user thanked author for this post.

alpha128

Reply | Quote

[anonymous]

The timestamp on the update in the catalogue (https://www.catalog.update.microsoft.com/Search.aspx?q=4088875) is still March 14th. So not much updating there …

Reply | Quote

[PKCano]

Running scripts and geeky bail-outs are not for the average Joe User who probably has WU on Automatic.. I hope they don’t put this back on WU until they get the bugs ironed out.

It has disappeared completely from WU on all of my VMs as well as four hardware installs. It doesn’t show up at all.

2 users thanked author for this post.

JDeC, Elly

Reply | Quote

[SkipH]

@PatchLady:

It also appears that the issues you mention in this thread might also apply to KB4088878 (2018-03 Security-only update), used by members of Woody’s “Group B update” process.

I have checked the MS web page for KB7088878, and it has the same prerequisites and VB script as KB4088875.

Information on KB7088878 does not list the problem with IE 11, as that sub-patch is not included in KB7088878.

Since there are still a number of us patching ‘hold-outs’ that are in the B-Group, I think that KB7088878 needs to be mentioned in this thread, as it appears to be subject to the same problems as KB4088875.

4 users thanked author for this post.

pmacS33, JDeC, MrBrian, Elly

Reply | Quote

[Elly]

It showed up initially, and I hid it. There were some reports that it was not being seen, or that the check mark had disappeared. Think that was on the 15th. I unhid it, and it disappeared. It hasn’t shown up in my Windows Update since… not unchecked… not at all.

Non-techy Win 10 Pro and Linux Mint experimenter

Reply | Quote

[Susan Bradley]

It’s still out on Microsoft update, it is unchecked however and thus not being pushed out, but it’s not been “pulled”.  When it’s pulled it then is removed from WSUS and the catalog.  When you hide it unless there is a detection change pushed by Microsoft it will stay hidden.

Susan Bradley Patch Lady

Reply | Quote

[Bill C.]

I am on WIn7-64_SP1, with WU set to Do not check. I initiate all checks manually and follow Woody’s Group B patching for the Monthly Security Only and the IE Rollup.

I originally had the March 2018 Security and Quality Rollup KB4088875 in my Windows Update as checked. I did not install it, nor did I hide it. I just closed WU to wait for the Defcon change.

SInce that intial view however, it has never appeared again. All I see is last months February 2018 Security and Quality Rollup KB4074598 as Important and checked. In February I did install the February Security Only KB4074587 from the catalog.

To further complicate th issue, my Intel-brand motherboard has both the Intel® 82567L and Intel® 82574L Gigabit Ethernet Controllers onboard. These both are listed as apparently being vulnerable to having their NIC settings wiped by the March Rollup AND the Security Only patches. Coincidently, Intel has just released (2/22/2018) new drivers for these controllers, but the controllers are listed as Legacy status, and there is no mention about them fixing the March Rollup issues. From experience, I do not usually mess with working network drivers unless it is a security issue or I am having a problem.

My main question is if the March KBs are not even showing on the WU on my machine now, either checked or unchecked, will they ever be, or would a fix come next month. However with a Security Only, NOT being a rollup, what is the implications for a Group B to miss a problematic month.

Reply | Quote

[Seff]

It remains unchecked on my two home machines, and therefore will not be installed until it becomes checked and there is a recommendation here to accept it. There is no question at that time of my fiddling with the registry or VBScript (whatever that is), either it’s ready to be installed through WU or it doesn’t get installed.

1 user thanked author for this post.

Cascadian

Reply | Quote

[pmcjr6142]

Susan, someone wrote this comment…”It remains unchecked on my two home machines, and therefore will not be installed until it becomes checked and there is a recommendation here to accept it. There is no question at that time of my fiddling with the registry or VBScript (whatever that is), either it’s ready to be installed through WU or it doesn’t get installed.”

These are my sentiments exactly.  There is no way I want to even try the work around you mention, ie, registry and/or VBS script.  I’m just a moderately computer literate senior who follows Ask Woody and not you.  It has been unchecked on my Win 7 machine for several days.  Do you recommend we just hide it and wait for something to replace it next month?  With the problems that accompany KB4088875, I can’t see you or Woody coming to a different conclusion and say go ahead and install it.

Thank you.

Edit to remove HTML. Please use the “text” tab in the entry box when you copy/paste.

3 users thanked author for this post.

Pepsiboy, woody, Elly

Reply | Quote

[MrBrian]

This script was altered by Microsoft on March 27.

2 users thanked author for this post.

walker, woody

Reply | Quote

[MrBrian]

Here is the older script, in case anybody wants to compare:

Option Explicit
Const HKEY_LOCAL_MACHINE = &H80000002
Dim oReg : Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
Dim oShell : Set oShell = CreateObject("WScript.Shell")
Dim sPath, aSub, sKey, aSubToo, sKeyToo, dwValue, Result, SaveResult
Dim NotDeleted
 
NotDeleted = 0
 
' Get all keys within sPath
sPath = "SYSTEM\CurrentControlSet\Enum\PCI"
oReg.EnumKey HKEY_LOCAL_MACHINE, sPath, aSub
 
' Loop through each key
For Each sKey In aSub
	' Get all subkeys within the key 'sKey'
	oReg.EnumKey HKEY_LOCAL_MACHINE, sPath & "\" & sKey, aSubToo
	For Each sKeyToo In aSubToo
	  Result = oReg.DeleteKey(HKEY_LOCAL_MACHINE, sPath & "\" & sKey & "\" & sKeyToo & "\" & "\Device Parameters" & "\SlotPersistentInfo")
	  ' Allow failure only if key never existed
	  If (Result = 1) Or (Result > 2) Then
		NotDeleted = 1
		SaveResult = Result
	  End If
	Next
Next
 
If (NotDeleted > 0) Then 
  Wscript.Echo "One or more SlotPersistentInfo keys still exist under HKLM\System\CurrentControlSet\Enum\PCI\<deviceid>\<subdeviceid>\Device Parameters.  Please delete manually. Result = " & Result
End If

Here is the current script (in case it changes again in the future):

Dim strPciFileVersion
Dim WindirFilePath
set WshShell = WScript.CreateObject("WScript.Shell")
WindirFilePath = WshShell.ExpandEnvironmentStrings("%WinDir%")
   
Dim fs
Set fs = CreateObject("Scripting.FileSystemObject")
   
strPciFileVersion = fs.getfileversion(WindirFilePath & "\\system32\\drivers\\pci.sys")
Dim strAryFileVersion1
strAryFileVersion1 = Split(strPciFileVersion, ".")
If (strAryFileVersion1(0) = 6 And strAryFileVersion1(1) = 1 And strAryFileVersion1(2) = 7601) Then
                If (strAryFileVersion1(3) < 17630 Or (strAryFileVersion1(3) > 20000 And strAryFileVersion1(3) < 21744)) Then
                               
                                Const HKEY_LOCAL_MACHINE = &H80000002
                                Dim oReg : Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
                                Dim oShell : Set oShell = CreateObject("WScript.Shell")
                                Dim sPath, aSub, sKey, aSubToo, sKeyToo, dwValue, Result, SaveResult
                                Dim NotDeleted
                               
                                NotDeleted = 0
                               
                                ' Get all keys within sPath
                                sPath = "SYSTEM\CurrentControlSet\Enum\PCI"
                                oReg.EnumKey HKEY_LOCAL_MACHINE, sPath, aSub
                               
                                ' Loop through each key
                                For Each sKey In aSub
                                                ' Get all subkeys within the key 'sKey'
                                                oReg.EnumKey HKEY_LOCAL_MACHINE, sPath & "\" & sKey, aSubToo
                                                For Each sKeyToo In aSubToo
                                                  Result = oReg.DeleteKey(HKEY_LOCAL_MACHINE, sPath & "\" & sKey & "\" & sKeyToo & "\" & "\Device Parameters" & "\SlotPersistentInfo")
                                                  ' Allow failure only if key never existed
                                                  If (Result = 1) Or (Result > 2) Then
                                                                NotDeleted = 1
                                                                SaveResult = Result
                                                  End If
                                                Next
                                Next
                               
                                If (NotDeleted > 0) Then
                                  Wscript.Echo "SlotPersistentInfo keys still exist under HKLM\System\CurrentControlSet\Enum\PCI\<deviceid>\<subdeviceid>\Device Parameters.  Please delete all manually and then install the updates. Result = " & Result
                                End If
                Else
                                WScript.Echo "Your system is ready to install the updates"
                End If     
Else
                                WScript.Echo "Your system is ready to install the updates"
End If

1 user thanked author for this post.

abbodi86

Reply | Quote

[MrBrian]

The difference between the old and new script is that the new script checks that the version of pci.sys is correct before proceeding with possible registry changes, and also adds a few informational messages.

Reply | Quote

[abbodi86]

Here is a slightly enhanced version of the newly modified script
https://pastebin.com/HKwLHBJc

it checks for and request Admin elevation, and display result as message box, so it can be ran by double-click

1 user thanked author for this post.

MrBrian

Reply | Quote

[anonymous]

Ah, so that was what was modified! I reread the page several times and did not find any changes in the normal text. Did not check the script, though.

Reply | Quote

[MrBrian]

I did some sleuthing on my Windows 7 x64 virtual machine, which is not offered KB4088875 in Windows Update. (I have the QualityCompat registry setting set.) I turned on verbose Windows Update logging by using the program at How to Enable Microsoft Installer logging and Verbose logging to gather additional troubleshooting Information; this program sets different verbose settings than those documented at How to read the Windowsupdate.log file. Then I ran Windows Update on the virtual machine.

I then searched log file \windows\Windowsupdate.log for 4088875 and also 26896846-497d-4755-893a-6870f72ddcf4 (its Update ID for Windows 7 x64, which can be found by looking in the Catalog). Three interesting things that I found in Windowsupdate.log related to this update:

1) ‘Final detection state for update 26323815 (updateId = {26896846-497D-4755-893A-6870F72DDCF4}.200) is “Installable”‘. This I what I expected to see for this update. This means that KB4088875 isn’t installed on the computer, and that it’s applicable to be installed on the computer.

2) ‘update {26896846-497D-4755-893A-6870F72DDCF4}.200 marked for pruning because of its deployment attribute supersedenceBehavior=1’. The phrase ‘marked for pruning because of its deployment attribute supersedenceBehavior=1’ appears only one other time in Windowsupdate.log, for update 3B785578-FF3C-4C49-BB6D-D6F9D2688503, which is KB4091290; I mentioned in another topic that KB4091290 has supersedence behavior that surprised me. I searched the web for documentation about supersedenceBehavior, but found nothing useful. It’s far more common to see ‘marked for pruning because it is potentially superseded’ in Windowsupdate.log (found 1201 times).

3) ‘Update {26896846-497D-4755-893A-6870F72DDCF4}.200 is pruned out due to potential supersedence’. But why, given that the Catalog notes that there are no updates currently metadata-superseding KB4088875? I hypothesize that this is related to the unusual supersedenceBehavior setting for KB4088875 noted in the last paragraph.

3 users thanked author for this post.

abbodi86, woody, Elly

Reply | Quote

[MrBrian]

The unusual supersedence behavior for KB4091290 was noted here.

Reply | Quote

[MrBrian]

I am curious if those who have KB4088875 listed in Windows Update see ‘update {26896846-497D-4755-893A-6870F72DDCF4}.200 marked for pruning because of its deployment attribute supersedenceBehavior=1’ (without the quotes) in their verbose-enabled Windowsupdate.log.

No longer curious! 😀

1 user thanked author for this post.

Elly

Reply | Quote

[MrBrian]

Related: “I had a “Eureka!” moment a few hours ago that ties together various seemingly unrelated aspects, and testing has confirmed it!”

Reply | Quote

[MrBrian]

“2. Can an admin run this script before the install of the update?  (based on admins testing this it appears the answer is yes)
3. In a consumer setting, where we only go to Windows update, do we need this? (I don’t think so but it would be nice to know for sure)”

The KB article states (my bolding):

“Prerequisites

Follow these steps before you apply this update to a physical computer or a virtual machine:”

My answer for both point number 2 and 3 is yes, and furthermore running the script beforehand is seemingly mandatory for all users who intend to install KB4088875 or KB4088878.

Reply | Quote

[geekdom]

How likely is it that Microsoft will include the script in the final release update?

On Hiatus {with backup and coffee}
offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender TRV=1909 WuMgr
offline▸ Win10Pro 20H2.19042.685 x86 Atom N270 RAM2GB HDD WindowsDefender WuMgr GuineaPigVariant
online▸ Win10Pro 20H2.19042.804 x64 i5-9400 RAM16GB HDD Firefox86.0 WindowsDefender TRV=20H2 WuMgr

Reply | Quote

[MrBrian]

Hopefully Microsoft will release a future update in which this script is not needed at all.

2 users thanked author for this post.

woody, geekdom

Reply | Quote

[MrBrian]

Report from a reddit user: From https://www.reddit.com/r/sysadmin/comments/84n3cy/microsoft_released_a_script_to_preventrepair/dvrcrf8/:

“It may do only that after the fact, but if you apply it before patching then it does prevent the issue with the NIC reverting to prior settings (be they DHCP or static) from happening in the first place. I’ve verified this on a test machine by taking a snapshot of it and then applying this month’s patches both with and without running the script first (reverting to the pre update snapshot in between).”

Reply | Quote

[MrBrian]

If the info on reddit is accurate, then I infer that:

1. If you didn’t run the script before installing the update, and you have NIC (Network Interface Card) problems afterwards, then you need to run the older script afterwards, and then manually fix whatever undesirably changed in the affected NIC settings.

2. If you run the script before installing the update, you will not have any NIC problems after installing the update.

Reply | Quote

[MrBrian]

A different interpretation is:

1. It’s ok to run the script (but may need the older version of the script) after the update is installed, but you need to reboot after running the script.

1 user thanked author for this post.

abbodi86

Reply | Quote

[MrBrian]

Tip: Since the script’s fixes (if needed) delete items from a part of the registry that usually needs admin privileges for such actions, you probably need to run the script with admin privileges. If you run the script without admin privileges, it should not be able to apply the fixes, but it should at least report if fixes are needed or not. In other words, running the script without admin privileges should give useful info but without successfully applying any needed fixes.

Reply | Quote

[MrBrian]

If I’m correct that the script needs admin privileges, you can do so by following method 1 at http://sigkillit.com/2013/01/26/running-vbscripts-with-uac-elevation/.

1 user thanked author for this post.

woody

Reply | Quote

[MrBrian]

I have confirmed in a test that admin privileges are needed to fix the issue if it’s present. If you don’t run the script with admin privileges, and you have the NIC issue, you should get a message similar to “SlotPersistentInfo keys still exist […]”.

1 user thanked author for this post.

Elly

Reply | Quote

[MrBrian]

For those that already installed the update without running the script beforehand, there are steps to fix the NIC issue at RUSH POST: Microsoft Convenience Update, KB4088875 and KB4088878 vNIC Incompatibilities:

“ACTION: If you have been impacted, please note that the following manual fixes have been known to resolve the issue (after the fact):

• Note the name of the new network adapter
• Open “Device Manager” -> “Show Hidden Devices” and delete ALL hidden/phantom network adapters from the list (be sure to NOT delete the drivers)
• Edit the properties of the new NIC and add the applicable IP address configuration. No reboot is required.”

Reply | Quote

[MrBrian]

The newer script appears to have a few bugs that can result in the script giving no information messages instead of the intended message “Your system is ready to install the updates”. However, I believe that the script likely correctly always reports that there are unfixed NIC issues if that’s indeed the case.

Thanks to the user who informed me about this via private message.

Reply | Quote

[MrBrian]

The older script has the same issue also.

Reply | Quote

[abbodi86]

I have been using the Convenience Rollup KB3125574 since the beginning (which supposedly have the same NIC issue), but i never had the issue

Reply | Quote

[Susan Bradley]

I’ve installed it (and uninstalled it to check to see if it was still unchecked) and have had no issues.  I’m wondering if there is something else like Broadcom code triggering this?

Susan Bradley Patch Lady

Reply | Quote

[ch100]

This looks very much like when installing virtualisation tools which create a new emulated or paravirtual NIC. VMware handles this better, but it is very visible with Citrix XenServer.
I think (without experiencing the issue directly, but based on description only) that it can be resolved by enabling View Hidden Devices in Device Manager and delete/uninstall the phantom devices. I can elaborate on this, but this is not something for the most common askwoody.com reader and certainly DHCP configuration makes this transition more graceful for the end-user.
However, there is no excuse for an update to cause this behaviour, unless maybe in the case of Microsoft’s own (Hyper-V) Virtual Machines.
This is certainly not something that an end-user should have to resolve, but if the same end-user uses virtual machines, then it is a different story.

EDIT: Windows 7 and 2008 R2 should be discontinued by now and everyone using them should plan and move away as fast as possible. It is obvious that there is not much effort from Microsoft in supporting them and those who insist on staying on those OSes do so on their own risk and headaches. There is no optimal option, either installing poor updates or not installing any updates at all.

2 users thanked author for this post.

abbodi86, MrBrian

Reply | Quote

[MrBrian]

Technical details: Deploying Windows 2008 R2 and Windows 7 templates with vmxnet3 renames the NIC as #2 (1020078).

1 user thanked author for this post.

ch100

Reply | Quote

[ch100]

From the VMware KB article:
Windows 2008 R2 and Windows 7 track PCI devices by which slot the device is connected to. Moving a PCI network interface between slots will allocate a new set of settings for the NIC as it is considered a new device.

This virtual slot concept in vSphere creates a lot of issues with PXE boot, common with virtual desktop solutions, when the slot changes. The NIC is simply not recognised anymore and as consequence the boot is not happening generating a BSOD.

1 user thanked author for this post.

MrBrian

Reply | Quote

[Mr. Natural]

4088875 dated March 13 is still showing in my wsus system but I declined that update as soon as I heard what it was doing to vmware systems. It remains declined for now.

Red Ruffnsore

Reply | Quote

[DennyC]

I initially allowed KB4088875 to install on my two older Win 7 Pro SP1 machines and right away noticed slow boot times…like it was taking twice to three times as long to boot.  I uninstalled the update and things are back to normal.  So I’m in a holding pattern at the moment.  Windows Update shows KB4088875 as available, but unchecked.  Note:  my normal boot time is around 45 seconds to a minute.

1 user thanked author for this post.

MrBrian

Reply | Quote

[anonymous]

Just to confirm – in our environment, we are applying the patch via Ivanti Patch for Windows Servers, and then running the old script via the patching system – this works perfectly and prevents the NIC from vanishing at reboot.

Reply | Quote

[MrBrian]

I have concerns that due to the new script’s pci.sys version checking, those who have already installed the Windows 7 March 2018 updates cannot successfully use the new script if you’ve already rebooted. The Windows 7 March 2018 updates install version 6.1.7601.24056 of pci.sys. Here is the version check in the new script:

If (strAryFileVersion1(0) = 6 And strAryFileVersion1(1) = 1 And strAryFileVersion1(2) = 7601) Then
If (strAryFileVersion1(3) < 17630 Or (strAryFileVersion1(3) > 20000 And strAryFileVersion1(3) < 21744)) Then

It appears that those with version 6.1.7601.24056 of pci.sys will not pass the second if statement, and thus the fixing code will not execute.

The old script, which doesn’t contain the pci.sys version check, is at https://www.askwoody.com/forums/topic/kb4088875-more-questions/#post-178558.

Reply | Quote

[MrBrian]

The phrasing of the NIC issue has changed in two of the three Windows 7 March 2018 updates:

Old: “A new Ethernet virtual Network Interface Card (vNIC) that has default settings may replace the previously existing vNIC, causing network issues after you apply this update. Any custom settings on the previous vNIC persist in the registry but are unused.”

New: “After you apply this update, a new Ethernet Network Interface Card (NIC) that has default settings may replace the previous NIC and cause network issues. Any custom settings on the previous NIC persist in the registry but aren’t used.”

Microsoft is thus acknowledging that the NIC issue also can involve non-virtual NICs.

Reply | Quote

[MrBrian]

“Microsoft has released update KB4099950” (“Network Interface Card settings can be replaced, or static IP address settings can be lost”)

1 user thanked author for this post.

abbodi86

Reply | Quote

[anonymous]

Hi, I tested KB4099950 on several servers that don´t have the march patches yet.
on all of them the SlotPersistentInfo Reg keys where still in place after the KB was installed.

I tried to install March patches after that and the nic info got lost.

Do anybody have an idea why the KB is not working for me?

If I manual run the .vbs with pci.sys version checking the keys get deleted and the March patches get installed without problems.

1 user thanked author for this post.

MrBrian

Reply | Quote

[Author]

Posts