As you make the move from Microsoft on-premises infrastructure to the cloud, you’ll move from Group Policy management of your endpoints to MDM management. This move isn’t always a “lift and shift” process because there isn’t always a 1-to-1 relationship between the settings available in Group Policy and those in Intune. Additionally, you need to consider what happens as a result of the device state changing as part of that move: are you keep your devices on-premises Active Directory joined in Hybrid Azure AD mode; or are you moving away from that and joining your devices to Azure AD only?
One area Microsoft does make it reasonably easy to “lift and shift” is Windows Defender Firewall. Built into Windows 10, Windows Defender Firewall comes with many default rules and is designed to control unauthorized network traffic to and from the PC. Administrators may, however, need to make changes or additions to these default rules to facilitate software requirements. For example, all network profiles, by default, block inbound connections unless an administrator creates an explicit allow rule or the application creates one itself.
In high-security environments, the best practice is, generally, to centrally control your firewall rules. Software may create rules on endpoints as it’s installed, but that complicates visibility for administrators. Therefore, Group Policy is a common way of introducing and managing those rules. An example of this can be seen below.
In order to migrate those rules from Group Policy to Intune, you’ll need a reference device that has the Group Policy applied. This article will guide you on how to use that reference device to extract the settings and get them into Intune to save you manually recreating potentially hundreds of settings.
1. Firstly, grab the tool Microsoft makes available at aka.ms/EndpointSecurityFWRuleMigrationTool. This is the Endpoint Security Firewall Rule Migration Tool. Catchy name, I think you’ll agree, but not sure if ESFRMT is the best way to abbreviate it. We’ll just call it the migration tool.
That link leads directly to an archive containing the PowerShell script Export-FirewallRules, which is the tool itself. Take that PS1 file, get it onto your reference device, and log in as a local administrator. If the device is already enrolled in Intune, you can see here how to manage local administrators easily.
2. In an administrator-elevated PowerShell window, run Export-FirewallRules. Depending on your execution policy, you may need to lift the execution policy to execute successfully.
Set-ExecutionPolicy -Scope Process Unrestricted -Force .\Export-FirewallRules.ps1
As the migration tool runs, it prepares several prerequisites, including installing the Intune PowerShell SDK and ImportExcel module which it obtains from the PowerShell Gallery. You may therefore be asked to confirm steps such as installing and importing the NuGet provider.
3. You will be prompted to provide credentials for an Azure AD user with one of the following roles:
Why’s this? Managing Intune using PowerShell requires OAuth permissions for an app called Microsoft Intune PowerShell. These roles have permission to allow that app the ability to get the privileges it needs, such as write to Intune policies. Consequently, you want to ensure this administrator also has the right to approve Azure AD enterprise applications (or be prepared to go through the approval steps with someone who does).
4. The migration tool will ask you to enter a profile name. This is the identity of the firewall rule profile in Intune. Telemetry can optionally be sent to Microsoft if the import hits any problems, with these also reported back to you and stored as spreadsheets in a logs subdirectory of whenever your PowerShell path is.
5. Visit endpoint.microsoft.com and navigate Endpoint Manager to Endpoint security > Firewall to review your policy; now migrated into Intune. In this example, the profile MyApp.exe Incoming-0 was created. The number at the end of the policy name increases incrementally if you have over 150 rules on the reference device. For example, if there are 160 rules, a second policy containing ten rules will also be created.
You’ll notice that only the rules you specified in your Group Policy are imported, and the hundreds of default are not. This is intuitive enough – the defaults will already exist on new devices you are enrolling into Intune and managing with it. If, however, you suspect they may have been removed or otherwise want to include them in your Intune policy, you can use .\Export-FirewallRules.ps1 -IncludeLocalRules to sweep those up too. A second parameter, -IncludeDisabledRules, is also available, which does what it says on the tin.
The firewall rules policy created in Endpoint Manager will not be assigned to any groups. As you assign it to groups and devices sync with Intune, they will apply the rule.
You can see from the above screenshot, on the device itself, Event Viewer (Applications and Services Logs > Microsoft > Windows > Windows Firewall with Advanced Security > Firewall) confirms the rule is applied with event ID 2004.
As the above screenshot shows, we can better still monitor the deployment from Endpoint Manager itself, allowing us to confirm successful (or not) deployment across our enterprise. After your rules are successfully rolling out, you should remove the Group Policy Object from them in Active Directory, if you are still targeting them.