Hi @mike_k  Regarding the coldToFrozenDir vs coldToFrozenScript, teh primary advantage of coldToFrozenScript is the ability to manipulate the data before archiving. Splunk provides an example Python script ($SPLUNK_HOME/bin/coldToFrozenExample.py) that compresses the buckets by removing the index files and gzipping the raw data. coldToFrozenDir simply moves the uncompressed bucket directory as-is, which consumes significantly more storage space. If coldToFrozenDir fails (e.g., due to a permissions issue or the destination disk being full), Splunk will continuously retry moving the bucket. When it comes to Local Drive vs Remote File Share (NFS/SMB) there may be trade-offs to be had here in terms of cost vs reliability. Writing to a locally attached drive (or block storage presented locally) avoids network latency and mount stability issues and I would personally consider high reliability, for a Remote File Share, If a NFS mount drops, hangs, or becomes latent while Splunk is attempting to freeze a bucket then it could cause the bucket-rolling threads to hang and have a knock-on affect through you indexers. CIFS/SMB is generally not recommended or supported for Splunk storage on Linux as is only supported on Windows. If you are already archiving to tape over time, using a locally attached drive as a staging area for frozen data is probably the safest and most resilient approach. Its worth nothing that if the frozen destination becomes unavailable or fills up, Splunk may not be able to freeze the buckets and then these buckets will remain in the cold database, eventually causing your cold partition to fill up and could halt indexing.  Remember that you will need to thaw frozen data prior to searching it again in the future, you cannot just copy the frozen files back to the cold DB directory. 🌟 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 @Kaitsu  The duplication of events here is expected if running the SCOM inputs on multiple HF - If you need HA then I would suggest having the secondary prepared but with the modular input turned off.  Regarding your search issue - are all the events the same sourcetype? Are you able to identify any distinction between the different hosts which do and do not get the enrichment?  🌟 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