Posted in : Microsoft, Windows Server By Hanessa Milaszewski Translate with Google ⟶

5 years ago

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.

Enable SMB v2 Client
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb20 start= auto
Enable SMB v2 Server
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB2 -Type DWORD -Value 1 –Force

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

Disable SMB v1 Client
sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled
Disable SMB v1 Server
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 0 –Force

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.

Detect SMB v2 Client status
sc.exe qc lanmanworkstation
Detect SMB v2 Server status
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | ForEach-Object {Get-ItemProperty $_.pspath}

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

Tags : Microsoft, PowerShell, Printing, Security, SMB1, SMB2, Windows 10, Windows Server, Windows Server 2008 R2

Personlig rådgivning

Vi erbjuder personlig rådgivning med författaren för 1400 SEK per timme. Anmäl ditt intresse i här så återkommer vi så snart vi kan.

Add comment

Your comment will be revised by the site if needed.