About upgrading to 7.0 READ THIS FIRST

Support for this version of Splunk Enterprise has ended.

Splunk ended support for this version of Splunk Enterprise on September 26, 2019, in accordance to the Splunk software support policy. Splunk will offer a Limited Support period through January 31, 2020. After the Limited Support period ends, Splunk no longer provides support for customers that run this version. Consider planning an upgrade to the most recent version to get the latest in performance enhancements, bug fixes, and features. See the following documentation for more information: How to upgrade Splunk Enterprise - for general instructions and upgrade paths. About upgrading - READ THIS FIRST - for important technical information about upgrading to the latest version. Splunk Software Support Policy - for the most up-to-date information on support dates and policies for each release.

Splunk App and Add-on Compatibility

Not all Splunk apps and add-ons are compatible with Splunk Enterprise version 7.0. Visit Splunkbase to confirm that your apps are compatible with Splunk Enterprise version 7.0.

Upgrade clustered environments

To upgrade an indexer cluster, see Upgrade an indexer cluster in Managing Indexers and Clusters of Indexers. Those instructions supersede the upgrade material in this manual.

To upgrade a search head cluster, see Upgrade a search head cluster in Distributed Search. Those instructions supersede the upgrade material in this manual.

Upgrade paths

Splunk Enterprise supports the following upgrade paths to version 7.0 of the software:

• From version 6.0 or later to 7.0 on full Splunk Enterprise.
• From version 5.0 or later to 7.0 on Splunk universal forwarders.

If you run a version of Splunk Enterprise prior to 6.0:

1. Upgrade from your current version to version 6.0.
2. Then, upgrade to version 7.0.

See About upgrading to 6.0 - READ THIS FIRST for tips on migrating your instance to version 6.0.

Important upgrade information and changes

Here are some things that you should be aware of when installing the new version:

Customers who run version 6.6.4 of Splunk Enterprise might reintroduce software defects by upgrading to version 7.0.1

Some defects that Splunk fixed in version 6.6.4 are not yet fixed in version 7.0.1. If you run version 6.6.4 of Splunk Enterprise, you might reintroduce those defects by upgrading to version 7.0.1.

This notice does not apply to customers who run a version of Splunk Enterprise that is earlier than 6.6.4.

Customers who run version 6.5.6 of Splunk Enterprise might reintroduce software defects by upgrading to version 7.0.0

Some defects that Splunk fixed in version 6.5.6 are not yet fixed in version 7.0.0. If you run version 6.5.6 of Splunk Enterprise, you might reintroduce those defects by upgrading to version 7.0.0.

This notice does not apply to customers who run a version of Splunk Enterprise that is earlier than 6.5.6.

Stats percentile results might shift by a few percent

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). Before Splunk Enterprise 7.0, 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, metrics data in particular.

Reports that use percentiles and medians might emit slightly different results upon an upgrade to Splunk Enterprise 7.0. 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.

The use of disabled lookups in searches or other lookups is no longer allowed

As of version 7.0 of Splunk Enterprise, 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.

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

As of version 7.0 of Splunk Enterprise, 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.

SPL operator keywords can break saved searches

(Originally introduced in version 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.

A new load-balancing scheme for forwarders is available

(Originally introduced in version 6.6)

As of version 7.0 of Splunk Enterprise, 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 data sent. The autoLBVolume setting in outputs.conf controls this setting.

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

Connectivity over SSL between version 7.0 and version 5.0 and earlier is disabled by default

(Originally introduced in version 6.6)

Because of changes to the security ciphers in version 7.0 of Splunk Enterprise, instances of Splunk software that run on version 5.0 or less cannot connect to instances of version 7.0 or greater by default.

When you upgrade, any instances that run version 5.0 or earlier 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 Known Issues - Upgrade Issues page in the Splunk Enterprise 6.6.0 Release Notes.

Data model acceleration sizes on disk might appear to increase

(Originally introduced in version 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.

When 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.0 is more accurate than in previous versions.

The number of potential data model acceleration searches has increased

(Originally introduced in version 6.6)

The default number of concurrent searches that are used 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 are accelerating the data models 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

(Originally introduced in version 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 software.

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

(Originally introduced in version 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 will 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

(Originally introduced in version 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

(Originally introduced in version 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. When you upgrade, if you have only configured this setting in fields.conf on indexers, you must configure it on the search heads if it is not there.

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

(Originally introduced in version 6.6)

If you have a setup where universal forwarders have been configured to send data to indexers in a load-balanced scheme, you should 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.

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

(Originally introduced in version 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.

Memory usage on indexers increases during indexing operations

(Originally introduced in version 6.5)

When you upgrade to version 7.0 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.

The free version of Splunk now includes App Key Value Store

(Originally introduced in version 6.5)

When you upgrade to version 7.0 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.

The instrumentation feature adds an internal index and can increase disk space usage

(Originally introduced in version 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 performance data in the Admin Manual.

Distributed search now defaults to a single protocol

(Originally introduced in version 6.4)

In an effort to reduce the potential for problems when search heads connect to search peers, several settings have been added or changed in distsearch.conf that control this process.

• The trySSLFirst setting no longer has any meaning in the context of search head to search peer connections.
• A new setting defaultUriScheme controls what protocol search heads use to connect to search peers, and can be configured to http or https. This setting acts as the default connection scheme for any peers that you add to a search head after you configure the setting.

After you upgrade, review distsearch.conf to confirm that the file has the new variables.

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

(Originally introduced in version 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.

A new capability 'deleteIndexesAllowed' has been added that inhibits index deletion

(Originally introduced in version 6.5)

A new user capability, deleteIndexesAllowed, 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.

User roles must also hold the "delete_by_keyword" capability to delete indexes.

Migration time might increase significantly if there are a large number of data model or report acceleration summaries

(Originally introduced in version 6.4)

When you upgrade to version 7.0 of Splunk Enterprise, the software generates checksums for data model and report acceleration summaries as part of the migration. This action is for better compatibility with indexes on indexer clusters, but happens on all deployments. If your deployment has a large number of existing data model or report acceleration summaries, the checksum generation process might take a long time. Splunk Enterprise generates entries in migration.log during the process:

Generating checksums for datamodel and report acceleration bucket summaries for all indexes.
If you have defined many indexes and summaries, summary checksum generation may take a long time.
Processed 1000 out of 10007 configured indexes.
Processed 2000 out of 10007 configured indexes.
[...]
Processed 10000 out of 10007 configured indexes.
Finished generating checksums for datamodel and report acceleration bucket summaries for all indexes.

The working directory for the inputcsv, outputcsv, and streamedcsv search commands has changed

(Originally introduced in version 6.4)

The working directory for the inputcsv, outputcsv, and streamedcsv search commands has changed. When you execute these search commands after an upgrade, Splunk Enterprise stores and reads the files they create in $SPLUNK_HOME/var/run/splunk/csv, rather than $SPLUNK_HOME/var/run/splunk.

The upgrade process moves any existing working files to the new directory and logs the following message to migration.log:

Creating $SPLUNK_HOME/var/run/splunk/csv and moving inputcsv/outputcsv files into the created directory.

Note the following migration issues:

• Apps, add-ons, or scripts that use the commands or that reference the old working directory can be negatively affected when you upgrade, due to the changed directory location.
• You must manually migrate any files that you use in conjunction with inputcsv that do not end with the .csv file extension, or that are in a subdirectory.
• If you have a component that is external to Splunk Enterprise and uses the outputcsv command, you must manually update the paths of any files or scripts in that component that use the command.
• Additionally, if the component contains files that outputcsv has generated, and those files either do not end in .csv or are in a subdirectory, you must migrate those files to the new working directory manually.

Search commands that exist only in a user context will no longer execute

(Originally introduced in version 6.4)

If you have search commands that have been defined in a commands.conf file for a specific user, for example, $SPLUNK_HOME/etc/users/alice/local/commands.conf, those commands are no longer available for execution after you upgrade.

As a workaround, you can move the command configurations to either the app level (put the configurations into $SPLUNK_HOME/etc/apps/<app_name>/local/commands.conf) or the system level ($SPLUNK_HOME/etc/system/local/commands.conf).

Confirm that the introspection directory has the correct permissions

(Originally introduced in version 6.4)

If you run Splunk Enterprise on Linux as a non-root user, and use an RPM to upgrade, the RPM writes the $SPLUNK_HOME/var/log/introspection directory as root. This can cause errors when you attempt to start the instance later. To prevent this, chown the $SPLUNK_HOME/var/log/introspection directory to the user that Splunk Enterprise runs as after upgrading and before restarting Splunk Enterprise.

The Splunk Web visualizations editor changes take precedence over existing 'rangemap' configurations for single-value visualizations

(Originally introduced in version 6.4)

If you use the rangemap search command to define ranges and colors for single-value visualizations on dashboards, use the Format editor instead when you upgrade. Changes that you make with the Format editor to these visualizations override the rangemap configurations. Going forward, generate new single value visualizations by using a query that does not contain the rangemap command, and then use the Format editor to configure ranges, colors, or any additional settings.

Any changes that you make with the editor to single-value visualizations that were generated with = rangemap override edits that you make to the range map command. Additionally, while the editor attempts to preserve the existing configuration, it no longer recognizes rangemap as a valid command to generate these types of visualizations.

Splunk Enterprise now limits the addition of search peers with a large time skew

(Originally introduced in version 6.4)

When you upgrade to Splunk Enterprise 7.0, you can no longer use Splunk Web to add search peers with a time skew of more than 10 minutes from the search head where you add the peers.

You can change this setting by editing limits.conf on the search head and setting the addpeer_skew_limit to a positive integer that is lower than its default of 600 seconds.

Splunk Enterprise support for running multiple searches on a single process might increase memory usage

(Originally introduced in version 6.4)

As of version 7.0, Splunk Enterprise can launch multiple searches on a single process on *nix hosts.

When you upgrade, you should see improved search performance, but you might also see increased memory usage.

This change is not applicable on Windows instances of Splunk Enterprise.

Support for the Deployment Monitor app has been removed

(Originally introduced in version 6.3)

Support for the Splunk Deployment Monitor App has been removed. When you upgrade to Splunk Enterprise 7.0, use the monitoring console instead to monitor your distributed deployment. See Monitoring Splunk Enterprise.

Data block signing has been removed

(Originally introduced in version 6.3)

Data block signing has been removed from Splunk Enterprise.

Accelerated custom data model summaries rebuild on upgrade

(Originally introduced in version 6.3, can happen on upgrades from 6.3)

When you upgrade to Splunk Enterprise 7.0, any accelerated custom data model summaries that are present on the instance - such as those created by the Splunk App for Enterprise Security - rebuilt. This is because of optimizations to data model searches that have been made, which make the searches incompatible with previously generated summaries.

During the rebuild process, CPU, memory, and disk I/O usage on indexers with the summaries increase significantly. Searches that rely on those data model summaries will be very slow and might not work fully.

If you need to prevent Splunk Enterprise from rebuilding these summaries on upgrade, make the following changes to your Splunk Enterprise configuration before starting an upgrade:

In datamodels.conf:

acceleration.manual_rebuilds = true

In limits.conf:

[tstats]
allow_old_summaries = true

There is now a limit on the number of learned source types

(Originally introduced in version 6.3)

For all versions of Splunk Enterprise, the number of source types that an instance can learn in the process of monitoring and indexing files has been limited.

To reduce instances where CPU and memory usage spiked during such operations, a new attribute that controls how many source types an instance learns when it monitors files and analyzes file contents has been created. The limit is 1000, and you can change this setting by editing the following attribute in limits.conf and restarting Splunk Enterprise:

learned_sourcetypes_limit = <number>

While this setting should prevent memory and CPU spikes, continue to use props.conf and inputs.conf to define and apply source types.

Parallel summarization for data model summaries has been enabled

(Originally introduced in version 6.3)

The number of searches that the Splunk platform runs at a time to generate summary files for data models has changed.

When you upgrade to Splunk Enterprise 7.0, the software runs two concurrent search jobs to generate the summary files, instead of one. This change is called "parallel summarization." It might result in an increase in CPU and memory usage on the instance that contains the data models while the search jobs run, but results in faster availability of data model summaries.

You can change this setting back to the previous default for individual data models. See Parallel summarization in the Knowledge Manager Manual.

You must now enable access to Splunk Enterprise debugging endpoints

(Originally introduced in version 6.3)

Splunk Enterprise used to allow access to debugging endpoints by default. This is no longer the case. When you upgrade, you won't be able to access the debugging endpoints until you make a change in web.conf and restart Splunk Enterprise:

[settings]
enableWebDebug = true

Migration from search head pooling to search head clustering

If you want to migrate to search head clustering from a standalone search head, or from search head pooling, which has been deprecated, you must follow specific instructions and use new Splunk Enterprise instances for search head cluster members. See the following topics in the Distributed Search manual for more information on migrating to search head clustering:

• Migrate from standalone search heads
• Migrate from search head pooling

Search head clusters now respect user- and role-based search quotas

(Originally introduced in version 6.3)

When you upgrade to Splunk Enterprise 7.0, any search head clusters that you have deployed will respect and enforce search quotas that are in place for users and roles. This might result in some searches not executing, depending on the number of concurrent searches that are active. To defeat this feature, set the following attributes in limits.conf:

shc_role_quota_enforcement = false
shc_local_quota_check = true

The App Key Value Store service might increase disk space usage

(Originally introduced in version 6.2)

The App Key Value Store (or KV Store) service, which provides a way for you to maintain the state of your application by storing and retrieving data within it, might cause an increase in disk usage on the instance, depending on how many apps you run. You can change where the KV Store service puts its data by editing server.conf, and you can restore data used by KV Store with the splunk clean CLI command. See About the app key value store in the Admin Manual.

Splunk Enterprise now identifies search commands that could negatively impact performance

In an effort to improve security and performance, some Search Processing Language (SPL) commands have been tagged with a variable that prompts Splunk Enterprise to warn you about performance impact when you use them in a search query. After an upgrade, you might see a warning message that a search that you run has commands that might have risky side effects.

Results for unaccelerated data models now match results from accelerated data models

(Originally introduced in version 6.2)

The way that unaccelerated data models query indexes for events has changed.

These models now query all indexes, rather than just the default index. This means that the number of results you see for unaccelerated data models should now match the number of results you see for accelerated data models.

After you upgrade, you might see more results for an unaccelerated data model than you did prior to upgrading.

New installed services open additional network ports

(Originally introduced in version 6.2)

Splunk Enterprise installs and runs two additional services: App Key Value Store and App Server. This opens two network ports by default on the local machine: 8065 (for App Server) and 8191 (for App Key Value Store.) Confirm that no firewalls block these ports. The App Key Value Store service also starts an additional process, mongod. You can disable App Key Value Store by editing server.conf and changing the dbPath attribute to a valid path on a file system that the Splunk Enterprise instance can reach. See About the app key value store in the Admin Manual.

Formatting for single-value visualizations has changed

(Originally introduced in version 6.3)

The formatting for single-value visualizations has changed in that these visualizations have been redesigned to be as readable as possible from a distance. When you upgrade, dashboards that use these visualizations might be impacted by very large letters or numbers.

There are several ways to change this formatting:

• Make use of the new time context if you show a numeric value that you can query over time.
• Use Simple XML to reduce the single value panel height from its default of 115 pixels
• Replace the single value panel with a custom HTML panel.

See this post on Splunk Answers for additional information prior to upgrading.

New default values for some attributes can impact Splunk operations over SSL

(Originally introduced in version 6.3)

There are new defaults which can possibly impact running Splunk Enterprise over SSL:

• The supportSSLv3Only attribute, which controls how Splunk Enterprise handles SSL clients, now has a default setting of true. This means that only clients who can speak the SSL v3 protocol can connect to the Splunk Enterprise instance.
• The cipherSuite attribute, which controls the encryption protocols that can be used during an SSL connection, now has a default setting of TLSV1+HIGH:@STRENGTH. This means that only clients that possess a Transport Layer Security (TLS) v1 cipher with a 'high' encryption suite can connect to a Splunk Enterprise instance.

Login page customization has changed

Login page customization has changed as of version 7.0 of Splunk Enterprise. To learn how the new customization process works, see Customize the login page in Developing Views and Apps for Splunk Web.

Windows-specific changes

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

(Originally introduced in version 6.6)

The TLS and SSL cipher suites that come with version 7.0 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 Windows Event Log monitoring input has improved performance, new settings, and changes in behavior

(Originally introduced in version 6.6)

The Windows Event Log monitoring input now 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:

• 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.

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

(Originally introduced in version 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.

Support for Internet Explorer versions 9 and 10 has been removed

(Originally introduced in version 6.5)

Microsoft has announced that support for all versions of Internet Explorer below 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 earlier versions of Internet Explorer.

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

The Windows host monitoring input no longer monitors application state

(Originally introduced in version 6.3)

The Windows host monitor input has been modified to no longer monitor the state of installed applications.

Due to a bug in the system call that Splunk Enterprise uses to monitor application state, the Windows Installer service attempts to reconfigure all installed applications.

When you upgrade, any Windows host monitoring input stanzas that reference the "Application" attribute no longer function. The host monitoring input continues to function with other host monitoring stanza types that you have defined.

To get application state data, use the Windows Event Log monitor and search for Event ID Nos. 11707 (for installation) or 11724 (for uninstallation/removal.) You can also use a PowerShell script or the Windows Management Instrumentation Command-line tool (WMIC) as follows:

• PowerShell: Get-WmiObject -Class Win32_Product | Format-List -Property Name,InstallDate,InstallLocation,PackageCache,Vendor,Version,IdentifyingNum
• WMIC: wmic product get name,version,installdate

New installation and upgrade procedures

(Originally introduced in version 6.2)

The Windows version of Splunk Enterprise has a streamlined installation and upgrade workflow. The installer now assumes specific defaults for new installations, and retains existing settings for upgrades by default. To make any changes from the default on installations, you must check the Customize options button. During upgrades, your only option is to accept the license agreement. See Installation options.

Changes have been made to support more granular authorization for Windows inputs

(Originally introduced in version 6.4)

Splunk Enterprise has been updated to allow for more control when using Windows inputs like Network Monitoring and Host Monitoring. If you use Splunk Enterprise as a user with a role that does not inherit from other roles, it is possible that the user might not be able to access certain Windows inputs.

The Splunk Web service installs but does not run

(Originally introduced in version 6.2)

The splunkd service handles all Splunk Web operations. However, on Windows instances, the installer still installs the splunkweb service, although the service quits immediately on launch when operating in normal mode. You can configure the service to run in legacy mode by changing a configuration parameter in web.conf. See Start Splunk Enterprise on Windows in legacy mode in the Admin Manual.

Do not run Splunk Web in legacy mode permanently. Use legacy mode to temporarily work around issues introduced by the new integration of the user interface with the main splunkd service. After you correct the issues, return Splunk Web to normal mode as soon as possible.

No support for enabling Federal Information Processing Standards (FIPS) after an upgrade

There is no supported upgrade path from a Splunk Enterprise system with enabled Secure Sockets Layer (SSL) certificates to a system with FIPS enabled. If you need to enable FIPS, you must do so on a new installation.

The default behavior for translating security identifiers (SID) and globally unique identifiers (GUIDs) when monitoring Windows Event Log data has changed

(Originally introduced in version 6.2)

The etc_resolve_ad_obj attribute, which controls whether or not Splunk Enterprise attempts to resolve SIDs and GUIDs when it monitors event log channels, is now disabled by default for all channels. When you upgrade, any inputs.conf monitor stanzas that do not explicitly define this attribute will no longer perform this translation.

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.