Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Need reality check/advice on upgrade plan SEP 11.0 to 12.1.2 (encryption password missing)

Created: 05 Dec 2012 • Updated: 06 Dec 2012 | 5 comments
This issue has been solved. See solution.

Hello everyone,

We are interested in updating our SEP from V 11 to 12.1.2 to support Win 8 clients (Win 8 is in testing mode here … the current machine has an unmanaged version of 12.1.2 on it). 

In going over the somewhat complex upgrade procedure and the “Disaster Recovery” part, I note that we do not have the encryption password (a previous employee installed it and did not recover it).  This means that we could go through an update in place but would need to run SYLINKREPLACER and push a new Sylink out to the clients.  It’s a small enough network that this shouldn’t be a huge problem, but obviously this made me think. 

I’d like to be able to “back out” easily and be able to minimize downtime for the application.  Our current SEP console runs on a VM.  I was wondering how feasible the following might be:

  1. Gather all backups for current SEP server per DR document
  2. Re-name and Re-IP the current SEP server
  3. Redistribute sylink.xml and see how things look on the console
  4. Build new server with the name and IP of the “original” server
  5. Install 12.1.2 fresh on server with parameters from old server (if so which ones beyond name and IP?)
  6. Run limited test
  7. Restore database from old server  (this can be from step 1, before rename)
  8. Run sylinkreplacer again when I’m ready to pull the plug
  9. Check the clients populating on new server (with original name and IP)
  10. Stop SEP services on former server, decommission

If I can accomplish this with the steps in another order (e.g. build the 12.1.2 server and then rename/re-IP it after testing is done and before restoring the database), I’m all ears. 

As a wrinkle, we do have some XP and 2000 clients that are “legacy” – not many, and they have already been moved into a separate OU under SEP, but they will need the old client version. 

Are there white papers or old threads about this?  Has someone been through the process recently and have wisdom to impart?  I did a Google search but apparently wasn’t using good terms, as I didn’t get the results I was hoping for. 

Many thanks!

Charlotte

 

Comments 5 CommentsJump to latest comment

CharlotteB's picture

Thanks for the link, I did try, but was unable to find the SEPM in ODBC as per it. 

pete_4u2002's picture

this password cannot be retrieved.

plan all steps as in DR , upgrade , it should be smooth . in case of failure then use sylink replacer or CDW for replacing the sylink (https://www-secure.symantec.com/connect/articles/sep-12-ru2-and-reset-client-communication)

 

on windows 200 client, you can have SEP 11 version. SEPM 12 can manage SEP 11 clients, however its better to plan for upgrade these servers

SMLatCST's picture

As the Encryption password is now unavailable and you have to swap the Sylink.xml files on all your clients anyway, then there is no reason to give the new server the same name and IP address as the old one.  The sole reason for giving a new SEPM the same name/IP is to re-establish communications with clients that are looking for the SEPM on those addresses withuot swapping the sylink.

Like I say, as you'll have to swap the sylink file anyay, you're better off building the new SEPM with a different name and IP address.  This means you can have both SEPMs up at the same time, and move SEP clients across in a managed fashion, with the rolback option of redirecting them back to the original SEPM if you need.

For the Win2k clients, you'll need to run SEP11 on these, but they can be managed by a v12.1 SEPM and it is supported.

SOLUTION
CharlotteB's picture

I've just been so wrapped up in the process that I overlooked this perfectly common-sense option.  That looks like our way forward!  Yeah, no reason to keep the same name/IP if we are going to have to run sylinkreplacer anyway.   Many thanks!