How do I migrate SEG to a later Windows version?


This article applies to:

  • Trustwave MailMarshal (SEG)
  • Upgrading to a new version on a different server
    • For example if the new version requires a later Windows Operating System version 

Question:

How do I migrate SEG to a later Windows version?

Comments:

  • Trustwave SEG can upgrade a configuration on import, or a database when first connecting. Using this ability you can move a single server installation to a new server in a few steps.
    • The new version/installation of SEG must support direct upgrade from the version you are migrating from.
    • MailMarshal (SEG) 10.X supports direct upgrade from 8.2.3 and above.
    • SEG 8.0 supports direct upgrade from 7.3 and above.
    • SEG 7.3 and below supports direct upgrade from 6.7 and above.
  • Moving an array requires more effort because you must adjust the processing server Node IDs.
  • In either case, expect some down time.

Procedure:

Before you start, upgrade all SEG servers to the latest SEG version supported on the current Windows servers, and verify the product functionality.

Migrating a Single Server or Array Manager

  1. On the existing installation, open the Configurator and back up/export the configuration.
    • You may also need to back up other items such as the custom file type configuration (filetype.cfg)
    • Caution: If moving to MailMarshal 10.X (and best practice for any version):
      • Older installations may have rules that reference the Category Scripts SpamZeroDay.xml and KnownThreats.xml
      • These rules cause the engine to fail in 10.X because included files are no longer provided by Trustwave. In older versions, these rules are no longer effective.
      • You must remove these rules before backing up the configuration.
      • After upgrading, review current Default Rules and add the recommended anti-spam and anti-malware rules.
  2. Stop SEG services on the old installation. For MailMarshal (SEG) 10.X also stop the SEG Configuration Service and SEG Management Console websites.
  3. If necessary, move the production SEG databases to the new production location.
    • This includes the main SEG database, the Syslog database (if enabled), and the SEG Configuration Service database (MailMarshal (SEG) 10.X only).
    • Follow the steps in Trustwave Knowledgebase article Q10410: How do I move my SEG, ECM, or MailMarshal SQL database to a new server? 
  4. On the machine that is to host the new installation, run the SEG installer.
  5. Select a custom installation.
  6. Install the Array Manager or single server/all components, as required.
  7. At the Trustwave SEG Database selection screen choose a new temporary database. Do not use the production database used by your existing installation.
    • The database could be hosted with SQL Express on the new SEG server, or on another SQL server.
    • For MailMarshal (SEG) 10.X you must also specify the Configuration Service database. It is safe to enter details of the production SEG Configuration Service database.
  8. Open the SEG Configurator/Management Console and import the configuration exported in step 1 above. Also copy other items such as fileype.cfg.
  9. If you are using a custom database retention period, set this period (Server Properties > Reporting).
    • The database retention period is not included in configuration backup. If not set it reverts to the default 100 days.
  10. Commit the configuration if prompted.
  11. Open the SEG Server Tool (found in the Start Menu program group) and select the production database. When prompted, choose to upgrade the database.
  12. On a single server installation you will be prompted to rejoin the local node to the array.
    • Also update Syslog database details if necessary.
  13. Use the SQL Management Studio or Enterprise Manager to delete the temporary database created in step 4 above.
  14. On a single server installation, you can now start email processing services.
    • Remember to update firewall settings or DNS MX records so that incoming mail is now routed to the new SEG server. Likewise, outgoing mail should be forwarded from your internal mail server to the new SEG server.

Migrating Processing Nodes

If you need to migrate processing nodes and preserve quarantined email, follow these steps.

For each server to be migrated:

  1. Run the installer on the new server, and select the SMTP Server option.
  2. When prompted, choose to join the array (the new Array Manager you have just installed).
  3. Do not route any email through the server.
  4. Stop all SEG services on the old server you are moving from, and the new server just installed.
  5. Copy the Quarantine folder and all contents from the old server to the new server.
  6. Update NodeID values
    • In version 8.X and below, use the Registry (for example, HKEY_LOCAL_MACHINE\Software\Trustwave\Secure Email Gateway\Node )
    • In version 10.X, see the file controller.config.json (Back up this file before making any changes.)
    • For full details of the location for each product version, see article Q10832.
  7. On the old server, note the value of the NodeId entry. This will be the oldNodeID.
  8. On the new server:
    • Note the value of the NodeId DWORD entry. This will be the newNodeID.
    • Change the value of the NodeId DWORD or integer entry to the value you found on the old server. Save the file. Do not start services yet.
  9. If you are using TLS for inbound connections and the server is using the same common name you can copy the priv.key and cacert.pem from old nodeconfig directory to the new server.  However, if the common name in the certificate does not match the server name you will need to generate a new certificate in the SEG Configurator. (If you have purchased a CA signed certificate and the name changes, you will need to purchase a new one.)

Next, make changes to SQL data and apply the changes.

  1. On your SQL Server, open SQL Server Management Studio.
  2. Select the SEG database from the drop-down list (the default name for older databases is MailMarshal).
  3. In the SQL pane, enter the following (substitute the integer values for old and new node ids):

      DECLARE
      @nServerName  varchar(32),
      @nDescription  varchar(256),
      @nLocation  varchar(128),
      @nTimeZoneOffset  int,
      @nTimeZoneName  varchar(128),
      @nProductVersion  varchar(50),
      @nOSVersion  varchar(128)

      SELECT
      @nServerName  = ServerName,
      @nDescription  = Description,
      @nLocation  = Location,
      @nTimeZoneOffset  = TimeZoneOffset,
      @nTimeZoneName  = TimeZoneName,
      @nProductVersion  = ProductVersion,
      @nOSVersion  = OSVersion
      FROM
      Server
      WHERE
      ServerID =       newNodeId

      UPDATE
      Server
      SET
      ServerName = @nServerName,
      Deleted  = 0,
      Description = @nDescription,
      Location  = @nLocation,
      TimeZoneOffset = @nTimeZoneOffset,
      TimeZoneName = @nTimeZoneName,
      ProductVersion = @nProductVersion,
      OSVersion = @nOSVersion
      WHERE
      ServerID =       oldNodeId

      UPDATE
      Server
      SET
      Deleted = 1
      WHERE
      ServerID =       newNodeId

      GO

      • Replace oldNodeId with the value of the NodeId DWORD from the old server
      • Replace newNodeId with the value of the NodeId DWORD from the new server.
    1. Execute the query. You should see "The command(s) completed successfully" in the result pane.
    2. Restart the MMArrayManager service on the Array Manager using the SEG Server Tool.
    3. Commit the configuration changes.
    4. Restart all SEG services on the new email processing server.

    At this point the migration of messages is complete. Verify the migration by using the SEG Console to search for and view messages.

    Once you have verified migration, update firewall settings or DNS MX records so that incoming mail is now routed to the new SEG server. Likewise, outgoing mail should be forwarded from your mail server to the new SEG server.

     

     

     

     

    Last Modified 7/11/2022.
    https://support.trustwave.com/kb/KnowledgebaseArticle16411.aspx