Hi @TheEggi98  export = system in default.meta.conf only governs ACL/visibility, not which app context the page renders in. The actual provlem is that another app's nav still loads the view inside that app's current context, so Splunk resolves your JS bundle under /static/app/<currentapp>/... instead of the app the JS actually lives in. I would suggest that the fix in your usecase is to not reference the view via <view> in the target app's nav at all. Instead add an absolute link so the browser actually navigates to a URL in the owning app: <nav> <view name="search" default="true" /> <a href="/app/your_kv_editor_app/edit_lookup">Edit Lookups</a> </nav>   🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @iamvikasjha  I think the offset on the table is retaining the page=5 setting when the filter is updated and not resetting to page 1 when it reloads. Its not possible to update the page offset token as far as I know although I think it probably should do itself, so it might be worth raising a ticket with Splunk support to see if they acknowledge this as a bug?  The link you referenced is from a Classic XML dashboard bug from mannny years ago so I suspect is unrelated. 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @saised  It looks like the app was released just before 10.6.0.5 was released therefore the app author will just need to go on an mark it as supported for 10.6 once they've had time to test it, however looking into the app it just looks like its parsing configs which should be unaffected by the version uplift as nothing breaking in that space from 10.4 > 10.6 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Good shout @PickleRick yes RULESET would work better and is just a quick change, covers already parsed data.  ... View more

Hi @Jasem  Yes, it's a reasonable and something ive done with customers in the past using an indexed field. Set a static indexed field at each HF, assume that the HF is common to all UF/syslog data from a given zone. We found overhead is be pretty negligible for this use case, Indexed-field cost in the TSIDX scales with cardinality × event count, not just event count, but you only have a handful of zone values, so the extra lexicon entries are small. CPU cost comes from evaluating the transform per event so with no regex this is pretty cheap. It gets noticeably more expensive (resource-wise) only if you try to derive the zone from a regex over host/source on every event instead of hardcoding it per HF. Configure only at the HF tier, nothing on UF/syslog or indexers: # props.con [default] TRANSFORMS-zone = set_zone_dmz # transforms.conf [set_zone_dmz] INGEST_EVAL = zone="DMZ" Repeat with the appropriate static value on each zone's HF. Putting it on [default] applies it to everything that HF parses, which is correct here since the field describes the forwarder's zone, not the data's sourcetype. You should really then create a fields.conf with your Indexed-Field definition which goes on the SH too. 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @jdmeek  blacklist/whitelist in inputs.conf only match against the file path/name, not content, so there's no monitor-stanza setting that can exclude a whole file based on what's inside it (see inputs.conf include/exclude docs). Given your PowerShell transcripts are indexed as a single multi-line event per file, you can drop the whole thing at parse time instead, by matching a string that only appears in the InTune-generated transcripts and routing that event to the null queue before indexing: #props.conf [your_sourcetype] TRANSFORMS-dropintune = drop_intune_transcripts #transforms.conf [drop_intune_transcripts] REGEX = (?i)Microsoft.Management.Services.IntuneWindowsAgent DEST_KEY = queue FORMAT = nullQueue   This has to run on the forwarder/HF that runs the parsing pipeline, since nullQueue must be applied before the event hits the indexing queue. Use a REGEX string that's unique to the InTune path info inside the file (e.g. a script path fragment you mentioned you can already filter on) rather than anything generic, otherwise you'll null-queue legitimate transcripts too. If the transcript header/footer is consistent enough, matching against it is more reliable than matching mid-script content. 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @kaurinko  It sounds like there is still some parsing somewhere with the truncate not set, it might be that these are happening on a server sending the data to your indexer already parsed, or perhaps a sourcetype in an app which is overwriting the default?  I would start by running a btool on your indexers and HFs: /opt/splunk/bin/splunk cmd btool props list --debug | grep TRUNCATE Do you see any non-20000 values there? Secondly, are there any other hosts which could be sending parsed data that need this setting on?  You could run a search to look at the length of your data to find those events capped at 10,000 which might help narrow things down but its not the prettiest search: index=<yourIndex (or *)> | eval rawLen=len(_raw) | where rawLen=10000 Or something similar - this would find the events cropped to 10,000 and might help work out where it might be happening. 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @PaulaCom  case() returns the value for the first condition that matches, then stops, it never combines conditions, which is why the "both true" scenario collapses into whichever branch is listed first. Your second attempt also has a syntax error: case(manager = "NULL") isn't valid (case needs condition/value pairs), and there's a missing comma before 1=1. You could try to build the individual flags first with if(), then combine them: | table cn manager accountExpires mail | eval needManager=if(manager="NULL",1,0) | eval needExpiry=if(match(accountExpires,"(never)"),1,0) | eval action=case( needManager=1 AND needExpiry=1,"Set expiry date and manager", needManager=1,"Manager to be added to account", needExpiry=1,"Apply Expiry Date", 1=1,"no action required") | fields - needManager needExpiry   This evaluates both conditions independently first, so you can test any combination (including both true) explicitly, rather than relying on case()'s single-match, first-true behaviour. 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @Matt_Splunk  Which TA are you using? I would investigate the ability to update an existing incident rather than create a new one, or some other interaction using the app which proves the connectivity is in place and work, ie a custom command which searches or loads a SNOW event/incident? 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @kaurinko  collect writes a .stash file where each result becomes a block starting with a ***SPLUNK*** header line (carrying the marker/host/time/index metadata) followed by the field data, one block per event. When you leave the sourcetype unset, that file is indexed with the built-in "stash" stanza in, which already knows how to break on those ***SPLUNK*** block boundaries. When you set sourcetype=my_events_summary on collect, the stash file gets parsed at index time with your my_events_summary props stanza instead of the built-in stash one. That stanza has SHOULD_LINEMERGE = true and no LINE_BREAKER matching the ***SPLUNK*** markers, so it line-merges the whole file into one event, since nothing tells it where one collected result ends and the next starts. I would try and give it its own line-breaking rules that mirror stash's sourcetype props: [my_events_summary] SHOULD_LINEMERGE = false LINE_BREAKER = ([\r\n]+)(?=\*\*\*SPLUNK\*\*\*) TIME_FORMAT = %F\ %T(,|.)%3N%z NO_BINARY_CHECK = 1 That gives you the one-event-per-block behaviour under your own sourcetype name. 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @kaurinko  I know you've been able to find a workaround for this but just a heads up, that endpoint is deprecated and the docs label it as disabled - instead you should use the v2 url/endpoint for export, see https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.0/search-endpoints/search-endpoint-descriptions#:~:text=search/jobs/export%20(deprecated,Copy for more info. 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @hotrodbass  Firstly, I'd probably look at setting a search-time field extraction so you dont need the rex each time, but to answer your question, try adding a streamstats run-length counter on high_cpu, reset each time the value changes, then trigger only once the streak reaches 5: index=linux | rex field=_raw "(?<pctUser>[0-9]+(?:\.[0-9]+)?)\s+(?<pctNice>[0-9]+(?:\.[0-9]+)?)\s+(?<pctSystem>[0-9]+(?:\.[0-9]+)?)\s+(?<pctIowait>[0-9]+(?:\.[0-9]+)?)\s+(?<pctIdle>[0-9]+(?:\.[0-9]+)?)" | eval cpu_busy_pct=round(pctUser + pctNice + pctSystem, 2) | eval high_cpu=if(cpu_busy_pct >= 90, 1, 0) | sort 0 host _time | streamstats count as consecutive_count by host, high_cpu reset_on_change=1 | where high_cpu=1 AND consecutive_count>=5 | table _time host cpu_busy_pct consecutive_count   reset_on_change=1 makes streamstats restart the counter whenever high_cpu or host changes value on the next row, so consecutive_count is effectively "how many minutes in a row this host has been at this state". The sort 0 host _time before is neeeded because otherwise it would reset every minute as it gets a new value for each host,  streamstats relies on row order and interleaved hosts will corrupt the run-length count otherwise. Use consecutive_count=5 instead of >=5 if you want the alert to fire exactly once per breach rather than on every minute the outage continues, as with >= it'll re-trigger every minute unless you suppress it. This assumes one event per host per minute with no gaps. If a host can miss a minute of data you might need to use filldown or other technique to ensure you get the correct count. 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

If there is a genuine concern that someone could alter the SIEM's previously ingested data then you could use Ingest Actions to store a copy in S3 and apply lifecycle policy/object lock to prevent deletion. If you detect manipulation (ie corrupt bucket or someone using the delete command) then you have a source of truth. 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

I would agree largely with @PickleRick although I think the TIME_FORMAT should be TIME_FORMAT=%m%d%y%H%M%S because the sample 091326 is MMDDYY.   🌟Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @Matzi  As this is a Splunk supported app I think the best action would be to contact Splunk Support and raise a support case directly, this should then get allocated to the relevant team internally.  Unfortunately as a community forum we aren’t really able to report these, its better coming from yourself through the official support channels.    🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @kwagner001  The instructions, capabilities etc are in the Add-On (https://splunkbase.splunk.com/app/7538) within the Splunk app itself. I would recommend installing the app in a dev environment to give yourself access to the user guide, alternatively I believe you can get a PDF version from [email protected] 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @sirpatrick  Im not sure if this has changed since you posted yesterday but the app compatibility is showing as supporting Splunk Enterprise/Cloud 10.4 and 10.5     🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @poojas89  Did you follow the installation instructions on the Splunkbase app page at https://splunkbase.splunk.com/app/8308#Installation:~:text=Details-,Installation,-Troubleshooting ? If you are still struggling you could reach out to the developer using their Support email: [email protected] or raise an issue on the app GitHub repo at https://github.com/rootiq-ai/splunk_genai_observability   🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @Na_Kang_Lim  Data Manager is not available on Splunk Cloud Platform trial instances. For a trial environment, use the Splunk Add-on for Amazon Web Services app instead as @gcusello mentions   To set this up: Create an IAM User with programmatic access keys, and configure the user in the add-on under Configuration > Account. Set up an IAM Role containing the required CloudWatch read permissions, configured with a trust policy that allows the IAM User to assume it. If security is a concern regarding IAM users/keys, add an IP restriction condition (aws:SourceIp) to the IAM policy to restrict calls strictly to your Splunk Cloud outbound public IP addresses. This mitigates key exposure risks while still enabling the add-on to pull data. I believe trial stacks are a single SH so an nslookup/ping should resolve the external IP for you.    🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing. ... View more

Hi @sakib  Yes, this is typical behaviour - When indexers track a large number of distinct (host, source, sourcetype, index) combinations within a reporting window that exceeds squash_threshold, Splunk squashes host (h) and source (s) to blank values while preserving sourcetype (st) and index (idx). All high-cardinality traffic for those sourcetypes aggregates under the blank host row, which can easily total 100+ GB or more in a big environment.  Check out https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/license-usage-report-view/about-the-splunk-enterprise-license-usage-report-view#:~:text=Reporting%20Manual.-,Squashing%20fields,-Each%20license%20peer and https://community.splunk.com/t5/Monitoring-Splunk/Wrong-host-license-usage-report-squash-threshold/td-p/758518 for more info too.  If you want to try and work out where the data is coming from then you could look at: index="_internal" source="*license_usage.log" type="Usage" (h="" OR NOT h=*) | stats sum(b) as bytes by idx, st | eval gb = round(bytes/1024/1024/1024, 2) | sort - gb | table idx, st, gb Then use this to look at the index=<idx> sourcetype=<st> as a search to see where the data is coming from. 🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing.   ... View more

Hi @Magidi  Typically incorrect password 5 times in 5 minutes will trigger an account lockout. This is usually for 30 minutes. Please try again after the cooling off period and see if you can get in. If you’re still having issues I would recommend calling Splunk Support using your local Splunk support contact number (as trial stack won’t give you web support) and explain to them.  for more info check out https://help.splunk.com/en/splunk-cloud-platform/administer/manage-users-and-security/9.3.2408/manage-credentials-and-keys/configure-splunk-password-policies   🌟 Did this answer help you? If so, please consider: Adding karma to show it was useful Marking it as the solution if it resolved your issue Commenting if you need any clarification Your feedback encourages the volunteers in this community to continue contributing.   ... View more