Step by Step: Safely disabling SMB v1 from your production environment.


In this blog I will not cover why we have to remove SMB v1 from production network, this have been already covered, probably one of the best articles covering this is

I will cover how you can audit the usage of SMB v1 in your network, so you can disable it safely without breaking anything on your production. To do, we will proceed with the three steps listed below:

· Enable Auditing on SMB Servers.

· Configure Event Forwarding.

· Retrieve Events on an Excel sheet and analyzing SMBv1 traffic.


Enable Auditing on SMB Servers:

First Question, on which servers we need to enable auditing?

the answer is simple, all SMB servers. Domain controllers are a good example, client computers and member servers use SMB to access SYSVOL and NETLOGON shares to apply group policy, so domain controllers are servers to audit. File and print servers also need to be audited.

In my scenario I have three concerned servers: DC01 and DC02 are domain controllers, MEM01 is a file server. All of them are running Windows Server 2012 R2.

To enable SMB v1 auditing on Windows Server 2012 R2 run the PowerShell command:

Set-SmbServerConfiguration -AuditSmb1Access $true


After enabling the audit, an event will be logged each time a client computer access server using SMB v1.

I can see the events by navigating Application and Services Logs à Microsoft à Windows à SMB Server à Audit




As you can see on the screenshot above, the event indicates SMB1 access and give you the client IP address.

Note: The command Set-SmbServerConfiguration -AuditSmb1Access $true will not work on a non-updated Windows Server 2012 R2, please install the latest monthly rollup to be sure everything will work just fine, till writing of these lines the latest monthly rollup is October 2018.


Configure Event Forwarding

Imagine you have a huge environment, let’s say more than 50 domain controllers or maybe more than 100, how you will analyze SMBv1 events on all these servers, here where windows event forwarding will be very useful to centralize logs for better analyzing. Below the steps to centralize SMBv1 events on the server MEM01.

1. Add the network service account as member of the group Event Log Readers on all audited servers.

On Domain Controllers use Active Directory Users and Computers.



On Member servers use Computer Management console as shown on screenshots below.







2. Give the Event Log Readers group permissions to access SMB Server audit Logs.

By default, Event Log Readers members have permissions to access Security and System logs…etc. But they don’t have permissions to access SMB Server Log.

Open command prompt as administrator and run the following command on audited servers.

wevtutil set-log Microsoft-Windows-SMBServer/Audit /ca:O:BAG:SYD:(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)


3. Create a subscription on the Windows Event forwarding Server. (MEM01)

Open Event Viewer

Click on Subscription and then Click Yes.



Right click on Subscription and select Create Subscription…



Enter a friendly name.

Select Source computer initiated.

Click on Select Computer Groups.



Click on Add Domain Computers…



Include the group Domain Controllers and MEM01.

Click OK.




Click on Select Events…



Choose the SMBServer Audit log.



Type 3000 to forward only Events with Event ID 3000.

Click OK.



Click on Advanced…



Select Minimize Latency.


Click OK twice.


Subscription SMBv1 is created.



4. Configure the group policy

Create a GPO and configure the policy setting: Configure target Subscription Manager



Enable the policy and click on Show…



Enter the URI of the event forwarder server. In my example MEM01.



My GPO is named: Event Forwarding.

The GPO is linked to domain controllers OU and BROMServers OU.



you might need to restart the servers before beginning viewing events on the Event forwarding server (MEM01).



Retrieve Events on an Excel sheet and analyzing SMBv1 traffic.


Use the PowerShell script below to export the events on a nice Excel Sheet. Run the PowerShell code below on the event forwarder server (MEM01).



Add-Content -Value “clientName,server,TimeCreated” -Path c:SMBv1.csv

$Events = Get-WinEvent -LogName ForwardedEvents

# Parse out the event message data

ForEach ($Event in $Events) {

# Convert the event to XML

$eventXML = $Event.ToXml()

$clientName = $eventXML.Event.EventData.Data.’#text’

$server = $Event.MachineName

$TimeCreated = $Event.TimeCreated

Add-Content -Value “$clientName,$server,$TimeCreated” -Path c:SMBv1.csv



Run the script.



You will find the SMBv1.csv on the C: drive



Screenshot of the csv file opened on Excel.



With Excel you can see the devices and computers using SMBv1. After treatment of all the devices you can disable SMBv1 safely .



The most important thing when disabling SMB v1 from production is auditing, following steps on this article you will have all the devices talking SMBv1 with your SMB Servers, you need to understand why these clients are talking SMBv1 and how to remediate, after treatment of these devices you can safely disable SMBv1 using the steps on the article below.




2 thoughts on “Step by Step: Safely disabling SMB v1 from your production environment.

  1. Great article! thanks 😉
    One thing that you missed I think is wrong sddl in this line:
    wevtutil set-log Microsoft-Windows-SMBServer/Audit /ca:O:BAG:SYD:(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

    It should be:
    wevtutil set-log Microsoft-Windows-SMBServer/Audit /ca:O:BAG:SYD:(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

    So it includes NS.

    1. Hi Lukasz.
      Thank you for your input.
      Actually the command I used will give permission to the group Event Log Readers. (S-1-5-32-573)

      wevtutil set-log Microsoft-Windows-SMBServer/Audit /ca:O:BAG:SYD:(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

      On the post, I started by adding Network Service account as member of Event Log Reader group.

      wevtutil set-log Microsoft-Windows-SMBServer/Audit /ca:O:BAG:SYD:(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20) will give an explicit permission to the network service account.

      I prefer always to give permission for the event log readers group 😉

Leave a Reply