Introduction
By default, Symantec's current internal LiveUpdate server, LiveUpdate Administrator 2.x, creates a "clu-prod" Distribution Center (DC) on the same drive as LUA 2.x was installed. There is no requirement that all of the endpoints, clients or other Symantec products in the network use this DC. In many cases, it is beneficial to allow the LUA server's bandwidth and resources to be dedicated to downloading and distributing the latest content. All of the clients can actually collect their materials from DC's established on other servers throughout the network, reducing the burden on the LUA server in large enterprises. Up to 100 DC's can be used with a single LUA 2.3.x server.
The following article provides excellent instructions on how to set up a LUA 2.x DC on a remote IIS server:
LiveUpdate Administrator: How to configure a remote Distribution Center
There is also an accompanying video:
LiveUpdate Administrator: How to configure a remote Distribution Center
And here is Symantec's official article on the subject:
How to configure a Windows Server 2008 as a Distribution Center for LiveUpdate Administrator 2.x content
Article URL http://www.symantec.com/docs/TECH132545
One additional valuable resource, discussing how LUA stores and distributes content....
Managing LiveUpdate Administrator 2.x Space Usage
One of the benefits of using a remote IIS DC is that the IIS logs can provide excellent diagnostic materials.
- How many clients are connecting to the DC daily?
- Are they successfully finding what they are looking for?
- Are they able to download these materials?
- Are the materials that have been distributed to this DC actually being used by clients, or are there unnecessary files?
There is currently a Connect Forum Idea (proposed enhancement request) suggesting that such diagnostic functionality be built directly into a future release of LUA ("Hit Counter" Page for LiveUpdate Administrator 2.x). Until that capability is available, these questions can be answered by examining the IIS logs.
How to Enable IIS Logging
Admins familiar with Microsoft's popular IIS webserver will be familiar with how to enable the logging for the various hosted sites. Microsoft's official steps on the subject can be found in the article How to configure Web site logging in Windows Server 2003 (http://support.microsoft.com/kb/324279)
Here are a couple of screenshots from a sample IIS server that hosts a LUA Distribution Center.
On the Default Web Site Properties, logging itself must be enabled. The directory location where the logs are stored can be seen, and there are option to choose exactly what material is stored in the logs and what format they take. For this article, we will assume that all defaults are used.
The virtual directory from which the endpoints collect their updates is called "luadmin2" though the files are stored at D:\IIS_LUA_DC:
"Log Visits" must be checked for this virtual directory.
Preparing the logs
After the DC has been working successfully on the IIS server for a while, it is time to examine the logs! In this example, endpoints connect to the DC via HTTP rather than FTP, so the correct log file is found in W3SVC and saved with a name like ex120103.log. Copy this file to a computer where a text editing program is installed. (Notepad or Wordpad are built into Windows, but many third-party tools offer additional functionality. This article assumes that such a tool is in use to automate the following steps.)
- Retain the IIS header line that contains just the fields: date time s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken
- Remove all lines that do not contain the name of the virtual directory (in this example, "luadmin2")
- Replace all strings that contain the name of the virtual directory with blank space ("/luadmin2/" should be replaced with "" so that just the filenames will be displayed in the resulting spreadsheet)
- Remove all lines that contain "HEAD" rather than GET
- Remove all lines that contain "F0^" or "F200^" (For more about this telemetry data, click here )
- If there are likely to be more lines than can open in a spreadsheet program like Excel, remove all lines that contain minitri.flg. It is also possible to eliminate requests for files which are supposed to result in a "404" - see below!
- Replace all spaces with a , (comma) and then save the files as a.csv.
Opening that CSV in MS Excel will enable admins to quickly use "sort and filter" features to narrow in on the data they need. Excel also offers the ability to hide columns- very handy! It is easy to see which clients made contact, when, requested which specific files, and whether or not they were available.
Examining the logs
What is a specific endpoint looking for, and when was the last time that client checked for new updates? Filter for the client's IP (if, indeed, that IP is static and not assigned to different computers by DHCP!)
For example:
15/01/2012 14:48:25 GET sms$20for$20smtp$20avenge$20definitions$20for$20x86$2dredhat7.2_5.0_symalllanguages_livetri.zip 10.x.y.z 200
15/01/2012 14:58:26 GET sms$20for$20smtp$20avenge$20definitions$20for$20x86$2dredhat7.2_5.0_symalllanguages_livetri.zip 10.x.y.z 200
15/01/2012 15:08:27 GET sms$20for$20smtp$20avenge$20definitions$20for$20x86$2dredhat7.2_5.0_symalllanguages_livetri.zip 10.x.y.z 200
15/01/2012 15:17:33 GET sms$20for$20smtp$20avenge$20definitions$20for$20x86$2dredhat7.2_5.0_symalllanguages_livetri.zip 10.x.y.z 200
15/01/2012 15:17:48 GET 1326565747jtun_ennluapi.lin 10.x.y.z 200
15/01/2012 15:19:08 GET sms$20for$20smtp$20avenge$20definitions$20for$20x86$2dredhat7.2_5.0_symalllanguages_livetri.zip 10.x.y.z 200
This SMS for SMTP machine is able to connect without any difficulty every 10 minutes and check for new definitions. It has found a file and successfully downloaded it at 15:17:48.
What are clients looking for that they are not able to find? Filter for all files with a "sc-status" of 404.
There are certain files which endpoints are programmed to check for, though no update is expected. These "normal" 404's include:
- liveupdate_3.3.0.96_english_livetri.zip
- liveupdate_3.3.1.23_english_livetri.zip
- liveupdate_3.3.0.101_english_livetri.zip (and all similar...)
- decomposer_1.0.0_symalllanguages_livetri.zip
- automatic$20liveupdate_3.3.0.96_english_livetri.zip
- automatic$20liveupdate_3.3.1.23_english_livetri.zip
- automatic$20liveupdate_3.3.0.101_english_livetri.zip (and all similar...)
- symevent$20installer files
- ms$20light files
- lines containing "segments"
404's on "Livetri.zip" file names generally mean that the endpoint is seeking a product component that LUA is not configured to download and distribute. For example: "sesm$20antivirus$20client$20win64_11.0.6005_english_livetri.zip." This is a SEPM checking to see if there are new SEP client updates. If LUA is configured just to download and distribute Antivirus definitions, this would be an expected 404.
The following article will be helpful to determining which product is associated with which file:
How To Determine the Corresponding Product for a LiveUpdate Administrator 2.x File
Article URL http://www.symantec.com/docs/TECH131177
The following articles will help admins to determine which product selections to make for SEP:
LiveUpdate Administrator: Product Selection Guide
https://www-secure.symantec.com/connect/articles/liveupdate-administrator-product-selection-guide
LiveUpdate Administrator 2.x: What product selections are needed for specific versions of Symantec Endpoint Protection?
Article URL http://www.symantec.com/docs/TECH139618
Type of files and extensions associated with definitions in LiveUpdate Administrator 2.x with Symantec Endpoint Protection 12.
Article URL http://www.symantec.com/docs/TECH166279
Admins should be concerned if specific endpoints are seeking files that are not .zip's. For example: if many IP's are receiving 404's looking for a file named "1326563429jtun_enncurd2v2.osx," it indicates that a necessary SEP for Mac AntiVirus definition update file is not available. (A search for the DC confirmed that this file had been manually deleted in error.)
How many times was a certain file downloaded? Just filter in on the file name. It will then be easy to determine how many IP's downloaded the file and when they downloaded it.
Are there any files that LUA currently distributes to the DC which are never actually used by the network's clients? Compare the list of contents in the Distribution Center (in this example, D:\IIS_LUA_DC) with the IIS logs. If the file exists in the DC but is never mentioned in the IIS logs, then no client has requested that file.
One warning: there are certain Symantec products which are configured to check for updates only periodically- weekly or even monthly. Please do not use a daily IIS log to determine if DC contents are "ever" needed. Examine logs that date back a month, just to be sure a file present on the DC is not actually needed.
If there are files which are never used by the endpoints on the network, save bandwidth by configuring LUA not to download and distribute the corresponding product or component.
Conclusion
Though it takes a little work, periodically checking the health of a ÌIS-hosted DC becomes easier with practice. This log analysis can identify necessary files that are missing, clients that are constantly trying to re-download the same files over and over, and products that are configured in LUA to download too many (and too few) of their necessary components. LUA 2.x itself has the ability to email administrators if download and distribution jobs fail: this manuall IIS log analysis is an excellent additional activity for checking the health and efficiency of the LUA's IIS-based Distribution Center.
To express support for building these features into a future release of LUA, please give a "thumbs up" to the proposed "Hit Counter" Page for LiveUpdate Administrator 2.x Idea.
Many thanks for reading! Please do leave comments below as to whether this article was helpful or not, and any ways it could be improved.