Video Screencast Help

de-centralized definition distribution

Created: 26 May 2009 • Updated: 04 Feb 2013 | 8 comments
rwessen's picture
15 Agree
1 Disagree
+14 16 Votes
Login to vote
Status: Implemented

An idea recently has been floated in the forums which would make a good feature enhancement.

Many admins like the idea of GUPs but are turned off by the management overhead of possibly hundreds or more individual GUP policies (or managing WINS/DNS records to resolve locally for hundreds of sites)

How about a de-centralized def distribution mechanism?  The protocols and caveats for this type of network are well known by now.  Just look at p2p networks or MS PNRP.  Allow clients to authenticate each other as being managed by the same SEP server and as long as they are, allow them to grab updates from 'close' peers.

Additionaly there would likely need to be policy that dictates minimum specs for a peer to 'share' updates with others.  These could be based on CPU/RAM/OS or further restricted by local subnet only or same DNS suffix only.

This would allow admins to reduce WAN bandwidth while simplifying management overhead.

Comments 8 CommentsJump to latest comment

MichaelHornung's picture

I agree with simplifying management overhead, but prefer a structured approach to update distribution.  I wish it was easier to deploy said structure and I think doing so is within the grasp of Symantec if they hear from us that we want it.  We want it!

0
Login to vote
Paul Murgatroyd's picture

So you will see some changes with MR5 around how we manage GUP's.

If I were to say "single GUP policy, enabling multiple GUP's, clients automatically roam to closest GUP by subnet"

how would that work for you?

Paul Murgatroyd
Principal Product Manager, Symantec Endpoint Protection
Endpoint twitter feed: http://twitter.com/symc_endpoint

+3
Login to vote
Jeff4379's picture

That would be much better administration wise!

0
Login to vote
rwessen's picture

sounds good, definitely a step in the right direction.

I can still see 'closest' being defined by subnet to be a problem though.  Most well designed networks have a different subnet for infrastructure vs clients, even for remote branches, so servers (which you would likely want to be a GUP) would not necessarily have any clients in the same subnet.  Depends how flexible the code is for 'closest' i guess....this was primarily why I proposed a de-centralized model.  By de-centralizing it and specifying certain classes of machine (by CPU/RAM/OS/etc) to become 'supernodes' in the p2p mesh, you eliminate that problem as well.

This is a similar issue currently seen for AD integrated shops and current GUP policy.  Most servers (made into GUPs) are not in the same OUs as the clients you want them to service.  This is partially what leads to the GUP policy mess we currently live with.

+1
Login to vote
MichaelHornung's picture

Sounds promising, thank you for chiming in Paul.

0
Login to vote
windessy's picture

Administrator can define net mask for every group of clients, and they'll share their defs using SAV-server as p2p server.
For example: i have 2 groups: "remote servers" and "workstations". For "remote servers" i set to recieve defs at 2am from central server, and for "workstations" - to use p2p with mask 255.255.255.0, so the first computer in remote office which recieves defs (primary it will be server from "remote servers" group) starts to distibute them. If every office is in is't own (standartised in organisation) ip-range, it wouldn't be any problem.

Невозможно жить в обществе без чёткой цветовой дифференциации штанов (С)

0
Login to vote
windessy's picture

in win2008server and windows7 is feature "Branch caching" - mix of torrent technology. So make sure LiveUpdate to integrate and correctly work with it.

Невозможно жить в обществе без чёткой цветовой дифференциации штанов (С)

0
Login to vote
Elisha's picture

We implemented a feature in SEP 12.1 to allow clients to find GUPs based on the local subnet.

Check this page out for more details:

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

0
Login to vote