![Server Service File And Printer Sharing Ports Blocked Server Service File And Printer Sharing Ports Blocked](/uploads/1/1/8/7/118747202/482206146.jpg)
Remote Connection Information
Mar 29, 2020 An SMB port is a network port commonly used for file sharing. IBM programmer Barry Feigenbaum developed the Server Message Blocks (SMB) protocol in the 1980s for IBM DOS. SMB continues to be the de facto standard network file sharing protocol in use today. Jun 26, 2012 Specifically, the port and protocol for windows file sharing translated into what is required to implement this on a hardware firewall. The question has nothing to do with the builtin windows firewall. 1) what it takes to be able to do a net use command to a share on a windows file server in a command prompt?
If you're using Active Directory, please make sure you are running the Ninite .exe itself as a domain administrator instead of passing the credentials to Ninite.
In order to run Ninite remotely, the following settings must be seton the remote computer:
- simple file sharing must be disabled
- remote UAC must be disabled (on Vista or later Windows versions)
- file and printer sharing must be enabled
- the admin$ administrative share must be enabled
If Ninite can't connect, you can run the following .exe on the remotecomputer to set these correctly:EnableRemote.exe
Also, the remote computer has to be accessed through an administratoraccount that has a password set (it won't work with an empty password).
According to Microsoft TCP ports139 and 445 and UDP ports 137 and 138 should be accessible for Ninite remote to function.
If you get an error'Failed - Not enough server storage is available to process the command. 8107'you can fix it by increasing the IRPStackSize value.
These features are only available in Ninite Pro Classic.
We're working on documentation for the new Pro web interface. For now the available help for that is inline in the interface.
Get a Free Trial or Learn more about Ninite Pro
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.
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.
What is it Detecting?
![File and printer sharing 10 File and printer sharing 10](/uploads/1/1/8/7/118747202/971911650.png)
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:
File And Printer Sharing For Microsoft Networks
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?
It seems to me that there is a logic error here:
File And Printer Sharing Xp
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”
What Is File And Printer Sharing
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 Twitter profile? Product Support?
An Unorthodox Workaround
File And Print Sharing Ports
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.