Video Screencast Help

Endpoint Encryption 8.2 MP1 Migration to New Hardware

Created: 14 Nov 2012 • Updated: 15 Nov 2012 | 2 comments
This issue has been solved. See solution.

We have decided to migrate our Symantec Endpoint Encryption Management Server to new hardware, and have decided at the same time to install Windows Server 2008 R2 as the Operating System.

The current server runs Server 2003, and SEEMS uses a local SQLExpress database.

We would like to retain the server hostname, and IP Address on the new server.

We want to ensure that clients are able to check in with the server after the migration.  Down-time is not an issue as the work will be carried out outside of business hours.

Is there a set migration plan for this type of migration?  Any assistance would be greatly appreciated.

Comments 2 CommentsJump to latest comment

SMLatCST's picture

The below article might be of used if you want step by step instructions:

Combine this with a DB move and you're pretty much away.  The DB move is as simple as:

  1. Backup DB from old SQL server
  2. Restore DB onto new SQL server
  3. Open SEEMS Configuration Manager
  4. Enter new SQL details

As long as authentication is ready, that's all there is to the SQL move.

Alternatively (and this might be preferred) is to build your new server in an isolated network (with the same name/IP Address), backup/copy/restore the SEEMSDB from your old server to the new, then install the SEE Management Server.

Then you should be to connect an existing client to this test/isolated network to see if communications work, If all's good, then you can shut down the old server, and connect the new into the production network. This also means you'd have the rollback option of switching off the new server and powering the old one back up if anything goes wrong.

Yet another option is to contact a Symantec partner (such as ourselves) to help with this wink

WilliamGraham's picture

Thank-you very much for your answer.  I had noticed that Tech Article you posted, but thought our scenario was different based on a database move.  But what you're saying makes perfect sense.

I particularly like the idea of building the new server isolated, leaving the production server unmodified.

I'm going to give this a shot.