Endpoint Protection

I'm a bit confused on the policy for LiveUpdate. The source of this is a constant "SescLU event 13" event in my logs. Since I have both:

- User the default management server (recommended)
- Use a LiveUpdate server

checked on, is it possible that the clients are not finding a LiveUpdate server (since I don't have one specifically designated) thus the SescLU events errors? That leads to my confusion. I have "Use the default Symantec LiveUpdate server" option selected. What is the default LiveUpdate server? I assumed it meant out through the internet and to somewhere at Symantec. Maybe this is incorrect.

The main reason I selected the "Use the default Symantec LiveUpdate server" option in the first place was because it allowed me to select the "Enable LiveUpdate Scheduling" option under the Schedule section in the policy. I have it set to check and download every hour and retry interval for 3 minutes. Now is this "Use the default Symantec LiveUpdate server" option necessary? If I don't have it set on, then how do I control the schedule for the default management server?

So I hope that makes sense.

Here is a good KB that may answer your questions.

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

Let me know if you need more info.

Thomas

Hey, thanks for that link. Okay it makes sense....sort of. Let me see if I got this straight....

The LiveUpdate settings that I can edit in the Admin>Tasks>Servers>Properties>LiveUpdate tab is for the management server (the recommended option in the policy).  The LiveUpdate settings that I can edit while in the actual policy is for how my SEP clients interact if I choose to have them also look to a LiveUpdate server either @ Symantec or internally.  Is that right?

So what is the best practice here? If I have only the default manager setting checked on, then only my SEPM server goes out to Symantec for updates right? That can be good in theory as it lessens the amount of traffic going out. But if the SEPM server goes down for any reason, then my SEP clients are then only configured to look at the SEPM server for updates and it won't find them....So is it best to have BOTH checked on?  How frequent intervals should we be checking for updates? Continuously? Every hour? 2 hours?

Hi,

here's just some other details on how SEP 11 works.
The SEP Manager tries to download the definition every 4 hours by default.
Clients can be set up in two possible communication modes.
In push mode the Manager sends a notification to the clients about the availabilty of the new definitions and they start to get them in few minutes (there is a randomization time to avoid a peack of traffic).
In pull mode the clients query the Manager every the amount of minutes you set up as heartbeat (usually less than 30 minutes, 5 minutes by default).
"Use the default management server (recommended)" means that the clients try to use the Manager in the way mentioned above.
In this case "Enable LiveUpdate Scheduling" is disabled because the upgrading mechanism is already in place as described above.
Because the implemented solution is already good, you don't need to have "Enable LiveUpdate Scheduling" enabled, therefore you don't need to enable "Use a LiveUpdate server" that is our server in Internet (its URL is already set up by default in the product, you don't need to set it up).
If you enable "Use a LiveUpdate server" you will face a performance degradation of your network because all clients are allowed to try and eventually download the definition through the Internet connection instead of use the centralized solution already implemented in the Manager.

Symantec releases new definitions three time per day, therefore you can set it to check for defs every 4-12 hours.
If SEPM goes down the clients with the only "default management server" option will not be able to get the definitions.
For this reason you can use the location awareness in this way:
if the clients are able to connect to the manager then apply a liveupdate policy with only the "default management server" option enabled,
else apply another LU policy where the external LiveUpdate is allowed.

Okay sounds good.  When you say "For this reason you can use the location awareness...." you mean create a secondary policy that only kicks in if cannot connect to SEPM? i didn't realize that was possible. interesting.


Last couple things. So configuring my SEPM LiveUpdate settings to go every hour is over kill then?  Also, what do you make of my SescLU event errors? Seems like after reading your posts and the link provided that my assumption of why I was getting those errors is wrong. I get the errors, but from what I can tell all my SEP clients get the updates still. Ignore the event errors?

Yes, the location awareness is a powerful feature.
Exactly, checking for definitions every hour is not so useful.
Regarding the error SescLU, there are already some discussions in this fourm, if they don't help you, call the tech support.

Thanks. I will look into this location awareness feature for sure.


I am striking out all over the place with the SescLU problems. Read all the threads here too. I'll call tech

On one customer case It looked like the Default LiveUpdate Policy created this problem.

Support performed the following steps and the issue got resolved
1. Created a new Group
2. Unchecked Policy Inheritance from going to the Policies Tab
3. Created a New LiveUpdate Settings Policy and Assigned that to the Newly Created Group
4. Moved Clients to this Group

After doing this Event Id 13 no longer appear in Application Logs.

Let me know what happens.

Thomas

Hi Jon,

Have you made any progress on this? Please let us know the status of your issue.

Thanks,
Thomas

I will follow up today. Just got in the office!

Thomas - just created a test group and test live update policy. have assigned a handful of PCs to this group, we'll see what happens. Note I also get the SescLU errors on my SEPM machine. I can't move this to the new test group because my SEPM machine doesn't show up in the list of Clients.

Okay, well no SescLU errors so far. I guess it worked. Odd. Now on to my new problem :( 

Dear Cycletech

I still have a case open in Symantec Enterprise support with the same Event ID 13 but it has not been ressolved yet. The solution provided by you didn't work in my case. We are still working upon it.