Hi Andrew,

This can be achieved and You will have to implement Replication. Each Site will have A SEPM connected to the main SEPM. With replication you will have all logs and other things replicated. You can also configure updates to be replicated between SEPMs.

Client at each site will report to their respective SEPMs,  and will get updates as well from their own SEPMs.

The important thing that you have to make sure is that all Sites should have same SEPM Release Installed

Below are articles for Best Practice for the same
Top 10 Symantec Best Practices - Deploying Symantec Endpoint Protection Architecture
Link: http://service1.symantec.com/SUPPORT/ent-security....

How to install the Symantec Endpoint Protection Manager(s) for replication.
Link: http://service1.symantec.com/SUPPORT/ent-security....

Hi Andrew,

I have designed and implemented 45 sites with replication(SEP MR4)

Keep this in mind

1 Replication
Install the first server as a primary Site and all other server as additional site.

If u have good network infrastructure then u can include client package and live update content replication. otherwise better u remove. (configuration is available in SEPM->Admin->Local Site->Replication partner->%Server%->properties

We always faced problem with replication in our setup. But it was solved once we removed LU content replication and configured separate Internal LU server.

2. Liveupdate
Install LU Admin and configure it get the updates form internet.
Host a lu site using IIS in secondary server.
(Lu Admin and its doc's are available in the second cd of SEP)

Configure all servers to get the updates from internal lu server.
Configure the lu policy of groups with url of lu hosted server.

This solved our major updation issue, because clients had two paths for updation.
One from SEP Manager through GUP and the second one from LU Server.
I scheduled lu policy to be active between 2 to 4PM so that it wont load the network.

Now we have connected 20000 clients with 45 servers and are able to achieve 70% of latest updates.

Andrew

The Replication server at each site will be the best solution for ur requirement. Please visit the link for more details:
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2009012721190648

Else you can alao go with a single managment console at ur datacentre and GUP at evry location. Ur network architecture is good so it will suite as well.

But again replication will help u in case of site failure.

Regards
Ajit

I think the better set up is to use a centralized management console, you can manage all of your client in one SEPM server but you need to use a SQL server.

1. Install Central SQL Server 2005 with Clustering if you want failover.

2. Install Central 2 SEPM Server & configure as a load balancing.

Note :-Install the server at the location where there will be network terminals. For eg If you have 10   2 MB Lease Line sites connecting to one location.
Install one server at that location as a additional site. This will reduce the Servers.Place the servers where u have good & healthy network.

3. Install a additional site server with SQL & SEPM on same Box.

Note:- Do not exceed 20 SEPM servers. Refer SEPM administration guide.

4. Install one live update server & add the live update url in all the additional SEPM servers. this will update all the servers.

5. For the peering sites create a GUP. this will update the clients quickly.

6. Configure Scheduled Replication 

7. Do not replicate client packages.

We have deployed 50K clients with this architectures with 16 SEPM servers & 2 SQL servers & 2Live update servers.
Daily we are updating 3 revisions & update percentage is 80.

Regards...
Ramji Iyyer

Depending on your network architecture you will have to use the combinations of Replication partners & GUP. I will suggest you to not make more than 5 Replication partners ( i.e. also maximum limit) Because if will cause you problems in future if you have may replication partners.

HI andrew have you tried the advise from this thread, let us know if you need more information we are happy to support your needs.

We have a similar setup to what Ramji listed and it works great.  One thing to note is that a GUP will not hand out policy updates nor will it collect logs.  That traffic is directly from the client to the SEPM.  However this traffic is typically verfy small and can be throttled down to lessen network traffic even more.

 Thanks for all your great feedback - I've just taken in all your advice into account and have started a test deployment.
I'll be sure to document each step, and put this up somewhere for others to reference.

My only question is;
Is it possible to replicate between an additional SEPM embedded (Sybase) site, with my central SQL SEPM installation?

I've also noticed that as you setup a replication partner, by default Liveupdate and Packages are set to replicate, which makes the initial replication longer than it needs to be.

Regards,
Andrew

Hi,

I have a similar query, have a central SEPM site with two management servers and SQL clustered DB. I have 10-15 remote locations with around 500 clients each. The central management servers have connection to internet through a proxy and will download signature via internet. My queries are as below -

1) Do i need to setup remote SEPM sites for these locations ? Or do i stick to one central site ? We were thinking of having additional management server at each site which connects to central Database. Each location will have defined management server list which will restrict communication to only local management servers. Is this a good idea ?

2) If the above stands good, how do the signature updates work ? Once they are downloaded to central management server , are they automatically distributed to each management server in the remote location ?

Any other thoughts would help.

Thanks,
Ravi

Replication does not occur directly between databases, rather the merge data is provided to replication partners via the same SEPM servlets that provide communication to the console application.

Although it is most common that all sites would have the same type of database, replication can be set up between SEPMs using different database types.

For example you can set up replication between an embedded database and a Microsoft SQL database.

 Thanks for your prompt reply.
I shall just wait for the replication to finish, although I suspect it's replicating packages by default.

Regards,
Andrew

@Ravi

You can go with replication between Central Site and Remote Sites. Install clients from their respective sites and As you said Client communication will be restricted for that site.

Definition can be updated either by your Central SEPM to remote SEPMs and also by Internet to each SEPM Site.

I would go with less SEPMs.  No need to complicate the environment with replication by having so many SEPMs replicating...  We have a single SEPM managing 15K+ systems and GUPs.  Over 150+ offices ranging from 20-700 systems.

What are the best practices to monitor GUPs?
How often u check the GUP status ?
How do u come to know whether the GUP is alive or dead ?
Is there any option to get Scheduled report on GUP ?

Regards...
Ramji Iyyer

@Fjorq - definitions aside, this would mean 10,000+ SEP clients all pulling policy changes from a central SEPM?

 A question regarding replication.

Do I need to setup Replication schedules on both partners? Changes will only be administered from the central site. I've forwarded the SEPM management port on both partners - I just need to confirm that replication is two way, not just a pull of the changes from the partner.

It is two way it will replicate it automatically.
What schedule you are using? preffer using hourly or daily dont use Auto.

 From my central SEPM server, I've scheduled a daily replication.

Then it should replicate the settings automatically.

 So I guess my final query before rolling this out is wheather or not I setup seperate Domains within SEPM to manage each site.
It doesn't get around all other sites/domains being replicated, however from an administrative perspective it will be better to delegate control this way to the onsite administrators.
The down-side is that each domain will have policies that need to be managed, rather than sharing 1 set of policies.

You can setup different Domains but for easier management but the things that you want can be achived with one domain as well.

Andrew,

Multiple domain will create confusion in policies implementation & it will be very difficult to manage & track the policies when operations will start.

Better I recommend to go for single domain.

Regards...
Ramji Iyyer