Endpoint Protection

Expand all | Collapse all

14.2 RU2 (14.2.5323.2000) inexplicable problems after upgraded to 14.3 (14.3.558.0000)

  • 1.  14.2 RU2 (14.2.5323.2000) inexplicable problems after upgraded to 14.3 (14.3.558.0000)

    Posted 16 days ago
    Hello everyone,

    I would like try and clarify something which for me, is inexplicable, before opening a Case at Symantec.

    Long story short, using SEP since 2012, i've always tested every versions that Symantec releases, so that i won't create damage to my customers environment.
    Never have i had these inexplicable issues when trying to just do a simple and classic upgrade from one version to another.

    The problem is like this.

    I have in my environment SEPM (2 servers in fail-over) which manage our customer environments.
    I was dreaming of planning my customers for SEP agents upgrade, but when i started testing the (so called) 14.3 version, i came across a strange issue.

    From the beginning i would like to point out that my Liveupdate Policy settings is to use JUST the SEPM.
    My agents do not go to the internet to download definitions.

    And here is where the fun began...

    I run a 14.3 558 over a 14.2 5323 (PLEASE keep in mind what i've said about the Liveupdate policy settings)... and after reboot my agent began experiencing errors.
    The message:
    ...corrupt definitions...

    Honestly i didn't understood why is this happening, so i started testing a little bit more... TO DISCOVER :( after a day of building-rebuilding test environment because i didn't understood why this is happening, to find out that IF i CHECK the USE A LIVEUPDATE SERVER in my Liveupdate policy, the upgrade performs smoothly, without any errors afterwards.

    BUT of course i don't want to have Use a liveupdate server CHECKED, because i want my agents to download definitions from SEPM.
    Thing that it's not happening after upgrading to 14.3

    KEEP in mind, i tested all the versions after 14.3, until RU1, on all i experience the same thing.

    Therefor my simple question is...

    Why is this happening ?
    Why a simple and classic upgrade, a 14.3 package run over a 14.2 5323 is behaving like this ?
    What is going on ?


  • 2.  RE: 14.2 RU2 (14.2.5323.2000) inexplicable problems after upgraded to 14.3 (14.3.558.0000)

    Posted 11 days ago
    Hi Calin,

    The SEPM needs to be running 14.3 558 to provide content update to 14.3 558 clients.

    I had the same reaction when I first saw that, support was like it had always been the case.


  • 3.  RE: 14.2 RU2 (14.2.5323.2000) inexplicable problems after upgraded to 14.3 (14.3.558.0000)

    Posted 11 days ago
    Indeed, later on i managed to find out, after opening a Case, they've provided this KB which explains everything.
    https://knowledge.broadcom.com/external/article/162142/manage-newer-endpoint-protection-clients.html
    It turns out that as of 14.3 558 Symantec changed something from Definitions point of view, information which i wasn't able to find... and trust me i've searched for some kind of explanation or something logical to make sense... but wasn't able to find anything.

    The KB above has an interesting mention, the last 2 sentences are the most relevant.

    SEP 14.3 clients cannot be managed by 14.2 or older SEPMs
    As above, SEP 14.3 client use a newer definition format and and cannot get content updates from SEPM versions 14.2.x or older.

    This explains everything.
    Also from my assumption is that, whatever version Symantec might release, you're somehow put in the position to mandatory upgrade also the SEPM.
    It's not like in the past, when you could manage newer SEP clients with older versions of SEPM.


  • 4.  RE: 14.2 RU2 (14.2.5323.2000) inexplicable problems after upgraded to 14.3 (14.3.558.0000)

    Broadcom Employee
    Posted 10 days ago
    Managing newer clients with an older SEPM has never been supported.  In some cases, it may work, but it is not supported.

    ------------------------------
    John Owens
    Strategic Support Engineer | Symantec Enterprise Division (SED)
    Symantec
    United States
    ------------------------------



  • 5.  RE: 14.2 RU2 (14.2.5323.2000) inexplicable problems after upgraded to 14.3 (14.3.558.0000)

    Posted 8 days ago
    So you're telling me that Symantec can force me into upgrading my SEPM also ?
    If this is the case, paste a Symantec KB which proves your statement, because never ever in my Cases opened at Symantec, nobody has told me that i have a newer client managed from an older SEPM.

    Perhaps i want manage my SEP 14.3 MP1 Refresh and 14.3 RU1 clients, from a SEPM 14.3 558 ?
    And from my point of view, i see nothing wrong with this setup.


  • 6.  RE: 14.2 RU2 (14.2.5323.2000) inexplicable problems after upgraded to 14.3 (14.3.558.0000)

    Broadcom Employee
    Posted 8 days ago
    SEPMs have updated policies and content to enable new features in each release. This is is the Admin Guide and order upgrade is always SEPM first. You would not be able to manage 14.3 RU1 clients with a 14.3 base SEPM. 14. 3 RU1 has new content monikers so the clients wouldn't be able to update content from SEPM in this case. You also couldn't administer new features from the SEPM if running 14.3 base SEPM with 14.3 RU1 clients. 






  • 7.  RE: 14.2 RU2 (14.2.5323.2000) inexplicable problems after upgraded to 14.3 (14.3.558.0000)

    Posted 7 days ago
    Indeed i noticed quite a few changes in the 14.3 RU1 Release Notes and considering what you said, which triggered my curiosity, i tested a SEP 14.3 RU1 with ATP PTP NTP enabled, on a SEPM 14.3 558, and the result... SEP client full of errors.
    Which is curious, because SEPM 14.3 558 with SEP 14.3 RU1 with Only Auto-Protect, works just fine.
    But when you add other components such as PTP, NTP, everything goes sideways, the agent reports nothing but errors and components malfunctioning.

    The thing i that, I would have assumed that all 14.3.x family packages and releases are all compatible and all have backward-compatibility between each other, but it seems this is not the case anymore as of 14.3 RU1.

    Well, another lesson learned :)
    As much as i would like to not agree with you :) the results say different.