A bumpy road for January

Topic

New Reply

PATCH WATCH By Susan Bradley I’m always conservative, but this month you must delay applying updates to avoid side effects. Business patchers — you fa
[See the full post at: A bumpy road for January]

Susan Bradley Patch Lady/Prudent patcher

7 users thanked author for this post.

windbg, lmacri, AlexEiffel, kbecker1213, abbodi86, MHCLV941, Alex5723

Reply | Quote

Replies

Windows 10 Pro 21H2

netsh http show servicestate:

Microsoft Windows [Version 10.0.19044.1466]
(c) Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>netsh http show servicestate

Snapshot of HTTP service state (Server Session View):
—————————————————–

Server session ID: FF00000420000001
Version: 2.0
State: Active
Properties:
Max bandwidth: 4294967295
Timeouts:
Entity body timeout (secs): 120
Drain entity body timeout (secs): 120
Request queue timeout (secs): 120
Idle connection timeout (secs): 120
Header wait timeout (secs): 120
Minimum send rate (bytes/sec): 150
URL groups:
URL group ID: FE00000440000001
State: Active
Request queue name: Request queue is unnamed.
Properties:
Max bandwidth: inherited
Max connections: inherited
Timeouts:
Timeout values inherited
Number of registered URLs: 1
Registered URLs:
http://*:5357/2B36A8B5-8C63-4122-938E-A6BEC4C89335/

Server session ID: FF00000120000001
Version: 2.0
State: Active
Properties:
Max bandwidth: 4294967295
Timeouts:
Entity body timeout (secs): 120
Drain entity body timeout (secs): 120
Request queue timeout (secs): 120
Idle connection timeout (secs): 120
Header wait timeout (secs): 120
Minimum send rate (bytes/sec): 150
URL groups:
URL group ID: FF00000340000003
State: Active
Request queue name: Request queue is unnamed.
Properties:
Max bandwidth: inherited
Max connections: inherited
Edge Traversal Config: Block
Timeouts:
Entity body timeout (secs): 0
Drain entity body timeout (secs): 0
Request queue timeout (secs): 0
Idle connection timeout (secs): 0
Header wait timeout (secs): 0
Minimum send rate (bytes/sec): 4294967295
Number of registered URLs: 1
Registered URLs:
http://+:10243/WMPNSSV4/2392143670/
URL group ID: FE00000340000001
State: Active
Request queue name: Request queue is unnamed.
Properties:
Max bandwidth: inherited
Max connections: inherited
Edge Traversal Config: Allow
Timeouts:
Timeout values inherited
URL group ID: FD00000340000001
State: Active
Request queue name: Request queue is unnamed.
Properties:
Max bandwidth: inherited
Max connections: inherited
Edge Traversal Config: Block
Timeouts:
Timeout values inherited
Authentication Configuration:
Authentication schemes enabled:
NTLM
Negotiate
Authentication settings:
Disable NTLM credential caching

Server session ID: FF00000520000001
Version: 1.0
State: Active
Properties:
Max bandwidth: 4294967295
Timeouts:
Entity body timeout (secs): 120
Drain entity body timeout (secs): 120
Request queue timeout (secs): 120
Idle connection timeout (secs): 120
Header wait timeout (secs): 120
Minimum send rate (bytes/sec): 150
URL groups:
URL group ID: FE00000540000001
State: Active
Request queue name: Request queue is unnamed.
Properties:
Max bandwidth: inherited
Max connections: inherited
Timeouts:
Timeout values inherited
Number of registered URLs: 1
Registered URLs:
http://*:2869/

Request queues:
Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs:
2840

Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Full
Max requests: 1000
Number of active processes attached: 1
Process IDs:
7836

Request queue name: Request queue is unnamed.
Version: 1.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs:
5448

C:\WINDOWS\system32>

Reply | Quote

Yup, if you want to know what application is using that use the task manager to match up those PIDs.

Susan Bradley Patch Lady/Prudent patcher

1 user thanked author for this post.

Alex5723

Reply | Quote

Mine shows the PIDs for two running services:

• FDResPub (i.e. Function Discovery Resource Publication service)
• SSDPSRV (i.e. SSDP Discovery service)

The Function Discovery Resource Publication service:

Publishes this computer and resources attached to this computer so they can be discovered over the network. If this service is stopped, network resources will no longer be published and they will not be discovered by other computers on the network.

The SSDP Discovery service:

Discovers networked devices and services that use the SSDP discovery protocol, such as UPnP devices. Also announces SSDP devices and services running on the local computer. If this service is stopped, SSDP-based devices will not be discovered. If this service is disabled, any services that explicitly depend on it will fail to start.

I’m guessing that both hark back to the days when Windows was able to show a graphical ‘network map’ of available resources and the Homegroup Provider component (now deprecated) was dependent upon FDResPub? As that functionality has now gone, I’m wondering whether this hidden usage of HTTP is still needed.

IMO Windows’ home networking has been in a mess since 1803 with no signs of interest by Microsoft in making it stable, fully-functional and easy-to-use again.

2 users thanked author for this post.

windbg, Alex5723

Reply | Quote

Aside from L2TP, KB5009545 also kills IPSEC VPN connections, including IKEv2.

The Microsoft article you mentioned does provide a workaround of sorts:

Workaround: To mitigate the issue for some VPNs, you can disable Vendor ID within the server-side settings. Note: Not all VPN servers have the option to disable Vendor ID from being used.

Aside from VPN servers that do not allow the Vendor ID to be disabled, this “workaround” won’t work if those who manage the VPN server won’t disable the Vendor ID.

Reply | Quote

I can confirm that KB5009543 on pc’s is creating issues with VPN’s, specifically seeing this with a Cisco Meraki VPN.

Reply | Quote

Rick Corbett wrote:

IMO Windows’ home networking has been in a mess since 1803 with no signs of interest by Microsoft in making it stable, fully-functional and easy-to-use again.

You are so right. I gave up on trying to fix home networking and reverted to use fix IPs to network devices.

1 user thanked author for this post.

windbg

Reply | Quote

kbecker1213 wrote:

I can confirm that KB5009543 on pc’s is creating issues with VPN’s, specifically seeing this with a Cisco Meraki VPN.

What technology does the Cisco Meraki VPN use? SSL? IPSEC?

Reply | Quote

Looks like they may have fixed at least Windows server 2016 Resolved issues in Windows 10, version 1607 and Windows Server 2016 | Microsoft Docs

Reply | Quote

I also see the fix for Server 2012 and 2012 R2

Reply | Quote

Rick Corbett wrote:

IMO Windows’ home networking has been in a mess since 1803 with no signs of interest by Microsoft in making it stable, fully-functional and easy-to-use again.

I’ve not had any problems setting up a home network with Windows 10, but I’ve never done so without a DHCP server somewhere on the network. I do, however, use DHCP reservations or hard address assignments for printers and other non-PC devices.

Reply | Quote

ChrisAVWood wrote:

Looks like they may have fixed at least Windows server 2016 Resolved issues in Windows 10, version 1607 and Windows Server 2016 | Microsoft Docs

I hope that article title is incorrect as I didn’t think Win 10 1607 was still supported.

Reply | Quote

Wow, maybe the ReFS bug is a small detail to many, but not for me. This is the second time Microsoft break ReFS with an update. This is beyond ridiculous. It is supposed to be a resilient file system but since they don’t seem to test it properly relying on Home version users to beta test their software which do not use it and since a few versions of Windows 10 don’t even have directly access to it when buying a new PC because they moved it to the weird Workstation version only, this is what is happening. Such a shame!

 

Reply | Quote

Fixed.

https://www.askwoody.com/2022/various-out-of-band-updates-out-to-fix-january-patch-issues/

1 user thanked author for this post.

AlexEiffel

Reply | Quote

If you use ReFS it’s a big big deal.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

I ran the netsh http show servicestate command on my Dell Inspiron 5584 / Win 10 Pro v21H2 laptop and found two processes using the HTTP Protocol Stack:

• Function Discovery Resource Publication (PID 4540 in the example below – see Rick Corbett’s post # 2418859 about this Windows service)
• Dell SupportAssist (PID 11488 in the example below)

I’d heard about past security vulnerabilities in Dell SupportAssist (powered by PC-Doctor, which is used for diagnostics utilities by several computer manufacturers like Dell, HP, etc.) so I normally have all automated tasks and optimization scans, data telemetry submissions, etc. disabled in my SupportAssist settings as a precaution. However, my SupportAssist service still launches automatically at Windows startup, and after I stopped the SupportAssist service at Start | Windows Administrative Tools | Services the netsh http show servicestate command did not find a PID for SupportAssist. For now I’ve changed the StartupType of the SupportAssist service from “Automatic (Delayed Start)” to “Disabled” while I test for side-effects, but I already know that the “Check for Updates” button on the support page <here> for my Inspiron 5584 won’t run if SupportAssist is uninstalled or the SupportAssist service is disabled.

I applied my January 2022 Tuesday updates and haven’t noticed any issues since KB5009543 was installed (see my post # 2418118), but I’m guessing that many Dell, HP and other users who have diagnostic utilities based on PC-Doctor who still haven’t installed their January 2022 Patch Tuesday updates could still be vulnerable to the wormable remote code execution (RCE) vulnerability CVE-2022-21907 discussed in the HelpNetSecurity article <here>. The only positive news I see here is that Microsoft guide for CVE-2022-21907 reports that this vulnerability has been publicly reported but that an exploit still hasn’t been detected in the wild yet.
_______________________________

A partial extract from my netsh http show servicestate results …

Request queues:
Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs:
4540

Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs:
11488

… and from Task Manager (note that the PID for a process will change after every system restart so you should check Task Manager immediately after running netsh http show servicestate in a command prompt) :

———–
Dell Inspiron 5584 * 64-bit Win 10 Pro v21H2 build 19044.1466 * Firefox v96.0.1 * Microsoft Defender v.4.18.2111.5-1.1.18800.4 * Malwarebytes Premium v4.5.0.152-1.0.1538 * Dell SupportAssist v3.10.4.18

1 user thanked author for this post.

windbg

Reply | Quote

Susan Bradley wrote:

ReFS

I had to look up ReFS and, while anything that fouls up a file system is indeed a big – and very bad – deal, who the heck can actually use ReFS? From what I got from Wikipedia, it looks like Microsoft is abandoning it. If so, this is the second replacement for NFTS that Microsoft has left n the weeds (HPFS was supposed to, well, every bit as wonderful as ReFS).

Reply | Quote

Exchange (mail servers) sometimes use it.  Bottom line it’s like many Microsoft technologies – touted as the next best thing until it’s not the next best thing and then it gets broken during patching.

Susan Bradley Patch Lady/Prudent patcher

3 users thanked author for this post.

wavy, IT Manager Geek, MHCLV941

Reply | Quote

“Bottom line it’s like many Microsoft technologies – touted as the next best thing until it’s not the next best thing and then it gets broken during patching.” a big AMEN, tip of the hat or formal bowing to @Susan Bradley’s statement.

I will add, touted as the next best thing, till Microsoft’s big enterprise customers or enough consumers say it ain’t (or there’s no value to Microsoft any more). 

Take care,

P.S.  Back to the main point, will be looking at the guidance as I prepare for the end of the month applying of updates to my 2016 File – Exchange – DC servers for the last weekend in January and my appreciation in advance.

IT Manager Geek

Reply | Quote

It doesn’t seem to be abandoned. They keep improving it and the new version 3.7 is for Windows 11.

For at home reliable redundancy for data files on mirrored drives, I find it a very good solution. It doesn’t replace backups, but if you are a bit lazy with your backups, it provides an additional layer of security plus it protects you against bit rot (drives getting old and having a bit flipped in some of your files). I use it with people I help to give them a bit more safety for keeping their files in case of a hardware hard disk failure.

In theory, you can move the mirrored drives to a different computer. It doesn’t have the need for a computer with a similar RAID controller since it is software based.

For having mirrored drives, I previously used the Intel Raid controllers, but I had a bunch of computers that after a few years, they got something and the RAID got deleted, the user ending up with two drives with exactly the same content instead of just one logical drive. Annoying at best.

I didn’t experience any issue with ReFS, but the two issues that Microsoft let fall through the cracks over the years of Windows as a service are really bad. It is not normal to fear Microsoft will break all your data after a patch each time you install a patch. Good thing I delay patches a bit and I run the oldest supported Windows version.

1 user thanked author for this post.

Microfix

Reply | Quote