This documentation does not apply to the most recent version of Splunk.
This documentation applies to the following versions of Splunk: 3.3 , 3.3.1 , 3.3.2 , 3.3.3 , 3.3.4 , 3.4 , 3.4.1 , 3.4.2 , 3.4.3 , 3.4.5 , 3.4.6 , 3.4.8 , 3.4.9 , 3.4.10 , 3.4.11 , 3.4.12
This topic discusses various issues and considerations you should review before upgrading to Splunk 3.3.
You should also review the Known Issues for additional information before you upgrade.
Before you perform the upgrade, stop Splunk and back up all of your files, including configurations, data and binaries. Splunk does not provide a means of downgrading to previous versions; if you need to revert to an older Splunk release, just reinstall it.
If you are using LDAP authentication and are upgrading from any version of Splunk to version 3.4, the Leopard DMG manager will delete your existing ldap.conf and replace it with the newer ldap.conf.default. If you've made changes to ldap.conf, make a backup copy of this file before upgrading to 3.4 and then reinstate it after you have upgraded.
Starting with version 3.3, Splunk's custom bundle directory structure and terminology have both changed. Bundles are now referred to as applications, and a new directory structure is in place. The existing directory structure and nomenclature will be supported in 3.3, but a switch to the new structure will be enforced in a future release. For detailed information about the new applications directory structure, refer to the documentation about configuration files.
Splunk provides a script for migrating your existing bundles directories to the new structure. Refer to these instructions for more information
$SPLUNK_HOME/bin/scripts. Make a backup of these scripts and reinstate them after the upgrade.
compressedExport.sh or flatfileExport.sh), these scripts may be removed or overwritten upon upgrade. Make a backup of these scripts and reinstate them after the upgrade.
Be aware of the following regarding saved searches:
foo=bar and you have an indexed field configured from previous versions as foo::bar, your search will fail if bar isn't anywhere in the raw data of an event. Make saved searches that fail for this reason work by either:
INDEXED = True or INDEXED_VALUE = False in the stanza for foo in fields.conf.
foo=bar with foo::bar.
| admin or | metaevents are not supported, and will generate a warning.
If you have a saved search containing the admin command which also contains a reference to the query field, you must recreate your search so that it does not use query. The admin command now uses search instead of query.
Affected search examples:
| admin mysavedsearches | rename query AS term stanza as name | admin mysavedsearches | top query
Unaffected search examples:
| admin mysavedsearches | rename stanza as name | admin mysavedsearches | stats count(name)
If you have made changes to the default values in indexes.conf, the configuration will not migrate. Make a backup of your changes and re-add them post-upgrade.
As mentioned in the Known Issues, you must upgrade all members of your distributed cluster to the same version.
As mentioned in the Known Issues, if you are running Splunk's deployment server, you must upgrade the deployment server and all its clients to the same version. Splunk recommends that you upgrade your Splunk deployment server first, before you migrate your other Splunk instances.
If you are unable to migrate all clients at one time, you can set up two deployment servers, one for your new 3.3.x clients, and one for your 3.1.x clients. This way, you can move each client over to communicate with the 3.3.x deployment server as you are able to upgrade it.