How to trace and troubleshoot the Intune Endpoint Security Firewall Rule creation process

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!

 

Background on MDM firewall policy structure

 

Intune firewall rules are sent through the Windows MDM client and come down in the form of SyncML with the following Atomic structure:

 

 

<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.

 

Example device status in the Endpoint Manager admin center that shows multiple ‘Assignment Status” line items that are in error.

 

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.

 

Common issue examples

 

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.

 

Bad file paths

 

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.

 

Invalid port or IP range

 

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.

 

Blocked policies and rules

 

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.

 

Filtered view on Event ID 404 showing firewall rule #3 (named ‘L_gEAAA’ in the CSP URL path) logged as failed. Later we discover this is a result of the prior rule #2 being failed in the policy block.

 

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.

 

Troubleshooting tips

 

If you suspect a parameter may not be valid, create a rule using the value so you can manually test it directly within Windows.

 

An image of an error message from Windows Defender Firewall with Advanced Security: “Error: The parameter is incorrect” and “Status: The application name could not be resolved.”

 

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.

 

A list of Firewall policies in the Endpoint Manager admin center, showing the ‘Duplicate’ option that is available when you right-click a policy.

 

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.

 

Test-IntuneFirewallRules PowerShell script

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 target a specific policy or all policies, based on whether they are assigned or unassigned. 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.

 

A screenshot of the script result, which shows a list of ‘Firewall rules with errors’ and columns for other details, including suggested fixes.

 

For more information, see the project in GitHub.

 

Advanced troubleshooting techniques and tools

 

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.

 

Policy and rule identifiers

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.)

 

Windows client-side tracing

 

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.

 

Example of a local Windows MDM failure report, showing the section ‘Enrolled configuration sourcesand target resources’ with selections 1 ,2, and 3 that are different parts of the example resource string.

 

1. Shows the entire policy + rule identifier
2. Policy ID mentioned in the prior section
3. Rule identifier

 

The deviceConfiguration id above 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.

 

Registry

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

 

Windows registry image showing a list of five firewall rules (a default rule and four rules from policy). Of the four policy firewall rules, the ones labeled 1-3 have the same policy ID. The rule labeled 4 has a different policy ID.

 

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

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

 

 

 

Image of Windows Powershell running the example ‘Get-NetFirewallRule’ command.

 

The DisplayName output above is the actual rule name configured within the policy, which is visible in the Endpoint Manager admin center.

 

Use Microsoft Graph API to find problem policies and rules

 

Graph Explorer

 

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:

 

 

https://graph.microsoft.com/v1.0/deviceManagement/deviceConfigurations/d444067f-f2b7-4006-993b-f3d10bd98467

 

 

 

In Graph Explorer, simply enter your deviceConfiguration id in the URL field and select Run query.

 

Image of Graph Explorer with the deviceConfiguration id in the request body and a detailed response with a ‘displayName’ value of “2P1G2B3G” highlighted.

 

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:

 

Image of [guid] command in PowerShell.

 

PowerShell script conversion of policy ID to policy name

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

 

 

 

Image of DisplayName command and results in PowerShell.

 

MDM diagnostic tracing

 

SyncML Viewer

 

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:

 

Image of SyncML Viewer results with “firewallrules” entered into the upper-right search box and the results. Callout 1 shows a SessionID, callout 2 shows the start of the atomic block, and callout 3 shows the CmdID and its data.

 

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>

 

 

 

Image drilling down into the status message for CmdID 3, that shows the aforementioned values/error info.

 

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:

      <Add>
        <CmdID>3</CmdID>
        <Item>
          <Target>
            <LocURI>./Vendor/MSFT/Firewall/MdmStore/FirewallRules/d444067ff2b74006993bf3d10bd98467LQEAAA/App/FilePath</LocURI>
          </Target>
          <Data>%2P2B%\2P2B.exe</Data>
        </Item>
      </Add>

 

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.

 

Conclusion

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.

Posted at https://sl.advdat.com/3qorTF4https://sl.advdat.com/3qorTF4