Video Screencast Help

LiveUpdate server authorization failure

Created: 29 Jun 2012 | 10 comments
I have a win xp  + sep and wehn I try to update from a local LiveUpdate server (plain installation of LiveUpdate Adminitrator) I get the following error (syslog.log on the client)
000000aa 01cd5622f7c02918 12070800 00000002 00000002 00000000 LiveUpdate encountered an error: LiveUpdate server authorization failure (0xA1000011). LiveUpdate Manager
Not sure how to troubleshoot it.
Event an empty folder undeer IIS when configured as dw location causes the same error.
Any clues?

Comments 10 CommentsJump to latest comment

Swapnil khare's picture

Hi Florin,

Are you able to ping ?

Is port open as needed from this machine ?

Firewall status ?

Proxy used in network ?

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

florin.d's picture

liveupdate from Symantec works.

I was having problems making the downloads from the LUA installation (standard distributors created by LUA). This morning these to work, but still cannot create a web folder under IIS to distribute the files as we used to do for SAV.


AravindKM's picture

How you are pointing SEP clients to this LUA--through SEPM policy?

Which is the version of LUA and SEP clients?

Please don't forget to mark your thread solved with whatever answer helped you : ) Thanks & Regards Aravind

SameerU's picture

Whether you have proxy in your network.

Check the authentication



Mick2009's picture

Hi Florin,

I have a win xp  + sep and wehn I try to update from a local LiveUpdate server (plain installation of LiveUpdate Adminitrator)

LUA is a fantastic tool when used correctly.  But in an all-SEP environment, the SEPM is usually the best tool to download and distribute the updates that the SEP clients need.  Here is an article on the cases where LUA is recommended for use with SEP:

When is it Recommended to Use LiveUpdate Administrator 2.x with Symantec Endpoint Protection?
Article: TECH154896   |  Created: 2011-03-07   |  Updated: 2012-05-15   | 
Article URL 

Also: do you have the LUA installed on a WinXP machine?  That is bound to be problematic.  Here's another good article:

About Installing LiveUpdate Administrator 2.x on a Windows XP, Windows Vista or Windows 7 Operating System
Article: TECH152817   |  Created: 2011-02-07   |  Updated: 2011-02-14   | 
Article URL

Please do update this thread with more details on your environment (number of clients, version, SEPMs, etc) and the admins here on Connect will share their experiences to help you out.  &: )

With thanks and best regards,


florin.d's picture

Thanks for all the info, but I am looking for ways to troubleshoot something, not make a decision on waht tool to use. Unfortunatelly of not this decision was made. SEPM is not an option (right now) as this would require opening additional ports.
Also we need to test the updates.

LUA is not installed on winxp but on a win7, on winxp I only have the SEP client.

Mick2009's picture

but still cannot create a web folder under IIS to distribute the files as we used to do for SAV.

Here is an article and video which can help you to make those Distribution Centers:

With thanks and best regards,


florin.d's picture

What we try to achive is to upgrade current deployment (clients) from SAV to SEP.

For SAV we have used a web site (IIS: http://servername/sav)making the virus definitions available for dw by the clients, which used to connect at certain intervals.

We are trying to achive the same thing right not with SEP (unmanaged) clients.

Trying to set up a web folder (virtual directory) under IIS (http://servername/sep) to distribute the updates, but received the mentioned error (from LUA folders seem to work this morning).

I created the IIS web folder, activated webdav (for distribution from LUA to it).

I can access that folder for browsing from the same computer which runs SEP client, but the LU fails (quite fast):

The following Symantec products and components are installed on your computer:
> Virus and Spyware Definitions Win32
> Virus and Spyware Definitions Win32 (hub)
> Symantec Endpoint Protection Client
Connecting to xxx...
Failed to connect to the LiveUpdate server.
Session summary: 0 update(s) available, 0 update(s) installed.
LiveUpdate session is complete.

The client is pointed to that IIS folder based on Settings.Hosts.LiveUpdate file, as exported from LUA

Also firewall was deactivated.


Then starting troubleshooting items one by one I seen that actually IIS refuzes to serve files. And this is due the IIS 7+ behavior to not serve unknown file types (like .FLG)

Now I only have to figure it out how to determine what makes LUA fail to distribute all the files to my IIS folder and where to get more info about distribution failures, as the LUA logs are quite irrelevant (only states failed but not why).


AravindKM's picture

Please reinstall IIS and follow this KB

How to configure a Windows Server 2008 as a Distribution Center for LiveUpdate Administrator 2.x content

Please don't forget to mark your thread solved with whatever answer helped you : ) Thanks & Regards Aravind

Ghent's picture

Often (not always), LiveUpdate download issues are some sort of HTTP setup/authentication issue. Often the problem is not really a "Specific LUA" issue, normally it's some type of HTTP protocol or web server configuration issue. (At least, in my limited experiance)

My very first troubleshooting step is to always use a browser. Try downloading some of the files. If you own the LUA or IIS server, you can see the files on the disk. Build a link in your browser, which will probably looks something like: http://MyWebServer:8080/clu-prod/LU-File-NAME-here...

If this works, make sure you try all the different extentions, such as .zip, .m26, .tri, etc.

If it doesn't work, check the web server logs, especially for HTTP 403 errors, the IIS Logs "error sub code" is very useful for isolating the issue. Usually it's something like HTTP 403.5

You should also be able to find HTTP links listed in the %ProgramData%\Symantec\Symantec LiveUpdate\ log.liveupdate file on SEPM servers and SEP 11.x clients (Or under the LUE folder in SEP 12.1 and higher clients). The HTTP error code should be listed in the log file as well. I like to copy-n-paste these links into a web browser, perferably on the client, and see if I can download the file via the web browser.

Most of the time, the web browser will have a similuar symptom to the LiveUpdate program (If you get HTTP 404 errors in the LU Log, you'll probably get HTTP 404 in the web browser). Using a web browser is also a faster way of re-testing when you change a setting.

Still having issues? You may want to get a wire capture out. WireShark is a common packet sniffer. This helps in those not-as-common cases when the web browser and LU client give different results. Wire captures let you see the raw WebServer response -- sometimes there is a useful error in the HTTP body you wouldn't otherwise see. Wire captures are especially good at helping with authentication type issue. You can see what authentication type the server requires and what the LU client is sending up. If your using an insecure authentication typpe, you can even check the credentials.

Wire captures also confirm the request is definately going to the right place. You can check the IP address and HTTP "hostname" filed to make sure it's correct (your host.settings file is working properly).

So quick recap:

  1. Try to download using the web browser.
    (I often find MIME, Permission, or directory related issues at this point).
  2. If you did not get HTTP 200, check the Web Servers logs. IIS provides an "HTTP Sub-code" that may not be listed in the browser or packet sniffer. The HTTP Sub-code is very useful for isolating the issue.
  3. Check the LU log files and run those exact links in the web browser (Use Copy-n-Paste to help detect typos).
  4. Again, check the Web Server logs if you did not get an HTTP 200.
  5. If you still cannot detect the issue, use a Packet Sniffer with the LU client.
    Examine the exchange closely. Check the actual IP address in the IP Packet. Check the "Hostname" HTTP protocol header in the GET request. Check the URL being used.

This should flush out any network, authenication, or web-server configuration related issues. If you still have trouble after this point, it's usually an issue more internal to LU or LUA. But whatever the case, these steps should help with isolation of the issue.