SEPM has new content, clients not updating

[Migration User]

I have a SEP12.1 RU1 deployment that I'm experiencing issues with. It seems that though the SEPM is downloading new content, none of the clients are updating properly. I can log on to individual clients, click the Live Update button, and the content updates fine, so it's not a networking issue. I've created a new LiveUpdate policy and pushed it out, no change. The policy says to check and update every four hours, but it just is not happening. Suggestions?

[pete]

when you click on the Liveupdate on client, it is the Internal Live update server or Symantec Liveupdate for updates.

Pass on the sylink log from one client which is not updating.

[Migration User]

The policy is set to download content from the default management server (which should be the SEPM). I wanted to look at the sylink.xml file but I cannot find it when I do a search on one of the systems for it. Where, specifically, is this file loacted in a Windows7 system?

[pete]

its the sylink log ( not xml). you may need to enable it

http://www.symantec.com/business/support/index?page=content&id=TECH104758

[Migration User]

I've enabled logging. What kind of information should I be looking for in the Sylink dump log? Hesitant to post it here as there is a lot of information I'd have to redact before posting it online. Just give me some key "gotcha's" I should look for.

[Migration User]

Look at the policy serial numbers of clients and SEPM. If they are not identical, there is a communication issue.

policy serial number in SEPM: Clients > [proper group], there it's at the top of the window.

policy serial numberin client: Help > Troubleshooting

BTW, it's not possible to schedule content download from SEPM to client. If a client notices that its SEPM has frash content, it will start the download instantly. If you want to schedule content download, you have to use a different LU server: either a Symantec LiveUpdate server or a LU Administrator server, which you have to configure yourself.

[pete]

basically the request for content and it's result.

[Migration User]

Sorry for the late reply. Had a going away party yesterday which diverted my attention. Sadly, the party was not for me.

 

The Policy serial numbers match on the two machines I checked, so communications between the SEPM and Clients is occurring. It's odd that everything seems to be functioning as required, the clients simply will not download the latest definitions from the SEPM server. At least they wont until I click the LiveUpdate button.

[NRaj]

Try the foll & give us the result.

 

I will ask you to go to the SEPM:

And go to the folder <drive>:\program files\symantec\symantec endpoint protection manager\inetpub/content/{C60DC234-65F9-4674-94AE-62158EFCA433}/

 

Can you check if you have this kind of content as displayed (not exactly the same):

80322021/delta80322003.dax

 

The aim is to test if the client can download it:

 

Use internet explorer and test it

http:// SEPM IP: PORT <8014 by default>/content/ <content type > /sequence/update <Example Full.zip as it should always be there>
SEPM Example:
http://10.0.41.110:8014/content/{C60DC234-65F9-4674-94AE-62158EFCA433}/80322021/delta80322003.dax

[Migration User]

Yes, I went onto one of the clients, and navigated to:

http://<my server>:8014/content/{535CB6A4-441F-4e8a-A897-804CD859100E}/120229021/full.zip

using Internet Explorer and the client asked to download or open the file. I downloaded it, which was successful. The client seems to be able to communicate with the SEPM, but is not downloading updated definitions that exist on the SEPM.

I get this messgae when looking through the System logs in Symantec client:

"Symantec Endpoint Protection Manager is available to provide updates, so the scheduled LiveUpdate was skipped."

Does this mean the client is trying to look somewhere other than the SEPM to receive updates (not supposed to based on policy)?

[NRaj]

Communication is good.

Client is capable of downloading the policy - No proxy issue - No n/w issue.

Can you paste a sceenshot of the LU policy configuration. That could be the only possibility that i can think of :(

[Migration User]

The policy is just the "Use Default Management Server" is checked. Once that's checked off, all the other configurable items disappear/grey out. I'm tempted to configure a GUP to see if the clients will pick up from that.

[Migration User]

for content.

This sepm content schedule then indirectly controls client update schedule, without requiring LU server.

[Migration User]

If only "Use Default Management Server" was checked, it would not be possible to run LU from your client GUI. You need to enable "Use a LiveUpdate Server" to allow this.

Please paste a screenshot of your LU policy server settings, as NRaj suggested.

Check the client's location ("Help > Troubleshooting") if you have more than one in a group. That's one of my favourite mistakes: Eagerly editing a policy which the client ignores

[Migration User]

Here are the three screenshots for my LiveUpdate Policy. I have only one policy, applied to all groups.

 

 

Schedule:

 

Advanced Settings:

[Migration User]

So I made some changes to the LiveUpdate Policy, basically telling the clients they have a LiveUpdate Server, and specifying an internal computer that doesn't exist. The "Use Default Management Server" button is still checked.

When I made that change, I altered the policy to not allow clients to click on Live Update. I then pushed the policy out to all the clients, and verified the policy numbers are the same

 

The top image is from the server, the bottom from the client. Though the numbers match up, I can still click on the LiveUpdate button on the client, though the policy explicitly says this is not allowed. For some reason, the Policies are not being followed by the clients.

Any suggestions on how I resolve this?

[Migration User]

This LU policy was not changed today. The serial number indicates that this policy is from december 6, 2011 (12/06/2011 ...) . Be sure that you are editing the policy in the proper group. It's easy to confuse them.

A serial number changed today should have the following format: ABCD-03/02/2012 <timestamp>

ABCD (or some alphanumeric stuff)  is the beginning of the individual group GUID.

[NRaj]

What is the curent mode of communication? push or pull? What is the heartbeat interval?

As a test measure, try to change the communication setting to push mode. Let us know if that changes anything.

[Migration User]

Perhaps this is the real cause of the issue. I've been editing the policy, creating new polices, etc. and that serial number has not changed.

[Migration User]

Was in Pull/25 min heartbeat. Changed it to Push/5 min heartbeat to see what this does.

[Migration User]

you can manually force a client policy update by "Help > Troubleshooting > Update" or "Right-click shield in systray > Update policy".

In push mode, however, policy changes should emerge in client after a few seconds.

[Migration User]

I've called in support from other groups, trying to get a Wireshark capture going, checking with Server group to see if any GPO's are interfering. Not sure what else to do at this point. Everything is set up correctly to work, it just isn't. I'll update this thread when/if I get any new information. Worse case senario I rebuild the SEP server and push new clients. Thankfully this is a small-ish install with only a couple hundred clients on it.

[Migration User]

I doubt it's a communication problem because the policy in your group didn't change for a long time.

Are you using a shared or non-shared LU policy in your group?

It's possible that you inadvertently switched your LU policy to non-shared in the group, but edited a shared policy in the Policies view of the SEPM console.

[Migration User]

So the conversation went something like this:

Server Guy: "Check it now"

Me: "What did you do?"

SG: "Nothing."

Me: "Then why should I check it, if you haven't done anything?"

I check it anyway, even though the SG did "nothing"

Me: "Now it works. Policies are updating, clients are getting new definitions. What did you do?"

SG: "Nothing. Can I close the ticket?"

Me: "Only if you put 'Nothing' for your resolution status."

 

So, without telling me what they did or did not do, my SEPM server is now behaving as it should have been all along. I wish I had something better to report, and I want to thank all those who responded and offered assistance!

[Migration User]

Hello,

I'm having exactly the same problem. Communication can be performed but no virus definitions updates.

 

I can see the SEPM is updating with no issues, the problems seems to be only from the clients.