About upgrading to 10.2 READ THIS FIRST

Read about changes in behavior to note for Splunk Enterprise and Splunk Universal Forwarder when you upgrade to version 10.2.

Lower or higher versions of this topic might present different information than the information for your target version. Use the Version drop-down list to choose the product version to which you're upgrading.

Administrators and advanced users can review changes to the .conf and .conf.spec files by using the Compare feature on different branches of the files in the jewnix/splunk-spec-files GitHub repository. Splunk thanks David Twersky (jewnix) for providing and maintaining this repository, and links to its contents with his permission.

For general instructions on how to upgrade Splunk Enterprise, see How to upgrade Splunk Enterprise.

Splunk App and Add-on Compatibility

Not all Splunk apps and add-ons are compatible with Splunk Enterprise version 10.2.

  • See the Splunk products version compatibility matrix for information about which versions of Splunk IT Service Intelligence and Splunk Enterprise Security are compatible with this version of Splunk Enterprise.
  • You can visit Splunkbase to confirm that your apps and add-ons are compatible with this version.

If your app or add-on is not compatible with version 10.2, consider delaying your upgrade until a compatible version is available.

Key points for upgrading to version 10.2

The following is a list of important items that you must consider before you upgrade Splunk Enterprise and its components. The sections that follow provide supporting details for these key points. Read through all sections in the topic before you begin your upgrade activities.

  • Updates included in Splunk Enterprise 10.2 that address certain Common Vulnerabilities and Exposures also render select older Linux distributions incompatible with Edge Processor on Splunk Enterprise. Attempting to upgrade your data management control plane to Splunk Enterprise 10.2 while running edge processors on an unsupported operating system will cause your edge processors to crash, resulting in data loss. Users must upgrade the operating system running their data management control plane and edge processors to a supported version prior to upgrading their data management control plane and edge processors to Splunk Enterprise 10.2. See Installation requirements for Edge Processors for an updated list of supported Linux-based operating systems.
  • Back up all KV store databases prior to upgrading Splunk Enterprise. For information about backing up your KV store, see Back up and restore KV store in the Admin Manual.
  • entry
  • Use the Splunk Products version compatibility matrix to ensure that any premium Splunk apps and add-ons you run are compatible with version 10.2. If they are not, do not upgrade until compatible versions become available.
  • See How to upgrade Splunk Enterprise for information on supported upgrade paths to Splunk Enterprise 10.2.
  • Splunk supports a direct upgrade from UF 10.0.x and higher to UF 10.2.
  • To upgrade search head or indexer clusters, see Follow specific instructions to upgrade clusters later in this topic.
  • If you run Linux machines that use the second extended (ext2) file system, upgrade that file system to third extended (ext3) prior to starting an upgrade.
  • If you use Azure remote storage and config fields remote.azure.tenant_id / remote.azure.client_id, take one of the following actions before you upgrade:
    • Add remote.azure.tenant_id / remote.azure.client_id fields to the [general] encrypt_fields list in server.conf.
    • Change remote.azure.tenant_id / remote.azure.client_id fields to clear values.

  • In a clustered environment, the Postgres ports must be available to all other members, or SPL2 will not be available. For more information, see Network requirements.

  • You can opt in to use Python 3.13 instead of Python 3.9. Splunk platform still uses Python 3.9 by default, but Splunk Web uses Python 3.13 only. For more information, see Python compatibility in Splunk apps.

Important change to configuration management

Starting with Splunk Enterprise 9.4.x, additional configuration files are now dynamically updated by Splunk software as a consequence of normal system operation. Newly added Splunk sub-processes, also known as sidecars, now dynamically register HTTP endpoints at runtime.

What's new
To support this dynamic registration of HTTP endpoints specific to sidecar processes, Splunk software will now dynamically write to system/local/web.conf and system/local/restmap.conf files during runtime.
Impact on cofiguration management tools:
If you use external configuration management tools such as Puppet, Ansible, or similar systems to manage your Splunk software configurations, especially in the system/local directory, you might experience instability or restart loops. These tools may detect the dynamic changes made by Splunk to system/local/web.conf and system/local/restmap.conf and attempt to revert them, leading to conflicts and operational issues.
Recommended action:
To avoid conflicts and ensure stable operation after upgrading to Splunk Enterprise 9.4.x or higher, it is crucial to note that you can manage system/local/web.conf and system/local/restmap.conf using external configuration management tools, so long as the tools accept that some portion of these files may be asynchronously edited by Splunk software. These files are now dynamically managed by Splunk software. Please adjust your configuration management practices accordingly for these specific files. Additionally, be aware that the ordering of stanzas within these dynamically written configuration files is not guaranteed by Splunk software.

Changes that can potentially break Splunk Enterprise installations

There is no supported method for rolling back an installation to a prior release. Follow the guidance for these critical items to avoid breaking your existing installation during an upgrade.

Updated Linux distribution support on Splunk Enterprise affects Edge Processor on Splunk Enterprise support

Applicable components: Splunk Enterprise, Edge Processor on Splunk Enterprise

Applicable OSes: Linux
Version introduced: 10.2
Upgrading to Splunk Enterprise 10.2 includes security updates that address specific common vulnerabilities and exposures (CVEs) but also make certain older Linux distributions incompatible with Edge Processor. If you upgrade your data management control plane to Splunk Enterprise 10.2 while edge processors are running on unsupported Linux versions, those edge processors will crash, and data loss can occur. To prevent this, update the operating systems on all management nodes and edge processor instances to a supported Linux version before upgrading to Splunk Enterprise 10.2 on those machines. Refer to the Installation requirements for Edge Processors for the latest list of supported Linux-based operating systems. Operating systems on machines that Edge Processor does not use do not need updates.

Splunk Enterprise no longer lets you run it as the root user by default

Applicable components: Splunk Enterprise

Applicable OSes: *nix
Version introduced: 10.2
On *nix machines, Splunk Enterprise no longer lets you run it as the root user by default. When you attempt this, the instance fails to start with an error message to that effect.

To work around the problem temporarily, you can specify the --run-as-root CLI argument when you start the instance:
$SPLUNK_HOME/bin/splunk start --run-as-root
Best practice is to not run Splunk Enterprise as the root user.

Splunk Enterprise on Windows no longer lets you install it as a local administrator or domain user by default

Applicable components: Splunk Enterprise

Applicable OSes: Windows
Version introduced: 10.2
As part of an overall effort to improve security, Splunk has removed the ability to install Splunk Enterprise on Windows as either the local administrator or a domain user. This means that if you have installed Splunk Enterprise on Windows as the local system or a domain user previously, the installer now installs Splunk Enterprise as the NT Service\splunkd service user.

You can retain your existing user configuration by supplying the INSTALL_AS_ADMINISTRATOR=1 argument for the msiexec installer utility during an upgrade. It is also possible to use this argument for new installations of Splunk Enterprise but this functionality will be removed in a future release.

To learn more about this significant change, see the following topics:

The Splunk platform uses version 3.13 of the Python runtime environment on Splunk Web

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 10.2
The Splunk platform now uses version 3.13 of the Python runtime environment for Splunk Web functions.

The Node.js JavaScript runtime environment has been removed

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 10.2

Splunk has removed the Node.js runtime environment, which it deprecated in version 10, from Splunk Enterprise as of version 10.2. This means that apps that require Node.js will no longer run. If you use or make an app that runs Node.js, then the app must include its own build of the Node.js runtime on Splunk 10.2 and higher.

Updates to Fishbucket

Applicable components: Splunk Enterprise

Version introduced: 10.2

In Splunk Enterprise 10.2, a database back end for the Fishbucket, a repository used to store file-monitoring checkpoints, was replaced with a more reliable back end.

If you are upgrading from earlier Splunk Enterprise versions, you do not need to take any action. No explicit or implicit migration is required. After the upgrade, Splunk Enterprise will continue to read existing file checkpoints from the legacy Fishbucket database. Going forward, it will write new checkpoints to and read new checkpoints from the new repository.

This information is provided because downgrading from Splunk Enterprise 10.2 to an earlier version is not officially supported. Customers who choose to downgrade may lose checkpoints that were created after the upgrade. As a result, file-monitoring state might revert to the checkpoint position that existed prior to the upgrade, which can lead to partial re-ingestion of files and potential event duplication.

Support for version 3.7 of the Python runtime environment has been removed

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 10.0

Splunk has removed support for version 3.7 of the Python runtime environment. Confirm that any apps and add-ons that use Python can work with version 3.9 of the interpreter before starting an upgrade.

Hadoop Data Roll has been turned off by default

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 10.0

Splunk has removed support for Hadoop Data Roll. As an alternative, consider archiving aged index data to local or other data storage.

KV Store requires computers that have CPUs with AVX, SSE4.2, and AES-NI

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 9.4, 10.0

Beginning with version 9.4 of Splunk Enterprise, any computer that runs the software must have a CPU that has support for the following extensions to the x86 instruction set architecture:

  • Advanced Vector Extensions (AVX)
  • Streaming SIMD Extensions 4.2 (SSE4.2)
  • Advanced Encryption Standard: New Instructions (AES-NI).

Typically, these extensions have support on Intel CPUs that belong to the Sandy Bridge and later microarchitecture families. There is additional support for the AMD Bulldozer 15h GEN3 family of processor chips. In both cases, there is support only for the x86-64 instruction sets.

Computers that do not use CPU processors that support AVX, SSE4.2, and AES-NI are unable to run Splunk Enterprise, and an attempt to upgrade the software on such computers will fail. This is because the latest version of the database engine that KV Store uses does not have support for CPUs that do not have support for AVX, SSE4.2, and AES-NI.

You must upgrade or replace computers that do not meet the standard before you attempt an upgrade. See Upgrade the KV store server version in the Admin Manual to learn about these new requirements for KV Store and plan the upgrade.

READ THIS FIRST: Should you deploy field filters in your organization?

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 9.3

Field filters is a powerful tool that can help many organizations protect their sensitive fields from prying eyes, but it might not be a good fit for everyone. If your organization runs Splunk Enterprise Security or if your users rely heavily on commands that field filters restricts by default (mpreview and mstats), do not use field filters in production until you have thoroughly planned how you will work around these restricted commands. See READ THIS: Restricted commands do not work in searches on indexes with field filters in the Securing Splunk platform manual.

Splunk Enterprise 9.1 fixes a critical vulnerability in deployment server but might introduce problems for older deployment clients

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 9.0

Splunk introduced a fix for a vulnerability in deployment server in version 9.0 of Splunk Enterprise, and this fix is also available in version 9.1. If you run a deployment server, upgrade that server to version 9.1 of Splunk Enterprise as soon as possible. Before the upgrade, carefully review your deployment server setup and the current versions of the deployment clients in your Splunk Enterprise network. Depending on the setup of your deployment server and whether that component shares a computer with other Splunk Enterprise components, you might need to do the following to ensure your deployment server and clients communicate without problems:

  • Isolate deployment server from other components on a machine. Isolating your deployment server means you only have to upgrade that component. The sole exception for isolation is if you run a deployment server and a license manager on the same machine.
  • Confirm that all deployment clients in your network run version 7.0.0 or higher of Splunk Enterprise or the universal forwarder. You don't have to upgrade deployment clients to version 9.0.0, but they must be at version 7.0.0 or higher to communicate with version 9.0.0 deployment servers.

See the following topics for additional information:

  • SVD-2022-0608 for more about the vulnerability
  • Client version compatibility in the Updating Splunk Enterprise Instances Manual for more about which versions of deployment client that the version 9.0.0 deployment server supports

Follow specific instructions to upgrade clusters

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 7.3

To upgrade indexer or search head clusters, follow the upgrade procedure for the type of deployment you have.

Back up App Key Value Store prior to starting an upgrade

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 7.3

Back up the app key value store (KV store) before any maintenance like an upgrade.

Confirm that you have accounted for this downtime in your upgrade planning. See Back up and restore KV store for more information.

The indexer cluster slave-apps directory is renamed to peer-apps

Applicable components: Splunk Enterprise

Applicable OSes: all

During upgrade of a Splunk Enterprise indexer cluster, the installer renames the slave-apps directory on an indexer cluster node to peer-apps. To accommodate this renaming, you must manually change any external hard-coded references to slave-apps, such as in external scripts, TLS certificates, and so on, to peer-apps. See Update common peer configurations and apps in Managing Indexers and Clusters of Indexers.

The setting master_uri is renamed to manager_uri

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 9.0

In the [License] stanza of the server.conf configuration file, the master_uri setting has been renamed to manager_uri. The old setting name is deprecated but still usable in 9.2. During an upgrade to 9.x, if you have a mixed deployment of 9.x and 8.x instances, do not change master_uri to manager_uri in the 8.x instances. Version 8.x instances do not recognize the manager_uri setting name.

Occurrences that appear to be problems but are not

You might see things happen during or immediately after an upgrade that appear to indicate that the upgrade is not working. In nearly all cases, the occurrences that happen here can be expected.

If the following things occur during the upgrade, let the upgrade continue and do not interrupt it. If they occur immediately afterward, then perform benchmark tests on the deployment and compare to any benchmarks that you set up as part of the first phase of upgrading. Consider involving Splunk Support only if those benchmarks differ by a significant margin.

  • On indexers, memory and CPU usage increases due to the following:
    • New data ingestion pipelines
  • Permissions on the Splunk Enterprise introspection directory might change. Confirm that the user that runs Splunk Enterprise has write permission to the $SPLUNK_HOME/var/log/introspection directory.
  • Deployment servers might push updates to all deployment clients due to app bundle hash recalculations.

The Splunk daemon and its associated components can now use version 3.13 of the Python interpreter, version 3.9 is still available

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 10.2
It's now possible to use version 3.13 of the Python interpreter for operations with the Splunk daemon. While Python version 3.9 remains the default, you can opt in to using version 3.13 for extensions like custom search commands, custom REST endpoints, scripted and modular inputs, external lookups and more. This change begins a transition toward a model where there are two versions of Python available: The long term support (LTS) version and a newer version that will ultimately become the default in a future release.

The Splunk platform now warns you when there is no configuration for allowed internet domains for alert actions that send emails

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 9.3

To improve security posture for Splunk Enterprise environments, Splunk implemented a change to how it processes the sending of emails as a result of an alert action. The allowedDomainList setting in the alert-actions.conf configuration file controls which internet domains to which the instance can send alert action emails. If the setting doesn't have a value, then the instance can send email to any domain as part of an alert action. This is a potential security risk.

If you have not configured an allowed email domain list with the allowedDomainList setting, then the Splunk Enterprise instance advises you of that exposure with the following message: 

Security risk warning: Found an empty value for 'allowedDomainList' in the alert_actions.conf configuration file. If you do not configure this setting, then users can send email alerts with search results to any domain. You can add values for 'allowedDomainList' either in the alert_actions.conf file or in Server Settings > Email Settings > Email Domains in Splunk Web

This message appears by design on any type of search head. It is a security posture that you, as a customer, are responsible for maintaining to reduce the potential of spam messaging and data exfiltration. To configure a list of valid internet domains to which your search heads can send email, see Configure email notification for your Splunk instance in the Alerting Manual.

If the message appears on an indexer, you can safely dismiss the warning without further action. Consider configuring an internet domain that does not send email and using that domain for this configuration to suppress further warnings.

Changes to deployment server architecture

Applicable components: Splunk Enterprise and Splunk Universal Forwarder

Applicable OSes: all
Version introduced: 9.2

See Upgrade pre-9.2 deployment servers in Updating Splunk Enterprise Instances for important details related to these changes.

Significant aspects of the deployment server have been redesigned in Splunk Enterprise version 9.2 to improve performance and manageability. Because of these architectural improvements, deployment server upgrades that span the version 9.2 release automatically undergo changes to implement these improvements.

Considerations for changed or removed features

The following major features have been changed or removed from this version. If you use features that have been removed, and have not yet migrated off them, consider delaying your upgrade until you have.

Splunk has deprecated the SSL v3 and TLS 1.0 and 1.1 network encryption protocols

Applicable components: Splunk Enterprise and Universal Forwarder

Applicable OSes: all
Version introduced: 9.4

Splunk has deprecated the use of version 3.0 of the Secure Sockets Layer (SSL) and versions 1.0 and 1.1 of the transport layer security (TLS) network encryption protocols for version 9.4 of Splunk Enterprise. While these protocols remain supported for the encryption of network traffic between Splunk services such as the Splunk daemon, deployment servers and clients, App Key Value Store (KV store), and forwarders and receivers, version 9.4 of Splunk Enterprise will warn you about these deprecated protocols if you use them after you upgrade.

The Internet Engineering Task Force (IETF) deprecated version 3.0 of the SSL protocol in 2015, and the TLS 1.0 and 1.1 protocols in 2021. Splunk will eventually remove these protocols as options to encrypt Splunk network traffic. When possible, configure communication between Splunk clients and services using TLS version 1.2. This might require that you obtain new certificates for use in your Splunk Enterprise deployment.

New file names for Splunk Enterprise and Universal Forwarder software packages

Applicable components: Splunk Enterprise and Universal Forwarder

Applicable OSes: all
Version introduced: 9.4

The file names of the Splunk Enterprise and Universal Forwarder software packages have changed to make them consistent and comply with platform specific conventions. The software download pages on splunk.com show the new file names.

Older jQuery libraries are restricted

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 9.4

The usage of older jQuery libraries and the Internal Library Settings page are removed. Deprecated libraries and unsupported hotlinked imports are restricted, and Splunk Enterprise no longer offers a self-service option to use them. For more information about Internal Library Settings, see Control access to jQuery and other internal libraries in the jQuery Upgrade Readiness manual.

The IOWait status check is delayed on startup

Applicable components: Splunk Enterprise

Applicable OSes: Linux
Version introduced: 9.0

The IOWait Health Report incorporates a 120 second delay after the Splunk Enterprise service starts to prevent false alerts.

Considerations for new features

Splunk has introduced the following new features in this version of Splunk Enterprise. You might need to perform some configuration after an upgrade to enable and take advantage of these features.

Macros now replicate by default to search peers

Applicable components: Splunk Enterprise

Applicable OSes: all
Version introduced: 9.1

Macros used in apps are now replicated by default to search peers as part of the knowledge bundle in Splunk deployments. As a result of this change, searches that previously failed now run successfully, which could affect downstream performance.

If you don't want to replicate macros for your apps, you can suppress replication by setting replicate.macros = false in the [replicationSettings:refineConf] stanza in the distsearch.conf file. Be aware that disabling distribution of macros might negatively impact your search results.

Learn about known upgrade issues

To learn about any additional upgrade issues for Splunk Enterprise, see the Known Issues - Upgrade Issues page in the Release Notes.