I'm just trying to get some stuff to pass traffic, that's all. However Windows Firewall on Server 2008R2 has decided that it's too much to ask and is going out of it's way to block the traffic.
Case in Point #1: I create a firewall rule to allow 443 in from a couple other subnets, everything works just fine. I turn on another system which resides in one of those subnets and it fails. I get a "Windows Filtering Platform has blocked a packet".
Very weird, but maybe there's something I'm missing. I turn on logging to see where we're getting the failure. Here's the funny part, the pfirewall.log file shows that it is allowing the traffic!
*NOTE: I highlighted the wrong one, so the arrow is pointing out the correct one.*
Some of the other things I've done to attempt to resolve the issue:
- "netsh advfirewall reset" followed by recreating the rule via admin templates
- "netsh advfirewall reset" followed by recreating the rule via Security Settings
- "netsh advfirewall reset" followed by recreating the rule locally
- Block Policy Inheritance, and retry all the above
- Set the scope to any and the port to 443
- Set the scope to any and the port to any
Everything else on the subnet is allowed in, so why would it be isolated to just this one system? I'm petitioning for a Microsoft Support Case to be made, hopefully they can get to the bottom of it.
Case in Point #2: Windows Firewall sees outgoing traffic and allows it. However, I get a "Windows Filtering Platform has blocked a packet" error again. The real head scratcher is that WFP sees the direction as being "Inbound".
I've gone through and created the proper firewall rules to allow a source port exception of 5989, and even a rule to allow all traffic from the offending system. Still no luck. So I'm hoping to add that to the case and finally get to the bottom of these problems.
Any thoughts or insight is much appreciated...
We ran into a HUGE problem with the migration of our file servers to Server 2008 R2 from Server 2003, our Techs noticed that the Previous Versions tab was only populating 64 of the oldest snapshots. This is a huge problem.
So I did some digging, ended up figuring out that if I opened up the Previous Versions tab in an older OS (I used Server 2003 as well as XP Pro) and could see all of the snapshots perfectly. So this now became a 2008/Win7 problem.
For those that don't know, the default maximum snapshot value is 64. This can be modified by going into the registry of the system that VSS is running on and going to: HKLM\SYSTEM\CurrentControlSet\services\VSS\Settings and adding the DWORD value of "MaxShadowCopies" and setting it to a decimal value of 512. 512 is the maximum number of snaps that can be done. More information can be found here: http://technet.microsoft.com/en-us/library/ee923636%28WS.10%29.aspx
On the left is a Server 2003 mapping of a 2008 R2 file share, on the right is the same file share mapped on a Windows 7 box. Big difference there.
We ended up creating a case with Microsoft. Turns out that it happens to be a known bug with no resolution in site. However, there did happen to be a workaround. To correct the problem, SMB2 has to be turned off. This is generally not something you want to do, however it worked in this particular instance. For information: http://en.wikipedia.org/wiki/Server_Message_Block#SMB2
So to turn off SMB2 and give yourself the ability to see all of the created snapshots in an OS newer than Server 2003 and/or XP, you have to dive back into the registry. Go to: HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters and create a new DWORD value of "SMB2" and ensure that the decimal value is 0. After that change has been made, reboot the system.
Note: Microsoft highly recommends turning SMB2 off at the desktop level rather than the server level.
After the reboot, here's what pulled up:
Success! Our techs can now help people out with the VSS snaps.