Mapped network printers unavailable due to SMB1 being obsolete


As we all might be familiar with, printers are one of those little peculiar matters within IT. Implementing these in an IT-environment is self-explanatory oftentimes, but when they do not cooperate the issue itself can stem from one single obscure root cause, if not a string of these having to be checked upon.

Recently, I encountered a particular printer issue which I found interesting enough to share. The root cause here, in summary, was due to the network protocol SMB1 (Server Message Block) being obsolete in recent Windows releases.


The printer issue in question was reported to occur on three clients specifically within an On-premise Domain. The environment contains almost 100 clients, all domain-joined and running Windows 10 as the OS with the same onboarding configuration and Group Policy Objects applied. One of these GPO’s fetch the shared network printers deployed via Print Management on a separate application server running Windows Server 2008 R2 as the OS.


As for how the issue acted, I instantly noticed that each network printer being mapped via the responsible GPO were grayed out in the Devices and Printers settings within Control Panel on the affected clients.

Due to this, I initially suspected an ordinary type of connection issue to the application server managing all of these network printers. I dismissed this rather prompt however, since I was able to ping this specific server from the affected clients.

With this information at hand, I eventually filtered out that the issue stemmed from not being able to access the shared resources on the application server whatsoever. However, I needed a more distinct error message about the issue, and fortunately enough I came across one by attempting to access the server’s resources via run.exe

To give some insight regarding this error message, Microsoft have previously come forward within security update MS16-114 that the network protocol SMB1 entails a security vulnerability in which could allow execution of harmful code by a skillful attacker. Since the update, it has been determined that the vulnerability is unique within the protocol itself, whereby any software update will not be able to patch this. To further mark this case, Microsoft even pursued to have SMB1 disabled as default starting from Windows release version 1709 and later according to the link mentioned in the error message.


With above background in mind, I obviously did not want to activate the SMB1 protocol for the sole reason of solving a printer issue specific to three clients. I instead looked out for solving the issue both centrally and permanently, and that was simply to activate the subsequent network protocol, SMB2, on the application server in order to disable SMB1 for good.

As there are two variants of the SMB protocol, Client and Server, I firstly activated SMB2 using below commands for each variant respectively within PowerShell.

After rebooting the server, I proceeded to disable SMB1 entirely using similiar commands.

After yet another required reboot, I wanted to confirm that the server was indeed running the SMB2 protocol solely by using the following commands. See image for reference.

With these commands being carried out, I hastily moved on to the three affected clients. After performing a reboot on these as well, the mapped network printers were not greyed out anymore, meaning that the reported printing issue was resolved.

If you have any questions or opinions on this subject, feel free to email me at


Disclaimer: All information on this blog is offered "as is" with no warranty. It is strongly recommended that you verify all information and validate all scripts in isolated test environments before using them in production environments.