Best Practices for LiveUpdate Administrator (LUA) 2.x

Article:TECH93409  |  Created: 2009-01-13  |  Updated: 2014-03-19  |  Article URL
Article Type
Technical Solution


What are the best practices for designing, implementing and maintaining a LiveUpdate Administrator 2.x (LUA 2.x) infrastructure?


The examples used in this document are based on implementing LiveUpdate Administrator for use with Symantec Endpoint Protection (SEP).


Is LUA appropriate for the environment?

Symantec products download updates from the Internet using a LiveUpdate client by default. Configuring and administering an LUA infrastructure adds several layers of complexity to the process of updating Symantec products. Use the following guidelines to ensure the extra complexity and bandwidth usage generated by LUA provide a net benefit.


LUA is not recommended for the following scenarios:

  • Updating any amount of clients through LUA instead of through a management server like Symantec Endpoint Protection Manager (SEPM)
  • Updating environments with less than 1700 unmanaged clients sharing the same Internet connection
  • Updating clients across WAN links


See When to use LiveUpdate Administrator for more information on recommended use cases for LUA.


Use the Latest Available Release of LUA

As a best practice, always use the latest available release of LUA. New versions of LUA are periodically released. These new releases contain new or updated features, enhancements and improvements to the stability and performance of the product, 3rd party middleware (Apache Tomcat, PostgreSQL, etc) updates and security vulnerability fixes. Updated product lists that allow LUA to download content for new products or updated versions of existing products are sometimes provided only for the newest version of LUA. An example of some of the important improvements in later versions of LUA are:

  • A cross-site scripting vulnerability patched in LUA 2.3
  • Vastly improved download failure recovery added in LUA 2.3
  • Built in automatic PostgreSQL database maintenance added in LUA 2.3
  • A much newer version of the PostgreSQL database included with LUA 2.3.1
  • Java Runtime Environment (JRE) bundled with LUA 2.3.1 (previous versions required a standalone Java installation on the machine)


Co-Location/Virtualization Considerations

LUA runs on an Apache Tomcat Web server and a PostgreSQL database server. Both of these applications run in the background as services and can produce a significant amount of I/O and network bandwidth. Virtual Desktop Infrastructure (VDI) environments tend to use large amounts of relatively fast storage shared among many machines. Even though the very fast shared storage is much faster than a single desktop hard drive, the I/O bandwidth available individual virtual machines running on shared storage is often much smaller than the I/O bandwidth available on a physical machine with relatively slow storage. To avoid I/O and network resource issues, Symantec recommends the following:

  • Do not install LUA to a server running other Tomcat server -based applications. This includes Symantec Endpoint Protection Manager (SEPM)
  • Do not install LUA to a server running other database applications
  • Do not install LUA on a Virtual Machine (VM) unless there is no alternative physical machine available
  • If a LUA must be installed to a VM:
    • Ensure adequate disk I/O bandwidth is available to the VM running LUA
    • Use a statically configured virtual drive, or dedicated physical drive to store LUA content ( a dynamically allocated drive requires more I/O than a statically assigned drive)
    • If LUA is deployed on a virtual server, the LUA server requires a dedicated Network Interface Card (NIC) for optimum performance


Disk Space Considerations

Ensure that enough disk space is available for LUA to download, process, store and distribute all of the content it is configured to.

Use the following guidelines to help configure LUA to minimize its disk space usage and to determine disk space requirements:


Number of Concurrent Tasks


When considering the scheduling of download and distribution tasks, ensure you minimize the number that will overlap (run concurrently).  LUA 2.x will run most efficiently when its resources are dedicated to a small number of tasks instead of simultaneously performing several different download tasks, a purge task, several distribution jobs, and so on.  

It is recommended to have no more than 5 tasks as an absolute maximum running at any one time.


Network Bandwidth Considerations

The amount of bandwidth used by LUA varies greatly depending on several factors including:

  • The number of products LUA is configured to download content for
  • The number of distribution center servers the content is being distributed to
  • The number of clients directly downloading content from LUA server's local distribution Web site

Monitor the bandwidth usage of LUA over time to ensure network stability. Bandwidth utilization statistics can be compared to estimated bandwidth usage based on the information in this section.


Best case bandwidth utilization for downloading/distributing a single content type:


32 bit only

32 and 64 bit

Initial download

1.0 - 1.2 GB

2.0 - 2.4 GB

Multiple Daily download

200 - 220 MB

400 - 440 MB

Once a month download

1.0 - 1.2 GB

2.0 - 2.4 GB


NOTE: These are averages based on downloading Antivirus definitions for the Symantec Endpoint Protection (SEP) 12.1 Client for Windows. This is the best case amount of bandwidth each download/distribution for this content type will consume. Multiply this times the amount of distributions when calculating for multiple distribution servers.


Best case bandwidth utilization for content hosting:


 Client Count

Total Bandwidth:

1 Client

450 KB

10 Clients

4.4 MB

50 Clients

22 MB

100 Clients

44 MB

500 Clients

220 MB

1000 Clients

440 MB

5000 Clients

2.2 GB

10000 Clients

4.4 GB

50000 Clients

22 GB

100000 Clients

44 GB


NOTE: These numbers are based on a 2-10 KB TRI file + 450 KB delta definition package. Which is typical for SEP 12.1 Clients for Windows clients that are 1 revision out of date. If clients are further out of date, or require a full definition set, the bandwidth utilized will be significantly higher (As high as 180MB per client). The amount of internal bandwidth used by clients updating from an LUA server will be identical to the external bandwidth required for the same client to update from the public LiveUpdate servers.


Daisy Chaining LUA Servers

Symantec does not recommend daisy chaining LUA servers. For more information on this, see Configuring LiveUpdate Administrator (LUA) to download updates from another LUA Server.


Maintenance and Tuning

File System Maintenance

  1. Ensure LUA is configured to periodically purge aged content from the local cached definitions as well as its distribution centers. By default these purge schedules run weekly and monthly respectively. Increasing the frequency these purge schedules are run will improve overall disk usage on the LUA server and any external distribution centers.
  2. Run a scheduled defragmentation of the hard disks where LUA stores cached and distributed content to improve the overall performance of the LUA server's disks.
  3. Ensure adequate system resources are available to prevent excessive paging of memory to disk.


PostgreSQL Database Maintenance

Since version 2.3.1, LUA can be configured to perform automatic database maintenance to prevent performance and reliability issues from occurring due to a poorly tuned or corrupted database. Ensure all LUA servers are 2.3.1 or higher for best performance.

If it is not possible to utilize a version of LUA newer than 2.3.1, see Tuning LiveUpdate Administrator 2.x's PostgreSQL Database for manual steps to set up periodic database maintenance.


Java Runtime Environment

LUA 2.3.1 and newer utilize an internal Java Runtime Environment (JRE) which should not be modified. Always use Java Runtime Environment release 6 update 24 or higher with LiveUpdate Administrator 2.3 and below, to ensure maximum application stability and security.

Legacy ID


Article URL

Terms of use for this information are found in Legal Notices