||If you have completed an upgrade from a release prior to Geneva, you must
perform the following tasks after you activate Change Management core to ensure that
change types and customizations are updated.
- If you had created newer change types in addition to the default change types,
then you must customize them based on the new change types being
- Modify the customizations that are affected to use the new change type
- If you had the Bulk CI plugin installed, then install the Mass updates CI
plugin for enhanced user experience and alignment with the new plugins.
For additional upgrade considerations, see Change Management upgrade
||When you upgrade to Helsinki, you have the option to use either the legacy chat
feature or Connect Support. You cannot use the two concurrently. For configuration
details, see Connect Support upgrade information.
- When you upgrade to Helsinki from a pre-Geneva release, you can still use the
legacy identifiers provided with your instance or switch to the new CMDB
identifiers by setting a system property. It is important to note that if
Service Mapping is active on your instance, the CMDB identifiers are always used
regardless of the property value. For details, see Discovery
Upgrades to versions prior to Helsinki Patch 10
can take an excessive amount of time if the Discovery Log [discovery_log]
or TCP Connection [cmdb_tcp] table contains a very large number of records.
Upgrade performance issues occur when the sys_domain or sys_domain_path
fields, used by domain separated systems, are added and populated in these
tables. To improve performance, reduce the number of rows in the discovery_log
and cmdb_tcp tables prior to upgrading to ensure they contain somewhat less
than 1 million rows.
Important: If you remove records from the TCP
Connection [cmdb_tcp] table, be sure to run any required Discovery after the
upgrade to repopulate the table.
|HR Service Management
||The Helsinki release contains new items, including a new plugin and HR
services. When you upgrade, you must reconcile your custom catalog items and
categories with new ones provided in the release. For details, see Human Resources upgrade information.
|GRC: Policy and Compliance Management
||In Helsinki Patch 7 and later releases, the GRC: UCF Import
(com.snc.ucf_import_add_on) plugin was deprecated and replaced by the new GRC:
Compliance UCF (com.sn_comp_ucf) plugin. See Policy and Compliance UCF upgrade instructions.
If your GRC effective contract date is before December
1, 2016, you are entitled to a free UCF CCH account for the period of December
1, 2016 through November 30, 2018. For customers on Helsinki (Patch 7 and
above), or Istanbul and whose effective GRC contract start dates start on Dec 1,
2016 or after, you need to arrange your own subscription if your organization
plans on using Unified Controls Compliance as the provider of your controls
library. For more information about establishing a UCF CCH account, see Unified Compliance
Knowledge Management has changed with Knowledge v3, which is
enabled by default for all instances. For migration information, see Knowledge Management v3
Some of the key differences between Legacy Knowledge and Knowledge v3 are:
- Multiple knowledge bases (instead of one knowledge base)
- Separate customizable workflows available for each knowledge base (instead
of a single lifecycle shared by all articles)
- Category structure that supports any number of levels (instead of a
two-level organizational structure using Topic and Category)
- Permissions defined per knowledge base and article, using user criteria
(instead of per article, using roles and ACLs)
For additional upgrade considerations, see the links under Migrate.
- To ensure that your MID Servers can upgrade successfully, run a series of manual tests
for free disk space, access to the download server, and file permissions on the MID
Server host. For details, see Test the MID Server before an
After all MID Servers have been upgraded to Geneva or higher,
complete the post-upgrade steps listed in the Workaround
section of KB0597396
- The MID Server application is downloadable from the ServiceNow service instance. The
MID Server is upgraded automatically when you upgrade the instance. However, you can
configure the version number to control MID Server upgrades. The MID Server is
configured to check with the ServiceNow instance hourly to determine whether it needs to
upgrade. This configurable behavior allows the MID Server to upgrade automatically when
the instance upgrades.
- In Helsinki, the MID Server can run SSH commands using either the J2SSH client or the
proprietary ServiceNow® SNCSSH
client. When you upgrade from Dublin or earlier, the MID Server property that controls
the SSH client selection is not active in your upgraded instance, and the MID Server
will use the J2SSH client by default. To enable the SNCSSH client, you must add the
mid.property.ssh.use_snc MID Server property and set it to
true. Instances upgraded from Eureka or later have the SNCSSH
client enabled by default, and no configuration is required. For details, see MID Server properties.
||Review Performance Analytics upgrade information for information about deprecated
properties and the potential impact on your configuration from the migration to the
||Upgrades from earlier versions of the platform must activate the Report
Security plugin manually to avoid overwriting custom ACLs. For instruction about
enabling this plugin either before or after the upgrade, see Reporting upgrade information.
||After upgrading to Helsinki, ServiceNow does not
support outbound connections to TLSv1-only endpoints.