@Stem Most probably, the user-seed file is not being parsed, likely due to syntax, or permissions. You may review the Splunkd logs to figure out the issue. Make sure to follow the below syntax for the user-seed.conf file. Any deviation (extra spaces, wrong section header) will cause Splunk to ignore it. [user_info] USERNAME = admin PASSWORD = <yourpassword> Confirm the Splunk service account has read access to the file. On Windows, run Splunk as Administrator during installation or startup. Ref:  user-seed.conf | Platform (last updated 2026-01-13T21:03:58.807Z) >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@Ka2 I would suggest you to review logs under /var/log/phantom/ especially playbook.log, for parsing or sync errors. Could you confirm whether you’ve tried importing the playbook via the Playbook Editor or registering it through the REST API? Instead of manual placement of file, can you try to import the playbook by using the /rest/import_playbook API as described in the documentation, or use the Import Playbook icon in the Splunk SOAR user interface. This ensures that the playbook is properly processed and configured in the system.  Ref: REST Playbook | Splunk Enterprise, Splunk Cloud Platform (last updated 2026-02-04T21:29:11.870Z) Export and import playbooks in Splunk SOAR (Cloud) | Splunk Enterprise, Splunk Cloud Platform (last updated 2026-02-04T21:30:34.086Z) >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@manchou0709 The REST endpoint only returns accurate client data when queried directly from the Deployment Server since that is the authoritative source for forwarder phone‑home data. So, running it on other search heads will either give no results or mix in hosts from different environments. The best way to get disconnected hosts is to run the query on the DS itself and then share or summarize those results into a new summary index and share across your other Splunk instances if you need wider visibility. Use collect command for this purpose at the end of existing query in DS. Refer documentation for advanced options if you want to enhance the summary index collection. | collect index=uf_status Once that scheduled search is in place on the deployment server, other search heads can simply query the summary index to see the disconnected forwarders without hitting the DS REST endpoint themselves. This ensures you are always working from the authoritative source while still giving visibility across multiple Splunk environments. Ref: collect | Splunk Enterprise (last updated 2025-07-04T01:27:46.382Z) >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@manchou0709 Query looks good. The behavior you are seeing comes down to how Splunk’s Forwarder Management UI calculates and labels status versus what you are deriving in SPL. The REST endpoint gives you raw fields like lastPhoneHomeTime, but it doesn’t expose the same "agent: offline" flag. The UI applies its own heartbeat logic and categorization, so when a forwarder misses a check‑in it may be marked as "in error" rather than "offline", depending on timing and internal thresholds. That’s why your SPL correctly identifies forwarders that haven’t phoned home for 10+ hours, but the UI shows them under "in error" and the offline count keeps changing as forwarders reconnect or miss intervals. In short, your query logic is fine, what you’re seeing is simply a difference in how the UI interprets missed check‑ins versus how your SPL calculates elapsed time. If you want closer alignment, you might need to match your threshold to the deployment server’s configured phone‑home interval, but you won’t be able to reproduce the exact "offline" label since that’s generated internally by Splunk. Hope it clarifies. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@acisac Since you’re running Splunk ES in an all‑in‑one Windows VM, that is a perfectly valid way to get familiar with the product and explore its capabilities. Just keep in mind that it's not recommended to keep Windows as a long‑term platform for Enterprise Security in production, so performance and scalability will be limited compared to a Linux‑based deployment. For evaluation purposes though, you will be able to see how correlation searches, dashboards, and investigations work. As you progress, I would encourage you to spin up at least one Linux VM for the core Splunk components and keep Windows VMs for forwarders, since that will give you a more realistic sense of how ES behaves in a supported architecture and help you avoid surprises when you move beyond proof‑of‑concept. Hope it clarifies. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@joshuaswink It looks like a session handling issue between Splunk DB Connect and Snowflake JDBC driver. You could try the below steps with the limited info you shared: [Test the below in dev or staging first before trying in prod] Enable DEBUG logging for DB Connect to confirm whether the issue is with connection reuse or any other issues. This is important from troubleshooting perspective to understand the root cause. If you see compatibility issues on debug logs, update the Snowflake JDBC driver to the latest version (v1.2.4) supported by DB Connect. Make sure to keep the DB Connect version is updated and compatible. Test in staging or dev first. Consider lowering maxConnLifetimeMillis to force connections to refresh more frequently and avoid stale sessions. Consider reducing idle connections so sessions don’t get stale. Review respective settings in reference documentation I shared. If the problem persists, raise a support case with Splunk sharing the debug logs and error we observed for faster troubleshooting. Ref: db_connections.conf.spec | Splunk Enterprise, Splunk Cloud Platform (last updated 2025-09-02T22:34:04.325Z) >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@theboss This app was built by Checkpoint itself, and the latest app version released almost two years ago where Splunk version 10 was not released at that time, hence not showing in compatibility section. I don't have a use case for Checkpoint specific, but general approach which I follow is to test it in our Dev splunk setup running with v10 and run the app inputs there to test for any errors related to Splunk version. You may also follow similar approach. Thanks. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@KevHaze   Perfecto, you're welcome! ... View more

@MJ_27 You can reliably get the last updated time, but not the original creation time. If you know roughly when they were created, you might be able to confirm with audit or config tracker data, but otherwise there isn’t a native field that records creation. This is a known limitation, and many admins rely on version control systems or change‑management processes to track when correlation searches were first introduced. Hope it clarifies. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >>   ... View more

@nongingerale Quick clarification, are your searches being launched directly from SOAR playbooks? or are you trying to monitor searches that were initiated independently in Splunk? That distinction will determine how to approach this. Since you mentioned REST API polling method, this is applicable if you want SOAR to monitor searches that were started outside of SOAR, you can use an HTTP connector action in your playbook to call the Splunk REST API, and configure the loop setting on that block to keep checking the job status until it reaches the state you care about. For this use case, you can query the job status endpoint using below format: https://<host>:<mPort>/services/search/jobs Playbook design flow: In a Splunk SOAR playbook, the flow to check whether a Splunk search has completed can be designed around the search job ID (sid). The playbook begins by capturing the sid of the search you want to monitor, then uses an HTTP action block to call Splunk’s REST API endpoint /services/search/jobs/{sid}. The response includes fields such as dispatchState and isDone, which indicate whether the search is still queued, running, or finalized. By enabling the loop setting on the HTTP action block, the playbook can keep polling this endpoint until the job reaches the desired state (for example in your case, dispatchState=DONE). Once the search is complete, the playbook continues to the next task, such as fetching results or triggering downstream task. Hope it helps. Reference: Search endpoint descriptions | Splunk Enterprise, Splunk Cloud Platform (last updated 2026-01-10T00:42:31.558Z) >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@acisac One thing to clarify - are you aiming for a quick all-in-one evaluation where everything runs inside a single Windows VM, or do you want a realistic testbed that mirrors production architecture? If it’s the former, you can install Splunk Enterprise and ES on Windows, but you should expect reduced performance. If it’s the latter, I would recommend at least one Linux VM for the Splunk platform components and then use Windows VMs for forwarders to simulate data ingestion. This way, you’ll get a more accurate sense of how ES behaves in a supported environment. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@detrue - One point I would like to clarify with you is what’s the reason for logging into the indexer’s UI to add data? In most Splunk distributed deployments, data ingestion is typically handled by forwarders or heavy forwarders, and indexes are created on the indexers for storage. The Add Data wizard is usually run on a search head or a standalone heavy forwarder during testing or small-scale ingestion, not directly on an indexer. To make custom indexes selectable, you need to deploy the same indexes.conf stanzas to the SHC via the deployer so that the UI is aware of them or create a new index locally on the standalone Heavy forwarder instance to properly map it since the indexes you define on Indexer Cluster won't get propagated to other layers in a Splunk distributed environment.  >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️  Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@spl_aficionado Just to bring clarity to this and good observation. When a deployment client connects to the deployment server, Splunk checks the checksum of every app package in the serverclass. If the checksum differs from what the client already has, the app is redeployed. So, after a DS bounce, the clients re‑establish their connection and the DS re‑evaluates all serverclass packages, which can look like a full redeploy cycle. In reality, only apps whose checksums have changed since the last connection are actually pushed, but because the DS has restarted and lost its cached state, it re‑runs the comparison for every app. Hope it clarifies. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@imsidrai  Federated search can definitely be set up one‑way from on‑prem to Splunk Cloud, since the local search head initiates the outbound connection to the Cloud management port (8089) and no inbound traffic from Cloud into your on‑prem environment is required, which matches the security restrictions you mentioned. Since the federated search only connects Splunk to Splunk, so while it lets you query Cloud data from your on‑prem instance, it doesn’t provide DB Connect‑style outputs. As you mentioned, DB Connect isn’t supported in Splunk Cloud, you can try this workaround to run federated searches from your on‑prem Splunk (where DB Connect is supported) and then use DB Connect locally to insert results into your database. If you want to handle this entirely from Cloud, you’d need to rely on the Splunk REST API to pull search results and then script the database insert logic yourself, including a rising column or checkpoint mechanism to avoid duplicates. In short, federated search solves the Splunk‑to‑Splunk connectivity piece, but the DB output workflow still has to be handled on‑prem or via custom API scripting. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@ra_52194724 - You can set up custom props.conf  so that Splunk automatically extracts both the hostname and job_id from the description field, then derive core_key from job_id. This will be like creating an EXTRACT- stanza with respective regex pattern which will pull out the values, and then you can add an EVAL stanza to compute the core_key field automatically. That way, every event of that sourcetype will have hostname, job_id, and core_key available without needing to run rex in your searches. Use regex101, my personal favorite for building regex. regex101: build, test, and debug regex Hope this helps. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >>   ... View more

@KevHaze The error you pointed out is not connected to version compatibility. It means the app archive isn’t packaged the way Splunk Cloud expects. Cloud validation requires the tarball to have exactly one top‑level directory (for example Splunk_TA_vmware/) containing all the app files.  Solution: Splunk VMWare app and add-on cannot be installed from the GUI. These binaries need a different type of installation, and that is documented in the link below: Install the Splunk App for VMware - Splunk Documentation Refer this knowledge article from Splunk which might help in addressing your issue. Error installing Splunk App for VMware: "There was an error processing the upload.Invalid app contents: archive contains more than one immediate subdirectory: and Splunk_TA_esxilogs" | Splunk >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@icarvaja - Since you already ruled out common issues, I would suggest you upgrade your MCP Server app to latest version 1.0.4 from Splunk base as it fixed certain issues. I suspect the issue related to the mcp_tool_execute role is addressed in the latest version. After upgrading, retest the mcp-remote client against the 8089 endpoints with your encrypted token. If issues persist, check splunkd.log for MCP‑related errors, as the app should expose SSE out of the box once correctly installed and enabled. App link: Splunk MCP Server | Splunkbase Hope it helps and keep us posted. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@MichaelRTR As per your use case, this is essentially a cron‑aware monitoring problem, but Splunk Observability detectors are built on SignalFlow, which operates on metric streams and time windows. Try the below approaches: Use SignalFlow which supports calendar window transformations (e.g., when(hour >= 13 and hour < 14)), which can approximate cron‑like checks. You can define detectors that look for job_event=START within those windows. For scaling, instead of creating separate detectors per job, consider templated detectors or Terraform automation (signalfx_detector resource) to generate detectors programmatically. SignalFX - Splunk terraform terraform-provider-signalfx/docs/resources/detector.md at main · splunk-terraform/terraform-provider-signalfx · GitHub Signalflow https://dev.splunk.com/observability/docs/signalflow/ >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️   Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@splunkreal Yeah, no new versions would be released by Splunk for this add-on going forward. For the current version, it would work with all the compatible versions listed in the previous screenshot. You can refer to the archival doc for more details. App archival | Documentation | Enterprise | Splunk Developer Program ... View more

@Alberto_Astolf1 Okay, couple of things which might be worth checking in that case. Make sure the modified inputs.conf  is in the correct directory (local vs default) within the app. Misplaced files can prevent the DS from packaging them correctly. Confirm that the forwarders not reflecting updates are still members of the intended server class. If they’re not, they won’t receive the updated app. Check the logs in $SPLUNK_HOME/var/log/splunk/splunkd.log on the DS for DeploymentServer activity to confirm it registered the app change and attempted distribution. On the UF side, look in splunkd.log for deployment entries. If you see regular phone‑home messages but no app update, that suggests the DS didn’t flag the app as changed. If you're unable to figure out still, highly recommend raising a support case with the Splunk support by providing them related log files for effective troubleshooting. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details ✏️ Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >> ... View more

@Alberto_Astolf1 - By default, the Universal forwarder (UF) contacts the Deployment server every 60 seconds to check for & download updated configurations, also known as phone home interval in splunk terms. You can verify the interval part from deploymentclient.conf under the "phoneHomeIntervalInSecs" parameter. On your second question, to verify the phoning activity in UF side, you should check the splunkd.log file located under $SPLUNK_HOME/var/log/splunk/ location. The deployment client writes messages tagged with DC:DeploymentClient whenever it connects to the Deployment Server, checks for updates, or downloads new configurations. Searching this log for keywords like phoneHome, DeploymentClient etc will show the exact timestamps of each check-in and update operation.  For additional confirmation, you can run $SPLUNK_HOME/bin/splunk btool deploymentclient list --debug to display the effective configuration on the UFs and confirm the current interval setting. Hope this helps. >> If this post addressed your question, you can: Give it karma to show appreciation 👍 Mark it as the solution if it solved your issue ✔️ Add a comment if you’d like more details  ✏️   Acknowledging helpful answers keeps the community strong and motivates contributors to continue sharing their expertise. >>   ... View more