Ahead of Patch Tuesday, a cautionary tale

Microsoft has officially deemed Windows 10 version 2004 as “ready for business,” but I’d argue it still needs a bit more help to be fully ready for consumers. With this month’s Patch Tuesday upon us, here’s an example of what I mean. It involves mysterious NAS issues, some sleuthing, and a workaround — all of which show how troublesome updates can be sometimes.

This case involves one AskWoody subscriber who told me recently that each time he upgraded to Windows 10 2004 the installation would break his computer. Like any good geek who refuses to let technology get the best of me, I emailed him back and asked for more information about what was getting broken when he upgraded. Turns out, he would lose access to mapped drives on his NAS (network attached storage) devices. Though he tried to remap the drives, they would fail, forcing him to roll back to  Windows 10 1909 — where everything would work.

Short term, this was an excellent workaround. Long term, however, this will only work until May with Windows 10 Home and Professional edition. That’s when support for security updates for 1909 end. (Enterprise and Education versions get an additional year of support after that.) Clearly, we had to come up with a solution soon.

The NAS units affected were a LinkStation and a TerraStation from Buffalo Tech. The minute he mentioned Buffalo Tech, I knew the root problem:  SMB v1.

SMB, or Server Message Block, is the basic file-sharing technology that’s been used for years. It’s the glue, both in Windows networks as well as Linux-based devices, that allows you to share and save files. But it’s also subject to attacks and so Microsoft has been making a concerted effort to remove SMBv1 as a native technology. Its weaknesses have been exploited by attackers for years, and as Ed Bott pointed out more than four years ago, the world has largely moved on to SMBv2 and SMBv3. Even so, some NAS users still rely on that platform.

In fact, if you install Windows 10 1709 or later in a clean install, SMBv1 is not enabled at all. If you have upgraded from older versions of Windows 7 or 10, SMBv1 will be enabled — but if it’s not used in 15 days, the system automatically turns it off. If you reenable it again, it will come back and should remain working. So, I first suggested that Michael reenable SMBv1 to reestablish connectivity to the devices.

The first roadblock we hit: SMBv1 has to be installed on Windows 10. And to do so you, need to enable a group policy that allows “optional component installation and component repair” so it can reach out to Windows update for the download. To set this, we had to follow guidance to enable the repair source.

In the local group policy editor, click on Computer Configuration, then Administrative Templates, then System, and double-click the “Specify settings for optional component installation and component repair.” The user chose to have the installation bits downloaded from Windows update.

After adjusting those settings, he tried again. Three shares came back this time after the 2004 insall. But two shares on an older device did not; they were still blocked.

I reviewed other ideas regarding cached credentials, stopped services, and I reviewed log files. Then I found an excellent Youtube video that gave us the solution: Launching the interface to the Buffalo device, he enabled SMBv2 on the NAS unit. This resolved the mapping issue. The step-by-step instructions are available here.

For those that have similar consumer NAS units, you need to determine whether they can support newer technologies. If they don’t support anything above SMBv1, you need to seriously consider whether it’s wise to continue using that device.

Though Microsoft says 2004 is “ready for business” it’s still treating it as the red-headed stepchild of the patching process. Microsoft normally releases optional preview updates that include bug fixes, but not security updates, to allow enterprises to test these updates before they are rolled into the normal security updates released on Patch Tuesday (which is this week). Normally, these optional releases come out on what is called the C or D week (third or fourth week) of the month. 2004 and 20H2, which share the same code, received optional preview updates in the form of KB4598291 and KB4598299. But some users installed KB4598299 and found it caused crashes in Visual Studio when docking windows or splitting them via the mouse. And the .NET preview for 1909, KB4598301, released on Jan. 26, is also is a trigger for this issue.

Given that these are preview updates and don’t include new security updates, it’s okay to uninstall them. In fact, Microsoft has already identified a workaround:

Edit %InstallRoot%Common7IDEdevenv.exe.config and %LocalAppData%MicrosoftVisualStudio16.0_xxxdevenv.exe.config and append the following text to the  element’s value attribute:

;Switch.System.Windows.Interop.MouseInput.OptOutOfMoveToChromedWindowFix=true;Switch.System.Windows.Interop.MouseInput.DoNotOptOutOfMoveToChromedWindowFix=true  

After restarting Visual Studio, you should be able to drag your Visual Studio windows around without crashing.

I generally do not recommend installing preview updates. Normally, these preview patches are not installed on Windows 10 computers patched by Microsoft update; they are only set to be “offered” up to your machine. This month the preview updates appear to have been pushed down to 2004 and 20H2 machines, kicking off a reboot. Interestingly, it appears that if you defer feature updates or use the targetreleaseversion setting, the preview updates won’t be offered. (This appears to be an undocumented side effect of the deferral process.)

Remember this is the time of the month you need to ensure you’ve got a good backup and set pause settings for your computer. Only if you want to test updates on systems should you install updates this week. I’ll circle back next week to recap any early issues we see in the released updates for February. You can join us on Askwoody.com as we watch and wait for issues.

Stay tuned.