In this support tip, we wanted to provide you with some tools and guidance to help you trace and troubleshoot the endpoint security Microsoft Defender Firewall rule creation process in Microsoft Endpoint Manager. Why would one need to troubleshoot this process you wonder? We have seen some customers enter invalid values for rules which lead to policy processing issues. The goal of this post is to help you understand the end-to-end process so you can figure out where things might be breaking. For a sample PowerShell script to quickly help you identify bad rules on a test system, be sure to see Test-IntuneFirewallRules PowerShell script below!
<atomic> Rule1 Rule2 Rule3 </atomic>
In the example above, we have a single Intune policy with three rules in it. The individual rules are sent in a single policy atomic block. If a rule within the block fails to process on a Windows device, the entire policy is reported as failed in the Microsoft Endpoint Manager admin center.
In the example above, if only rule 2 were bad, rule 1 would be created, rule 2 would fail to be created, and rule 3 would be blocked from being created until rule 2 is fixed.
The Endpoint security firewall rule migration tool for Microsoft Intune is a powerful tool for migrating Azure Active Directory Group Policy Object (GPO) rules to Microsoft Intune Endpoint Security Firewall rules. However, we have seen customers bring over bad rules which were incorrectly configured in GPO. The following are possible issue examples to be aware of.
An invalid file path specified on a firewall rule will lead to policy processing errors. As an example, having a typo in an environment variable, such as an extra space in %ProgramFiles(x86)% will lead to an entire policy being reported as failed. The Windows Firewall client only supports built-in Windows environment variables, which can cause other file path issues. Custom variables, even if valid, cannot be used. For example, %programfiles%\folder\executable.exe will work, but %customvariable%\folder\executable.exe will not work even if %customvariable% is a functional variable on the client. Aside from applying to MDM firewall policy, these limitations also apply to Group Policy, and even manual rule creation. This is the most common error we have seen.
Check for invalid port ranges, which can lead to errors, such as a descending range like 65535-65534. For more information, see the configuration service provider reference to learn more.
If a policy targets a bad rule, subsequent policy rules may also fail to process. In this case, you must find the first policy and bad rule to fix and unblock the following rules. Note in the example below, rule L_gEAAA is logged as failed.
However, this is actually the third rule in policy d444067ff2b74006993bf3d10bd98467. From the SyncML trace below, as well as the registry and Get-NetFirewallRule cmdlet output, we will see that it is actually our second rule (LQEAAA) that is the first blocking failure that needs to be addressed.
If you suspect a parameter may not be valid, create a rule using the value so you can manually test it directly within Windows.
Note that the “Error: The parameter is incorrect” message in the image above aligns with the Event Log error example earlier in this post.
If you want to test changes to a policy, for example to remove suspect rules, you can quickly and easily copy policies. In the Microsoft Endpoint Management admin center, under Endpoint security | Firewall, right-click a policy and select Duplicate.
Finally, the EndpointSecurityPolicy_Export.ps1 sample script is a powerful tool for exporting all of your endpoint security policies (to JSON), which you can then quickly review in your favorite text editor or IDE. After you find a bad rule in a policy, this can be a quick way to review the remaining policy for additional instances of that same issue.
The Intune Customer Service and Support team’s Mark Stanfill created this sample script Test-IntuneFirewallRules to simplify identifying Windows Defender Firewall rules with errors for you (on a test system). This script allows you to run diagnostics against all of your policies in Intune, or offline selectively against policies you export to your local system. It will try to create the rules on the local system and will generate a report on related failures, including the policy and rule names along with any detected issues and instructions on how to fix the rule in the Endpoint Manager admin center.
For more information, see the project in GitHub.
The following section walks through additional methods for manually tracing the end-to-end process and tools which may further assist in the troubleshooting process.
To identify and fix problematic rules, it is necessary to understand how policies and rules are each identified, stored, and progress end-to-end between Endpoint Manager and Windows.
Within Intune, the policy will have a unique deviceConfiguration id. The id component is a globally unique identifier (GUID), for example: d444067f-f2b7-4006-993b-f3d10bd98467.
The individual rules within the policy will each have a correlating unique ID string, which will consist of 6 characters, for example: LAEAAA. (Sometimes, you will find additional “padding” within these rules containing underscores, which will make the rule component appear to vary in length; more on this later.)
MDM diagnostic report
To diagnose MDM failures in Windows 10, go to Settings > Home > Accounts > Access work or school > Info > Create report. You can also run mdmdiagnosticstool.exe -out c:\temp from a command prompt to generate an MDMDiagReport.html file. Within this report, under Enrolled configuration and target resources, you can see the firewall rules targeted to the device (Control-F for FirewallRules), as show in the following example.
The deviceConfiguration id in the above screenshot example has the hyphens which would normally be included in a GUID removed from it. We will use PowerShell later to convert this back to a “proper” GUID (e.g. d444067f-f2b7-4006-993b-f3d10bd98467) format so we can query Intune for it.
Important: The MDM report shows what is targeted to the device. If you are hitting an issue with policy processing, the actual rules created on the device will vary from what is displayed here. In the following tracing examples, we will look to the Event Logs, PowerShell, and Windows registry to reconcile what is targeted to the device versus displayed in the MDM diagnostic report as targeted.
Windows Event Viewer
The Application and Services logs\Windows\DeviceManagement-Enterprise-Diagnostics-Provider/Admin (or C:\windows\system32\winevt\Logs\Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx) log will contain related errors, as well as successes on individual rule creation.
To filter, select EventID 404 and search for the keyword FirewallRules, which brings us to the following Event Log failure entry example:
MDM ConfigurationManager: Command failure status. Configuration Source ID: (GUID), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (Firewall), Command Type: (Add: from Replace or Add), CSP URI: (./Vendor/MSFT/Firewall/MdmStore/FirewallRules/d444067ff2b74006993bf3d10bd98467L_gEAAA /Name), Result: (The parameter is incorrect.).
Again, note the deviceConfiguration id and rule id combination within the error, along with the “parameter is incorrect” result. While the event log entry above will indeed show you a rule that is failing to process, we will have to dig further using the additional techniques and tools below to find the actual rule and reason for the failure.
Within the Windows registry, you can confirm which rules were created on the device under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\Mdm\FirewallRules
Important: In the example above, rule entries 1-3 are from the same policy (e96193e75beb4758a6007cbf7f6beb76). Rule 4 (LAEAAA) is the only rule entry created from a different policy (d444067ff2b74006993bf3d10bd98467), which we will call Policy B. In comparing this to what is reported in the MDMDiagReport pictured above, we can deduce that Policy B's next rule (i.e. Rule #2 in the Endpoint Security policy, since the policy’s rules are processed together sequentially) is broken and blocking subsequent rules within the same atomic block from being created. Additional details on this behavior are covered in the Known Issue Examples.
PowerShell can be used to identify and pipe out all firewall rules created on the local system using:
Get-NetFirewallRule -PolicyStore ActiveStore
To filter on rules from a particular policy, you can use the policy ID followed by a wildcard * to capture all rules with the policy ID prefix in the name, for example:
Get-NetFirewallRule -Name d444067ff2b74006993bf3d10bd98467* -PolicyStore ActiveStore| Format-List DisplayName, Name
The DisplayName output above is the actual rule name configured within the policy, which is visible in the Endpoint Manager admin center.
You can use Graph Explorer (or any other preferred Graph interface) to call to Intune to resolve the policy ID from the Event Log back to the Endpoint Security policy name that is failing, for example:
In Graph Explorer, simply enter your deviceConfiguration id in the URL field and select Run query.
For more information on using Graph Explorer with Intune, please see Working with Intune in Microsoft Graph. For a step-by-step learning module on connecting to and working with Microsoft Graph with Graph Explorer, please see Introduction - Learn | Microsoft Graph Fundamentals.
Tip: To convert the policy ID from the Event Log into a properly formatted GUID, you can use [guid] "d444067ff2b74006993bf3d10bd98467" in PowerShell:
In addition to the Graph Explorer example above, you can also use the Get-IntuneGraphAPIObject sample script to resolve the deviceConfiguration id back to its Endpoint Manager admin center friendly name. For example:
Get-IntuneGraphAPIObject.ps1 "deviceManagement/deviceConfigurations/d444067f-f2b7-4006-993b-f3d10bd98467" | fl DisplayName
A SyncML Viewer trace can be performed to see each individual rule created, its parameters, and the related status for a failure. Again, you can keyword search for FirewallRules to get to the related policy sync session quickly. Note the SessionID (#1 below, 14E), the <Atomic> block (#2 below) containing the rules in the policy, and the individual rules and their CmdID (#3) below:
Important: Here is where we can see the first sync failure is occurring on firewall rule “d444067ff2b74006993bf3d10bd98467LQEAAA”. This is our blocking rule which causes subsequent rules to fail.
Within the following Status message for SessionID 14E (obtained from #1 above), we can see the first failure is for CmdID 3 in the status:
<Status> <CmdID>3</CmdID> <MsgRef>4</MsgRef> <CmdRef>11</CmdRef> <Cmd>Atomic</Cmd> <Data msft:originalerror="0x80070057">507</Data> </Status>
Error 0x80070057 resolves to:
Error Code: 0x80070057 (2147942487)
Error Name: E_INVALIDARG
Error Source: Windows
Error Message: One or more arguments are invalid
Referring to the prior related CmdID 3 trace details, we can see that we were failing to <Add> the following application file path value:
Note that the policy rule ID aligns with what we saw in the Event Log sections error example above: d444067ff2b74006993bf3d10bd98467LQEAAA. We have the additional knowledge from the <Data> value that we were failing to set the file path to %2P2B%\2P2B.exe. The file path of %2P2B% is not a valid value for the Windows Firewall client to create the rule. As a result, the rule creation process failed.
We hope this blog post helps you better understand how to avoid and troubleshoot Endpoint Security firewall failures, should you encounter them. There are improvements to existing features and new features on the roadmap. To stay up-to-date with new features, visit our In development and What’s New docs in Intune to learn more.
We will update this blog post as we make diagnostic or behavior changes related to the scenarios noted above. If you have any questions or feedback on the new template, reply to this post or reach out to @IntuneSuppTeam on Twitter.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.