deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-18 16:27:22 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Minor changes

Browse Source
This commit is contained in:
Asha Iyengar 2020-11-18 17:58:54 +05:30 committed by GitHub
parent 70f5d6d5fb
commit 0e669df0f1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
windows/security/threat-protection/windows-firewall/firewall-settings-lost-on-upgrade.md
View File

@ -17,7 +17,7 @@ ms.topic: troubleshooting
# Firewall Settings Lost on Upgrade
This article describes a scenario whereby previously enabled firewall rules revert to a disabled state after performing a Windows upgrade.
This article describes a scenario where previously enabled firewall rules revert to a disabled state after performing a Windows upgrade.
## Rule Groups
@ -29,15 +29,15 @@ Individual built-in firewall rules are categorized within a group. For example,
- Remote Desktop – User-Mode (UDP-In)
Other examples include the Core Networking, File and Print Sharing, and Network Discovery groups. Admins can filter on individual categories in the firewall interface (wf.msc) by selecting and right-clicking on ‘Inbound’ or ‘Outbound Rules’ and selecting ‘Filter by Group’; or via PowerShell using the `Get-NetFirewallRule` cmdlet with the `-Group` switch.
Other examples include the Core Networking, File and Print Sharing, and Network Discovery groups. Admins can filter on individual categories in the firewall interface (wf.msc) by selecting and right-clicking on ‘**Inbound**’ or ‘**Outbound Rules**’ and selecting ‘**Filter by Group**’; or via PowerShell using the `Get-NetFirewallRule` cmdlet with the `-Group` switch.
```Powershell
Get-NetFirewallRule -Group <groupName>
```
> [!NOTE]
> It is recommended to enable an entire group instead of individual rules if the expectation is the ruleset is going to be migrated at some point.
> It is recommended to enable an entire group instead of individual rules if the expectation is that the ruleset is going to be migrated at some point.
It is recommended to enable/disable all rules within a group, as opposed to enabling/disabling just one or two of the individual rules to help avoid unexpected behaviors. For example, while rule groups can be used to organize rules by influence and allows batch rule modifications, they are also used as a way to maintain rule state across a Windows upgrade. Rule groups, as opposed to individual rules, are the unit by which the process determines what should be enabled/disabled when the upgrade is complete.
Take the Remote Desktop group example mentioned above. It consists of three rules. To ensure that the ruleset is properly maintained once the upgrade is complete, all three rules should be enabled. If only one rule is enabled, the upgrade process will see that two of three rules is disabled and subsequently disable the entire group to maintain an as pristine out-of-the-box configuration as possible. Obviously, in this scenario, this brings the unintended consequence of being unable to establish RDP connection to the host.
Take the Remote Desktop group example mentioned earlier. It consists of three rules. To ensure that the ruleset is properly maintained once the upgrade is complete, all three rules must be enabled. If only one rule is enabled, the upgrade process will see that two of three rules are disabled and subsequently disable the entire group to maintain an as pristine out-of-the-box configuration as possible. Obviously, in this scenario, this brings the unintended consequence of being unable to establish RDP (Remote Desktop Protocol) connection to the host.