I found this in the msi log ’SetAccountType:  Error 0x80004005: Cannot set GROUPPERFORMANCEMONITORUSERS=1 since the local users/groups are not available on Domain Controller’ Now I just need to found out if I can bypass it  

I'm a bit confused about how you're getting data to your SOAR instance - you say you're pulling, but you're also using the Splunk App for SOAR Export? When I hear pull, I'm assuming you have the SOAR App for Splunk configured to pull events in from SOAR (yes, I know the app names are all similar and this definitely caused some confusion for my team early on)   Assuming you just have the event forwarding configured, you can maybe try changing your advanced options to this: This would send everything as a single artifact, rather than the multiple you have.

Further more, if I "open In search" the search code of the two dashboards, and change every occurrence of -30d@d to -60d@d, and search, there will be 60 bars - last 60 days. This happens although the frozenTimePeriodInSec = 2592000 (30 days) for index _internal. Do we really need to double this setting? It looks that just changing -30d@d to -60d@d,  is enough. best regards Altin

@Symon   To effectively monitor Linux Auditd events in Splunk, you can use the Splunk Add-on for Linux. This add-on allows you to collect and analyze audit logs from your Linux devices. Here’s how you can set it up: Configure AuditD to Send Data to the Splunk Add-on for Linux: https://docs.splunk.com/Documentation/AddOns/released/Linux/Configure4  https://splunkbase.splunk.com/app/833  This Add On for linux Auditd allows Administrators to make their data OCSF Compliant and CIM compliant for related Linux Auditd Events https://preview.splunkbase.splunk.com/app/7045   

@pavithra  Kindly refer the below links:  How to display the count in piechart as labels - Splunk Community  Chart configuration reference - Splunk Documentation Chart configuration reference - Splunk Documentation

Before you format your table, you'll need to take your return value in the array and convert it to a string. You will need to do some custom code for this. The beauty of SOAR is that you're able to throw in some python code to manipulate the data in whatever way you want it to.

ok something is not clear.  the trigger condition is results count greater than 4, then trigger/run the trigger conditions.  1) do you say that when the results are greater than 4, but still the trigger did not work.  2) on your latest reply, you got only one result, but the trigger condition ran successfully ya? Can you pls attach the trigger conditions screenshot pls. 

@yazeed    Splunk's _configtracker can be used to monitor changes to alerts and saved searches in Splunk. The _configtracker index: With Splunk 9, the _configtracker index was introduced. This index stores changes to Splunk configuration files, including the date and time of the change, as well as all the new and old values associated with the modified item. However, the data in _configtracker has a limitation: it only monitors changes to configuration files. Consequently, a crucial piece of information is missing from these logs: the user responsible for the change. While it does provide a record of the previous and updated settings, this information is not available in the same event. Therefore, to create a comprehensive alert, we need to perform data aggregation and enrichment. For instance, after the described change to the Windows failed logons alert use case, the configtracker will contain two related events. Note the search looks in the _configtracker index, for a configuration update, where the changed item (data.changes{}.stanza) is specified, and particularly for a saved search being changed, independently of the app and Splunk installation directory ("*/savedsearches.conf"). Here is the SPL query: index=_configtracker component=ConfigChange data.action=update data.changes{}.stanza=* data.path="*/savedsearches.conf"  

@splukiee    Certainly! Addressing high CPU usage in your Splunk environment due to specific dashboards can be challenging, but let’s explore some strategies to mitigate the issue: Dashboard Optimization:- Review Dashboard Components: Inspect each dashboard panel. Are there any resource-intensive visualizations (e.g., complex charts, tables, or maps)? Simplify or optimize them. Reduce Real-Time Updates: If dashboards update in real-time, consider increasing the refresh interval. Frequent updates can strain CPU resources. Limit Concurrent Sessions: Since users have multiple sessions open, limit the number of concurrent sessions per user. Excessive sessions can overload the system. Use Summary Indexes: Consider using summary indexes for frequently accessed data. This reduces the need for real-time searches. Monitoring and Troubleshooting: Splunk Monitoring Console (MC): Use MC to monitor resource usage. Check the CPU Usage by process class graph to identify which components consume the most CPU. https://lantern.splunk.com/Splunk_Platform/Product_Tips/Administration/Troubleshooting_high_resource_usage  https://docs.splunk.com/Documentation/Splunk/9.2.0/DMC/ResourceusageCPU