I connect using "Computer Management" from computer A to computer B. Both computers are Windows Server 2008 x64 with all current hotfixes. The connection succeedes, and I don't even try to open any of the sub-snapins. But computer A (the connection source) logs the following event in its System Log: Log Name: SystemSource: Microsoft-Windows-DistributedCOMDate: 9/13/2008 8:59:58 PMEvent ID: 10006Task Category: NoneLevel: ErrorKeywords: ClassicUser: N/AComputer: <Computer A name's here>Description:DCOM got error "2147944122" from the computer <Computer B FQDN's here> when attempting to activate the server:{03837521-098B-11D8-9414-505054503030} And computer B (the connection destination) logs the following two events (three times each) in its Security Log: Log Name: SecuritySource: Microsoft-Windows-Security-AuditingDate: 9/13/2008 9:00:11 PMEvent ID: 5152Task Category: Filtering Platform Packet DropLevel: InformationKeywords: Audit FailureUser: N/AComputer: <Computer B name here>Description:The Windows Filtering Platform blocked a packet. Application Information:Process ID:568Application Name:\device\harddiskvolume1\windows\system32\services.exe Network Information:Direction:InboundSource Address:<Computer B IP's here>Source Port:57144Destination Address:<Computer A IP's here>Destination Port:63485Protocol:6 Filter Information:Filter Run-Time ID:0Layer Name:Receive/AcceptLayer Run-Time ID:44and Log Name: SecuritySource: Microsoft-Windows-Security-AuditingDate: 9/13/2008 9:00:11 PMEvent ID: 5157Task Category: Filtering Platform ConnectionLevel: InformationKeywords: Audit FailureUser: N/AComputer: <Computer B name here>Description:The Windows Filtering Platform has blocked a connection. Application Information:Process ID:568Application Name:\device\harddiskvolume1\windows\system32\services.exe Network Information:Direction:InboundSource Address:<Computer B IP's here>Source Port:57144Destination Address:<Computer A IP's here>Destination Port:63485Protocol:6 Filter Information:Filter Run-Time ID:0Layer Name:Receive/AcceptLayer Run-Time ID:44 Well, I already know that events 5152 and 5157 are nearly the same, so we need to look only into one of them in each case. But what's next?It seems to me that the firewallhere treats the initial connection and a responce as two different connection. So it allowsthe initial connection (from A to B)because I havesome rules in place that are supposed to allow remotemanagement. But then it blocksthe responce (from B to A). In this case, looking into separate connection from B to A,I guess, it should treat it as outbound and not filter at all. But it still calls it "Inbound" for some reason, apply some firewall rules and blocks it.Are my assumptions wrong? What are the explanation for this behaviour? How do I prevent the packets from being blocked?

Hi, Please use the following commands to enable the predefined group Remote Administration on both machines and check the result: Netsh advfirewall firewall set rule group=remote administration new enable=yes For more information about configuring Windows Firewall to allow MMC snap-in(s) to connect, refer to the section To configure Windows Firewall to allow MMC snap-in(s) to connect of the following article: http://technet.microsoft.com/en-us/library/cc753802.aspx

This is an old thread, but makes absolutely NO sense at all. I have firewall completely disabled on both nodes on my cluster, and still I get these 5157 event log entries. It is a 2-node cluster. Any thoughts? Why is is filtering ANYTHING, if I have firewall service completely disabled? The Windows Filtering Platform has blocked a connection. Application Information: Process ID: 536 Application Name: \device\harddiskvolume3\windows\system32\lsass.exe Network Information: Direction: Outbound Source Address: 10.1.3.106 Source Port: 54706 Destination Address: 10.1.3.104 Destination Port: 49158 Protocol: 6 Filter Information: Filter Run-Time ID: 0 Layer Name: Connect Layer Run-Time ID: 48 ================== The Windows Filtering Platform has blocked a connection. Application Information: Process ID: 4 Application Name: System Network Information: Direction: Outbound Source Address: 10.1.3.137 Source Port: 3343 Destination Address: 10.1.3.136 Destination Port: 3343 Protocol: 17 Filter Information: Filter Run-Time ID: 0 Layer Name: Connect Layer Run-Time ID: 48

Guess #1: What do you mean by “Disabled”? Do you specify the correct option in firewall settings or simply stop the relevant windows service? Guess #2: If I were you I'd try to check over the network for dropped/unsynced packets.

Also, I tried Joson's exact command via "cut-and-paste," but I get an error: Netsh advfirewall firewall set rule group="remote administration" new enable=yes Group cannot be specified with other identification conditions. ???

What is your Operating System and version? This group doesn't exist on Client SKUs (e.g. Windows 7). What do you try to achieve? Probably the same goal can be served by one of the “Remote XYZ Management” groups.

It is Window Server 2008 R2, as is the subject of this forum - with SP1, of course. I'm not trying to ACCOMPLISH anything specific, except ridding the event log of non-sensical errors. When I say "firewall disasbled," I literally 'mean' it - first, I turned off all firewall features on domain, public, private, etc.; and THEN I disabled the actual service - you know... services.msc, set the properties to "disabled" and yes, it is 'stopped' as well. I just have been noticing the errors in the event logs and wanted to find out what, why, etc. Thanks for any info.

Correction - this forum us 2008 Server firewall, not specifically R2. But still, the questions stand. Thanks.

If you have the service disabled it might well explain why you cannot change any firewall settings (e.g. enable a rule group). Basically there's no real reason to disable the service. This can have unpredictable consequences since the filter driver is still loaded and you cannot manage it any more. I would suggest enabling the service then ensure that firewall is actually disablled for all three profiles. Then wait for the repro.

Many thanks. That sounds almost logical. Your statement regarding "no real reason to disable" is not exactly valid. There are myriad reasons to actually disable the service itself - one of which is other software that conflicts and sees the 'service' state, and not the 'profile state' of the firewall settings. Those products - let me give you at least one as an example... wait for it... wait for it... The 'infamous' SQL Server! Yes, pups and pupettes, that' is correct - SQL Server does indeed give you a "false positive" during its pre-req checks and so forth; and and tells you, "Oops, dear systems manager, your firewall service is still enabled... blah blah" - that's not the exact quote, but very close indeed. Does it bother to check and see that, "OH, well, you've got firewall disabled for ALL profiles, so all is cool?" Noooo, of course it doesn't. [Note to Microsoft, please fix this!] Now, it may be okay [at this point], since I already have SQL server properly installed, and past all the "pre-checks," to re-enable the firewall service; but, to just off-hand say "there's NO reason whatsoever to disable the firewall service;" well, that is just not correct. For that matter, there are many of us who completely 'remove' the service - yes, it can be done - and, yes, I have written a technical article on doing just that; and, no, it will NOT cause unpredictable results - [IF] done properly and [IF] all the technical whatcha-ma-jig-its are lined up with the North Star when Pluto is in retrograde. But, yes, it is best just to let policy take care of disabling the various levels of the firewall and then leave the service as-is, since Microsoft puts more and more hooks in their o/s. Thanks again.

The requirement to actually disable the service is a common misunderstanding. 9 times of 10 you actually mean disabling the firewall, not the service itself. And 1 time left it is a buggy 3rd party vendor that doesn't care how to make his software working properly without conflicts with the underlying OS. We can take it case by case if you want. We specifically designed the Firewall for coexistance with 3rd party apps. So they can take control and orchestrate its behavior and even disable certain code paths in a fully supported manner. Specifically SQL Server is happy with one or two simple port exclusions and this is exactly what the setup wizard warns you about. It doesn't say to disable anything at all. It just reminds you to create those exclusions. And if you feel uncomfortable with it for any reason you're always free to disable the firewall. But please don't disable the service unless you know exactly what you're doing. (And, frankly, don't expect to receive much help from the forums in such a case). Sure you're free to do whatever you want with your PC unless you vialate the law (e.g. crack or disassemble stuff). If you disable or even remove the service you probably feel okay and things are working fine. But please understand that the filtering driver is still there and loaded. And this is probably the exact reason why you see the messages in event logs. And you have nothing to do with it since this config is very likely unsupported and not ever intended to work this way anyway (as opposite to co-existance scenarios noted above).

No, the actual "windows clustering" or "sql clustering" pre-tests appeared to 'fail' - until you actually disable the service. Maybe it was the Windows Cluster that I was thinking about - which is very picky anyway. Either way, I would almost swear that it was definitely a "stopper;" i.e., it would not let us go further until we disabled it. I have some more SQL installs coming up, and will re-visit that to be sure. Anyway, point taken. I never do anything lightly, without adequate forethought and hindsight. Presently, the Microsoft/Windows firewall service is quite good - much improved over the days of old. It doesn't bother me either way - I deal with multiple vendor firewalls, both hardware- and software-based. Thaks again - I appreciate your insights.