An even longer answer: How can search head know who is viewing and which time zone each user prefers - if not from user preference? By the end of day, this is not a technical question, but a design question.  As you stated, you have a global workforce, implying that you cannot force everyone to accept Eastern US time.  Is this correct?  If it is, you need to ask yourself: What is the reason why you cannot allow those special users to set their preference? If there is a good reason for 1, the second question is: Will a dashboard selector be acceptable? One way or another, you need to give your global workforce a method to tell search head their preference.  After the user makes a selection, then yes, there is a way to display specific time zone.

Thank you for describing your SOC workflow.  Yes, that can be implemented.  The question remain about your dataset including content of the lookup (whitelist), maybe also the procedure used to produce this lookup.  One particular aspect is characteristics of  sourcetype="ironport:summary" and sourcetype="MSExchange:2013:MessageTracking". How frequently are they updated respectively? Is one extremely large compared with another? How does each sourcetype, and each lookup contribute to the workflow you are trying to implement?  Do they play similar role or differing roles?  In other words, describe your workflow in terms available data. Which fields in each are of particular interest to SOC analyst?  Which field(s) from which source contains sender domain, which contains known domain, for example? What each of lookups contain?  How are they of interest to SOC analyst? There are a lot of miscellaneous fields in the code sample, e.g., file_name.  Do they materially contribute to the end results?  If so, how? A technical detail is macro `ut_parse_extended()`.  What does it do? (Which input fields does it take - explicit inputs are senderdomain and list, obviously but an SPL macro can also take implicit inputs, and which output fields does it produce/alter?) Another macro `security_content_ctime()` also invoked twice.  What does this do? Additionally, is your main goal to improve performance (join is a major performance killer as @PickleRick points out), or to improve readability (hence maintainability)? These two do not necessarily converge as join is better understood in many circles.

Thank You very much @gcusello  OK that I go for _internal retention from 30 to 60 days. But when I open - "Open In Search" - the two first dashboards, the code is as below Daily License Usage index=_internal [`set_local_host`] source=*license_usage.log* type="RolloverSummary" earliest=-30d@d | eval _time=_time - 43200 | bin _time span=1d | stats latest(b) AS b by slave, pool, _time | timechart span=1d sum(b) AS "volume" fixedrange=false | join type=outer _time [search index=_internal [`set_local_host`] source=*license_usage.log* type="RolloverSummary" earliest=-30d@d | eval _time=_time - 43200 | bin _time span=1d | dedup _time stack | stats sum(stacksz) AS "stack size" by _time] | fields - _timediff | foreach * [eval <<FIELD>>=round('<<FIELD>>'/1024/1024/1024, 3)] Percentage of Daily License Quota Used index=_internal [`set_local_host`] source=*license_usage.log* type="RolloverSummary" earliest=-30d@d | eval _time=_time - 43200 | bin _time span=1d | stats latest(b) AS b latest(stacksz) AS stacksz by slave, pool, _time | stats sum(b) AS volumeB max(stacksz) AS stacksz by _time | eval pctused=round(volumeB/stacksz*100,2) | timechart span=1d max(pctused) AS "% used" fixedrange=false As you see, there are " earliest=-30d@d" in both of them, two in the first dashboard and one in the second. I guess I need to set those to " earliest=-60d@d".  Otherwise, extending the retention to 60 days, would have any value ? best regards Altin

Quick glance over this app (haven't downloaded it and looked into internals, just relying on the docs) suggest that this app is simply badly written. It aims at downloading some data from the Bloodhound service (whatever that is) and putting that data into an index. The problem is that the authors of this app probably have never seen something more complicated than a single-server Splunk installations. Also even the destination index seems to be hardcoded (or at least provided by default and not docummented as configurable). So I wouldn't be surprised at all if thw app used kvstore for whatever it needs to use it for.

I followed all of the steps and I'm not seeing anything in Splunk for these email logs. Doing | sendemail also did nothing. Some alerts work perfectly fine but others don't. Configuration is identical too. 

Try this: ```Gets the original timestamp. In this case it's when the latest data was ingested into Splunk. The friendly time will be in YOUR LOCAL time zone set in Splunk preferences.``` index=something sourcetype=something | stats latest(_time) as LATEST_DATA_PULL_TIME | eval LATEST_DATA_PULL_TIME_friendly_local=strftime(LATEST_DATA_PULL_TIME, "%m/%d/%Y %I:%M:%S %P") ```Sets the TARGET time zone.``` | eval to_tz="US/Eastern" ```Converts timestamp to friendly showing YOUR LOCAL time zone, then replaces YOUR LOCAL time zone with the TARGET time zone, then converts the time back into epoch. This creates a new epoch timestamp which is shifted by the difference between YOUR LOCAL time zone and the TARGET time zone.``` | eval LATEST_DATA_PULL_TIME_tz_replaced=strptime(mvindex(split(strftime(LATEST_DATA_PULL_TIME, "%c|%Z"), "|"), 0)+"|"+to_tz, "%c|%Z") ```Calculates the difference between the original timestamp and the shifted timestamp, essentially returning the difference between YOUR LOCAL time zone and the TARGET time zone, in seconds.``` | eval time_diff=LATEST_DATA_PULL_TIME-LATEST_DATA_PULL_TIME_tz_replaced ```Increses the original timestamp by the difference calculated in the previous step, and then converts it to friendly time.``` | eval LATEST_DATA_PULL_TIME_tz_corrected_friendly=strftime(LATEST_DATA_PULL_TIME+time_diff, "%m/%d/%Y %I:%M:%S %P")

Hi @gcusello , The kv-store isn't usable in the SHs.  The original ask was to take the items in the kv-store and create an alert for each item.  Since the kv-store gets recreated every 4 hours, this would cause alert duplication which we wanted to avoid.  I added another kv-store on the HF that contains a hash of the values in the items and then check to see if an item is new or already exists in the kv-store.  If new, an alert.  If not, it gets dropped.  The analysts decided they wanted to have the kv-store copied to the SHs they use.  Thus the original question since they don't have access to the HF.  Currently the best suggestion is to output the kv-store as a csv, scp it from the HF to the SHs, and load it into a local kv-store. Regards, Joe

Hi @jwhughes58, I'm not sure that a kv-store, created in a HF, is usebla from a Search Head: kv-store must be located in SH. On HF, you should locate the inputs.conf, the props.conf and the transforms.conf, not the other parts of the app. Ciao. Giuseppe