Video Screencast Help

Out-of-place upgrade of SEPM 11 to SEPM 12

Created: 07 Nov 2012 • Updated: 08 Nov 2012 | 6 comments

Hi,

We have a simple environment: no replication, one LiveUpdate server in the DMZ, and one SEPM 11.0.5002.333 server inside. There are around 1,500 clients and we use the embedded database.

We want to do an out-of-place upgrade (or what I call a migration) from SEPM 11 to SEPM 12, without changing the existing SEPM 11 production environment. In other words, a phased upgrade, bringing clients gradually across to SEPM 12, so that any potential problems and headaches are averted.

I think this should be possible using the steps below, but it would be good if someone could confirm this:

  1. Create new Windows servers
  2. Install SEPM 12 (independent of existing SEPM 11 install)
  3. Export policies on SEPM 11 and import into SEPM 12
  4. Manually bring other settings across and configure SEPM 12 as required
  5. Select a few SEPM 11 clients (for testing so to speak) and with the sylink tool, point these clients at SEPM 12
  6. Upgrade the selected clients to version 12
  7. Test and tweak with the now-upgraded clients
  8. Once all good, point remainder clients at SEPM 12 and upgrade
  9. Remove SEPM 11 servers

Now one thing that will happen is that we will loose the history of the clients; I can live with that.

As far as alternative approaches go, I have seen a discussion around first creating a duplicate SEPM 11 server, then either replicating or doing a database backup and recovery. Then its upgrading to SEPM 12. This was done in order to upgrade the underlying Windows version and I think that is a good approach for that. But, this does not solve the problem of having to upgrade to SEPM 12 in one go with all the production clients connected to it, which is just too risky.

Thanks for reading and don't be shy to comment with recommendations or better still a go-ahead with the above steps,

someforum64

Comments 6 CommentsJump to latest comment

.Brian's picture

Looks pretty good.

You can directly upgrade 11.x clients from the 12.1 SEPM though using the migration wizard. You don't need to move the 11.x clients over first. But either way will work, whatever is easier for you.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Chetan Savade's picture

Hi,

Plan looks good to me as well.

Only few points I would like to add here:

1) Follow Supported upgrade path only. Do not upgrade SEP clients directly from SEP RU5 to SEP 12.1 RU1 MP1.

First you should upgrade to SEP 12.1 RU1 then MP1.

If SEP 12.1 RU2 releases in coming days then you can migrate clients directly from RU5 to SEP 12.1 RU2.

I would suggest to wait till RU2 release.

Test above plan with RU2 only.

 

 

Chetan Savade
Sr Technical Support Engineer, Endpoint Security
Enterprise Technical Support
CCNA | CCNP | MCSE | SCTS |

Don't forget to mark your thread as 'SOLVED' with the answer that best helps you.<

sandra.g's picture

I would agree with waiting for RU2. It will save you from needing to stagger the SEPM update (you can go directly from 11 RU5 to 12 RU2). Plus, if you don't want to upgrade all clients right away, you will be able to deploy a Communication Update Package directly from the SEPM. This connects clients to the new SEPM. Sylinkreplacer will no longer be needed.

sandra

Symantec, Information Developer
Installation, Migration, Deployment and Patching
User Protection & Productivity, Endpoint Protection

Don't forget to mark your thread as 'solved' with the answer that best help

MichaelD50's picture

I would suggest posting this to the SEP support forum for Enterprise Edition

This is the discussion forum for Small Business Edition (SBE)

MJD

Mithun Sanghavi's picture

Hello,

Moved the Thread to the correct Forums Queue.

I favour your plan completely as well as suggest you to consider the suggestions provided by Chetan above.

Secondly, a proper backup plan is also recommended.

SEP 12.1 RU2 Release is due anytime this year. There is no official date for the Release of SEP 12.1 RU2.

Check this Thread- http://bit.ly/TOWOF5

Hope that helps!!

 

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

Beppe's picture

Hi,

in my opinion this plan to migrate a single SEPM in a middle size environment is OK on the paper but not less risky than other more comfortable procedures. A lot of effort has been put to implement in the product a migration wizard from 11.0 to 12.1 as much simple, safe and automatic as possible while your manual activities to move settings and clients from a SEPM to another look to me like a source of headache, maybe more stress, hence higher risk of human mistakes.

A different approach could be:

1) take a proper backup of your SEPM 11.0:
http://www.symantec.com/docs/TECH102333

2) restore it in a separete test network, you need to keep the same IP and hostname:
http://www.symantec.com/docs/TECH102333
for a realistic simulation, install a test SEP client too but with the sylink.xml of the production installation, check if the connectivity is OK, you will then know if you are really able to recover your SEPM in case of issues

3) test the migration and the product in the test environment

4) once you are more comfortable with SEP 12.1, migrate only the SEPM in production (after fresh backup), no consequences are expected in the clients since product version and settings are kept but, in case of issue, you already know how to roll back to SEPM 11 (step 2)

5) once anything is OK with the SEPM, migrate only a limited number of clients from 11 to 12.1 for test, if anything is OK, move on with the rest

The advantages of the above procedures are:
- increase confidence in the disaster recovery procedure
- reduce the risk of human mistakes by using automatic procedures
- keep settings and logs with no effort
- put more focus on testing the product and the official procedures meant for it in regards of backup, recovery and migration rather than custom approaches.
 

Regards,

Giuseppe