Endpoint Protection Small Business Edition

Hello.

I am having trouble when attempting to view any page from the SEPM server that are sent through port 8443.
When I attempt to log on to the SEPM program, I get "Unexpected server error" about 95% of the time.
When a log on is successful, I have a 95% chancce of getting "Unexpected server error" when I click on a task, such as clients, or admin.

When I attempt to browse to http://192.168.0.11:9090 I can view the page without any issue.
But when I click on "Launch" to launch the web console of the manager, I am redirected to a page from an 8443 port, and 95% of the time get the generic IE "Page cannot be displayed" error.
If I attempt to refresh this page many times, occasionally it will show.
However, again, attempting to log on, or do anything mostly resultes in the "Unexpected server error" dialog.

I have been tackling this issue for a couple of weeks with tech support, but we're not really getting anywhere.

Thus far, we have tried:

Upgrade to the latest (14) version of SEPM.
A repair of the installation.
 A clean sweep and re-installation.
Re-installing the appropriate version of Java.
Changing the port numbers on the management server configuration wizard.
Disabling one of the NIC's on the server.
Changing the NIC that the SEPM uses (192.168.0.12, instead of 192.168.0.11).
Changing the "Listen 8014" line in the apache config file to "Listen 192.168.0.11:8014" and "Listen DELL:8014".
We have tried upgrading the database.
We have installed a redistributable C++ workframe from MS, restarted the server.
Creating an entire new database, without any clients (not a size issue).
Disabled enhanced protection mode in IE11 (Was already disabled).
Installing the certificate in root certification authorities in IE.
Restored all of IE advanced settings to default.

Can anyone here shed some light on to what might be causing this?
I think a step in the right direction is realizing that only pages and/or services served through port 8443 are affected.
Everything else can be viewed fine.
Is there a log file that is associated with the SEPM service that uses port 8443 I can view?

I would be most thankful for any help, as I have raised support ticket for this in the past, and tech support were unable to assist, and I have given up after a week or two of the case being ongoing.

Did they check scm-server-0.log file for errors?

Thank you for taking the time to reply.
Yes, this file was cheked with the tech support, and some errors were listed, but no action was taken.
I have included this file for analysis, as some similar sounding errors are present in this log. (also renamed the '.log' extension to '.txt')
I am not familiar enough with this program or java to understand their meaning

I'll review it to see if anything jumps out. I would suggest you request that your case be escalated. This may help get it moved up the chain.

Thanks for taking the time to look into that for me.
I was on support call today for another two hours. Making a total of 8 hours phone time w/ remote assistance.
The issue is still not resolved.

We tried changing the logon details of the Symantec services, deleting the "Listen 127.0.0.1:8014" and then replacing the same line in the Apache config file.
Logging on several times.
And collect a troubleshooting report with the symdiag tool - This wouldnt work, as during initialization, it was unable the verify the authenticity of several .dll files.

How do you escalate an open case? I think this has been going on long enough.
Or does a case automatically escalate when it's been open a few months?
I am even now starting to consider abandoning the active licenses and going for an entirely new program.
 

Request to speak to a duty manager and tell them you need it escalated as you're not getting anywhere.

I'm having the same issue - support suggested to reboot the SEPM and surprisingly that did work but the issue came back within a day or so. This is clearly something they are not prepared to deal with and the outsourced support just isn't capable of escalating. Do keep us posted if you find the root cause and solution to this issue.

Thanks

I've got the case elevated to a level one, and I've been speaking to a guy in a US based call center. Much better, but we're still having trouble diagnosing the cause.
In the tech supports own words, they are very weird errors. Something to do wish TSL and certificates.
I've had to enable CAPI2 logging on the event manager, look at the error events, and send these off.
We've tried installing a new, fresh set of certificates, six of them to be precise.

I will be sure to post a solution as soon as I find it out, and I would kindly ask you to do the same if you happen to solve it first.

I hope to get this solved, however, I've arranged a callback from ESET antivirus company, and will be trialing their software shortly.
I can't afford to re-install windows, as it's a mission critical server.

I just don't know what to troubleshoot next...
In the past six months or so, I think I have tried next to everything possible to resolve this. I'm pretty dissapointedm that I've paid good money for geniuine licenses for it all not to work in the end.

Cloud based management is not really an option - I like to have everything done on site.

 

Thanks Daniel, looks like we are going down the same rabbit hole; I will be sure to report any credible progress or remedy on this issue! What I can confirm so far is that a SEPM server reboot DOES FIX the issue temporarily! Boyan

Thanks for the update on this.
Unfortunately, as I am a home user, we only have a single physical server. This server manages DHCP, DNS, Domain Controller, File server, Hyper V, IIS, and VPN.
Without it, the home network comes crashing down, and no one can use their computer properly. We can't afford to restart it often.

Due to the ongoing nature of this issue, I have had to change vendors of AV program, and close my case.
This was a difficult decision, as I had a few licenses with several years leftt on them.

I am currently in the trial period of ESET Businesss edition, the prices are comparable, and have had no issues. I am actually very impressed with the management console so far.

If you do ever solve this issue, please let me know via PM though, I will be vert interested to find out exactly what the cause was.
It might even be a good idea to collaberate and work togeather on putting some documentation together for anyone else having this issue, as well as reporting the findings to Symantec, so they can be aware of what the issue is, and how to fix it. Maybe even create a patch for it in the next release.

 

Check you Micrsoft updates. If this issue occured immediately after applying certain updates, you may need to roll back specfic updates. We had this issue and have had to roll back update KB4041963. That update superceded updates KB4041681 and KB 4041678. If one of these two are installed, you may need to roll one or both of them back as well.

Once we rolled back KB4041693, the issue was resolved.

Symantec will likely need to update their console software on a future update before you can apply those MS Security updates again.

So my case has produced one credible suggestion which was implemented today 10-20-2017 and we shall see; I'll report results in few days whether this actually worked:

from Bharathi Subramanian to All Participants:
Open Windows Explorer and browse to the drive where SEPM is installed
Open the Symantec directory
Right click the Symantec Endpoint Protection Manager directory > properties > security tab
Click Advanced
Check 'Replace all child object permission entries with inheritable permission entries from this object'
Click Apply
Click Yes
Restart the Symantec Endpoint Protection Manager and Symantec Endpoint Protection Manager Webserver services

I am sorry to be a pessemist here, but that is also one of the steps they took with me.
It had no change on the behaviour of the problem.
We also tried changing the user account some of the services run under - also to no avail.

Despite not being a user of the software myself anymore, I will still continue to comment, and help as best I can from memory, as I am genuinely curious as to what exactly the issue is here.

May I ask, are you running this on Windows Server 2008 - That's the OS my installation was running on.

@daniel Hi I am running it on Server 2016. Well today is 10-25-2017 and following that procedure to replace permissions of the SEPM tree I am still up and running without the nasty error. That's the longest I've seen it run without the issue occurring. Typically it will work following a reboot for about a day or so but never for 5 days. This remedy is a good candidate; if it keeps working for 2 weeks I'm happy to proclaim it as a solution! So far I consistenly get the login prompt as I expectred:

I am glad to hear that is looking good for you.
I am certain that this wasn't the cause of my issue, as the problem persisted without any change on my side.
As LelandJ stated above about the MS updates, I believe my issue may have had something to do with that.
I was not made awaare of these updates potentially causing an issue.

Thank's for the update.
Let me know in a couple of weeks if you have any problems.

So the saga continues; at this point changing the permissions does appear to fix the issue with "internal system error" using the web interface. However the "fix" broke something else. It remained undetected up until now because it only exhibits after a reboot - upon reboot the server stops working with errors about the embedded database service not being able to start. That of course makes the SEPM server completely unusable.

It turned out to be a file level permissions issue. The account SQLANYs_sem5 needed to be given FULL permissions to the tree "C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager"; now reboot doesn't break it but I need another week to see whether the web GUI still works LOL At the moment it does but then I'm resting it right after a reboot which always worked. The original issue is what it stops working in few days. Now that I'm back to status quo the clock is tickting again. Test and update in 5 days or so: