Hi, I have the same issue but its not working for me.. I first created the lookup and save the search as a report, and then i need to edit my query to append ONLY new values. The current query does not push values at all.     index="rapid7_threat_intelligence" type="Domain" |table _time, source, type, value |outputlookup DOMAIN_IOC_ACTIVE.csv append=true | append [ | inputlookup append=true DOMAIN_IOC_ACTIVE.csv] | dedup value

Another sign something is not right - when I construct the database query as described in the Snowflake Integration blog post the resulting SQL string is completely malformed.   SQL string from the integration post:  SQL string results when I select the same options:  I am able to construct the SQL string using the selection options, however each selection takes another 4-5min to load. 

Hi @Rao_KGY , the code of your dashboard is correct (except the difference I already described), I don't see any reason because two equal searches give different results. Try to manually copy one on the other, maybe there's some char that we don't see. Ciao. Giuseppe

I just stumbled on this and thought I'd add a few other notes on this... with props.conf in the stanza "sourcetype" where this props.conf creates a field called "action". Just to confirm, how is the field being created? I'm assuming you mean a search time field as opposed to an index time field. Skimming the #Mimecast for Splunk app it looks like there are field aliases, and eval statements for different source types around the `action` field which are both search time... but I could be missing something. If you were instead referring to an index time transformation, not only is precedence order different, but also reingestion of data would need to happen before things take effect. Speaking of precedence order, probably time to mention that search time attributes use user / app precedence order as documented: https://docs.splunk.com/Documentation/Splunk/latest/Admin/Wheretofindtheconfigurationfiles#Precedence_within_app_or_user_context  Some effects of this is 1) your app needs to be lexographically after the app you're trying to override (precedence by name of other apps is reverse lexographic order as opposed to forward lexographic order) 2) your app needs to export the corresponding settings 3) even with all that done, your settings from other apps will lose if searches are being launched from within the mimecast app because the current app's settings gets highest precedence for the same stanza. (may or may not be an issue, I'm not familiar enough with the app to say, but it is a potential edge case).  Here's where we need to address something else:  Splunk Cloud doesn't allow using local folder Splunk Cloud doesn't let you upload an app with a local folder, however, Calculated fields, and field aliases are both editable via the UI, so you could actually create a local override within the context of the original TA itself via the UI and those would win. (since merging between default and local per app happens first with user/app context resolution order). No additional app needed necessarily (that gets into a long term management discussion).  @richgalloway already provided an alternative solution since within props.conf, there is an additional merging between stanzas for sourcetypes, hosts, and sources... But if course need to be careful with those since you could affect other sourcetypes too. From the props.conf.spec: **[<spec>] stanza precedence:** For settings that are specified in multiple categories of matching [<spec>] stanzas, [host::<host>] settings override [<sourcetype>] settings. Additionally, [source::<source>] settings override both [host::<host>] and [<sourcetype>] settings. In either case once settings are in place on the search head, they need to be replicated to your indexers as part of the knowledge bundle before they can take effect during a search... So if you're already over the 3GB limit there need to spend some time trimming the bundle size.  Seeing resolved search time precedence can be done per stanza with the properties rest endpoint on the search head, and/or the btool command. (make sure to specify the appropriate `--app` and `--user` context for correct resolution order of search time values).  (And before you say but btool is an enterprise only command.. I may have brought it to Cloud as a SPL command along with a knowledge bundle utility in Admins Little Helper for Splunk ... my officially unsupported but I think its useful side project Check it out on Splunkbase: https://splunkbase.splunk.com/app/6368 </shameless plug> )  Hope these notes help you and others in the future.

@skalliger wrote: How did I find all of that? I have developed an app which gives an overview of the Splunk environment's mitigation status against current Splunk Vulnerabity Disclosures (SVDs) as well as recommended best practice encryption settings.  Nice work @skalliger . Is this app publically available? I would be interested in this functionality.

You should look at the _internal index size before changing it   | dbinspect index=_internal | stats sum(sizeOnDiskMB)    In our setup with 30 days of internal index, size of file is 680GB.  So double the time, double this file. As you see above, I posted a dashboard uses _telemetry index instead to see index uses.  Our telemetry index is 215 MB of size.  We have change  _telemetry to 20 years, since it does not take up much space:   [_telemetry] # This is 20 years to get longer historical license useage. frozenTimePeriodInSecs = 788400000    

Hi @Rao_KGY , good for you, see next time! let us know if we can help you more, or, please, accept one answer for the other people of Community (even if your answer). Ciao and happy splunking Giuseppe P.S.: Karma Points are appreciated by all the contributors