The use of GUPs in your SEP environment can either be a useful tool or something that requires more management.   In this article we wanted to explore what a GUP is, how they can be useful, and proper implementation.

 

What Is a Group Update Provider?

The GUP technology in SEP allows administrators to designate client systems within the environment to distribute client definitions in a peer fashion.   In an environment where a GUP is configured, clients designated to use GUPs will reach out on port 2967/TCP  to see if there is a definition update available.  If the GUP does not have a definition it will reach out to its defined SEP Manager and download the correct update. On the next heartbeat interval the client will then download the definition from the GUP.

 

If the client is not able to download the definition from the GUP due to the amount of time it takes or if the GUP is unavailable, it will then default to pulling definitions from the SEPM.  This is to insure that definitions are available to the client even if GUPs are unavailable.

 

When should a Group Update Provider be used?

To understand the bandwidth savings of using a GUP it is important to understand the amount of traffic generated by definitions updates.  A freshly installed client will take a few hundred megabytes to get updated to the latest definition set.   Once clients have been installed and operating normally the definition updates are normally between 40kb-200kb.  These updates occur roughly three times a day on average.

 

While in the field we have seen clients use GUPs in different ways, the purpose of the GUPs was to reduce bandwidth requirements.   On a subnet over a WAN link, you would have a single client retrieving definitions from the SEPM.   This is the same whether you have ten clients over the remote WAN link or two hundred.   For sites with a very small number of clients, it is unlikely that a GUP would be needed.

 

Depending on how you publish definitions within your environment, something else to consider is the difference between cheap and expensive bandwidth.  In some environments client communication will go over the WAN while Internet traffic will traverse through a cheaper local ISP.   In this scenario one serious discussion should be if it is better engineered to have all clients retrieve their definitions directly through the Internet to Symantec’s public LiveUpdate servers.

 

Since differential updates are normally small, in an environment where all the traffic is on the same local LAN as the SEPM, it almost is never beneficial to use GUPs in this scenario.    While some bandwidth could be recovered by putting a GUP on each subnet, the management of a large-scale GUP environment in a local LAN will likely take more time and effort than any nominal bandwidth savings.

 

Can all clients be defined as a Group Update Provider?

Recently we had a customer ask if all systems could be GUPs.  In theory all clients in an environment can act as a GUP.  However, this is not saving any bandwidth.  What it is going to do is require all clients to reserve more hard drive space because they will all save separate definitions to be available to any possible peers.

 

In this scenario none of the agents will actually communicate with another GUP since a GUP can only retrieve updates from a SEPM.   This is a scenario where some people could believe that the environment would act in a full peer-to-peer fashion. Since the controls are in place to insure that definitions originate from a SEPM to the GUP this will not occur.

 

Things you need to be aware of when using Group Update Providers

 

The most important thing to understand is that GUPs only work with Windows clients.   Linux and OSX clients will not use the GUP functionality at all. Depending on the mixture of operating systems within your environment, this is important to know.

 

If you are trying to schedule updates to occur only at certain time periods through the day, this can only be achieved by using a LiveUpdate server. At this time GUPs do not offer this functionality.  Group Update Providers work by requesting definitions from the SEPM directly.   If you have an environment where you have a separate LiveUpdate in your environment, the GUPs will not request definitions from this system.

 

Depending on how clients are chosen to be GUPs, the antivirus team will need to be aware of any system decommissions.   We have run into scenarios where SEP administrators have configured remote client desktops as GUPs.   A few months later it was discovered that these systems have been decommissioned and replaced.  During this time while they thought a GUP was being used, all clients at this remote site were actually updating definition directly from the SEPM.

 

About the Author

Brent M. Gueth is a Senior Security Consultant with Conventus specializing in Symantec Endpoint Protection and Symantec Data Center Security.   He has worked in the IT Security field for over a decade including positions with Symantec and NASA.  He has consulted for many Fortune 500 companies and assisted them with their security needs.