SEPM replication mechanism details

[Migration User]

Dear Community

I am planning on setting up SEPM in two separate data centers and do replication between them.

I have not been able to find any official Symantec articles with detailed info on the actual replication mechanism. Some forum posts have indicated that this is not native SQL replication, but I have not seen any official documents with much details on this.

I will have a SQL Server 2008 in each data centers. As I have other production databases, I was planning on doing log shipping. I was wondering if I could do the same for the SEP database or will this not work?

Can anyone share further details.

[Migration User]

See this articles

Replication and considerations

https://www-secure.symantec.com/connect/articles/replication-and-considerations

 

How replication works

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

Managing sites and replication

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

[Migration User]

Check it

How replication works

Article:HOWTO55328

|

Created: 2011-06-29

|

Updated: 2011-12-16

|

Article URL http://www.symantec.com/docs/HOWTO55328

How to add "Replication Partners" and Schedule Replication

Article:TECH104986

|

Created: 2008-01-22

|

Updated: 2011-10-12

|

Article URL http://www.symantec.com/docs/TECH104986

How to install the Symantec Endpoint Protection Manager(s) for replication

Article:TECH105928

|

Created: 2008-01-16

|

Updated: 2010-08-13

|

Article URL http://www.symantec.com/docs/TECH105928

How to configure the replication schedule for Symantec Endpoint Protection Manager (SEPM)

Article:TECH104454

|

Created: 2008-01-21

|

Updated: 2010-08-18

|

Article URL http://www.symantec.com/docs/TECH104454

Video also available for same :

https://www-secure.symantec.com/connect/videos/replication-concepts-and-configuration

Replication and considerations

https://www-secure.symantec.com/connect/articles/replication-and-considerations

[Migration User]

Thank you both.

That article shed some light, but still does not mention anything about the actual mechanism being used.

Can I use SQL log shipping or do I have to let SEPM manage the replication?

 

I also noticed the article mentioned to keep the number of content revisions to a minimum. That kind of goes against other recommendations to increasing the number of content revisions to allow more clients to download only a delta rather than the entire content revision during an update cycle.

 

As for backup, the article states (under best poractices, item 8) that I should delete a replication partner when I want to manually back up the database.

Does this means that I cannot use e.g. Backup Exec or native SQL backup jobs to back up the SEP database at all, if the database is part of a SEPM replication setup?

 

The note mentioned about not using LiveUpdate in continuous mode and that LiveUpdate should not overlap replication schedule, does that only apply when adding a new replication partner or is this a general recommendation?

 

[SMLatCST]

I think I'd posted in your other thread an article on the the process behind replication:

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

In answer to your questions though:

1. SEP Replication is entirely managed by the SEPMs.  There is no need to make any changes within SQL.  SQL Mirroring is supported, but that is for HA of the SQL DB, and not of the SEPM (i.e. SQL Replication can handle losing a SQL Server, but not a SEPM)
2. Regarding Content revisions, I suspect that was written when you could not omit content from replication.  This shouldn't be much of a worry now, as you can choose to not replicate content (Defs/, Client Installers, etc.)
3. Backups and LiveUpdate:
   I'm answering these together as the reasoning behind them is the same.  The aim behind the recommendations is to strictly avoid messing with the DB during replication (as you'd risk the DB going kablooey).

Oh yeah, it's worth noting that if you're not replicating content, then you will have to have at least one SEPM in each site doing LiveUpdates (just not continuously, and not during replication).

[Migration User]

SMLatCST

 

As always, many thanks for your detailed feedback.

As for backup, does this mean that companies having a multi-site setup with replication never perform backup of the SEP database?

I do see the potential issue with a third party application accessing the DB and put a lock on it while SEPM replication or LiveUpdate is running. But not backing up a DB can be risky business.

[SMLatCST]

It typically just means that they schedule the Backups and the replciation waaaaaaay apart 

[Migration User]

I see. That makes sense.

In terms of replication , LiveUpdate (and adding backup to the mix), are there any best practices or guidelines in terms of schedule/frequency?

I obviously would like to run LiveUpdate frequently enough to avoid delay in deploying new content to my endpoints.

I would also like replication to be as frequent as possible to make sure my RPO is not too far from current.

 

[SMLatCST]

It kinda depends on how long replication takes in your environment TBH.  When you initially set things up, chances are this will complete in less than an hour, leaving you with plenty of time to get daily LiveUpdates in.

The kicker is that the time required for replication is a moving target.  As more clients are added and more changes made, the time required will increase.  This means you'll need to reveiw this fairly regularly in order to judge when you can fit in a LiveUdpate and a Backup.

You can keep the replication times to a minimum by not replicating logs and/or content.  Just be aware that not replicating logs means you lose centralised reporting (centralised management is unaffected), and not replicating content means that each site will have to run it's own LiveUpdates.

[SMLatCST]

Oh yeah, from a security stand point, I'd try to fit it at least one LiveUpdate run a day.  It just depends on your priorities (security vs risk of DB possible corruption).

[Migration User]

Thank you.

I would definitely need to replicate logs. I might hold off performing any DB backup for the first few days or even a couple of weeks to see how the replication mechanism is working and how long it takes every time.

And I would absolutely need to run at least one LiveUpdate daily. On that note, I might need some advise on LiveUpdate config, but will post a new question on that topic later on.

[SMLatCST]

Aye aye cap'n 

[SMLatCST]

Oh yeah, somethign else just popped into my head.

As the centralised reporting is a requirement for you, it's worth noting that SEP has the ablity to feed events out to a Syslog server:

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

Obviously, this would require that you have a SIEM solution of some sort (and want to use it for SEP reporting), but this could potentially negate the requirement for log replication, allowing you greater flexibility in your SEP LiveUpdate/Backup scheduling.

[Migration User]

Thank you for the suggestion. Indeed something to consider, especially if I have other systems/components that will require Syslog for events/alerts.