LiveUpdate on Isolated Network

[Migration User]

3 interconnected networks (low-bandwidth links)
No Internet connections
Less than 100 clients on each network
Migrating from SAVCE to SEPM
Separate stand-alone Internet machine.

What is the best method of auto-updating Symantec Endpoint Protection on networks that are isolated from the Internet? I can find no single KB article that covers this scenario.

With SAVCE all we had to do was download the xdb file and copy it to "C:\Program Files\SAV\" on the server. Server and clients would pick up the new signatures within minutes. This was simple and effective.

SEPM/SAVCE Definition Downloads

With SEPM I've discovered that it's not enough to copy the jdb file to "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\inbox\content\incoming\". While this does update the the virus definitions, it does not update definitions for "Proactive Threat Protection" and "Network Threat Protection". Nor does it make program updates available. The link on the downloads page for SEPM warns that this only updates virus defs but does not provide references to update the other defs for installations "no direct access to the Internet".

How to update definitions for Symantec Endpoint Protection Manager using a JDB file

I read some forum articles suggesting that I could setup LiveUpdate Administrator on the Interenet machine. After downloading updates and defs I could transfer the downloaded files to an internal http/ftp server to which I could point the SEPM server for updates. It's not clear to me whether the SEPM server would push these updates to clients or simply configure client policy so they'd know where to look. It's also not clear to me whether I'd need to setup a LiveUpdate Administrator on the inside network or just place the content on a local http/ftp server.

I'd appreciate any suggestions that would shed light on this setup. I've just begun migrating our systems from SAVCE to SEPM. We've got one network converted to SEPM that, as of now, only has updated virus defs.

Thanks in advance. :-)

[Migration User]

 You can Install Liveupdate Administrator anywhere inside or outside the network...however it should have internet connection
Liveupdate admin will download the defs you'll have to manually copy the defs on SEPM server then it would update the clients.

If you can open a http/FTP connection between SEPM and Liveupdate Admin it will be easier

Check these links
https://www-secure.symantec.com/connect/articles/installation-and-configuration-lua

http://service1.symantec.com/support/ent-security.nsf/docid/2008101508103148

[Migration User]

Your concerns are right. jdb will only update the AV and AVS

LUA is the Best Choice.

LUA should have acess to the internet and it will update the SEPM and SEPM will update the clients



Title: 'How to configure LiveUpdate to use alternate sources through the Symantec Endpoint Protection Manager Console'
Document ID: 2008010911461748
> Web URL: http://service1.symantec.com/support/ent-security.nsf/docid/2008010911461748?Open&seg=ent



Title: 'LiveUpdate Administrator 2.2: What product selections are needed for specific versions of Symantec Endpoint Protection'
Document ID: 2008101012361148
> Web URL: http://service1.symantec.com/support/ent-security.nsf/docid/2008101012361148?Open&seg=ent



Title: 'Best Practices for LiveUpdate Administrator (LUA) 2.x'
Document ID: 2009041314165848
> Web URL: http://service1.symantec.com/support/ent-security.nsf/docid/2009041314165848?Open&seg=ent

[Migration User]

Thank you for the swift response Vikram. The links you provided should help a lot. I'll read through them carefully before my next response.

The networks being protected by SEPM are completely isolated from the Internet with no physical connection whatsoever. Opening a http/FTP connection from inside to outside is not an option. I must devise a method of transferring files from outside (Internet) to inside (intranet) using a USB drive or DVDR.

I need to keep the process as simple as possible. I'd rather not have to maintain a separate set of internal LiveUpdate Administrator servers if I don't have to. Is there a way to just transfer the update files themselves to an internal FTP server and let SEPM distribute them or point the clients to them? (maybe described in the references you provided)

What benefit would I gain by having internal LiveUpdate Administrator servers versus just using SEPM and a local FTP server?

I have installed LiveUpdate Administrator on a separate Internet machine and I've begun downloading updates. I'm on my 4th attempt since Friday - getting a lot of failed and skipped files. I can see that the successful downloads are going to "C:\TempDownload\" but that directory gets emptied at the end of each attempt and I can't find where the files go after that.

If I can manage to get a complete download, it looks like my next step will be to modify the LiveUpdate policy on my SEPM server(s), pointing to the local LiveUpdate location. I'm not sure yet whether LiveUpdate clients will expect a specific FTP directory hierarchy so I don't know how to setup the FTP server directories at this point.

It concerns me that the list of products offered in the configure section of LU Administrator do not include the latest LiveUpdate Administrator (v2.2.2.9), or latest specific SEPM (11 MR5) versions. For the immediate future, however, I'd be happy to get the additional definitions for "Proactive Threat Protection" and "Network Threat Protection". These cannot be downloaded separately like the virus defs. Choices offerred in the selection dialog are not self explanitory. I'm using this link from another article but the chart doesn't match up well either.

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008101012361148

[Migration User]

 After the C:\TempDownload the definitions gets processed to be distributed in
\Program Files\Symantec\LiveUpdate Administrator\clu-prod

This guide should give more info on how to go about it
http://service1.symantec.com/support/ent-security.nsf/docid/2008040813470748

[Migration User]

Thank you for your comments and references Prachand. They're much appreciated.

Ref A: How to configure LiveUpdate to use alternate sources through the Symantec Endpoint Protection Manager Console

Thank you Prachand. I'll refer to this when setting up SEPM after getting successful downloads on the external machine.

Ref B: LiveUpdate Administrator 2.2: What product selections are needed for specific versions of Symantec Endpoint Protection

I found this when originally setting up LU Administrator but the chart doesn't quite match what's offered so I found it only marginally useful.

Ref C: Best Practices for LiveUpdate Administrator (LUA) 2.x

This was an interesting reference. It reinforces my apprehension about setting up internal LiveUpdate Administrator servers. Reading through this guide, it seems much simpler to just copy the contents of the "clu-prod" directory to our internal Linux FTP server under "/liveupdate". I can then configure it as a local LiveUpdate server in the LiveUpdate policy.

Ref C may be somewhat outdated in terms of its claims that SEPM uses Tomcat. My recent install of SEPM on an internal server used IIS that conflicted with my WSUS server on the default web site. I had to do a custom web server install to work around that. I didn't have this problem on the external (Internet) machine because it's only used for downloading updates so it has an unmanaged SEP client.

I think that SEPM does use PostgreSQL, though. If LUA cannot coexist with SEPM in its use of PostgreSQL, that would be a show-stopper. I'm not going to stand up a new, separate server just for LiveUpdate. PostgreSQL is capable of running more than one database. If Symantec hasn't figured out how to share a DBMS then they've certainly got some work to do.

[Migration User]

Thank you Vikram.

Ref: How to configure IIS as a Distribution Center for LiveUpdate Administrator 2.x content

Nothing is ever getting into the "clu-prod" directory, I'm guessing because all  attempts met with failure. Apparently, the download is an "atomic" operation where failure of any single file to download causes the entire operation to fail. I've yet to complete a download, although each attempt seems to get farther along. My last attempt got to 73% before bombing out.

The second link from your original reply led me to find where some of the update files go after a download fails. It seems that some are stored in "C:\Documents & Settings\All Users\Application Data\Symantec\LiveUpdate Administrator\Downloads". Date/time stamps match the last download but the size of that directory (146 MB) is much smaller than the TempDownload was (about 1.4 GB) just before the download failed. Total size of download files was about 2 GB so I'm not quite sure why this small set of files is stored under "Documents & Settings".

Anyway, I'm going to try a smaller set of files for my next download attempt.

Thanks.

[Migration User]

After reading through the references you folks were kind enough to provide, I believe my best solution for our purposes will be to set up our existing internal Linux FTP server(s) to provide the LiveUpdate files. We have a local FTP server in each of our internal networks so our low-bandwidth intranet links won't be a problem.

There are provisions in LiveUpdate policy to use an (internal) local LiveUpdate server. I should be able to point LiveUpdate to these Linux FTP servers using the policy editor. All the product selections can be accomplished on the external machine based on what we have internally. From what I've read, it seems the internal LiveUpdate server is just a file repository anyway as long as I'm not trying to push updates. Please correct me if I'm wrong on this.

My main hurdle right now is getting the external LiveUpdate Administrator to successfully complete a download. I guess I'll try to whittle down my download list to simplify things until I figure out what's going wrong. Even though I've already got virus definitions, I'll try just downloading those first. Then I'll expand from there until I find the problem.

I'll update this thread tomorrow after I've worked on this some more.

Thanks to all for your comments and references.

[Migration User]

Try like this.
Install and configure LUA in the PC which is having Internet. Create a distribution schedule which will put the update files ti clu-prod folder.Copy these files to a network share.install LUA in a PC in your internal network and use this network share as source server.Point the SEPM to download from this LUA.

[Migration User]

I'm getting very frustrated now. I can't proceed further until I can get LiveUpdate Administrator to successfully download something... ANYTHING!

After another failed download attempt I Googled [+"liveupdate administrator" +download +slow] and came up with this Symantec forum article:

LiveUpdate Administrator VERY slow to download

This sounds very much like what's happening to me.

Advice was to minimize downloads and do this:
##!! I do not recommend anyone else follow this!

LiveUpdate Administrator 2.2 Performance Tuning

I went though all the steps in the performance tuning KB article, following them to the letter. I ran a scheduled download that was configured to get only virus definitions. When I started the download it raised an error instead of going to the download details page. All I could do was refresh the Activity page and check the size of "C:\TempDownloads" to monitor progress. After it got to about 60% it failed like all the others. Immediately afterward I ran "debug.do" to collect troubleshooting info.

With all the debug info in the logs it was impossible to pick out anything useful. I was going to open a Symantec support ticket but found out that I'd need a "Support ID". Since the SEPM installations I manage are on a DoD site license I have no such ID. Normal support channel for site licenced products is Navy Infosec but they didn't even answer my last support request so I guess I'm SOL.

I was going to try some other actions but I quickly found out that the "Performance Tuning" steps had screwed up LUA so bad that I could do almost nothing without getting the following completely useless error.

"Appliation error, please contact the system administrator."

I ended up uninstalling LUA and all Java components I'd installed during "Performance Tuning". After re-installing JRE and LUA I tried the absolute simplest download possible, selecting only Win32 client virus signature option (just one check-box). This seemed to be going well (but still slow) until it got to 83% and stayed there until once again failing.

I examined the log file "C:\Program Files\Symantec\LiveUpdate Administrator\logs\lua-application.log" and found 2 download errors. See below for excerpts from this log. Using the URL from the log, I successfully downloaded these two files manually in MSIE without problems. This tells me that something is wrong with "LiveUpdate Administrator" and confirms to me that there is nothing wrong with the server or its configuration. I've followed all the install instructions and checked everything I can think of but LUA just refuses to work!

There were other comments in the forum thread I mentioned above suggesting to cancel and retry the download. Nothing worked for that guy and nothing has worked for me. I just check that thread again and it still hasn't been resolved. I don't take comfort in someone else's misery but at least I don't feel like it's something I'm doing wrong.

I would be grateful for any useful suggestions at this point. Otherwise I'll have to scrap plans to use SEPM for anything except plain-old virus protection, updating definitions from downloaded VDB files. I still have the debug logs in the luadebuginfo.zip file created during "Performance Tuning" if anyone thinks there might be something useful there.

The (Internet connected) system on which LUA is installed is very responsive and has been running our WSUS service flawlessly for months. Here is a platform profile:

Hardware:

Computer: Sun VirtualBox VM
CPU: Intel Core 2 Duo @ 2.33 GHz
Memory: 2 GB dedicated
Disk: 60 GB (50 GB free)

Software:
MS Windows 2003 Server Std Ed. SP2
    All latest patches
MSIE 7
JRE 6 U18
WSUS 3 SP2
SEP 11.0.4202.48 (unmanaged)
LiveUpdate 3.3.0.85
LiveUpdate Administrator 2.2.2.9

## Excerpt:
C:\Program Files\Symantec\LiveUpdate Administrator\logs\lua-application.log
---------------------------------------------
(prior to this all events successful)
...
2010-03-09 15:00:10,876 [pool-3-thread-9] INFO  com.symantec.lua.util.rcl.HttpHelper  - Successfully downlowded file (url): http://liveupdate.symantecliveupdate.com:80/1266365094jtun_nav2k8ennful25.m25
2010-03-09 15:00:10,876 [pool-3-thread-9] INFO  com.symantec.lua.util.rcl.HttpHelper  - Released connection for HTTP Get Method
...
2010-03-09 15:04:34,772 [pool-3-thread-5] ERROR com.symantec.lua.util.rcl.HttpHelper  - download: Exception closing input stream.
java.net.SocketTimeoutException: Read timed out
...
2010-03-09 15:04:34,772 [pool-3-thread-5] INFO  com.symantec.lua.util.rcl.HttpHelper  - Released connection for HTTP Get Method
2010-03-09 15:04:34,772 [pool-3-thread-5] ERROR com.symantec.lua.util.rcl.SegmentedDownloader  - Exception while download of file1266365094jtun_nav2k8enn06m25.m25
...
2010-03-09 15:05:57,132 [pool-3-thread-40] ERROR com.symantec.lua.util.rcl.HttpHelper  - download: Exception closing input stream.
java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(Unknown Source)
    at java.io.BufferedInputStream.fill(Unknown Source)
    at java.io.BufferedInputStream.read1(Unknown Source)
    at java.io.BufferedInputStream.read(Unknown Source)
    at org.apache.commons.httpclient.ContentLengthInputStream.read(ContentLengthInputStream.java:169)
    at org.apache.commons.httpclient.ContentLengthInputStream.read(ContentLengthInputStream.java:183)
    at org.apache.commons.httpclient.ChunkedInputStream.exhaustInputStream(ChunkedInputStream.java:368)
    at org.apache.commons.httpclient.ContentLengthInputStream.close(ContentLengthInputStream.java:117)
    at java.io.FilterInputStream.close(Unknown Source)
    at org.apache.commons.httpclient.AutoCloseInputStream.notifyWatcher(AutoCloseInputStream.java:176)
    at org.apache.commons.httpclient.AutoCloseInputStream.close(AutoCloseInputStream.java:140)
    at com.symantec.lua.util.rcl.HttpHelper.downloadFile(DashoA10*..)
    at com.symantec.lua.util.rcl.SegmentedDownloader.downloadFile(DashoA10*..)
    at com.symantec.lua.util.rcl.DownloadAccelerator.downloadFile(DashoA10*..)
    at com.symantec.lua.util.rcl.DownloadAccelerator.download(DashoA10*..)
    at com.symantec.lua.handler.download.FileDownloader.call(DashoA10*..)
    at com.symantec.lua.handler.download.FileDownloader.call(DashoA10*..)
    at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
2010-03-09 15:05:57,132 [pool-3-thread-40] INFO  com.symantec.lua.util.rcl.HttpHelper  - Released connection for HTTP Get Method
2010-03-09 15:05:57,132 [pool-3-thread-40] ERROR com.symantec.lua.util.rcl.SegmentedDownloader  - Exception while download of file1266365094jtun_nav2k8enn09m25.m25
java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(Unknown Source)
    at java.io.BufferedInputStream.read1(Unknown Source)
    at java.io.BufferedInputStream.read(Unknown Source)
    at org.apache.commons.httpclient.ContentLengthInputStream.read(ContentLengthInputStream.java:169)
    at java.io.FilterInputStream.read(Unknown Source)
    at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInputStream.java:107)
    at java.io.FilterInputStream.read(Unknown Source)
    at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInputStream.java:126)
    at com.symantec.lua.util.rcl.RemoteFileHelper.pipeData(DashoA10*..)
    at com.symantec.lua.util.rcl.HttpHelper.downloadFile(DashoA10*..)
    at com.symantec.lua.util.rcl.SegmentedDownloader.downloadFile(DashoA10*..)
    at com.symantec.lua.util.rcl.DownloadAccelerator.downloadFile(DashoA10*..)
    at com.symantec.lua.util.rcl.DownloadAccelerator.download(DashoA10*..)
    at com.symantec.lua.handler.download.FileDownloader.call(DashoA10*..)
    at com.symantec.lua.handler.download.FileDownloader.call(DashoA10*..)
    at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
2010-03-09 15:05:57,132 [pool-2-thread-1] INFO  com.symantec.lua.handler.RequestHandler  - Updating status of downloadJob : 1 to ---> JOB_FAILURE
...
---------------------------------------------

[Migration User]

Make sure your liveupdate is not getting blocked by your network firewall
http://service1.symantec.com/SUPPORT/sharedtech.nsf/docid/2003090514252213

[Migration User]

Thank you Vikram. Firewall is not blocking any Symantec content. Besides, if it were I would not be able to download any files at all. As I've described above, the download successfully gets a large number of files (albeit very slowly) until it ultimately hangs and fails. I did add the "akamai.net" domain to the "Trusted Sites" in MSIE, however. I doubt if that will make a difference but I'll give it yet another try to be sure.

[Migration User]

Most recent download attempt:

Download details page is never accurate
    shows 24% with all files status still showing "downloading"
TempDownload folder has 539 MB
Total size of files in Request: 679,153 KB
    That's closer 90%
Some of those files should show "downloaded" or "skipped" or something!


At 30% and 619 MB in TempDownload only 2 files show as downloaded.

At 73% and 652 in TempDownload only 3 files show as downloaded, 1 failed and the rest skipped.
    Why doesn't it retry the failed downloads?
    What does it mean when a file is "skipped" anyway?

Must be preparing to fail the download... TempDownload stays at 652 and download details still shows 73% complete.

Several minutes later it's still showing status as "retrieving" updates at 73% completion.

I'm done for today. Thanks for the suggestions anyway.

[Migration User]

The picture is starting to fill in but it's not pretty.

Some Facts:

1. Download details page doesn't update status of downloaded files even though I verify the complete files in C:\TempDownload.

2. Download details progress bar never shows true progress (not even close) when comparing total download size to contents of C:\TempDownload. Typically will show 20% when 1.6 GB of 1.8 GB is downloaded.

3. "lua-application.log" contains enough "time out" errors to account for differences above.

4. Pairs of these errors fill the log, illustrating the problem closing connections:

---------------------
2010-03-10 16:50:12,344 [pool-3-thread-5] ERROR com.symantec.lua.util.rcl.HttpHelper  - download: Exception closing input stream.
java.net.SocketTimeoutException: Read timed out

2010-03-10 16:50:12,344 [pool-3-thread-5] ERROR com.symantec.lua.util.rcl.SegmentedDownloader  - Exception while download of file1266365094jtun_nav2k8enn03m25.m25
java.net.SocketTimeoutException: Read timed out
---------------------

5. "ThreadPool" status messages like this one confirm that the majority of download transactions never complete, even though their files have been downloaded.

---------------------
2010-03-10 16:49:17,688 [pool-3-thread-30] INFO  com.symantec.lua.adapter.threadpool.LUAThreadPool  - Execute: LUA THREAD POOL SIZE: 10 total task count: 214 Active task count: 10
---------------------

I think the reason why the details page doesn't update when I can clearly see several hundred files are downloaded is the "Exception closing input stream." The transactions (connections) for most of those files never get completed. The process is taking forever because all these threads and tasks remain active. Either the server is not sending

Near the end, just before the whole download fails there are 10 threads out of a pool of 10 with 214 total threads, of which only  10 are active. The remaining 204 tasks never get completed even though the file has already been downloaded.

This is clearly a communication problem between LUA and the Symantec servers. Maybe there is some set of conditions on my server (and some others) that brings this bug to light. If so, it's not obvious. I can rule out common problems by successfully downloading any of the LUA target files manually in MSIE.

I was only slightly more successful after disabling Auto Protect. While Auto Protect was disabled, I had a successful download of a single file and a set of about 8 files. When I attempted a large number like the virus defs, however, it once again failed with the same errors.

For now I'll try getting a few at a time, as I have time in my schedule. Meantime, I'm updating my internal SEP servers using the VDB AV defs  from the Symantec definition download page.


Seriously Disappointed,

Cal Webster

[Migration User]

 Can you try just wiping out LUA. re-install it keep everything at default.( hope you have enough disk space on C:\ )

then update Symantec catalog.
Select SEP(english)
in Sub components only select Network Threat Protection updates ( IPS defs )
.Let is finish the download. Once its done then select Truscan -Proactive threat Protectio defs.
then Select Virus defs 32 and then 64.

Once the initial download is computele which is very huge when compared to the daily defs.
Then things should go smooth.

However I feel the internet connection might be dropping in between..Even if it drop for 1 sec it is eough to corrupt the whole download.

[Migration User]

Thank you for the idea Vikram. That is almost exactly what I did during the last round of troubleshooting. I got successful downloads until I tried ANY virus definition items besides the "whitelists".

Removed and re-installed LUA 2.2.2.9
Click [Configure]->[Update Symantec Product Catalog]
    Product catalog downloads in a few seconds
Click [Add New Products]
    Available product list appears
Click [Symantec Endpoint Protection]
    Selections appear below product list
Select: [x] Symantec Endpoint Protection v11.0 English
Click: [OK]
    "My Symantec Products" list appears with SEP 11
Click: [Download & Distribute]->[Manual Download Request]
    "Manual Download Request - Step 1 of 2" page appears
Click: [Add]
    "Select products to be added" page appears
Expand +[Symantec Endpoint Protection v11.0 English]
    +[Behavioral Crimeware Protection]
Select: [x] SESM Symantec Known Application System_lumetadata 11.0
Click: [OK]
    Product list reappears showing product(s) selected
Expand +[Symantec Endpoint Protection v11.0 English]
    +[Behavioral Crimeware Protection]
     [SESM Symantec Known Application System_lumetadata 11.0]
Click: [Next >]
    "Manual Download Request - Step 2 of 2" page appears
Expand +[Symantec Endpoint Protection v11.0 English]
    +[Behavioral Crimeware Protection]
     [SESM Symantec Known Application System_lumetadata 11.0]
Product: Symantec Known Application System
Size: 3.41
Reboot Required: No
File Name: 1222722077jtun_symantec$20known$20application$20system_1.5.0_symalllanguages_lumd.zip
Select: [x] SESM Symantec Known Application System_lumetadata 11.0
Click: [Next >]
    "Request Details" page appears
    After a few seconds, progress bar goes to 100% and status changes to "Completed successfully"

From here, I went back to [Download & Distribute]->[Manual Download Request] and selected groups of about 4 "Behavioral Crimeware Protection" items, omitting the 64-bit ones. Our SEP Manager is on a 32-bit platform and the selection chart shows the 64-bit "SEPM" selections not needed on 32-bit management platforms. After a short while, these were also successful.

I repeated this procedure, keeping number of download files close to 10, for the remaining items that were not in the "Virus Definitions" category and had no problems. None of these downloads exceeded a few MB, though.

I could find no "Virus Definitions" item with less than about 40 files and several hundred MB. Picking the smallest item had 43 files and about 730 MB. I can still never get through a single virus definition download without getting the errors and symptoms I've described above.

If it is, as you say, "the internet connection might be dropping in between" then why would it only affect LiveUpdate Administrator and only for downloads beyond 10 files and/or about 300 MB. I would expect the same behavior for MSIE downloads of the same files but those succeed.

As I indicated above, the error messages seem to point to the LUA connections to the Symantec server(s). It is possible that network latencies exist and the java routines in LUA are not able to cope as well as our WSUS server, MSIE and other network applications on the same server. If that's the case, I'd call it a bug anyway. Since I'm not the only one having this problem, I'd say it's more likely something in LUA that behaves badly under certain conditions. It's hard to determine what specific conditions are affecting LUA without more information.

Virus Defs:
14 items on the Symantec Security Content A1-64 (whitelists)
14 items on the Symantec Security Content A1 (whitelists)
14 items on the Symantec Security Content B1-64 (whitelists)
14 items on the Symantec Security Content B1 (whitelists)
All above items succeed.

43 items on the SESC Virus Definitions Win64 (x64) v11
Total size: 732,599 KB
Fails after  when nearly complete.

There is no way to select individual files for download. It's either all or nothing.

Thanks anyway.
 

[Migration User]

Give a continuous ping to 4.2.2.2 and same time you try to download the updates.Observe any ping failures are coming..If you are not getting continuous ping it is the problem with Internet connectivity...If you are having any proxy/firewall in the middle try to bypass them also...

[Migration User]

It might be that your network firewall has does Content Scanning..I seen few times virus defs detected and blocked by Content Scanning hardware firewalls..

for testing..

Can you try installing it on your local machine or say any xp or server machine in the same network ..and just try to download the defs.

[Migration User]

Thanks for the idea but, although the round trip times are large (around 900 ms), I loose no packets. To ensure there is no latency introduced by the virtual machine I also ran a ping test on the host (linux) machine with the same results. Thare are no proxies to deal with, only the permimeter firewall, which I will not attempt to bypass. No other applications or hosts have any issues with connectivity, latency, or speed.

It's only prudent to now compare these against a known-good Internet file repository so I also ran ping tests against mirrors.us.kernel.org from both machines.  Average RTT for these was about 90 ms, one tenth of the time it took for the Symantec servers. To be fair, liveupdate server farms are probably some of the busiest on the Internet. It does, however, support the conclusion that this LUA problem is not related to network latency or speed.

On the same LUA machine I'm running a SEP (unmanaged) client. The LiveUpdate client connects and retrieves definitions and program updates in 1 or 2 minutes. It looks like the LiveUpdate client is using FTP for file transfers whereas LUA uses strictly HTTP. I ran a quick test downloading the same large file (58M) from the http-only server "liveupdate.symantecliveupdate.com" and from one of their ftp servers "update.symantec.com". Using FTP turned out to be at least 20% faster.

Maybe there are TCP handshaking issues still to work out in the latest LUA. Maybe some of the LUA Java routines need work. Maybe the LUA servers are overloaded. In any case it has become too much overhead for me to continue to pursue. Until I hear of a fix or major update to LUA 2.2 I'm going to revert to an older version and see what happens.

Regards,

Cal Webster

[Migration User]

There is no content scanning on the perimeter firewall. This DMZ is only used by network/system administrators. I disabled the Win2k3 Svr firewall that hosts LUA and even turned off AutoProtect and got the same results. As I've indicated in other replies, this problem appears to be only with LUA. All other network applications on the LUA machine and others using the same connection run without problems. I'm going to try an earlier version of LUA next.

Thanks.

Cal Webster

[Migration User]

can you try installing LUA on a diffrent machine just to make sure if the problem lies on the server or on the network.

[Migration User]

I only have one permanent Microsoft machine on each external Internet connection and they're all setup like this one. Everything else is done using Fedora Linux or RHEL because they're so much more efficient with computer resources. There's a MS Windows XP laptop available but I'm not permitted to connect that to the Internet. If I had an available XP license I'd bring up another virtual machine but I don't.

I'm satisfied that the problem lies with LUA itself since I have no performance issues at all with the only other applications on that machine (WSUS & SEP/LiveUpdate). Plus, transfering the exact same files from the exact same Symantec server on Linux (the machine that hosts the Windows Server virtual machine) never fail at all.

Thank you for the suggestions but I'm going to try an older version of LUA next.

Cal Webster

[Migration User]

Login to LUA
Go to configure--->source server ,edit it and keep only symantec ftp site and see any difference is present..