Endpoint Protection

 View Only
  • 1.  Why are the client properties on SEPM not what it actually is?

    Posted Feb 11, 2013 10:32 PM

    Case in point. From SEPM I go to a client and look at properties and it tells me False on the GUP and also that it rejected the upgrade package. Both of these are not true because I log into the client and sure enough it is using the GUP correctly. The client status updating time is current but not the info.

    thanks



  • 2.  RE: Why are the client properties on SEPM not what it actually is?

    Posted Feb 11, 2013 10:35 PM

    On the GUP, open a Run prompt and type smc -stop and wait 10-15 seconds, than type smc -start.

    Check the system log to ensure it says it has become a GUP. Check the SEPM again after a few minutes to see if GUP is now reporting as True

    Or you can just delete the client from the SEPM and force it to check back in and than see what it is showing.

    I believe this is just a "cosmetic" type issue.



  • 3.  RE: Why are the client properties on SEPM not what it actually is?

    Trusted Advisor
    Posted Feb 12, 2013 01:34 AM

    Hello,

    Could you try deleting the SEP client from the SEPM machine?

    Make sure you have SEPM and GUP client are of the same version.

    On the next heart beat interval, the client would re-apear on the SEPM group and would provide the correct status.

    Check this - 

    Symantec Endpoint Protection : The Heartbeat Process

    www-secure.symantec.com/connect/articles/symantec-endpoint-protection-heartbeat-process

    Hope that helps!!

     



  • 4.  RE: Why are the client properties on SEPM not what it actually is?

    Posted Feb 12, 2013 01:48 AM

    Hi,

    agreed with above both comments, 

    Please restart the gup machine or restart the symantec services and wait some time it will be act as a GUP. other wise you have to delete it from console...



  • 5.  RE: Why are the client properties on SEPM not what it actually is?

    Posted Feb 12, 2013 01:56 AM

    I remember a simillar issue where the issue was with different versions.

    check if GUP and SEPM should are of same version.



  • 6.  RE: Why are the client properties on SEPM not what it actually is?
    Best Answer

    Posted Feb 12, 2013 02:18 AM

    "I go to a client and look at properties and it tells me False on the GUP and also that it rejected the upgrade package. Both of these are not true because I log into the client and sure enough it is using the GUP correctly."

    The Group Update Provider Status in the client properties - designates if the selected machine is a GUP, not if it is using a GUP for update.

    As for the rejected package there may be several reasons - client is already on that version, different language package, 32/64bit difference between the installed client and the pushed package.



  • 7.  RE: Why are the client properties on SEPM not what it actually is?

    Broadcom Employee
    Posted Feb 12, 2013 07:44 AM

    Hi,

    Could you please confirm SEPM version.

    GUP clients in RU5 are randomly switching to FALSE

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

    If it's happening with the latest SEP version then need to log a case with support.

    As other said make sure SEPM and GUP are on the same version.

     



  • 8.  RE: Why are the client properties on SEPM not what it actually is?

    Posted Feb 12, 2013 09:23 AM

    I rebooted the machine that is the GUP and it still says false. However the monitor logs of sylink and the clients themselves tell me it is workng 100% as a GUP. One difference is that I identified the GUP in SEPM by ip address and not by name as it appears in the SEPM console.



  • 9.  RE: Why are the client properties on SEPM not what it actually is?

    Posted Feb 12, 2013 09:59 AM

    Identification by IP should work as well, try restarting the smc service on this GUP machine: smc -stop, smc -start. There have been some issues with it on older SEP version - but if you confirm the GUP is really providing the updates, seems to be only a cosmetic issue then.