LiveUpdate Behavior from Settings.LiveUpdate
Hi All,
We have been noticing that a unusual behaviour from LiveUpdate on our clients and would like some advise on it.
I appears that if a client cannot contact our internal LiveUpdate server the file C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Settings.LiveUpdate is overwritten with the settings from C:\Program Files\Symantec\LiveUpdate\Settings.Default.LiveUpdate. This file Settings.Default.LiveUpdate has the Symantec LiveUpdate server defined (i.e. HOSTS\0\ACCESS=liveupdate.symantecliveupdate.com) this is not our LiveUpdate server.
The problem we are facing is that when the Settings.LiveUpdate has the Symantec LiveUpdate server defined it appears they are permanently tattooed into the file (Settings.LiveUpdate) and are not replaced, even with a forced client Policy update and survives reboots. To me this is not the correct behaviour from SEP and LiveUpdate as we have a SEPM Client Policy that should force the client to our LiveUpdate server and not Symantec's?
The reasons for our concerns are that some clients are not allowed to connect to the internet and hence are not getting updated Definitions. Also if policy enforcement is not occurring for our LiveUpdate policy, hypothetically what other client policies are not being enforced.
Our environment details;
SEPM Version = RU6MP2 (soon to be RU6MP3)
Clients Version = MR4 MP2 --> RU6 MP1 (this problem is occuring across all versions)
Client LiveUpdate Version = 3.3
Client OS = WinXP SP3
Thanks in advance
Jarrod
Comments
Hi
Settings.liveupdate is only used when interenet option is selected,
even if you have SEPM select for update you dont find that info in the settings.liveudpate.
click on start
click on run
type luall.exe -> this will always go to internet or your liveudpate administrator not SEPM.
Liveupdate for the client happens when heart beat is occured; u can check this using the sylink.log file
if clients are having the problem. then replace the settings.liveudpate file from a client which is working fine.
Please don't forget to mark your thread solved with whatever answer helped you : ) Rafeeq
Known Behavior / Handy Trick
Hi Jarrod,
What you are describing is a known behavior. Whenever LiveUpdate's settings become corrupted, they will automatically repair themselves by resetting to some default calues: that is what is in the C:\Program Files\Symantec\LiveUpdate\Settings.Default.LiveUpdate file: three internet hosts for Symantec's LU servers.
Later on this year, there will be a change/improvement in the behavior of managed SEP clients. The default values will come from the LU policy assigned by the SEPM rather than using the internet-based source servers. This change is expected in SEP 11 RU7 MP1.
In the meantime, here is one trick that I have used successfully: when a minor change is made at the SEPM to the applied LiveUpdate policy, a fresh configuration is distributed automatically to all clients. So when you notice that some clients are trying to access the internet (using the default.liveupdate settings) just change the description for the applied LU policy (add a “!” to the end of the description one day, remove it the next) and the “updated” policy (containing the internal LUA server details) will be automatically applied to all clients. This is only a few seconds work and it will successfully reapply the internal LUA server details to the clients.
In very large environments it is not unusual to occasionally see a client or two "self heal" itself and revert to default LU values. If every client is reverting to defaults (indicating that something is trying to corrupt LU) then there's need for further investigation: is some other software product trying to manipulate Symantec files and accidentally corrupting them-?
Please do keep this forum thread up-to-date with your progress, and if this trick works be sure to mark the thread "solved" for the benefit of future visitors who find themselves in the same situation. &: )
Thanks and best regards,
Mick
With thanks and best regards,
Mick
Enter subject (optional)
Thanks Mick for your response I like your idea (trick) of forcing the LU policy to update. We are yet to determine the root cause of the problem. We have around 6500 clients in out environment but only a small number (approx. 50ish) exhibiting this problem. We are wondering if it a max retry scenario. Where the LU client tries so many times (unsuccessfully) and then reverts to the default setting.
I will give your trick a try and keep you post on its success.
Thanks agin
Jarrod.
Hi Mick a bit late but your
Hi Mick a bit late but your trick seems to have fixed the problem. Do you know if this was fixed in RU7?
Thumbs up to Mick! Mick is
Thumbs up to Mick!
Mick is this seen in SEP 11 RU7 as well? as per your message "This change is expected in SEP 11 RU7 MP1".
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Still on Schedule for RU7 MP1
Hello all,
Glad to know the trick worked. &: )
This change is still on schedule for RU7 MP1, which is currently expected to become available in October 2011. (Note: that date may of course change...)
Is there anything further that is required on this thread? Be sure to update it with any outstanding info you need, or you can mark it as "solved" for the benefit of future admins who are searching for the answer to the same question.
Thanks and best regards,
Mick
With thanks and best regards,
Mick
Would you like to reply?
Login or Register to post your comment.