Video Screencast Help

Troubleshooting SEP client => GUP conectivity

Created: 08 Nov 2012 • Updated: 08 Nov 2012 | 5 comments
Jordanco's picture
This issue has been solved. See solution.

 

HI

I need some guidence with troubleshooting client to gup conecctivity.Have sep 12 clients,using multiple gup`s setting in a policy.Some clients in the branch offices download their updates from their local gup,others contact SEPM although the policy prevents failover to the SEPM.This causes problems due to the increased network traffic.I know that the first steps are pinging and telneting the GUP computer,but what next?I guess that will be using sylink monitor?

I have a couple of questions.

1.The sep client must have conectivity to the SEPM in order to download the GUP list and i know that the client keeps a copy of the list localy.Is it possible to allow access from the client to the SEPM for some period of time so that the client copies the gup list localy and then cut the comunication with the sepm.Will the client keep the local gup list forever????

2.After successfully pinging/telenting the SEPM and the GUP computer the next step is using the sylink monitor?If that`s the case should i enable sylink debugging prior to using the sylink monitor or that is just "an alternative to using sylink monitor" as described in the link below

http://www.symantec.com/business/support/index?pag...

3.Does the GUP have a local log that`s used just for that role?

 

Thanks

 

Comments 5 CommentsJump to latest comment

Mithun Sanghavi's picture

Hello,

I would suggest you to install the SEP Content Distribution Monitor / GUP monitoring tool which would assist you.

You can use the GUP monitoring tool to get the required information - 

SEP Content Distribution Monitor / GUP monitoring tool

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

GUP content monitoring tool video

https://www-secure.symantec.com/connect/videos/sep-content-distribution-monitor-introduction

and

link to download the tool

https://www-secure.symantec.com/connect/downloads/new-sep-content-distribution-monitor-gup-health-checking

 

Also, Check this Article:

How can we check which content SEP 12.1 clients are downloading from GUP?

https://www-secure.symantec.com/connect/articles/how-can-we-check-which-content-sep-121-clients-are-downloading-gup

Hope that helps!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

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

SMLatCST's picture

"Thumbs Up" to Mithun for those links.  Further to the above, the following article may also be of use, as it tells you how to identify when a client fails to use a GUP:

http://www.symantec.com/docs/TECH187283

Now, onto your questions:

  1. A SEP Clients must always be able to contact the SEPM and should never be cut off from it.  Beyond the download of policues and the GUP list, SEPM connectivity is still used for uploading logs and finding out if/when new definitions are available.  Only after finding out from the SEPM that new content is available would a SEP Client then ask the GUP for it.
  2. Sylink logging vs the Sylink Monitor is an either/or decision.  I'd personally just create the sylink log as per your article
  3. According to the below article, there is a GUP specific log, but I've always just used the sylink log to troubleshoot definition distribution by GUPs.  Theres also some minor log info in the GUP's and SEP Clients logs, visible via the client console under "View Logs -> Client Management -> System Logs".
    http://www.symantec.com/docs/TECH141236
SOLUTION
Jordanco's picture

Thanks Mithun / Thanks SMLat

Thank you both for the answers,pitty i cant mark more than one answer as a solution.I just have a couple more question

1.The GUP computer must be in the same group as the clients using it.Is this a must,or it is enough for the GUP and the client to have the same Live Update policy applied.The GUP will identify itself as a GUP and the client will be designated to use a GUP in the same subnet.If the GUP and the client must be in a same group then there might be problem if the groups are organizes geographically and in each location there is a group for server o.s.`s and for client o.s.`s and the GUP runs on a server o.s.

2.When analyzing the sylink monitor log file since a single hearthbit produces 20-30 rows of comunication what would be the best filter to use:the ip adress of the gup server maybe,"SYLINK" maybe??? Is it enough to run the sylink monitor just on the client that is having trouble comunication with the GUP or i must run the monitor on the GUP itself simultaneously?

3.Regarding the second question,will the client that uses a GUP initiates a comunication to the GUP according to the hearthbit frequency?If i want to initiate a comunication in order to monitor it does the"update policy" would do the trick?

4.The last one :) Does the GUP holds delta`s only or the full updates "full.zip".For example i deploy a client that has 2 months old definitions the delta`s wont do the trick?
 
Thanks in advance

 

SMLatCST's picture

Hey there, in answer to your questions...

  1. As long as the GUP is assigned a policy telling it to be a GUP, and the SEP Clients have a policy assigned telling them which GUP to use (and the GUP list in the two policies match), then you can place GUPs in different groups with different policies if you wanted.
  2. The below article has some example logs to look for in the Sylink Log:
    http://www.symantec.com/docs/TECH104539
    You'd ideally want Sylink Logging enabled on both the GUP and the SEP Client(s) you're troubleshooting to get a full picture of what is going on.
  3. In theory, the "Update Policy" command tells the client to perform a heartbeat to the SEPM.  It will then only contact the GUP if the SEPM tells the client (via the heartbeat) that there is new content available.
  4. The GUP only caches what is requested of it.  If a client requests a delta, then the GUP will cache that delta.  If a client requests the full defs (because the client is so far out of date that the SEPM cannot calculate a delta for it), then the GUP caches the full defs (for that particular definition revision)

As a bit of background, deltas can only be calculated for clients whose definition revision is still within the backlog kept by the SEPM (under Site settings -> LiveUpdate -> Content Revisions Retention).  The recommendation from Symantec is to retain 42 revisions, which equates to approx 2 weeks of defs (assuming 3 def revisions per day).

Jordanco's picture

Thanks a lot SMLat,thanks

 

Best Regard