Endpoint Protection

Symantec Endpoint Protection
Version 11.0.4202.75
Windows XP SP2

I have a running SEP 11 environment, some of our clients need laptops that never connect to the internal network. To make sure those laptops stay safe I have decided not to give them a pure standalone SEP client but install an exported unmanaged client from the SEP server that have some settings defined that disable stopping SEP services, uninstalling the product, etc. I have exported an unmanaged client based on one of the available groups in SEPM so it inherites it's policies but uses an internet update server.

After installing however the client refuses to update it's antivirus definitions, when running luall.exe it states that all products are up to date but I am pretty sure there are definitions beyond april 15th of 2009 ...

When looking at the log.liveupdate file I see some interesting information:

EVENT - SERVER SELECTION SUCCESSFUL EVENT - LiveUpdate connected to server liveupdate.symantecliveupdate.com at path  via a HTTP connection. The server connection connected with a return code of 200, Successfully download TRI file
LiveUpdate is connected to a server with Mini-TRI file support.  LiveUpdate will download and process the remaining Mini-TRI files.
Check for updates to:  Product: Automatic LiveUpdate, Version: 3.3.0.85, Language: English.  Mini-TRI file name: automatic$20liveupdate_3.3.0.85_english_livetri.zip
Check for updates to:  Product: Symevent Installer, Version: 12.5, Language: SymAllLanguages.  Mini-TRI file name: symevent$20installer_12.5_symalllanguages_livetri.zip
Check for updates to:  Product: MS Light, Version: 5.0, Language: SymAllLanguages.  Mini-TRI file name: ms$20light_5.0_symalllanguages_livetri.zip
Progress Update: TRIFILE_DOWNLOAD_END: Number of TRI files: "0"
Progress Update: TRIFILE_DOWNLOAD_START: Number of TRI files: 3 Downloading Mini-TRI files
Progress Update: DOWNLOAD_BATCH_START: Files to download: 1, Estimated total size: 0
Progress Update: DOWNLOAD_FILE_START: URL: "http://liveupdate.symantecliveupdate.com/automatic$20liveupdate_3.3.0.85_english_livetri.zip", Estimated Size: 0, Destination Folder: "C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads"
HttpSendRequest (status 404): Request failed - File does not exist on the server.
Progress Update: DOWNLOAD_FILE_FINISH: - NOTE - URL: "http://liveupdate.symantecliveupdate.com/automatic$20liveupdate_3.3.0.85_english_livetri.zip", Full Download Path: "C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads\automatic$20liveupdate_3.3.0.85_english_livetri.zip" HR: 0x802A0026
HR 0x802A0026 DECODE: E_HTTP_NOT_FOUND
Progress Update: DOWNLOAD_BATCH_FINISH: HR: 0x0       , Num Successful: 0
Progress Update: DOWNLOAD_BATCH_START: Files to download: 1, Estimated total size: 0
Progress Update: DOWNLOAD_FILE_START: URL: "http://liveupdate.symantecliveupdate.com/symevent$20installer_12.5_symalllanguages_livetri.zip", Estimated Size: 0, Destination Folder: "C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads"
HttpSendRequest (status 404): Request failed - File does not exist on the server.
Progress Update: DOWNLOAD_FILE_FINISH: - NOTE - URL: "http://liveupdate.symantecliveupdate.com/symevent$20installer_12.5_symalllanguages_livetri.zip", Full Download Path: "C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads\symevent$20installer_12.5_symalllanguages_livetri.zip" HR: 0x802A0026
HR 0x802A0026 DECODE: E_HTTP_NOT_FOUND
Progress Update: DOWNLOAD_BATCH_FINISH: HR: 0x0       , Num Successful: 0
Progress Update: DOWNLOAD_BATCH_START: Files to download: 1, Estimated total size: 0
Progress Update: DOWNLOAD_FILE_START: URL: "http://liveupdate.symantecliveupdate.com/ms$20light_5.0_symalllanguages_livetri.zip", Estimated Size: 0, Destination Folder: "C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads"
HttpSendRequest (status 404): Request failed - File does not exist on the server.
Progress Update: DOWNLOAD_FILE_FINISH: - NOTE - URL: "http://liveupdate.symantecliveupdate.com/ms$20light_5.0_symalllanguages_livetri.zip", Full Download Path: "C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads\ms$20light_5.0_symalllanguages_livetri.zip" HR: 0x802A0026
HR 0x802A0026 DECODE: E_HTTP_NOT_FOUND
Progress Update: DOWNLOAD_BATCH_FINISH: HR: 0x0       , Num Successful: 0
Progress Update: TRIFILE_DOWNLOAD_END: Number of TRI files: "0"
********* Finished Finding Available Updates *********


It seems that there are a whole bunch of files that are not available for download.

I have setup a packetanalyzer to make sure that the client does try to connect to a Symantec server on the internet to get get it's updates and that it does, the packetanalyzer also states that the client tries to download files that are not available and some files even return an access denied upon trying to download.

I have deleted the minitri.flg files but that just results in a new download of that file and the same results as in not updating any definitions,
there are no proxy servers anywhere on the route from the client to the update server,
liveupdate policies for the group which is the base for the exported unmanged client are setup to update all content to latest available definitions,
if I install a normal standalone client to the same machine it does update it's definitions so there is something missing or wrong in the exported package but I can't seem to find it

Does anybody have an idea what is going on here and if I am missing something ?
Why is liveupdate claiming that all products are up to date while they are not ?
Why is liveupdate trying to download files that are not present on the update server ?

check if firewall stopping it first
then run a fresh install on client and see if that works
http://service1.symantec.com/SUPPORT/sharedtech.nsf/d3c44a1678bd8f45852566aa005902cb/c0aeb869920b38b688256d980074e389?OpenDocument&prod=Symantec%20AntiVirus%20Corporate%20Edition&ver=10.0&src=ent&pcode=sav_ce&dtype=corp&svy=&prev=&miniver=sav_ce_10

Thanks for your reply, however the firewall is not running, even better, it is disabled for testing purposes.

A fresh install is of no use, I have allready tried that multiple times.

remove LU
remove sep
download 3.4 from
ftp://ftp.symantec.com/public/english_us_canada/liveupdate/3.4/
install LU
install sep
check the defs now

When I take the unmanaged client, the updates do not work
When I take the same version standalone client, the updates work
When I take the same version managed client, the updates work

The problems therefor cannot be in the version of liveupdate being used, the problem has to be somewhere else. The suggested procedure also is a workaround, it is not a solution. For the sake of the exercise I have installed a newer version of LiveUpdate and it resulted in the same error, LiveUpdate thinks my products are up to date.

So my questions remain:
Why is liveupdate claiming that all products are up to date while they are not ?
Why is liveupdate trying to download files that are not present on the update server ?

 When I take the unmanaged client, the updates do not work
and
When I take the same version standalone client, the updates work

What are you doing differently between "unmanaged" and "standalone" ?

The unmanaged client is an exported client with selecting Export an unmanaged client.
The standalone client is the client that came on the cd.

From your response : " When I take the same version standalone client, the updates work
When I take the same version managed client, the updates work" , following is my inference.

1. When you export an unmanaged client from the SEPM, it will be built with the policies that has been configured for managed. So, the client communication is only going to change. So, if you notice, the default LiveUpdate policy that comes with SEPM will specify the clients to get updates from SEPM and not over the internet. You have to change this setting to enable LiveUpdate on the clients.

2. So, whenever you run LiveUpdate from the client, it will read "product is uptodate" ; because the catalog files ... i.e product.inventory and settings.LU does not have the correct information so as to fetch updates from internet....

3. To fix this, you will have to do this :

* Uninstall LiveUpdate.
* Delete the LiveUpdate catalog files from ApplicationData\All users\Symantec\LiveUpdate (You can delete the LU folder itself)
* Reinstall LiveUpdate.
* Perform a repair install of SEP client to register it with LU.
* From now on, you will be able to fetch definitions from internet.

Cheers,
Visu.

 When you make "unmanaged client" package in the SEPM it has the same settings as the "managed client" with regard to updating, but it cant get definitions from the SEPM because it is not "managed".

For clients that are not managed by SEPM the easiest way to allow LiveUpdate is to install from the CD1, which you refer to as "standalone".

The other way to do this is to build an "unmanaged" install package but  modify the LiveUpdate Settings Policy to allow the client to update via LiveUpdate before you export the package.

Ah, that makes sense, I see now where I made a mistake.

I exported a client based on a group that has an internal management server as update server (Use Default Managament Server selected on the LiveUpdate policy assigned to the group) assuming that the client would automatically redirect to internet when it cannot find the Management Server, seems that it doesn't work like that.

To solve this problem I:
- created a new LiveUpdate policy and selected Use a Liveupdate server - Use the default Symantec LiveUpdate Server
- created a new client group
- set policies on the group
- assigned the new LiveUpdate policy to the group
- exported a client based on the group

Everything is working as expected now, thanks for the replies, kudo's for Visu !


Weird thing still though is that the log.liveupdate and the packet analyzer did tell me there was a connection being made to the Symantec update server on the internet, that is a weird situation that can trick you into making wrong assumptions, as I did.

That's cool man :) ... good to know things are working.. :) .. and yes, its by design that LUALL will try connecting to LU servers and only then check with the local client whether or not to download... :) ..  Tricky, it is, yeah... or perhaps, an intricate design, as they say .. :P ..

Cheers,
Visu.