Hi @dilipkha, Under the hood, Boost calls getaddrinfo on Linux, which should accept IP addresses as strings. When I compile the example with g++ 8.5.0 and Boost 1.66.0 on my RHEL 8 host, the program works as expected using http as the service:   $ g++ -o sync_client -lboost_system -lpthread sync_client.cpp $ chmod 0775 sync_client $ host httpbin.org httpbin.org has address 23.22.173.247 httpbin.org has address 52.206.0.51 $ ./sync_client 23.22.173.247 /get Date: Sun, 28 Jan 2024 04:47:22 GMT Content-Type: application/json Content-Length: 225 Connection: close Server: gunicorn/19.9.0 Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true { "args": {}, "headers": { "Accept": "*/*", "Host": "23.22.173.247", "X-Amzn-Trace-Id": "Root=1-65b5dc5a-2e13219829bcecc360851dcb" }, "origin": "x.x.x.x", "url": "http://23.22.173.247/get" }   In your implementation, you may need to use a different query constructor on line 35, e.g.:   tcp::resolver::query query(argv[1], "8089", boost::asio::ip::resolver_query_base::numeric_host | boost::asio::ip::resolver_query_base::numeric_service);   Note that I've also replaced "http" with "8089" to use the default Splunk management port. On most systems, the http service resolves to port 80. See e.g. /etc/services.

At a glance, it's a score calculated from _audit data based on search run time, the absence of an index predicate, the presence of prestats transforming commands, the position of other transforming commands, memory use, and the presence of an initial makeresults or metadata command. Pain is inversely proportional to efficiency. @sideview may be lurking. Have you tried contacting them directly?

Hi @klim, I don't have an active IdP to validate, but as I recall, you would specify your preferred mapping as the Name ID format/attribute in the SAML IdP and not in the SAML SP (Splunk). Home directories can be managed at the file system level in $SPLUNK_HOME/etc/users by renaming directories. Ownership of most knowledge objects can be changed from Settings > All Configurations > Reassign Knowledge Objects. For the few objects that can't be reassigned via the user interface, you'll need to update all instances of $SPLUNK_HOME/etc/apps/*/metadata/*.meta as needed.

The scheduled alert should be owned by a user with access to the app and (probably) be saved within the app. Their access to Splunk should have no bearing on whether they can access MIME attachments in their email client; however, they may not not be able to access any links you include. The CSV file will be an attachment, not a link.

Hi @Splunkanator, If your events have an extracted uri_query field, which is typical for e.g. NCSA and W3C log formats, you can use != or NOT to exclude events: index=main sourcetype=access_common uri_query!=*param=X* uri_query!=*param=Y* uri_query!=*param=Z* or index=main sourcetype=access_common NOT uri_query IN (*param=X* *param=Y* *param=Z*) However, those will exclude events with partially matching names or values. Performance will vary, but you can use the regex command to match events with fields that do no match a regular expression: index=main sourcetype=access_common | regex uri_query!="(^|&)param=(X|Y|Z)(&|$)"

Ah, you are correct. "name" is the relative distinguished name (RDN) of the object. If the object's distinguished name is CN=foo,DC=example,DC=com, the name value should be foo. accountExpires is a valid attribute in my Windows Server 2022 Active Directory environment. A slightly modified version of the search works for me: | ldapsearch search="(&(objectClass=user))" attrs="name,accountExpires" What other information can you provide about your Active Directory environment?

Hi @tv00638481, Make sure Splunk Add-on for Salesforce is installed on the search head and verify the lookup_sfdc_usernames KV store lookup definition is shared globally and accessible to everyone who needs to use Salesforce App for Splunk. Also make sure the Lookup - USER_ID to USER_NAME saved search is enabled and scheduled. This is the search that populates the lookup. To improve performance, modify the saved search to user your Salesforce index instead of index=*. Splunk normally uses macros to specify indexes, but that was overlooked in this add-on.

No. I suggest follow up with your account team so they can see what values you are comparing and ensure they are accurate. (Or post what actual values you are looking at. All your storage forecasting should be is how much RAW data do you ingest a day, mulltipled by how many days you want to store in searchable + archive,  and does that fit into your DDAS and DDAA entitlement? Splunk Cloud service takes care of the rest.  No compression math at all vs on-prem days.  

I think u mean DDAA (dynamic data active archive) is archive storage (cold storage), and no we don't only store compressed raw data.  Whole bucket goes to archive storage then us copied back into object store upon restore. DDAS (dynamic data active searchable) is basically "smartstore".  Customers using ddas and ddaa only need to care about the raw size, not compression. Compression doesnt come into play with splunk cloud entitlements, so the old onprem math doesnt apply. now depending on what data hes actually looking at, he may or may not be seeing compressed buckets, but more often it comes down to understanding when buckets will actually roll due to timestamps in the bucket. overall in splunk cloud all you care about is raw data size as you are not sizing disk in cloud, u are sizing your subscription. https://docs.splunk.com/Documentation/SplunkCloud/9.1.2308/Service/SplunkCloudservice see storage section

Thank you for the response. You mean to say the daily ingested  data is compressed whenever it is coming to online active storage due to the reason , I'm only noticing a difference of ~60GB on day 2 day basis.is my understanding correct.