<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Operational Exception without Case in Cortex XDR Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/cortex-xdr-discussions/operational-exception-without-case/m-p/1256976#M9392</link>
    <description>&lt;P data-path-to-node="2"&gt;We are currently facing an issue with a Windows service. This service only functions properly after we add a specific executable (.exe) to the &lt;STRONG data-index-in-node="143" data-path-to-node="2"&gt;Operational Agent Exceptions&lt;/STRONG&gt;&amp;nbsp;. We haven’t seen any corresponding case or alert in the console, meaning Cortex XDR is not actively blocking anything.&lt;/P&gt;
&lt;P data-path-to-node="3"&gt;This raises the following questions:&lt;/P&gt;
&lt;H3 data-path-to-node="4"&gt;1) Wildcards in Operational Agent Exceptions&lt;/H3&gt;
&lt;P data-path-to-node="5"&gt;Unfortunately, wildcards cannot be used in the Operational Agent Exceptions profile. Is there any plan to support wildcards for these exceptions in the future?&lt;/P&gt;
&lt;H3 data-path-to-node="6"&gt;2) Module Identification &amp;amp; Support Files&lt;/H3&gt;
&lt;P data-path-to-node="7"&gt;A more granular &lt;STRONG data-index-in-node="16" data-path-to-node="7"&gt;Process Exception&amp;nbsp;&lt;/STRONG&gt;would be highly preferred over a blanket operational exception. To achieve this, we obviously need to identify which specific module needs to be disabled for this process.&lt;/P&gt;
&lt;UL data-path-to-node="8"&gt;
&lt;LI&gt;
&lt;P data-path-to-node="8,0,0"&gt;What is the best troubleshooting workflow to determine this?&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P data-path-to-node="8,1,0"&gt;How can we extract this information from the Support Files?&lt;/P&gt;
&lt;/LI&gt;
&lt;/UL&gt;
&lt;H3 data-path-to-node="9"&gt;3) Best Practice for Single-Endpoint Exceptions&lt;/H3&gt;
&lt;P data-path-to-node="10"&gt;This exception is intended for a single server only. To apply this single operational exception, we currently have to create a separate policy row containing a Malware, Restriction, and Agent Setting profile. Is creating a completely dedicated policy structure for a single endpoint really considered best practice? Over time, managing exceptions this way makes the policy overview difficult to maintain.&lt;BR /&gt;&lt;BR /&gt;Thank you &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;</description>
    <pubDate>Mon, 22 Jun 2026 07:17:46 GMT</pubDate>
    <dc:creator>M.Wempen</dc:creator>
    <dc:date>2026-06-22T07:17:46Z</dc:date>
    <item>
      <title>Operational Exception without Case</title>
      <link>https://live.paloaltonetworks.com/t5/cortex-xdr-discussions/operational-exception-without-case/m-p/1256976#M9392</link>
      <description>&lt;P data-path-to-node="2"&gt;We are currently facing an issue with a Windows service. This service only functions properly after we add a specific executable (.exe) to the &lt;STRONG data-index-in-node="143" data-path-to-node="2"&gt;Operational Agent Exceptions&lt;/STRONG&gt;&amp;nbsp;. We haven’t seen any corresponding case or alert in the console, meaning Cortex XDR is not actively blocking anything.&lt;/P&gt;
&lt;P data-path-to-node="3"&gt;This raises the following questions:&lt;/P&gt;
&lt;H3 data-path-to-node="4"&gt;1) Wildcards in Operational Agent Exceptions&lt;/H3&gt;
&lt;P data-path-to-node="5"&gt;Unfortunately, wildcards cannot be used in the Operational Agent Exceptions profile. Is there any plan to support wildcards for these exceptions in the future?&lt;/P&gt;
&lt;H3 data-path-to-node="6"&gt;2) Module Identification &amp;amp; Support Files&lt;/H3&gt;
&lt;P data-path-to-node="7"&gt;A more granular &lt;STRONG data-index-in-node="16" data-path-to-node="7"&gt;Process Exception&amp;nbsp;&lt;/STRONG&gt;would be highly preferred over a blanket operational exception. To achieve this, we obviously need to identify which specific module needs to be disabled for this process.&lt;/P&gt;
&lt;UL data-path-to-node="8"&gt;
&lt;LI&gt;
&lt;P data-path-to-node="8,0,0"&gt;What is the best troubleshooting workflow to determine this?&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P data-path-to-node="8,1,0"&gt;How can we extract this information from the Support Files?&lt;/P&gt;
&lt;/LI&gt;
&lt;/UL&gt;
&lt;H3 data-path-to-node="9"&gt;3) Best Practice for Single-Endpoint Exceptions&lt;/H3&gt;
&lt;P data-path-to-node="10"&gt;This exception is intended for a single server only. To apply this single operational exception, we currently have to create a separate policy row containing a Malware, Restriction, and Agent Setting profile. Is creating a completely dedicated policy structure for a single endpoint really considered best practice? Over time, managing exceptions this way makes the policy overview difficult to maintain.&lt;BR /&gt;&lt;BR /&gt;Thank you &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 22 Jun 2026 07:17:46 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/cortex-xdr-discussions/operational-exception-without-case/m-p/1256976#M9392</guid>
      <dc:creator>M.Wempen</dc:creator>
      <dc:date>2026-06-22T07:17:46Z</dc:date>
    </item>
  </channel>
</rss>

