Symantec Endpoint Protection Client Attempts to Contact www.symantec.liveupdate.com

Due to hardware problems I had to perform a full reinstall of SEPM v11.0.5 and LiveUpdate Administrator v2.2 on an in-house 2003 Server. Prior to this incident SEPM and LUA have been running for the past two years without any problems.
I've recreated the SEPM groups, install packages, feature sets, etc. and added my workstations, notebook PCs, and servers successfully to SEPM. The LiveUpdate Admin receives downloads from symantec.liveupdate.com each night at 2:00 a.m. and distributes the updates to the SEPM server at 4:00 a.m.
The SEP clients are scheduled to receive any updates from the in-house SEPM server each morning at 8:45 a.m. The clients are configured to use ONLY the in-house SEPM server for updates. All clients receive their updates properly; all clients have the green circle displayed with the SEP shield in the system tray. This indicates all clients are being properly managed.
Why is it then that the client workstations periodically attempt to connect directly to Symantec's LiveUpdate web site? These attempts can happen any time during the day (not just at 8:45 a.m.) and when a number of the workstations do this simultaneously it consumes the entire bandwidth of my 1.5 t-lines. This effectively shuts down incoming connections that are in use by the company's web customers.
I've been using a web surfing monitoring application to block requests from the workstations to the IP addresses used by Symantec's LiveUpdate web sites. Symantec periodically changes these addresses so the possibility continues to exist that LiveUpdate will create self-induced denial of service attacks.
The SEP logs and Event logs on the workstations reveal nothing out of the ordinary. Symantec tech support has been unable or unwilling to help me with this issue. Any help you can give me is greatly appreciated.
SnakeEyedMojoAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jhalapradeepCommented:
Hi,

Make sure the liveupdate settings policy is configured properly.
-> because in one setting it happens, that clients first tries to get update from managemenet server or internal liveupdate server, and if that fails, it then connects to the internet to get updates
-> So in liveupdate settings policy, under server settings-> make sure ONLY second check box is marked. Uncheck the first one and under second box there should be second radio button selected.
-> Also make sure the policy inheritance is off and the policy is non shared, coz if the parent policy over rides the child policy then also it may result in such situation.

Regards,
pradeep Jhala
0
SnakeEyedMojoAuthor Commented:
Thanks for the suggestions. I did verify that the three parameters are properly configured (and they are).
0
jhalapradeepCommented:
Hi,

If these settings are confirmed, then its difficult that the client will connect to internet for updates.
-Can you upload the log.liveupdate from any such client?
location: c:\documents&settings\all users\application data\symantec\liveupdate

regards,
Pradeep Jhala
0
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

SnakeEyedMojoAuthor Commented:
Will do.
0
SnakeEyedMojoAuthor Commented:
This file is from a user's workstation that attempted to connect to the 80.67.74.143 LiveUpdate web site over 8,000 times in the last 24 hours. I've included only entries from April 1st due to the size of the full file.

log.liveupdate.johnsmith.txt
0
jhalapradeepCommented:
Hi,

The logfile is pretty clear:
-> All the catalogfiles downloads, definition downloads.. everything is starting from URL: \\MAGILLA\D$\........\.......\....
In the whole log file there is not a single instance of liveupdate where it connects to the url: liveupdate.symantecliveupdate.com or liveupdate.symantec.com or update.symantec.com

Regards,
Pradeep Jhala
0
SnakeEyedMojoAuthor Commented:
That is correct, the client does not connect to the external site. That's because the 80.67.74.143 address (and six or seven others) are explicitly blocked using the Websense content management application. If I removed the block so the SEP clients could connect to symantec.liveupdate.com, it would consume all of the company's internet bandwidth. Any external customers accessing or attempting to access their accounts that are hosted on the company's web server would be disconnected or not permitted to connect. Therein lies the problem.
0
jhalapradeepCommented:
Hi,

Yes thats correct, but you mentioned earlier that you are observing the clients connecting to the external site symantec.liveupdate.com and u are getting those multiple instances.

But as per the log file, i dont think the client is trying to connect to the external site.. it is successfully getting all the required updates from the internal liveupdate server itself.
So if the clients are not connecting directly to external site.. and getting updates from internal liveupdate server, then what is the issue here?  Then from where you are finding that the clients are connnecting to liveupdate.symantecliveupdate website?

Regards,
Pradeep Jhala
0
SnakeEyedMojoAuthor Commented:
I'll send you a copy of the Websense log so you can see that the clients are attempting to connect to the Symantec web sites and the volume of attempts I seeing here. Both Symantec and Microsoft are using multi-thread update processes which basically uses all available bandwidth it can when performing downloads.
The issue is that I will have to constantly monitor the outbound traffic in order to detect Symantec adding a new IP address to their LiveUpdate server list. The block in Websense is by explicit IP address so if Symantec adds a new address (which they periodically do), the bandwidth will be pegged again by the SEP clients connecting to the new LiveUpdate server.
0
jhalapradeepCommented:
Hi,

Yes this makes sense....
At this point in time, what I would suggest you is to contact Symantec Technical support and create a case with them.  I am sure they will be able to figure out the exact point of failure here and will try to fix it. As now on for further troubleshooting, remote session is required and also they might run Wireshark tool and try to capture the network traffic to get indepth information.  which will be a bit difficult to suffice while here on forum.
So please if possible can you contact the Symantec Technical support team, as it will save time as well as efforts.

Regards,
Pradeep Jhala
0
SnakeEyedMojoAuthor Commented:
I have opened a case with Symantec technical support. I was contacted by the first level group verifying that I do in fact have a problem. That tech has passed me on to the next level and that's whom I waiting to speak with.

I contacted Experts Exchange because this issue is consuming most of my work day. I need to get it resolved and move on to my open project list.

Thanks for your time and attempts in trying to help me. I will keep this post updated when I receive additional information.
0
jhalapradeepCommented:
Hi,

yes you are correct, this is a kind of issue that has to get escalated to next level of support. And its good if gets escalated soon enough.
-Is your case being handled by the technician in India (Pune) ? or some other region?
- I was a part of escalation team in India(Pune) till some time back.
-Anyways, lets hope it gets resolved soon so that you can spare your time on other projects. :)

Yes and please keep this post updated so that I will come to know about the resolution provided.

Regards,
Pradeep Jhala
0
jimmymcp02Commented:
0
SnakeEyedMojoAuthor Commented:
I will investigate MR6.

An update:
Symantec tech support contacted me yesterday. The engineer connected remotely to my SEPM server and a client that is attempting to connect to LiveUpdate.com. He verified that the configuration settings on the SEPM server were correct. He also reviewed that logs on the SEP client workstation but did not find a possible reason for the problem.
Lastly he had me create a new SEPM group, create a new LiveUpdate policy using only the in-house LiveUpdate server, and move 3 workstations that were attempting to connect to LiveUpdate.com into the new group. This effort would eliminate a corrupted LiveUpdate policy as the possible cause. Unfortunately the three test workstations continue to attempt to connect to LiveUpdate.com.
One thing he did suggest was to remove the LiveUpdate Administrator application from the server. Currently both the SEPM and LUA reside on the same server. This is not recommended by Symantec. As I have only a single site and a domain, I intend to remove the LUA application from the server in order to test his theory.
I will post the results of this test as well as the possible upgrade to MR6.
0
jhalapradeepCommented:
Hi,

Thank you for this update. Yes there was no issue with the policy and no possible indication in the logs as I had already told you.
Yes the LUA is not recommended on the same server as SEPM, you can test that.

Regards,
Pradeep Jhala
0
SnakeEyedMojoAuthor Commented:
All:
Thanks for the suggestions. The upgrade to MR6/RU6 did not work. I have completely uninstalled the SEPM application from the server and reinstalled it (v11.0.6000.550). I'm adding clients to a test group which I'll monitor for attempted connections to symantec.liveupdate.com. I'll keep you updated.
0
SnakeEyedMojoAuthor Commented:
The only way I've found to resolve the matter was to:
1. Perform a 100% new install of SEPM on a Windows 2003 server and using a newly initialized embedded database file.
2. Create new installation packages for 32-bit and 64-bit workstations on the SEPM.
3. Create new policies, feature sets, groups, etc. on the SEPM.
4. On each client, completely uninstall LiveUpdate and Symantec Endpoint Protection.
5. Reboot the client PC and run the appropriate install package from the SEPM server share.

Symantec tech support basically stopped answering my e-mail messages after their remote connection to my network last week. I had sent 3 or so messages asking for assistance but was ignored. The "support" contract with Symantec will expire and my company will seek another provider of AV and security software. This was a pathetic example of so-called "Level 2 Critical" support.

One other note: Even after the bandwidth overload problem with SEP was resolved, the client workstations continue to connect to symantec.liveupdate.com when they're first powered on in the morning. The connection only lasts 1-2 seconds but the fact that my workstations are still "phoning home" to Symantec is of concern to me. They're supposed to be getting all their updates from the SEPM server so what's going on?

Thanks to those of you who offered suggestions. I did eventually install the MR6/RU6 release but I'll leave the awarding of the points to the EE administrator because of the circumstances of the eventual solution to the problem.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Member_2_4421735Commented:
Shame I didn't see this post earlier. The behavior is from having IDCENABLE=1 in your installation settings. This sends anonymous data back to Symantec that reports on the installation and health of the client. They use it to better future releases of the product.

You can turn it off in setaid.ini in the installation string line under the Setup section.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Anti-Virus Apps

From novice to tech pro — start learning today.