Fix for the Windows 7 SMB network bug caused by Update KB4480970/KB4480960

win7[German]On January 12, 2019, Microsoft released a fix for affected Windows 7 systems to fix the issue caused by the January 2019 update when accessing network shares. 


What's the problem?

Microsoft released security updates KB4480970 (Monthly Rollup) and KB4480960 (Security only) on January 8, 2018 for Windows 7 SP1 and Windows Server 2008 R2 SP1, that ends with some collateral damage.

  • Many users were unable to access network shares after the update was installed. 
  • The network issue also affects SMBv1 shares used by scanners or fax machines.
  • Also users of client server software (like German DATEV customers) suffered from network errors accessing shares. 

I've addressed the topic within my blog post Network issues with updates KB4480970 and KB4480960. In this context, the article also includes a workaround (other than Uninstall Update) to allow access by changing the LocalAccountTokenFilterPolicy in the registry. 

The network issue occurred with users who belong to the group of administrators on the machine providing the network sharing. A configuration, you should avoid – but on most Windows computers people work with administrator accounts (default after installing Windows).

That would also be the reason why I wouldn't have noticed the bug if I had installed the patch. Since Windows Vista I work with standard accounts. Only the use of the Media Creation Tool requires the login to the administrator account (Run as administrator is not enough). Under Windows 10 this method of working with standard accounts becomes more critical for admins. The reason: In the settings page administrative options are only visible if the user belongs to the group of administrators. A User Account Control to enable administrator features for standard users, like offered within the Control Panel, is not provided in the Settings app. 

Microsoft has confirmed the issue within the KB article and proposes to remove the user from the group of administrators as a workaround. Not a bad solution – but not everyone will be able or willing to follow this suggestion.

Microsoft provides a fix

German blog reader riedenthied pointed within this comment to Microsoft's fix. Also some Readers commented here and here within my English blog, pointing to the fix (thanks for that). Within kb article 4487345 (Description of the update for Windows 7 SP1 and Windows Server 2008 R2: January 11, 2019) Microsoft released a fix for this issue.


This update resolves the issue where local users who are part of the local "Administrators" group may not be able to remotely access shares on Windows 7 SP1 and Windows Server 2008 R2 machines after installing the January 8th, 2019 security updates. This does not affect domain accounts in the local "Administrators" group.

The fix can be downloaded as a standalone update from Microsoft Update Catalog and must be installed manually.

Important: Undo your registry fix!

Within my blog post Network issues with updates KB4480970 and KB4480960 I had described a workaround that manipulates the LocalAccountTokenFilterPolicy in the registry so that access to network shares is also allowed for users of the Administrators group.

A short-term workaround, but with the disadvantage that the access to the network shares get an administrative token. This is clumsy from a security point of view (keyword: Ransomware accesses to shares). Whoever installs the above fix or removes the users from the administrator group should therefore undo a change made in LocalAccountTokenFilterPolicy.

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 0 /f

To do this, execute the above command in an administrative prompt. This command deactivates the policy again.

BTW: See also Susan Bradley`s article Patch Lady – That SMB issue isn't SMB at

Similar articles:
Patchday: Updates for Windows 7/8.1/Server Jan. 8, 2019
Patchday Windows 10-Updates (January 8, 2019)
Update KB971033/KB4480960/KB4480970 bricks Windows 7 Genuine (0xc004f200)Microsoft explains the Windows 7 KMS activation issue
Network issues with updates KB4480970 and KB4480960
Windows January 2019 Updates breaks access to Access DBs

Cookies helps to fund this blog: Cookie settings

This entry was posted in issue, Update, Windows and tagged , , , . Bookmark the permalink.

7 Responses to Fix for the Windows 7 SMB network bug caused by Update KB4480970/KB4480960

  1. Pingback: 修正 Windows 7 系列系統安裝2019 一月份安全性更新後的網芳問題 – Heresy's Space

  2. Lanshark says:

    On January 30th 2019 I installed MS updates including KB4480970 on my home server Windows 7, and to my dismay after it was rebooted my remote desktop no longer worked and my shared files were no longer accessible.
    After trying all kinds of settings changes I resorted to running system restore to before the updates and now my PC is back to running normal.
    Scouring the internet for clues I came across your blog that confirmed my suspicions it was the MS updates that caused my issues so now I'm torn between reinstalling the update and trying the patch/fix or just skipping this update all together.

  3. Dan says:

    Thank you for the info worked perfect.

  4. Advertising

  5. A. Long says:

    In my case, neither internet nor local network, including the router page were available. Uninstalling the MicroCrash update, kb4480970, reinstalled access to the normal world. I can only find reference to network shares, so I was a bit surprised.

    Like Apple with it's pitched battle with the people who want access to the machines they purchased (leased?) Microcrash seems more absorbed with telemetry, spying and sales than with cybersecurity.

    Is it possible that Microcrash has outlived it's usefulness but just hasn't stopped thrashing? What happens if we remove the feet prior to the head, I wonder?

  6. Jeff Rivett says:

    Installing the KB4487345 patch fixed the problem on two Windows 7 computers I manage. Thanks!

    Sadly, on one of these computers, Microsoft's February updates (automatically installed on February 12) seem to have caused the problem to return. Has anyone else noticed this?

  7. kore02 says:

    thank you
    worked instantly

Leave a Reply

Your email address will not be published. Required fields are marked *