Video Screencast Help

Updating GUPs Manually

Created: 08 Jan 2013 • Updated: 26 Feb 2013 | 20 comments
This issue has been solved. See solution.

Hello,

 

Our current situation is that all of our GUPs close to 200 are out of date on definations, atleast a month behind. Right now we have the content directory on all of our SEPM's hidden so that clients can't download straight from the SEPM servers. We did this while troubleshooting some bandwidth issues. This came as a solution when we needed to control the client via policy updates but couldn't have the clients download from SEPM.

 

What I would like to know is if there is a way to update the GUPs manually with the latest definations (full.zip?) and what the recommended procedure will be? If this can be done, we can safely unhide the content directory from SEPM's as all the GUPs will be caught up and wont' cause a bandwidth issue.

 

Thank you for all help.

Adam.

 

 

Comments 20 CommentsJump to latest comment

pete_4u2002's picture

you can update the Virus definition on GUP machine for the local client to be updated using jdb or intelligent updater. however if the shared update folder needs to be updated manually , you may try copying from another GUP machines directory.

Adamster's picture

Yes I am following the intelligent updater router for the local client on the gup. My main concern is updating the shared update folder, right now all of the gups are outdated and all i see on them is gup.dat in the shared update folder. So I do not have a ideal gup to copy the folder from.

Even if I had that, suppose I have a test environment and I make one of the machines a gup. Can I just copy the contents from that folder to the rest of my gups? If so, do the machines that the data is copied from and to have to be on the same version of SEP client? I have a mix of SEP 11 and 12 clients acting as GUPS.

pete_4u2002's picture

i have not tested, however the monikers for SEP 11 and SEP 12 are different. may be you can update the clients first using LUA or manual method?

Adamster's picture

Because of the large size of the environment, updating all of the clients manually or through intelligent updater is not feasable for us. Ideally, just updating the 200 gups in quesitons should solve the issue and that is what I am seeking a good solution for.

pete_4u2002's picture

i would suggest to test in one branch by copying the content from shared update folde. Note that if the client at other location has different request and not present in the copied content, still SEPM will generate definition for the request.

Adamster's picture

is there a need to also copy gup.dat files over?

pete_4u2002's picture

no, the machine supposed to be GUP should contact SEPM and once it gets the policy that it has to be GUP then the file should be there and shared updates folder will be created.

the GUP machines list is available on SEPM in the globallist.xml file.

Adamster's picture

so monikors are differnt between 11 and 12? can I get a confirmation on that? The monikoris not different between the same version but different variations right? i.e sep 11.06 sep 11.07 etc.

Adamster's picture

can I also get monikors from a gup from a different site?

.Brian's picture

Check this thread:

https://www-secure.symantec.com/connect/forums/sep...

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Adamster's picture

Thanks.
I took a sharedupdates backup of a different sep 11 client on a different site that is acting as a gup and copied that folders contents to the sep 11 client on my side that is also setup as a gup. Now how do I tell if the clients are actively downloading from this gup?

.Brian's picture

You can run sylink monitor on the client to check that it is getting it's updates over port 2967

You can also run Wireshark either on the client or the GUP and set a display filter to filter on traffic for port 2967

Wireshark is easiest in my opinion

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

pete_4u2002's picture

has the client assigned as GUP?
check globallist.xml to identify if the IP address is listed.

once confirmed, the client should be taking the updates, enable sylink on client machine and check for the content request on port 2967.

Adamster's picture

I enabled the debug log to see if GUP is serving clients and below is what I see, I change the IP to x.x.x.x
01/09 08:42:54 [15640:20268] GUProxy - Throttle changed to [0X00007D00] BPS since Thread Count sub to [0]
01/09 08:42:55 [15640:11840] GUProxy send response to the client all right.
01/09 08:42:55 [15640:11840] GUProxy: cache file is not on the disk: #content#{07B590B3-9282-482f-BBAA-6D515D385869}#130108022#Full!zip
01/09 08:42:55 [15640:14516] GUProxy: accepted socket 856 for x.x.x.x port 60184
01/09 08:42:55 [15640:20304] GUProxy: Begin to handle accepted socket 856
01/09 08:42:55 [15640:20304] GUPROXY - GUProxy HTTP in - GET /content/{07B590B3-9282-482f-BBAA-6D515D385869}/130108022/Full.zip
01/09 08:42:55 [15640:20304] GUPROXY - GUProxy File - /content/{07B590B3-9282-482f-BBAA-6D515D385869}/130108022/Full.zip
01/09 08:42:55 [15640:20304] GUPROXY - GUProxy mangled file - #content#{07B590B3-9282-482f-BBAA-6D515D385869}#130108022#Full!zip
01/09 08:42:55 [15640:20304] GUProxy - Add request into download queue.
01/09 08:42:55 [15640:6884] GUProxy - Throttle changed to [0X00007D00] BPS since Thread Count added to [1]
01/09 08:42:55 [15640:6884] GUProxy - Contacting the SEPM server at x.x.x.x:8014, GET /content/{07B590B3-9282-482f-BBAA-6D515D385869}/130108022/Full.zip BEGIN =0
01/09 08:42:55 [15640:6884] GUProxy - Download Faile GET://x.x.x.x:8014/content/{07B590B3-9282-482f-BBAA-6D515D385869}/130108022/Full.zip ResponseStatus=403
HTTP/1.1 403 Forbidden

Date: Wed, 09 Jan 2013 16:42:55 GMT

Server: Apache

Content-Length: 267

Connection: close

Content-Type: text/html; charset=iso-8859-1

01/09 08:42:55 [15640:6884] GUProxy - Throttle changed to [0X00007D00] BPS since Thread Count sub to [0]
01/09 08:42:56 [15640:20304] GUProxy send response to the client all right.
01/09 08:42:56 [15640:20304] GUProxy: cache file is not on the disk: #content#{07B590B3-9282-482f-BBAA-6D515D385869}#130108022#Full!zip

pete_4u2002's picture

client is asking full definition from GUP for 64 bit content "07B590B3-9282-482f-BBAA-6D515D385869"
when GUP making the request to SEPM , its showing error 403.

Adamster's picture

Even after I put that file in place after doing a manual copy, it seems like freecacheentry is running and deleting that file?

01/09 08:59:52 [15640:11068] GUProxy - Throttle changed to [0X00007D00] BPS since Thread Count sub to [0]
01/09 08:59:53 [15640:11112] GUProxy send response to the client all right.
01/09 08:59:53 [15640:11112] GUProxy: FreeCacheEntry is running: delete cache file C:\Program Files\Symantec\Symantec Endpoint Protection\SharedUpdates\#content#{07B590B3-9282-482f-BBAA-6D515D385869}#130108022#Full!zip
01/09 09:04:09 [15640:16584] Saving SMC State

Elisha's picture

Yes.  You can manually update the content that the GUP gives out. 

But, keep in mind that the content the GUP hands out is different from the content that the GUP client is using.  For example the SEP client that is a GUP is using content revision 9 (which could be the latest) but the GUP cache only has content revision 8 then the GUP can only hand out content revision 8 until it downloads revision 9 from SEPM.  It does not matter what the SEP client is using it maters what the GUP has cached.

The GUP cache is stored in the SharedUpdates Folder:

SEP 11 - C:\Program Files\Symantec\Symantec Endpoint Protection\SharedUpdates

SEP 12.1 -

  • (32 bit machines) C:\Program Files\Symantec\Symantec Endpoint Protection\12.1.x.x.x\Bin\SharedUpdates
  • (64 bit machines) C:\Program Files(x86)\Symantec\Symantec Endpoint Protection\12.1.x.x.x\Bin64\SharedUpdates

You can manually copy files to this folder for the GUP to use as long as the file names and paths of the files you manually add are correct.

Keep in mind that the GUP will only give out files that the remote client requests.  So for example if a client asks for a delta file from rev8 to rev9 and the GUP has the full rev9 content file but does not have the delta file then the GUP will download the delta file from SEPM, even though it has the full content file for rev9.

Adamster's picture

Thank you Elisha, I have tried manually copying the files to the GUP folder but it seems like the FreeCacheEntry deletes those files and tries to redownload them?

01/09 08:59:53 [15640:11112] GUProxy: FreeCacheEntry is running: delete cache file C:\Program Files\Symantec\Symantec Endpoint Protection\SharedUpdates\#content#{07B590B3-9282-482f-BBAA-6D515D385869}#130108022#Full!zip

Elisha's picture

Yes.  I checked on this further and it appears that there is a dat file that needs to be updated also.  This dat file contains a list of all the cached content files that the GUP has.  There is no way to update this dat file manually updating the GUPs content offline will not work.

SOLUTION
SebastianZ's picture

I believe using GUP this way may only cause issues - you will never be able to fully cover all the possible client requests - and if some of them are missing on the GUP - request to SEPM goes out. If SEPM is not available to GUP - clients gets no definition.

As Sharedupdates folder is created on a client request basis - this will change as well constantly as the client will request updates reported as available on SEPM.

 

Why don't you use Live Update Administrator instead? Here you can set up a remote distibution center (something GUP alike) where you can copy the definitions from the Main Liveupdate Administrator (this one would require internet access) on a pendrive or disc and paste to the remote center. The remote disrtibution centers (could be simple IIS Share) would then provide clients with definition updates but not requiring internet access or connection to SEPM at all:

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

https://www-secure.symantec.com/connect/articles/l...

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