Skip to content

“File and Printer Sharing Ports Blocked” — But Are They?

A recent upgrade to System Center Operations Manager, taking it to the new 2019 release, perhaps combined with an update to the Windows Server management packs, created an interesting issue.

On the management server, an alert was triggered about the management server itself:

Resolution State: New
Alert: Server Service: File and Printer Sharing Ports Blocked
Source: SCOM (SMB)
Path: SCOM.fqdn
Last modified by: System
Last modified time: 3/13/2019 2:14:28 PM
Alert description: Either Windows Firewall is disabled or the firewall inbound rules for TCP ports 445 or 139 are disabled.

Interesting. Did the upgrade to SCOM 2019 or the management pack somehow break Windows File Sharing? And if it did, why hadn’t we noticed more significant issues than just this alert?

Well, no — it looks like this alert is actually earlier from March, but perhaps the alert has re-surfaced, post upgrade, as the monitor re-evaluated. What I was sure about, however, was that the file sharing ports were indeed open and that this alert couldn’t be correct!

Right? Right?

To the Firewall!

Investigating all the relevant firewall rules revealed that everything was in order — Windows File and Printer Sharing exceptions were allowed, as appropriate, across the board.

File and Printer Sharing rules

What is it Detecting?

So, it was time to dig a little deeper.

I was able to go to the Alert details and click on the Alert Monitor to drill down and find the details of how the monitor was coming to this apparently erroneous conclusion.

I extracted the script and tried running it manually on the server using cscript.

With a few WScript.Echo calls of mine sprinkled in, the relevant part of the VBScript that powered the monitor was as follows:

Dim rule

For Each rule in fwPolicy2.Rules
  If (rule.Protocol = NET_FW_IP_PROTOCOL_TCP) And (rule.LocalPorts = "445") Then
    WScript.Echo("Proto " + CStr(rule.Protocol) + " and port " + rule.LocalPorts + " enabled: " + CStr(rule.Enabled))
    WScript.Echo("rule.Profiles: " + CStr(rule.Profiles) + " and rule.Enabled " + CStr(rule.Enabled))

    If (Not rule.Enabled) And (rule.Profiles And fwCheckProfile )  Then

      WScript.Echo "Setting file sharing ports enabled to true"
      fwFileSharingPortsEnabled = "True"

      Exit For

    End If

  End If

So, let’s go ahead and run this.

The script also checks to see if any non-hidden shares exist on the server and will only put the monitor in an unhealthy state if at least one exists.

It iterates over all the rules for port 445, decides all the rules are enabled, which would allow access to File Sharing, but then ends up with fwFileSharingPortsEnabled still being false.

This propagates to the ultimate script output of a PropertyBag with the value Disabled under PortStatus.

All the rules are enabled, but the result is that it considers the ports not open for business??

Is this Logic?

Is this Logic?

It seems to me that there is a logic error here:

If (Not rule.Enabled) And (rule.Profiles And fwCheckProfile )  Then

Only if the firewall rule is not enabled and the profile matches the current network profile, we consider the port enabled?

Remember that if the rule is not enabled, traffic would be blocked by the Windows Firewall.

It seems that this might be a simple logic error in the management pack. A comment later in the script even states:

‘ Only if regular share exists and port 139/445 are not open will portStatus be returned as “Disabled”

Am I missing something obvious?

I’d Report This…

I cannot figure out where I should report this, if I’m correct in thinking how this should be working. Should I complain on a forum? Is there a System Center Operations Manager support Short-Form “Bird” Social Media Site Before It Went Terrible profile? Product Support?

An Unorthodox Workaround

For now, disabling at least one of the rules for port 445 suppresses this alert. For example, if you don’t need or want Remote Event Log Management, you can disable the Remote Event Log Management (NP-In) rule. This script will then return Enabled and the alert will not be fired.

Any of the port 445 rules being disabled will cause the script to be happy again.

Like this post?

If you would like to support the time and effort I have put into my tutorials and writing, please consider making a donation.


  1. eric mosby wrote:

    I found that the Network Location Awareness service needed to be set to delayed start. otherwise the wrong network profile is detected and the scom script errors.
    We wanted DOMAIN profile and our server was getting PUBLIC profile. After setting to delayed start server was on correct profile and scom script ran successfully
    alert went away

    Wednesday, August 21, 2019 at 18:42 | Permalink |
  2. christopher frew wrote:

    This is making me tear my hair out as well! I just don’t understand why this is a problem! I will log a support case with Microsoft and report back here with the results…

    Tuesday, December 10, 2019 at 02:08 | Permalink |
  3. Kester wrote:

    The only thing im assuming is that the current network profile has to be either private or domain, as the script does not make reference to the public profile (stand to be corrected).

    Tuesday, January 21, 2020 at 13:55 | Permalink |
  4. Sandeep Arora wrote:

    Kindly provide the script which needs to run onto the server on which SMB is re-occuring

    Monday, February 24, 2020 at 03:13 | Permalink |
  5. Paul Sterud wrote:

    Eric was on the right track….. network location said unknown location, restart the network location awareness service fixed it right up

    Tuesday, March 17, 2020 at 19:11 | Permalink |
  6. Dave Fenwick wrote:

    You’re spot on. The network awareness service restart only exposes the actual problem here, which is the logic is incorrect. The entire script looks to see if there is a disabled rule for port 445, and if there is, it says everything is correct.

    This is fallout from a change from the Server 2012 SMB MP in which they were checking for specific rule names, which failed for servers that were in non-English locales. They attempted to invert the logic from the 2012 MP script, but failed to actually take the comparisons into account. It’s pretty much a broken rule. It will ONLY pass if you have a rule on port 445 that is disabled.

    Just like you, I have no idea where to report this either. I’ll see if I can let Kevin Holman know. He might know who to report it to.

    Tuesday, August 11, 2020 at 22:49 | Permalink |

Post a Comment

On some sites, you must be logged in to post a comment. This is not the case on this site.
Your email address is not made public or shared. Required fields are marked with *.

Posting a comment signifies you accept the privacy policy.
Please note — your comment will not appear straight away, as all comments are held for approval.