See also Symantec Endpoint Protection 12.1 System Requirements and Upgrading and migrating to Symantec Endpoint Protection 12.1

Planning for Migration

•          Best Practices

–      Back up the database first.

–      Run DBValidator to confirm the database is healthy.

–      Ensure that tcp port 8014 is opened between clients and servers, tcp port 8445 is opened between console machines and servers.

–      The entire SEPM infrastructure should be brought down and upgraded.

–      Customer has a mix of SEP 11 and 12.1 servers:

•          Once the database schema is updated, only managers of that version can communicate with the database and with other managers.

•          New feature in 12.1: manager won't start unless it matches the schema.

•          SEPM 11.x doesn't have this feature, so it could still start up and corrupt the database.

–      Whether replicating or not, all managers should be upgraded at once.

•          If all SEPMs can't be upgraded, suggest:

–        Break replication between site A.

–        Upgrade site A.

–        Enable replication between sites which have been upgraded.

•          Ensure no clients are roaming between SEP 12.1 Managers and SEP 11.x Managers.

•          Notes

–      If an administrator is responsible for managing both an 11.x Manager and a 12.1 Manager, they will need to install both versions of the Remote Console.  They cannot cross-manage versions.

–     Group update providers (GUPs) are fully backwards compatible. A 12.1 manager can manage 11.0 GUPs and 12.1 GUPs can update 11.0 clients.

–      Tool update:

•          DBValidator has been updated for SEP 12.1.

•          Collectlogs.cmd now collects Apache logs.

–      Tested performance recommendation for 250,000 clients:

•          3 SEPMs, 1 site, 1 hour heartbeat.

Things to watch for

•          Migrations for customers utilizing an embedded database will require additional drive space:

–      The SEP 12.1 SEPM upgrade installer requires three times the current database size (sem5.db) if upgrading from pre-12.1 SEPM with the embedded database only.

–      If the drive space is not available, the Upgrade Wizard would fail to convert the pre-12.1 database to the new 12.1 database.

–      The administrator will get an error message during the pre-install checks and the installation will gracefully fail: "This destination disk has less than 11.10 GB of free space, which is lower than the minimum system requirement. Installation cannot proceed."

•          If you want to move a client, but create a default client install package from a 12.1 Server, existing settings are preserved ("Preserve Existing Settings)"; - the sylink file from the package will not be applied, and the client will continue to point to the existing server.  Remember, 11.x SEPMs cannot manage 12.1 clients.

–      Example:

•          Cloned SEP 11.0 clients.

•          Installed 12.1 SEPM.

•          Exported packages to upgrade to 12.1.

•          Manually ran packages on the client.

•          Client still points to 11.x server.

–      To move the client:

•          Set up new 12.1 SEPM

•          Restore the 11.x database to get policies etc.

•          From 12.1 SEPM, create a client package (using the Client Deployment Wizard (CDW)) without preserving existing settings.

–        Note:  Logs get purged from client.

•          Do a remote push: Find computers by IP, or browse for clients on the network, email, third party apps.

•          If client is in User Mode, any custom policies will be overwritten.

•          System requirements for SEPM:

–      Published minimums are equal to OS published minimums.

–      The values have increased to match the OS requirements.

•          Previously we called out "free memory"; this time we are talking about the actual specs on the box.

–      Increased requirements if you have SQL and SEPM installed on the same box.

•          Importing/Exporting policies:

–      Exporting a policy from an 11.x SEPM and importing into a 12.1 SEPM is fully supported (feature-by-feature).

–      Importing a policy from 12.1 to 11.x SEPM is not blocked, but is not supported.

–      Uses default setting for anything that is new.

–      Ignores any setting that is no longer applicable.

–      If 12.1 SEPM is managing an 11.x client:

•          If the policy includes a setting that the client doesn't use, the setting is ignored. (TruScan settings, for example.)

–      Tamper protection respects previous setting.

Notification Migration

•          Migration from previous versions:

–      When an administrator upgrades from a previous version of SEP, any existing notifications will be preserved across the upgrade. 

–      When the upgrade is from a previous version of Small Business Edition (SBE), all the preserved notifications of type “New software package” will have the “Client package” checkbox checked and the “Security Definitions” checkbox unchecked after the upgrade. 

–      When the upgrade is from a previous Enterprise Edition (EE) version, all the preserved notifications of type “New software package” will have both the “Client package” and “Security Definitions” checkboxes checked after the upgrade.  Note that the behavior described above is only for notifications preserved across the upgrade. 

–      For any “New software package” notification created after the upgrade, the “Client package” checkbox will be checked and the “Security Definitions” checkbox will be unchecked by default.

–      When an administrator upgrades from a previous SEP SBE version, the value of the “Send email to system administrators” checkbox will be preserved across the upgrade.

–      When a administrator upgrades from a previous SEP EE version, the value of the “Send email to system administrator” checkbox will be unchecked for all notification conditions except for “New software package” notification. “New Software package” notification is enabled by default on upgrades from all previous versions.

–      In previous versions of SEP SBE, the company name is stored in the administrator full name field in the server. When an administrator upgrades from a previous SEP 12.0 SBE version, the value of the administrator full name field will be copied over to the company name field in the administrator information, and the value in the administrator name full name field will be cleared.  When an administrator upgrades from a previous version of SEP EE, the value in the administrator full name field will not be copied over to the company name field.

–      SEP 12.1 servers will pre-define a set of notifications “out-of-the-box”.  One issue with pre-defining the notifications is what happens across an upgrade.  If a user has already created one or more notifications with the same type as one of the pre-defined notifications, then the corresponding pre-defined notification is probably not needed.  So, we will not create a pre-defined notification if there is already at least one notification of the same type in the system prior to the upgrade.  Instead, the notification that existed prior to the upgrade will remain after the upgrade.

–      Since some notifications are new in SEP 12.1, it is not possible that a user could have decided not to use them in a previous version of SEP.  If a notification is new in SEP 12.1, then we will enable it even across an upgrade.

•          In some cases, a customer may have purposely decided not to use a particular notification.  Such a customer would potentially be dismayed if, after an upgrade to 12.1, the system administrators started getting notifications email that they specifically did not want.  Since the product currently cannot always determine which notifications have been purposely turned off, the pre-defined notifications will have a different default behavior after an upgrade.  They will be disabled by default, using the mechanism described below.

–      A user has the ability to decide what actions will occur when a notification is triggered by choosing appropriate settings in the “What should happen when this notification is triggered?” section of the notification configuration dialog. Two of the settings are “Send email to system administrators” and “Log the notification”.  On a fresh install of 12.1, the pre-defined notifications have both of these settings enabled. In an upgrade scenario, for the pre-defined notifications that get newly created, potentially neither of these settings will be enabled. This will have the effect of having the notification do nothing by default.  If a user then desires to have any of the disabled pre-defined notifications “do something”, they can edit the notification configuration and enable either of the settings (or modify any of the other settings available in the notification configuration). This behavior will allow the user to not have to create the notification from scratch, but will prevent the notification from being “active” until the user desires it.

•          The following table shows which pre-defined notifications will be enabled in the different upgraded scenarios:

(1) The Trialware License Expiration and Upgrade License Expiration notifications will only be pre-defined if there are no paid licenses in the system. The table above covers the enabled/disabled state for those notifications when they are pre-defined

•          As the table shows, most of the pre-defined notifications will be disabled after an upgrade. The exception is the licensing related notifications when upgrading from a SEP 11.x server. Since the licensing exceptions did not previously exist in SEP 11.x, they will be enabled after the upgrade from 11.x. In all other cases, the pre-defined notifications are not considered to be new and will therefore be disabled.

•          The Trialware License Expiration and Upgrade License Expiration notifications will only be pre-defined if there are no paid licenses in the system. The table above covers the enabled/disabled state for those notifications when they are pre-defined.