Endpoint Protection

I am currently preparing to migrate from SEP 11.0.7000.975 to SEP 12.1 RU2. Our environment does not run off of the embedded database as we use a separate server running SQL.

I have read through all the documents and taken classes on SEP 12 and most everything in all documentation is for the embedded db only. What happens with SQL?

I am planning on building a separate SQL server and 2 new SEPM consoles. We will back up the database and restore to the new SQL server. Then install SEP 11 to the new servers and perform disaster recovery. Once running we will upgrade to SEP 12.1 RU2 and then use the sylink mover to get all the 11 clients moved to the new server.

This seems to be the easiest way with fall back plan is to put clients back on the old infrastructure. However there is no real documentation on this or any other knowledge for SQL installation types I have found. Everything I have read may mention SQL but then just goes into embedded database structure. I have over 35000 clients. I can't do embedded. One huge question on this is that everything states that the db will increase 3x during migration. It also states for embedded only. Is this true? Will my SQL also expand to 3x with the migration to 12? What other issues will we have by doing this? I know we can't access the 12 database from 11 management consoles or it will corrupt the database. Is there any other restrictions to doing this?

Any help would be much appreciated.

Have you seen these KB articles?

Best practices for upgrading to Symantec Endpoint Protection 12.1.2

Symantec Endpoint Protection 12.1: Best Practices for Disaster Recovery with the Symantec Endpoint Protection Manager

Have a look at the migration documentation to RU2:

http://www.symantec.com/docs/TECH197426

"I am planning on building a separate SQL server and 2 new SEPM consoles. We will back up the database and restore to the new SQL server. Then install SEP 11 to the new servers and perform disaster recovery. Once running we will upgrade to SEP 12.1 RU2 and then use the sylink mover to get all the 11 clients moved to the new server."

- if you perform the disaster recovery with import of the settings from the old server the use of sylink replacer won't be required - the clients should be still connected to the server - as well after later upgrade to RU2.

for moving of clients you can use SEPM 12 RU2 feature as highlighted in below article.

https://www-secure.symantec.com/connect/articles/sep-121-ru2-and-reset-client-communication

The problem is I am not even sure this will work...IP address of new servers will be different...it sounds good but DR requires same IP address. However I think the sylink replacer would tell all clients to move to the new server thus not an issue once the new server comes online with the new instance of SEPM 11 and is upgraded to 12.

So does anyone know if the SQL database will need 3x space? We are talking about going from around 50GB of space to 150GB when moving to SEP 12. Again there is only mention of the embedded db growing to 3x...not the external SQL version. I think I have read just about every document there is and nothing mentions anything specific to SQL...only embedded.

Hi,

Check this article

SEPM 12.1 Fresh install with SQL database - graphical overview

https://www-secure.symantec.com/connect/articles/sepm-121-fresh-installation-sql-database-graphical-overview

One huge question on this is that everything states that the db will increase 3x during migration. It also states for embedded only. Is this true?

--> Yes it's applicable in Embedded database only.

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.

Reference :  http://www.symantec.com/docs/TECH162730

From SEP 12.1 RU2 onwards no need to use Sylink replacer you can use built in feature to reset server client communication.

Check this artilce: https://www-secure.symantec.com/connect/articles/sep-12-ru2-and

Ok...lots of good info and most of it I already bookmarked. Continuing on.