A “Symantec Endpoint Protection Product Versions” report shows we have a total of 1207 computers. But, in the SEPM dashboard under “Endpoint Status” the “Total Endpoints” shows 1539. Our license is for 1500 computers and we’re getting pinged that we’re “overdeployed”. Why the discrepancy?
Latest from Symantec shows “Information is currently unavailable” on the Endpoint Protection Manager Home page
Known issue being investigated. Please subscribe to this KB for updates:
Symantec Endpoint Protection Manager (SEPM) reports that a Client Health State is “Off-Line” in status. It only started when I changed the workgroup name and add a user.
So what I did first as a solution is I uninstall the SEP software to each client, delete the client in the client group in SEPM (by deleting the client, it reduces the license “seat used”) and try to install again the SEP via Remote Push. It worked in one client but the rest are not.
So what I did is I save the installer SEP package and manually install it to each client.
But since the Server Connection status to the SEPM is Not Connected to the SEPM, the newly added client does not show in the SEPM Client Group and it did not distribute its license, “Seat Used” number in the licensing details in SEPM is still the same.
(On the Symantec Endpoint Protection (SEP) client, the tray icon has a green dot. Within the client, under Help,> Troubleshooting… > Server Connection Status, the client shows “Status: Not Connected.”)
I found a solution in the forum that I should perform Rebuild Indexes, but unfortunately, it does not work.
What would be some possible solutions? Cause it seems that my connection between SEPM and SEP is broken.
Hi all. Has anyone been able to order SEP any time in the past month? As a Symantec partner, I do my SEP ordering at Ingram. Ingram is unprepared for this Broadcom merger and they’re falling apart over there. I have been nearly a month trying to place some orders for new customers. These customers have purchased new computers as part of the Win 7 situation, and we’re having to deploy them WITHOUT ANY ENDPOINT SECURITY. To say this situation is riduclous is an udnerstatement.
When I do get a reply from Ingram, it was at first to say things like they are in training for the new procedures and have reduced staff etc. while adapting to tthe Broadcom stuff. So I let it go a bit what with the holidays and all. Inquiring further a couple weeks later, now I’m told they’re prioritizing renewals it seems at least to the end of January, so basically will not get my orders in anytime soon, and really in my mind who knows if Feb 1 we’ll just be told sorry we’re backed up for a nother month.
What I find odd is that SEP will keep on functioning just fine whether you’re license is current or not, at least for 30 days or more. So why not let existing customers continue as-is and fix up their licensing renewals later, and prioritize taking on new customers who, unless they’re loyal Symantec people like me, will end up moving elsewhere.
So again I have business clients that are running computers without any form of endpoint security. Am I the only Symantec partner finding this situation utterly idiotic? .
Also is there a Symantec parnter group on here? The PartnerNet doens’t seem very active.
I wanted to update my Symantec 14 to 14.2 RU2. The starting version was 14.0.1 becaue I’m using Windows 10 64bit. I successively updated to newer versions which was successful till version 184.108.40.206 (14.2 RU1 MP1) 14.2.4814.1101 but when I run the patch to update to the newest version, hence, 220.127.116.11 (14.2 RU2) 14.2.5323.2000, it doesn’t work. The SEP_INST_PATCH.log shows the following output:
01/09 09:04:49.949 [ec] SymDelta FileVersion: 18.104.22.168
Log initialized: LogLevel=4 Log, Size=2097152, RotationCount=2
01/09 09:04:49.965 [ec] (SymDelta::CSymDelta::invokeUnzip) Inflating…\?C:UsersxxxAppDataLocalTemppft34D4.tmpPatch.dax
01/09 09:04:50.684 [ec] (SymDelta::CSymDelta::invokeUnzip) UnZipTask took (milliseconds): 703
01/09 09:04:50.684 [ec] (SymDelta::CSymDelta::PerformApplyDelta) Performing [ XDELTA3 – Apply Delta ]
01/09 09:04:50.699 [ec] (SymDelta::CXDeltaTool::Apply) Dir: \?C:ProgramDataSymantecSymantec Endpoint Protection14.2.4814.1101.105DataCached Installs
01/09 09:04:50.699 [ec] (ApplyPackage) Apply package command line: “DummyXdeltaPath” -d -s %src% %patch% %out%
01/09 09:04:50.699 [121fc] (LaunchXDeltaInternalAndWait) Launching: “DummyXdeltaPath” -d -s “\?C:ProgramDataSymantecSymantec Endpoint Protection14.2.4814.1101.105DataCached InstallsSetup.exe” “C:UsersxxxAppDataLocalTempSymDelta_65416Patch.dax.tmpSetup.exe.DIFF” “\?C:UsersxxxAppDataLocalTemppft34D4.tmpSmcLUSetup.exe”:
01/09 09:04:50.746 [121fc] (LaunchXDeltaInternalAndWait) Launching: “DummyXdeltaPath” -d -s “\?C:ProgramDataSymantecSymantec Endpoint Protection14.2.4814.1101.105DataCached Installsdcsagent.cab” “C:UsersxxxAppDataLocalTempSymDelta_65416Patch.dax.tmpdcsagent.cab.DIFF” “\?C:UsersxxxAppDataLocalTemppft34D4.tmpSmcLUdcsagent.cab”:
01/09 09:04:50.949 [121fc] (LaunchXDeltaInternalAndWait) Launching: “DummyXdeltaPath” -d -s “\?C:ProgramDataSymantecSymantec Endpoint Protection14.2.4814.1101.105DataCached InstallsSep64.msi” “C:UsersxxxAppDataLocalTempSymDelta_65416Patch.dax.tmpSep64.msi.DIFF” “\?C:UsersxxxAppDataLocalTemppft34D4.tmpSmcLUSep64.msi”:
01/09 09:04:51.152 [121fc] (CDeltaApplyThread::run) 74236 \?C:ProgramDataSymantecSymantec Endpoint Protection14.2.4814.1101.105DataCached Installssep_NE.slf CRC match failed.
01/09 09:04:51.152 [ec] (SymDelta::CXDeltaTool::Apply) Return Code: 31
01/09 09:04:51.152 [ec] (SymDelta::CSymDelta::processDirs) ApplyDelta Operation failed.
What’s the problem?
I know Symantec has release the following workaround – https://support.symantec.com/us/en/article.tech256047.html – for the Google Chrome 78/79 ‘Aw Snap…’ issue.
I also noticed that SEP 14.2 RU2 was released on November 12, 2019, and the release notes don’t mention this issue been fixed.
When does SEP plan to address this issue?
We have a Windows 2012 R2 server running Symantec Endpoint Protection 22.214.171.124.2000. Same behavior I am reporting was also observed with ver 14.0.3876.1100
We have a backup appliance Rubrik on version 5.2 that archives virtual machines fine to the above server fine. It is when we attempt to write a virtual machine tape, using Qstar software we run into a problem. The job keeps restarting.
If we disable Symantec the jobs fails. If we put exceptions in place for the Qstar directories the job fails too.
If we remove Symantec the job completes.
How do we go about troubleshooting this type of scenerio? Rubrik and Qstar believe Symantec is the cause.
I want to know the best way forward where we have a number of Windows 10 clients which will either never connect to a network or may rarely do so. I am thinking of making them unmanaged clients in this case,which will be no plroblem from an update point of view as they will be able to update using the intelligent updater files from Symantec, however we also need to manage the USB devices so that only certain ones can be utilised. The list of approved USB drives will be subject to regular changes and we will need to have the ability to add / remove them in the field on the unmanaged clients.
From what I have read, this sounds as though this will need to be done by creating the appropriate policy on a computer with the SEP Manager inistalled,and then the policy shipped out to the client and imported, but this sounds potentially cumbersome so I was wondering if there is another way of doing this on the unmanaged client directly using the latest version of SEP.
Please can someone advise me the best way forward,