Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

GUP Updates Failing (v12.1 RU2 MP1)

Created: 05 Jun 2013 • Updated: 10 Jun 2013 | 38 comments
This issue has been solved. See solution.

Morning all, so we're upgrading all our GUP's from v11 to v12 SEP. Seemed to be going smoothly and all v11 clients on our remote sites are updating from the newly installed v12 GUP's as expected. I've already got a Symantec case open, but wondered if anyone else had seen this.

The AV client on the GUP isn't updating from it's self.

Debug log below:

06/05 02:04:59.650 [7952] <CHttpFileDownload::CHttpFileDownload()>

06/05 02:04:59.650 [7952] </CHttpFileDownload::CHttpFileDownload()>

06/05 02:04:59.650 [7952] [Content]<LUDownloader::DownloadFile>  Address: PXGBSSC1VPM001 Port: 8014 Protocol: 0

06/05 02:04:59.650 [7952] [Content]<LUDownloader::DownloadFile>  Source Path: /content/{535CB6A4-441F-4e8a-A897-804CD859100E}/130604003/Full.zip Target Path: C:\Program Files\Symantec\Symantec Endpoint Protection\12.1.2100.2093.105\LiveUpdate\LUF{535CB6A4-441F-4e8a-A897-804CD859100E}1306040031.TMP Target Size: 243209638

06/05 02:04:59.650 [7952] <CHttpFileDownload::Do()>

06/05 02:04:59.650 [7952] <CHttpFileDownload::getRemainingBytesToDownload()>

06/05 02:04:59.650 [7952] <CHttpFileDownload::getRemainingBytesToDownload> Remaining bytes to download: 243209638

06/05 02:04:59.650 [7952] </CHttpFileDownload::getRemainingBytesToDownload()>

06/05 02:04:59.650 [7952] <CHttpConnector::SendRequest()>

06/05 02:04:59.650 [7952] Request> http://10.135.1.100:2967/content/{535CB6A4-441F-4e8a-A897-804CD859100E}/130604003/Full.zip

06/05 02:05:01.994 [7952] SendRequest() failed.

06/05 02:05:01.994 [7952] </CHttpConnector::SendRequest()>

06/05 02:05:01.994 [7952] </CHttpFileDownload::Do()>

06/05 02:05:01.994 [7952] <CHttpFileDownload::~CHttpFileDownload()>

06/05 02:05:01.994 [7952] </CHttpFileDownload::~CHttpFileDownload()>

06/05 02:05:01.994 [7952] [Content]<LUThreadProc---->to download from GUP with appointed SEPMPXGBSSC1VPM001

06/05 02:05:01.994 [7952] [Content]<LUThreadProc----> Content update download failed: unexpected error. Moniker: {535CB6A4-441F-4e8a-A897-804CD859100E} Target Seq: 130604003 HTTP code: 0

06/05 02:05:02.041 [7952] [Content]<LUThreadProc----> Using GUP for updates, try the next GUP in our candidate list for the same content update.

06/05 02:05:02.041 [7952] [Content]<LUThreadProc---->Content update downloaded from /content/{535CB6A4-441F-4e8a-A897-804CD859100E}/130604003/Full.zip to C:\Program Files\Symantec\Symantec Endpoint Protection\12.1.2100.2093.105\LiveUpdate\LUF{535CB6A4-441F-4e8a-A897-804CD859100E}1306040031.TMP, size: 243209638

06/05 02:05:02.041 [7952] <PostEvent>going to post event=EVENT_LU_REQUIRE_STATUS

06/05 02:05:02.072 [7952] <PostEvent>done post event=EVENT_LU_REQUIRE_STATUS, return=0

06/05 02:05:02.072 [7952] [Content]<CSyLink::IsContentSpaceAvailable>Sufficient disk space available on C:\ to download content {535CB6A4-441F-4e8a-A897-804CD859100E} 130604003

06/05 02:05:02.072 [7952] [Content]<LUThreadProc---->GUP address is empty.. No more GUP to use - maybe all of them may have failed.. Backoff/ or switch to SEPM are the options

06/05 02:05:02.072 [7952] [Content]<LUThreadProc---->Executing GUP backoff...

Anyone know what could cause a SendRequest() Failed and "Unexpected error" message? As I said, other v11 clients are updating from this GUP fine and the GUP is downloading the updates correctly, I even tried putting the file download location into IE on the GUP server it's self and it can download the Full.zip file it's requesting.

I'm at a bit of a loss!

Thanks

Oliver

Operating Systems:

Comments 38 CommentsJump to latest comment

W007's picture

Is the GUP offline ?

06/05 02:04:59.650 [7952] Request> http://10.135.1.100:2967/content/{535CB6A4-441F-4e8a-A897-804CD859100E}/130604003/Full.zip

06/05 02:05:01.994 [7952] SendRequest() failed.

06/05 02:05:01.994 [7952] </CHttpConnector::SendRequest()>

06/05 02:05:01.994 [7952] </CHttpFileDownload::Do()>

06/05 02:05:01.994 [7952] <CHttpFileDownload::~CHttpFileDownload()>

06/05 02:05:01.994 [7952] </CHttpFileDownload::~CHttpFileDownload()>

06/05 02:05:01.994 [7952] [Content]<LUThreadProc---->to download from GUP with appointed SEPMPXGBSSC1VPM001

06/05 02:05:01.994 [7952] [Content]<LUThreadProc----> Content update download failed: unexpected error. Moniker: {535CB6A4-441F-4e8a-A897-804CD859100E} Target Seq: 130604003 HTTP code: 0

Troubleshooting the Group Update Provider (GUP) in Symantec Endpoint Protection (SEP)

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

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

Ollie2001's picture

No, the GUP is not offline. The AV Client on the GUP cannot download the updates from it's self. That is the problem.

The GUP is connected to the management server also.

Tried the troubleshooting guide, turned up empty.

Even tried uninstalling SEP completely (and cleaning up) and reinstalling (with reboots). Exactly same issue.

W007's picture

Kindly Ensure GUP client and SEPM version are same or not ?

Check also how many disk space available ?

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

Rafeeq's picture

Do you have any proxy or firewall between SEPM and GUP.

What we need to check is to see if the System account is able to download the necessary updates from  http://10.135.1.100:2967/content/{535CB6A4-441F-4e8a-A897-804CD859100E}/130604003/Full.zip

can you bypass the proxy and check?

Ollie2001's picture

The GUP and Client are the same version. They are installed on the same server so I didn't think it was possible to install a GUP and AV client of different versions as the GUP is built into the AV??

Free space is over 4GB and it states there is sufficent space in the logs i provided:

06/05 02:05:02.072 [7952] [Content]<CSyLink::IsContentSpaceAvailable>Sufficient disk space available on C:\ to download content {535CB6A4-441F-4e8a-A897-804CD859100E} 130604003

Ollie2001's picture

There is no proxy between the GUP and the Client as they are ON THE SAME SERVER.

Rafeeq's picture

GUP is also a client(AV).  Your gup is not getting updated. Thats why its not updating other clients. who are suppose to get update from GUP.

what I ment was if there is a firewall between your GUP(AV)  and Your SEPM.coz its sending the request to 

 http://10.135.1.100:2967/content/{535CB6A4-441F-4e8a-A897-804CD859100E}/130604003/Full.zip

on port 2967 are you able to telnet this port and check if your GUP has a little green dot 

Ollie2001's picture

Getting a bit frustrated now.

The GUP is updating (I can see all the full's and delta's in the sharedupdates folder)

Other clients on the same site as the GUP are updating from the GUP as intended (as per the policy)

The AV Client on the GUP is not updating from it's own sharedupdates folder, with the above error messages.

The AV Client and the GUP are one of the same, they are the same server, there is no proxy or firewall between them.

There is no firewall/proxy between the GUP and SEPM. The GUP is connected to SEPM.

If I open IE on the server and browse the to file it wants to download, it prompts me to download it as normal so I'm pretty sure the GUP is functioning as intended, it's the AV client on the same server that isn't updating from it's self.

Rafeeq's picture

Got it now :) Whats the date its showing on the AV , 1 week old defs or 2-3 days old definition?

Did you try repairing from add/remove programs. Normally you will see Event ID 4 in the event viewer if virus defs are getting failed. Do you see any of those?

Ollie2001's picture

The definitions are approx. 3 weeks out of date as I uninstalled and reinstalled the client. The package was created 3 weeks ago, hence the 3 week old definitions.

As I've uninstalled/reinstalled, that would be better than just a repair I would have thought?

This is happening on approx. 7 of the servers we've upgraded. The rest seem to be functioning correctly.

No event ID 4's in the event logs either.

Ollie2001's picture

Support have suggest I download the latest defintions from the website and update them manually.

I've done this and they are all now in date, will check tomorrow to see if the same symtoms come back!

Not hopeful to be honest.

Ollie2001's picture

What a surprise, it hasn't fixed them. Up to 14 faulty GUP AV Clients now.

Provided Support with logs from SymHelp tool.

Might get escalated one day!

Ollie2001's picture

Finally been escalated, should get a call back tomorrow. Still can't believe no one here has seen this with 12.1 RU2 MP1? Can't be the only one's with GUP's updating from themselves?

Ninja123's picture

Hi,

Issue is reoccurring even after uninstall/reinstall then definitely support can ask you to upgrade to SEP 12.1 RU3 before doing in depth troubleshooting.

gnkev's picture

Hi,

How is possibile that some client (v11) download correctly from the GUP that itself is outofdate?

In the SEPM Console, your GUP is located on the same group as client?

Ollie2001's picture

Didn't even know RU3 was officially released? Support haven't mentioned it at all.

The GUP function is updating and downloading deltas and fulls (I can see them in the sharedupdates folder), however the AV client can't seem to download/install those definitions to its self.

The GUP is in the same group as the clients, yes.

gnkev's picture

So if in the console, the GUP is on the same group as the client; this mean that the same policy is applied and that the AV client on the gup is looking for a gup to update (is looking for him self).

It's could be a solution to try to make the GUP on a different group where you will apply a policy making the GUP downloading from the manager?

Then in the console apply the policy making clients to ask downloads from the GUP

Ollie2001's picture

Yes that works, however we don't want the GUP function downloading updates and then the AV client also downloading updates (doubling the bandwidth required). We want the AV client to update from it's own GUP.

gnkev's picture

hi Ollie2001

are you sure that the downloads will be done 2 time if you make this changes (download for gup and download for AV client?)

try doing it, for temporaly test (create a group where you willl put you GUP, with policy telling to download from the manager) then go to the Live Update policy and fix the maximum bandiwth (so you can controll traffic).

if it works, this mean that the problem is in the policy (like this we can eliminate some hypothesis)

Ollie2001's picture

4 days ago! Put a change in our system to update to RU3 on Monday.

Fingers crossed!

Ollie2001's picture

Can't see my specific issue mentioned in the list of fixes, this comes close but a reboot/restart service doesn't resolve it:

Client repeatedly requests content from the Group Update Provider or Symantec Endpoint Protection Manager

Fix ID: 3160786

Symptom: A client attempts to download a delta from Group Update Provider or Symantec Endpoint Protection Manager. The update fails and the client requests a full.zip file. This request also fails, and the client continues to request a full.zip in a "loop." Rebooting the computer or restarting the SMC service resolves the issue.

Solution: Modified SMC to add error handling when reading and writing files from the network.

Rafeeq's picture

In SEPM there is a policy to state that Clients should get updates from SEPM after they fail x number of tried from GUP. Are you sure that clients are getting updates from GUP and not from SEPM?

 http://10.135.1.100:2967/content/{535CB6A4-441F-4e8a-A897-804CD859100E}/130604003/Full.zip

.100 is your GUP? if its fails to send the request I dont understand how its getting the update.

If you remove the client as GUP and make it a normal client, Does it get the update from SEPM?

Ollie2001's picture

The policy is never to update from the SEPM, always update from the GUP. I know the GUP is working as I've run a sylink monitor trace on another machine on that site and watch it download the update from the GUP.

.100 is the GUP yes, the GUP function downloads updates from SEPM but the AV client on the GUP cannot update from it's self.

If I tell the server to update from SEPM direct via policy, that works successfully. But that isn't our design, the AV client on the GUP should update from it's own sharedupdates folder, as it did in v11 and as about half of the v12 installs are doing at the moment. We have approx. 14 installs that do not.

Rafeeq's picture

Can you try this on one GUP? may be its own defs got corrupted and it stopped updating itself.

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

Ollie2001's picture

Already tried completely installing the client, rebooting, deleting all folders/reg keys and reinstalling. Still the same.

AjinBabu's picture

HI, 

The Group Update Provider gets content updates from the Symantec Endpoint Protection Manager and locally distributes the updates to groups of clients. For each LiveUpdate Settings policy, you can configure a single Group Update Provider or multiple Group Update Providers.

Note:

The Group Update Provider does not act as a proxy for operational states, events, commands, command status, or profiles between the server and the clients.

Regards

Ajin

Rafeeq's picture

Even the GUP client itself updates by requesting files be sent from the SEPM to the GUP process.

GUP cannot update itself.. It has to talk to SEPM to get updates.

Ollie2001's picture

It's working that way on over 20 GUP's v12 GUP's and another 20 or so v11 GUP's so I beg to differ!

GUP gets updates

AV Client on GUP updates from itself 

Rafeeq's picture

Let me check that document for you.

GUP can get updates and get updated only from SEPM and not by Itself.

Event if you update gup by manual ways like jdb or intelligent updater it will not work as GUP

Rafeeq's picture

Please check this document

The GUP code can only get content updates from Symantec Endpoint Protection Manager. As far as the GUP is concerned, it does not know about the client it resides on. Even if the client were to be updated through alternative means such as: Intelligent Updater or Symantec Internal Liveupdate, the GUP would not be able to use those updates to proxy for other clients.

https://www-secure.symantec.com/connect/videos/group-update-providers-part-1

for Ex: ServerA->SEP installed and Configured as GUP

Server C and D get update from ServerA

ServerA has to talk to SEPM to get updates for iteslf. As an additional duty of GUP it will create those sharedfolders.put all the defs from SEPM so that server C and D can get the updates from ServerA.

@Mithun Can you clarify if a GUP can update itself from its shared folder or it has to go to SEPM.

Mithun Sanghavi's picture

Hello,

GUP Client would update itself from the SEPM client and can update itself from SharedUpdates folder. It completely depends on how is the Liveupdate Policy configured.

Example: In case if the clients are not configured to take the updates from the SEPM and only from GUP, the GUP client itself would have to take updates from SharedUpdates Folder.

The "SharedUpdates" directory will be populated when the GUP receives a request to see if the requested files are present in the local cache. If the file is present, it responds to the request with the file. If it is not present then the GUP holds the pending request, and re-issues the same "GetLUFile SyLink" request to the server. When that file arrives, it is added to the GUP cache.

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.

Ollie2001's picture

Yes I'm aware of how it's supposed to work and this is working on several sites as designed, but about 14 v12 GUP's are not updating themselves from the sharedupdates folder as the others are.

Hence me creating this thread and raising a ticket with support who seem to be fixated on me uninstalling and reinstalling as many times as possible but not actually fixing the issue.

Ollie2001's picture

You guys are driving me bonkers.

The GUP code on the server is pulling down the updates from SEPM successfully. This works and I can view/download all the files in the sharedupdates cache folder.

The AV Client on the server which is also hosting the GUP code, cannot update from it's self. It is configuered to update from the site GUP which just happens to be itself. If I tell it to update from the SEPM, it will do, but that effectively doubles the amount of bandwidth required as the GUP pulls down the updates and then the AV client would also pull down it's own updates.

I don't know how much more simple I can explain it!

Mithun Sanghavi's picture

Hello,

Could you assist me with your Case # of Symantec Technical Support.??

Let me look into the case.

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.

Ollie2001's picture

I'll take my hat off to Symantec Support, they finally came through for us :)

It was brought to my attention that the built in Symantec update feature uses the Default user profile (System) and uses the IE proxy settings within that profile to connect to its GUP (in this case, it's self), unfortuently there were some legacy settings in there that I was unaware of.

As you can't logon to the default/system profile, you have to delete the below 2 reg keys:

HKEY_USER\DEFAULT\SOFTWARE\MICROSOFT\WINDOWS\Current version\Internet settings\Connections\Default connect settings

HKEY_USER\DEFAULT\SOFTWARE\MICROSOFT\WINDOWS\Current version\Internet settings\Connections\Saved Legacy settings

This solved the problem on all our servers instantly!

Got there in the end and I hope this is useful for someone else in the future!

SOLUTION