About upgrading to 8.0 READ THIS FIRST

Here are some changes in behavior to note for Splunk Enterprise and the Splunk Universal Forwarder when you upgrade to version 8.0.

The information on this page only applies to version 8.0. If you don't want to upgrade to version 8.0, use the Version picker on this page to choose the target version you want to upgrade to.

Always use the upgrade instructions for the version to which you want to upgrade. Lower or higher versions of this topic can present information that appears to conflict with information for your target version.

Splunk App and Add-on Compatibility

Not all Splunk apps and add-ons are compatible with Splunk Enterprise version 8.0. 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 also 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 8.0, consider delaying your upgrade until a compatible version is available.

Key points for upgrading to version 8.0

Following is a list of the most important elements that you must understand for upgrading 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 commence upgrade activities.

• Splunk data collection practices have changed. In an effort to provide better support for you, Splunk now automatically opts you in to sharing telemetry data after you upgrade. You can still opt out; see Splunk data collection practices have changed later in this topic to learn how.
• Adjust any scripts and templates that depend on Splunk Web to use Python 3-compatible syntax before you upgrade. See Choose your Splunk Enterprise upgrade path for the Python 3 migration for more information.
• Use the Splunk Products version compatibility matrix to ensure that any premium Splunk apps and add-ons you run are compatible with version 8.0. If they are not, do not upgrade until compatible versions become available.
• Do not try to upgrade Splunk Enterprise or Splunk universal forwarders directly to version 8.0 from a version that is lower than 7.0.
• Do not upgrade search head or indexer clusters in-place. Follow the specific instructions for upgrading each cluster type, or data loss can result. See Follow specific instructions to upgrade clusters later in this topic.
• If you use SSL to secure communication between Splunk platform instances, ensure that all instances are at the highest available maintenance release level first, or communication problems can occur. This is particularly important if you run versions of Splunk Enterprise or the universal forwarder that are lower than 6.2.
• Back up your App Key Value Store (KV Store) databases prior to starting an upgrade. If you run version 7.1 and lower of Splunk Enterprise, you must stop Splunk Enterprise instances first.
• 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.

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.

Plan your upgrade to work with the Python 3 migration

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 8.0

When you upgrade to version 8.0, Splunk Enterprise will continue to use the Python 2 interpreter globally by default, but Splunk Web will support only Python 3.7. You have several options for how and when you adjust Python scripts that are not dependent on Splunk Web, but scripts and templates that depend on Splunk Web must be adjusted to use Python 3-compatible syntax before the upgrade or they will break. See Choose your Splunk Enterprise upgrade path for the Python 3 migration for more information.

On Splunk Enterprise indexer cluster masters, enable maintenance mode before you upgrade

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 8.0

Because of changes to bucket data with the release of the latest version of Metrics Store, indexers that run versions of Splunk Enterprise lower than 8.0 cannot handle bucket replications from versions that run 8.0 and higher. Before you upgrade a cluster master, ensure it is in maintenance mode first.

This change has particular implications for site-by-site upgrade of multisite indexer clusters. It means that you cannot use that method to upgrade a cluster with metrics data from 7.3.x or earlier to 8.0.x or later. Instead, you must use the rolling upgrade method or take down and upgrade all peer nodes as a single operation. See Upgrade an indexer cluster for details.

Splunk Enterprise and Universal Forwarders must be version 7.0.x or higher to upgrade to version 8.0

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 7.3

Upgrades to Splunk Enterprise and Universal Forwarders version 8.0 require the existing installation to be version 7.0.x or higher. If the existing installation is version 6.6.x or lower, then you must upgrade to version 7.0.x as an intermediate step. See Upgrade paths to version 8.0 for more information.

If you need to upgrade to 7.0.x first, then read the READ THIS FIRST topic for version 7.0 for important information on potentially breaking changes for that version.

Follow specific instructions to upgrade clusters

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.3

Do not upgrade clusters in-place. Search head and indexer clusters have unique rolling upgrade processes to mitigate synchronization problems, outages, and even data loss. You must follow the upgrade procedures for the type of deployment you have.

• If your deployment has indexer clusters, follow the index cluster upgrade instructions.
• If your deployment has search head clusters, follow the search head cluster upgrade instructions.

Connectivity over SSL between version 7.x and version 5.0 and lower is disabled by default

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 6.6

Because of changes to the security ciphers in version 7.x of Splunk Enterprise, instances of Splunk software that run on version 5.0 or lower cannot connect to instances of version 7.x or higher by default. This includes universal forwarders.

When you upgrade, any instances that run version 5.0 or lower no longer communicates with the upgraded instance over SSL. For a workaround, you can edit inputs.conf and outputs.conf on the sending instances to enable ciphers that allow communication between the instances.

For more information, see the Upgrade Issues section of the Known Issues page in the Splunk Enterprise 6.6.0 Release Notes.

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.

If you are upgrading from version 7.1 or lower, you must stop Splunk Enterprise before you can back up the KV Store databases. Confirm that you have accounted for this downtime in your upgrade planning. See Back up and restore KV store for more information.

Support for the second extended (ext2) file system on Linux has been removed

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: Linux
Version introduced: 7.1

Support for the ext2 file system on Linux operating systems has been removed. If you still run the ext2 file system on a Linux machine that runs Splunk Enterprise, you must upgrade that file system to a minimum of ext3 before you start a Splunk Enterprise upgrade.

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) cipher suites in version 7.2 and higher are not supported on Windows Server 2008 R2

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: Windows
Version introduced: 6.6

The TLS and SSL cipher suites that come with version 7.2 and higher of Splunk Enterprise do not support Windows Server 2008 R2 by default. If you upgrade, and you used SSL and TLS to handle forwarder-to-indexer communication or alert actions, those actions will not work until you make updates to both Windows and Splunk Enterprise configurations.

See About TLS encryption and cipher suites in Securing Splunk Enterprise for instructions on how to configure Windows Server 2008 R2 and Splunk Enterprise to use the new cipher suites.

The Splunk Enterprise credential creation scheme might affect scripted upgrades

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 7.2

Splunk Enterprise 7.1 introduced an updated authentication scheme for users that requires that you create a password for the admin account. In version 7.2, the scheme was extended to let you customize administrator credential creation for Splunk Enterprise instances.

This scheme includes additional settings and configuration options, which can affect how you upgrade if you use scripts to automate the upgrade process. You might need to change your upgrade scripts before performing scripted upgrades. Specifically, confirm that you do not pass any illegal arguments to the Splunk CLI for starting or restarting Splunk Enterprise during the upgrade, as this could result in a situation where Splunk Enterprise does not start after the upgrade has finished.

Search head pooling has been removed

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 8.0

Search head pooling has been removed from Splunk Enterprise. This feature, which was replaced by search head clustering, has been deprecated for many years. If you still use search head pooling, then do not upgrade to version 8.0. Consider switching to search head clustering where possible, as soon as possible.

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.

CPU and memory usage on indexers increases

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.3

By default, new data ingestion pipelines consume more resources when they are enabled.

Permissions on introspection directory might change

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 7.3

Confirm that the user who 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.

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 7.3

Memory usage on indexers increases during indexing operations

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 6.5

When you upgrade to version 7.0 or higher of Splunk Enterprise, the amount of memory that indexers use during indexing operations increases. If you have configured an indexer with parallelization (multiple indexing pipelines), the usage increase can be significant.

Indexers that have been configured with a single indexing pipeline, which is the default for a Splunk Enterprise installation, see memory usage increases of up to 10%. Indexers that have two pipeline sets see increases of up to 15%. Indexers that have been configured with four indexing pipelines see increases of up to 25%.

Confirm that your indexers meet or exceed the minimum hardware specifications that the Capacity Planning Manual details before you perform an upgrade. See Reference hardware for memory details for each host.

Scheduled views reaper process might increase disk I/O and CPU usage on startup

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.1

When you upgrade to version 7.1 or higher of Splunk Enterprise, a new process runs that checks and removes orphaned scheduled views, such as saved searches or reports that generate PDFs on a schedule. This happens when Splunk Enterprise starts, and might result in increased disk I/O and CPU usage on startup.

Data model acceleration sizes on disk might appear to increase

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 6.6

If you have created and accelerated a custom data model, the size that Splunk software reports it as being on disk has increased.

After you upgrade, data model acceleration summary sizes can appear to increase by a factor of up to two to one. This apparent increase in disk usage is the result of a refactoring of how Splunk software calculates data model acceleration summary disk usage. The calculation that Splunk software performs in version 7.x is more accurate than in previous versions.

The number of potential data model acceleration searches has increased

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 6.6

The default number of concurrent searches that Splunk Enterprise uses for data model acceleration has been increased from two to three.

If you have an environment that uses data models that have not yet been accelerated, Splunk software might run up to three searches to accelerate the data models. This can result in increased CPU, memory, and disk usage on the search heads that perform the data model acceleration, and can also cause more concurrent searches overall in an environment where the search heads are not clustered.

Security changes in SSL and TLS could affect customers who use LDAP

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 6.6

If you have configured Splunk software to use the Lightweight Directory Access Protocol (LDAP) to authenticate, after an upgrade, changes in security settings for Secure Sockets Layer (SSL) and Transport Layer Security (TLS) could prevent the software from connecting to the LDAP server.

If that occurs, you can roll back the updated settings by doing the following:

1. Open $SPLUNK_HOME/etc/openldap/ldap.conf for editing with a text editor.
2. Comment the lines that begin with the following:




#TLS_PROTOCOL_MIN ...
#TLS_CIPHER_SUITE ...

3. Save the ldap.conf file and close it.
4. Restart Splunk Enterprise.

Instrumentation adds an internal index and can increase disk space usage

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 6.5

The instrumentation feature of Splunk Enterprise, which lets you share Splunk Enterprise performance statistics with Splunk after you opt in, includes a new internal index which can cause disk space usage to rise on hosts that you upgrade. You can opt out of sharing performance data by following the instructions at Share data in Splunk Enterprise in the Admin Manual.

Certain JSChart limits have been increased which might reduce performance in older browsers

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 6.5

The number of series, results, and data points that a JSChart chart element can display has been increased.

The number of series has doubled from 50 to 100. The number of results that can be displayed has increased from 1000 to 10,000. The number of total data points has increased from 20,000 to 50,000.

If you have not already changed the defaults for these JSChart elements, then you will see more data points on your JSChart elements after an upgrade. If you use an older browser to interact with Splunk Enterprise, you might also see slightly reduced performance.

Support for Internet Explorer versions 9 and 10 has been removed

Applicable components: Splunk Enterprise
Applicable OSes: Windows
Version introduced: 6.5

Microsoft has announced that support for all versions of Internet Explorer lower than version 11 has ended as of January 12, 2016. Owing to that announcement, Splunk has ended support for Splunk Web for these same versions. This might result in a suboptimal browsing experience in lower versions of Internet Explorer.

When you upgrade, also upgrade the version of Internet Explorer that you use to 11 or higher. An alternative is to use another browser that Splunk supports.

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 data collection practices have changed

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 8.0

In an effort to provide better support to its customers and improve its products and services, Splunk has changed its data collection practices. After you upgrade, Splunk automatically opts you in to sharing telemetry data. To learn what data Splunk collects, see What data Splunk collects in the Admin Manual.

The change happens when you first log into an instance with an administrator user after the upgrade. You receive a pop-up message that indicates the policy change, and the instance overwrites any existing data-sharing configurations after you acknowledge the pop-up.

You can still opt out of sharing telemetry data at any time. To learn how, see How to opt out in the "Share data in Splunk Enterprise" topic of the Admin Manual.

The "access controls" Splunk Web menu options have changed

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 8.0

The "Access controls" menu item under the "Users and Authentication" header in the Settings menu in Splunk Web has been replaced with individual links to user, role, password, and authentication scheme management.

The default memory resource allocation for workload categories has changed

Applicable components: Splunk Enterprise
Applicable OSes: Linux
Version introduced: 8.0

On upgrade to version 8.0, the default memory resource allocation for the ingest workload category changes from 20% to 100%. This might cause an increase in memory usage in the ingest category after upgrade. The default memory resource allocation for the search and misc. categories remains the same, at 70% and 10%, respectively.

For more information on workload categories, see Configure workload categories in the Workload Management manual.

The "failure to localize search" Splunk Web error message has been replaced with a "partial results" message

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 8.0

When you upgrade to version 8.0 and run a search that encounters a localization error, the message that appears in Splunk Web has changed. Instead of displaying a "failure to localize" message, Splunk Web notifies users that the search process might have returned partial results.

Roles with the "install_apps" capability also need the "list_settings" capability to access certain REST endpoints

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 8.0

After you upgrade to version 8.0 of Splunk Enterprise, any roles that hold the install_apps capability must also hold the list_settings capability for role users to be able to manage app installations through REST (using the manager/appinstall/<app> endpoint, for example.

Splunk Enterprise forwarders at version 8.0 cannot forward metrics data to indexers that run lower than version 8.0

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 8.0

There is no support for the forwarding of metrics data from forwarders that run version 8.0 or higher to indexers that run version 7.3 or lower. If you need to forward metrics data from a version 8.0 forwarder, confirm that all indexers that receive this kind of data also run version 8.0.

Upgraded search head nodes will complain of missing metrics indexes in lower-version indexer nodes

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 8.0

If you upgrade your distributed search environment to version 8.0 of Splunk Enterprise but keep your indexer nodes at a version below 8.0, your search head nodes will generate alerts about a missing _metrics index when they try to send metrics.log events to those indexers. You cannot work around this problem by adding an _metrics index to the indexer cluster, as the format of the metrics data is different on indexers that run a lower version. Upgrade all Splunk Enterprise components to the latest version where possible.

After an upgrade, configure limits.conf settings on all search head cluster nodes that handle metrics data

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 8.0

After you upgrade your search head and indexer clusters to version 8.0 of Splunk Enterprise, edit limits.conf on each search head cluster and set the always_use_single_value_output setting under the [mcollect] stanza to false. This lets these nodes use the "multiple measures per metric data point" schema when you convert logs to metrics with the mcollect command or use metrics rollups. This new schema increases your data storage capacity and improves metrics search performance.

Streaming metric alerts are not available on indexer clusters that run version 7.2 and lower

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 8.0

Splunk Enterprise version 8.0 introduces streaming metric alerts, which are evaluated on a continuous basis, and which can reduce the load on your system by enabling similar alerts to share the same search process. There is no support for streaming metric alerts on indexer clusters that run version 7.2 or lower. If you have an indexer cluster and a search head cluster, and you upgrade the search head cluster to version 8.0, you lose the ability to trigger streaming metric alerts for that search head cluster. If you need to retain this ability, upgrade the indexer cluster to version 8.0 first.

Tstats searches must now name fields for their statistical functions

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 8.0

Beginning with Splunk Enterprise version 8.0, with the exception of count, the tstats command supports only statistical functions that are applied to fields or eval expressions that resolve into fields. For example, a search like | tstats sum or | tstats sum() is no longer allowed. Going forward, the syntax requires that at least one field argument be provided for the function: | tstats sum(<field>).

Prior to Splunk Enterprise version 8.0, tstats searches processed functions without named fields as functions with wildcarded fields, like this: | tstats <function>(*). But tstats does not allow explicitly wildcarded fields, so it should not allow implicit wildcarded fields, either.

You can no longer use wildcards in real-time searches that use the mstats command

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 8.0

Beginning with Splunk Enterprise version 8.0, you can no longer use wildcards in real-time searches that contain the mstats command. If you have these kinds of searches, change them so that they no longer use wildcards of any kind, either in aggregation fields or metric names, prior to upgrading

Metrics indexing and search is now case-sensitive

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 8.0

The indexing and search schema for metrics data is case-sensitive as of Splunk Enterprise 8.0. Instances of Splunk Enterprise that are lower than 8.0 might encounter problems retrieving results when searching instances that run version 8.0 or higher.

Older, deprecated configuration file settings for knowledge bundle replication have been removed

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 8.0

Many older, previously deprecated settings under the [replicationSettings] stanza in distsearch.conf have been removed. If your configuration uses these settings, consider changing them before you start an upgrade.

Configuration file settings for specifying the mounted bundle option for knowledge bundle replication have changed

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 8.0

The distsearch.conf setting for specifying the mounted bundle option for knowledge bundle replication has changed. Previously, the setting was shareBundles=false. The new setting is replicationPolicy=mounted. If the upgrade process finds the old setting in your configuration files, it converts it automatically to the new setting, so no manual intervention is required on your part.

Workload management adds separate workload categories for different process types

Applicable components: Splunk Enterprise
Applicable OSes: Linux
Version introduced: 7.3

On upgrade to from 7.2 to 7.3 or from 7.2 to 8.0, workload management automatically creates workload categories that allocate resources based on the process type (search, ingest, and misc.), and places existing workload pools in the appropriate workload category, as follows:

• search: All existing search pools are placed under the search category. The existing default_pool becomes the default_category_pool in the search category.
• ingest: The existing ingest_pool becomes the default_category_pool in the ingest category
• misc.: The misc category is created with no pools defined.

For detailed information on upgrading workload management, see Upgrade workload management in the Workload Management manual.

The new Splunk credentials scheme might affect new scripted installations

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 7.2

While the software retains existing credentials during an upgrade, if you perform scripted installations, those installations might be affected significantly by the new credential scheme. You might need to modify your scripts before you perform scripted installations with version 7.2 and higher of the software. Carefully read the following topics to understand the updated installation process:

• Install on Linux in the Installation Manual
• Install on Windows using the command line in the Installation Manual

For more information on the updated password policy, see Password best practices for administrators.

Additionally, your Splunk administrator might introduce password eligibility requirements that affect you if you change your password after an upgrade. See Configure Splunk password policies in Securing Splunk Enterprise for additional information.

The Django framework has been removed

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.3

The Django framework and all its associated components have been removed from the Splunk platform. Apps and dashboards that use this framework will not function anymore. Before you upgrade, confirm that apps and dashboards you regularly use no longer use Django, as an upgrade will render them inoperable.

Updated field alias behavior might result in null values

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.2

When you upgrade to a version of Splunk Enterprise that is 7.2 or higher, the behavior of certain field alias configurations changes. This behavior affects events where the alias field is already present before field alias processing takes place.

• If both the source field and the alias field are present in the event, the search head overwrites the value of the alias field to match the value of the source field.
• If the alias field is present in the event but the source field is missing or has a null value, the search head removes the alias field from the event.

This is how field aliasing should work in these situations. However, you might have searches that rely on the old field alias behavior. A new ASNEW syntax has been added to enable you to provide the pre-7.2 behavior to your field alias configurations.

The pre-7.2 field alias behavior enabled users to create sets of field alias configurations that matched multiple source fields with one alias field. You can use the ASNEW syntax to continue doing this. A better practice would be to use a calculated field that uses the coalesce function to create a new field that takes the value of one or more existing fields. This method lets you be explicit about ordering of input field values in the case of null fields. For example: EVAL-ip = coalesce(clientip,ipaddress).

See Field alias behavior change in the Release Notes for further details.

Event Log monitoring input has improved performance, new settings, and changes in behavior

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: Windows
Version introduced: 6.6

The Windows Event Log monitoring input has improved performance. Owing to improved efficiencies in how the input retrieves and processes events, it provides up to twice the performance as previous versions. To improve performance further, several new input settings have been added. Also, the input now respects the checkpointInterval setting in an Event Log monitoring stanza. For additional information about the changes, see Monitor Windows Event Log data in Getting Data In.

Before you upgrade, do the following:

• Review your Event Log monitoring input stanzas and confirm that the checkpointInterval setting is not set to something very large. Large settings might result in a large number of duplicate events after Splunk Enterprise restarts from a crash. If you have not already set checkpointInterval then you do not need to set it now.
• Confirm that the machines that retrieve Windows Event Log data meet or exceed the minimum requirements as described in System Requirements for user of Splunk Enterprise on-premises. In particular, if the timely arrival of Event Log events is critical for your organization, any machines that use the input must conform with those requirements.

Splunk Enterprise meters metric data points under 150 bytes by volume on a scale that is similar to the scale used for event data

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 7.3

There is a change to the way that Splunk Enterprise meters metrics data in version 7.3. Prior to this release, all metric data points counted against the license as if they were a flat 150 bytes. As of 7.3, Splunk Enterprise meters each metric data point that measures less than 150 bytes by volume on a scale that is similar to the scale used for event data. This scale is capped at 150 bytes. Metric events with volumes over 150 bytes are metered as if they are only 150 bytes. As a result, license usage for such events might be lower than in prior release.

For additional information on licensing, see How Splunk Enterprise licensing works in the Admin Manual.

The tstats command now reports the actual number of matched events in an index bucket as the scan count of those events

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.3

The tstats search command, which performs statistical queries on indexed fields in tsidx files, has updated behavior with regard to the number of events it finds in a bucket.

Previously, the command reported the scan count of events in a bucket. After an upgrade, the command now reports the actual number of matched events in a bucket as the scan count. If you use tstats for searches, you might see scan counts fall significantly. This does not indicate incorrect results.

The Splunk Web user interface has been updated significantly

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.2

Splunk Web has been refreshed with a new, improved look. While many user interface controls remain the same as they were in previous versions, the interface looks different than before, and some items have been relocated. This might cause confusion for those who have become accustomed to the previous interface.

Data model searches now only use fields that have been defined within the data model

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.1

When you upgrade to version 7.2 or higher of Splunk Enterprise, data model searches can only use field names that have been defined within the data model. Splunk Enterprise no longer automatically extracts field names. Knowledge objects that depend on such fields will require the data model to have such fields explicitly added in order to continue working as expected.

Additionally, if you have a data model search that references an automatically extracted field name that contains whitespace, you must work around the fact that data models do not allow field names that contain whitespace.

The default color scheme for choropleth maps has changed

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.1

The color scheme for choropleth maps and single-value visualizations has changed in Splunk Enterprise 7.2. Existing visualizations will be retained through the upgrade, but any new visualizations that you create after an upgrade will use the new color scheme.

Modified navigation menus in default Splunk apps will be removed after upgrade

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.1

After an upgrade to version 7.2 or higher of Splunk Enterprise, any modifications that you have made to navigation menus in default Splunk apps will be removed.

As a reminder, you should not make edits to default apps or configurations, as they can be and, in nearly all cases, are removed after an upgrade. Edit local configurations rather than making modifications to Splunk default configurations and apps.

Stats percentile results might shift by a few percent

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.0

Splunk software computes percentiles and median in stats and related commands (tstats, streamstats, eventstats, chart, timechart, sistats, sichart, sitimechart) using an approximation algorithm, unless you use the exactperc aggregation function. In versions lower than Splunk Enterprise 7. , these commands used an approximation algorithm called rdigest. After you upgrade, the default digest behavior changes to tdigest, which has been shown to be more performant than rdigest in some cases, and for metrics data in particular.

Reports that use percentiles and medians might emit slightly different results upon an upgrade to Splunk Enterprise 7.x. The difference is usually small (less than 1%) but could be greater for highly skewed datasets. After the initial shift, stats continues using the new digest method and does not produce another shift unless you switch back to using the rdigest method.

If you want, you can revert the digest behavior globally in limits.conf. The behavior for stats, tstats, streamstats, eventstats, chart, and timechart are controlled by the setting in the stats stanza. The behavior for sistats, sichart, and sitimechart are controlled by the setting in the sistats stanza.

See limits.conf.spec in the Admin Manual.

You can no longer use disabled lookups in searches or other lookups

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.0

You can no longer use a disabled lookup as part of a search or other lookup. After you upgrade, when you attempt to use a disabled lookup, you receive the error message The lookup table '<lookup name>' is disabled.

SPL operator keywords can break saved searches

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 6.6

As of version 6.6 of Splunk Enterprise, new SQL-style search processing language (SPL) keywords were introduced, such as IN and OR. These new keywords can potentially break existing saved searches after an upgrade if those searches contain these new keywords (for example, search country=IN or search state=OR.

Before you upgrade, review existing saved searches and add quotes around any searches that contain these new operators (for example, search country="IN" or search state="OR".) For more information on these operators, see the search command usage information in the Search Reference Manual.

The 'autoLB' universal forwarder setting in outputs.conf is no longer configurable

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 6.6

The autoLB setting, which controls how universal forwarders send data to indexers, and which only had a valid setting of true, has been locked to that value. Since auto-loadbalancing is the only way that forwarders can send data, there is no longer a reason to make that setting configurable. Universal forwarders now ignore attempts to configure the setting to anything other than true.

You might notice an error about a bad configuration for autoLB during the startup check. You can safely ignore this error.

The 'compressed' settings on a forwarder and a receiving indexer no longer must match for the instances to communicate

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 6.6

Forwarders and indexers now auto-negotiate their connections. After an upgrade, it is no longer necessary for you to confirm that the compressed setting in an outputs.conf stanza on the forwarder matches the corresponding compressed setting in a splunktcp:// stanza in inputs.conf on the receiver for the forwarder-receiver connection to work.

Indexers in a distributed Splunk environment now respect the INDEXED setting in fields.conf on search heads only

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 6.6

To better align with documented best practice, the way that indexers handle the INDEXED setting in fields.conf has changed.

Indexers now respect the setting as it has been configured on search heads only. After you upgrade, if you have only configured this setting in fields.conf on indexers, you must configure it on the search heads also.

Protection for the '/server/info' REST endpoint is now on by default

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 6.6

In version 6.5 of Splunk Enterprise, a setting was introduced to require authentication to access the server/info REST endpoint.

After you upgrade, this protection is enabled by default.

The 'deleteIndexesAllowed' capability that inhibits index deletion has been added

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 6.5

The deleteIndexesAllowedcapability has been added. Non-administrator user roles must hold this capability before they can delete indexes. After you upgrade, you can assign this capability to any non-administrator user roles so that they can delete indexes.

In addition to the deleteIndexesAllowed capability, user roles must also hold the delete_by_keyword capability to delete indexes.

Universal forwarder installation package no longer includes the Splunk Add-on for Windows

Applicable components: Splunk Universal Forwarder
Applicable OSes: Windows
Version introduced: 6.5

The installation package for the universal forwarder no longer includes the Splunk Add-on for Windows. If you need the add-on, you must download and install it separately.

The installer does not delete existing installations of the add-on.

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.

New configuration settings for importing structured data files

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 8.0

Splunk Enterprise 8.0.0 and higher has added some new settings for configuring the indexing of structured data. Previously, the structured data processor converted characters that it encountered in header field names that were neither alphanumeric nor a space into underscores. With the new HEADER_FIELD_ACCEPTABLE_SPECIAL_CHARACTERS setting in props.conf, you can control which characters the processor accepts as valid in header field names. Some characters might cause the processor to malfunction, so if you import lots of structured data and want to use the feature, use a test index to confirm that the processor imports the data in the way you want.

Systemd support boot-start

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: Linux
Version introduced: 7.2.2

Splunk Enterprise 7.2.2 and higher adds broad support for systemd on Linux with an updated enable boot-start command that lets you automatically configure systemd to manage splunkd as a service. Use of systemd changes the commands used for managing the Splunk processes and requires non-root users to have certain sudo capabilities. These differences may require changes to any scripting, automation, or support documentation.

See Run Splunk Enterprise as a systemd service for instructions.

Significant tsidx performance improvements are turned off by default

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.3.x

New Splunk Enterprise releases sometimes introduce improvements to the file format of tsidx index files. For example, 7.2 introduced a new file format that significantly reduced the size of tsidx files, resulting in improved search performance through decreased I/O, improved utilization of SmartStore caches, and so on. Similarly, 7.3 offers more improvements to the file format.

For the best possible performance from your indexers, always use the most recently released format level, because the latest format provides optimizations that are beneficial under all circumstances.

You must update the file format level manually. New releases are not automatically configured to use the latest level due to the way that certain indexer cluster upgrades work.

To upgrade multisite indexer clusters without search interruption, it is necessary to defer any format change until after the upgrade completes and all peer nodes can switch to the new format simultaneously. For this reason, new releases of Splunk Enterprise default to the pre-7.2, unimproved file format.

Immediately after you complete an upgrade, configure the indexers to use the most recent file format.

If you previously upgraded your indexers to 7.2 or higher, then you probably already configured your indexers for at least one level of improvements.

To specify the file format to use, edit the tsidxWritingLevel setting in indexes.conf on each indexer (or, in the case of indexer clusters, in the master node's configuration bundle).

To determine whether the tsidx format has changed since your last upgrade and what value to set tsidxWritingLevel to, search for the description of the setting in the indexes.conf spec file. Compare the highest level documented in the spec file with the level currently configured on your indexers. Under all circumstances, it is best to configure the setting to the highest level documented in the current version of the spec file.

For example, in 7.2, the highest level available was 2. In 7.3, more improvements to the file format were made and a new level 3 was introduced. Therefore, after you upgrade, set tsidxWritingLevel to 3. Make this change at the global level of the indexes.conf file, so that it applies to all indexes:

[default]
tsidxWritingLevel=3

For post-7.3 releases, always check the spec file immediately after upgrade and, if the highest level documented there is greater than the level currently configured on your indexers, update tsidxWritingLevel to the highest value then available.

Splunk Enterprise uses a new cipher suite and message authentication code for inter-Splunk communication

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 7.2

Splunk Enterprise 7.2 introduced a new cipher suite and message authentication code (MAC) that replaces the existing cipher suite that was responsible for securely handling inter-Splunk communications.

The new suite and MAC are not compatible with the old suite. Splunk instances that run version 7.2 and higher of Splunk software have been configured by default to allow inter-Splunk communication using both the new and old suites. However, if you later configure a 7.2 or higher instance to run only the new suite and MAC, inter-Splunk communication between versions that run only the old suite is not possible. You cannot configure lower versions of Splunk software to use the new suite.

For more information about the changes, see Configure secure inter-Splunk communications with updated cipher suite and message authentication code in Securing Splunk Enterprise.

HTTP Event Collector now cleans up idle indexer ACK channels by default

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 7.1

After an upgrade to version 7.2 of Splunk Enterprise, the HTTP Event Collector now cleans up any indexer ACK channels it finds that have an idle time of more than maxIdleTime seconds, as defined by that setting in the inputs.conf configuration file, by default. While this results in improved HEC performance, you might experience a slight increase in network and CPU activity during the cleanup.

The ability to customize the number of reports retrieved might reduce browser performance

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 7.0

You can now increase or decrease the number of reports that Splunk Web can retrieve at a time by modifying an entry in web.conf. If you increase the number of reports that can be retrieved after you upgrade, you might cause problems with browser performance due to the number of reports available.

A new load-balancing scheme for forwarders is available

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 6.6

All forwarder types now have a new scheme for balancing load between receiving indexers.

In addition to balancing load by time, they can also balance load by amount of sent data. The autoLBVolume setting in outputs.conf controls this setting.

See Choose a load balancing method in Forwarding Data for additional information.

Use different settings for better data distribution between indexers in a load-balanced forwarder configuration

Applicable components: Splunk Enterprise and Splunk Universal Forwarder
Applicable OSes: all
Version introduced: 6.6

If you have a setup where universal forwarders have been configured to send data to indexers in a load-balanced scheme, replace configurations that have forceTimeBasedAutoLB with those that use EVENT_BREAKER_ENABLE and EVENT_BREAKER instead. For more information about these new settings, see Configure load balancing for Splunk Enterprise in the Universal Forwarder Manual.

The free version of Splunk now includes App Key Value Store

Applicable components: Splunk Enterprise
Applicable OSes: all
Version introduced: 6.5

When you upgrade to version 7.0 or higher of Splunk Enterprise, the free version of Splunk Enterprise gets access to the App Key Value Store feature.

This change results in processes running on your host that support App Key Value Store. These processes might result in extra memory or disk space usage.

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.