Endpoint Protection

Yesterday we upgraded to SEP 12.1.2.  The upgrade went well, but since the upgrade the SEPM console on remote computers is having an issue connecting to the server.  They will show a failed to connnect to the server error (ErrorCode: 0x80020000) and then connect.  But, after connecting the reporting screens (Home, Monitor, Reports) fail to load, but the Policies, Clients and Admin screens load fine.  I thought it might have been related to Java due to the changes to make this compatible with Java 7, so we tried redownloading the console, but this did not work either.

I was able to get this working by using the IP address instead of the DNS name of the server, but it is strange that this worked fine before the upgrade using the DNS name.  The console works fine on the SEPMs, only remote machines have the issue.  Has anyone else experienced this?  We have about 30 limited administrators who do not have access to RDP into the SEPMs, so having the console working on remote machines is definitely helpful.

Thanks!

did you change your sepm server name and kept the ip intact.

clearly a DNS issue , when you do a name resolution what to you get ? 

HI,

Did you try remove java version on Add/Remove programe ?

what happend if you have connect sepm console on sepm server ?

Just Upgraded the SEPM server from 12.1.1 to 12.1.2 and I am having the same problem, if I connect to the SEPM webconsole with the IP I get all of the pages correctly, If I use the FQDN some pages don't show through FireFox and Chrome.... I have no problem with the SEPM console on the server itself... 

Francisco 

Hi we are having the same problems after upgrading to 12.1.2 yesterday.   Has there been any resolution to this issue?

Hello, exact same problem here, did anyone find a solution?

Sorry, have not been on in a while.  My issue ended up being the aliases we were using for our SEPMs.  They did not work with the reporting screens (Home, Monitors, Reports), but worked with the admin screens (Policies, Clients, Admin).  Using the IP Address or the FQDN or our SEPMs worked for us.  Hope this helps!

Thanks, as you mentioned using the IP of the FQDN works but I was hoping to use the alias since it worked in earlier versions.

Same issue here.  Any solution for using aliases?

Same issue.  The console only works when you specify the servername alone (https://server:8443/console/apps/sepm) or the IP (https://192.168.1.100:8443//console/apps/sepm).  The self-signed cert references just the server name and not the FQDN.

Maybe they changed how the console processes requests for the web console involving the certificate.  I wonder if re-doing the cert, self-signed or otherwise, to include the FQDN might fix it?

I would take care replacing certs for SEP as the cert for the web console (admin screens) is also used to sign policies for clients.  I believe there is a process for doing it, but it is kind of complex.

I emailed our Symantec Engineer contact about this.  He is out of the office this week, but I hope to hear back from him when he returns.  Hopefully he can get more info about the issue.  

just reconfigure the serveur via the assistant.

"Reconfigure existant serveur" and select the backup of the private key and just press next and dot not continue the configuration of the database.

problem solved for me.

Regards.

Hi

Please reinstall Java and check

Regards

If the IP works and the friendly computer name doesn't then it's a DNS issue.  Especially, if it seems to log you in (with errors) but the POLICIES, CLIENTS and ADMIN buttons produce data and the HOME, MONITORS and REPORTS dont.

 Some people have multiple ways a machine can be addressed on the network but what's important is you use the one that NSLOOKUP resolves as.  Do an NSLOOKUP on the IP address of your SEP server. Then use the friendly name it resolves to in the NSLOOKUP as the server name in the SERVER: field with TCP port.   Make sure you include the full FQDN as it resolves in DNS in the SEP console logon screen.   For example if your SEP server's IP is 192.168.3.4, if NSLOOKUP 192.168.3.4 command produces   mysepserver.company.me.com,  then type mysepserver.company.me.com  in the SERVER field and try again. 

Also, if you have issue with logging in with both the IP and FQDN , SEP 12.1.2 intruduced a new TCP port for the console HTTPS communication (TCP 8445).  Make sure you add this port to your server's incoming firewall (Windows or network based firewall).  Both TCP 8443 and 8445 are needed for remote console access (unless you changed the ports from default).  (For the logon piece, I believe it uses 8443 and then once you are in the console, 8445 is used for some of the tabs) For all ports used by SEP you can see this page: http://www.symantec.com/business/support/index?page=content&id=TECH163787&profileURL=https%3A%2F%2Fsymaccount-profile.symantec.com%2FSSO%2Findex.jsp%3FssoID%3D1367857441149S5l57SYoNeYFY003ZRiTlNHuaU6zzi03n77od

I will try to address these one by one as I have not been on in a while.  Thank you all for your time.

DAGHBOUJI, the configuration wizard already was run after the upgrade.  A DNS alias is not changed in the SEP configuration wizard, it is changed in DNS

SameerU, we have tried this on multiple remote computers already running different versions of Java and also tried reinstalling Java on one of the remote computers and this did not resolve the issue.

jfschafer, respectfully your statement about port 8445 being new in 12.1.2 is incorrect, it has been the reporting port for long before this in 12.1 (possibly since the beginning of 12.1), to my knowledge, at least since our first version installed (12.1.1000.0157).  It is even mentioned in the training manual put out in 2011.

The issue is not logging in with the IP Address or FQDN, it is logging in with an alias assigned in DNS that does not work properly.  It is not a DNS isssue as the server would not be able to be connnected to at all if this were the case.  Also, as I mentioned above and others have as well, this worked PERFECTLY till after the upgraded from 12.1.1101.401 to 12.1.2015.2015.  It is not a firewall issue either as no ports have changed.

I never heard back from our Symantec Engineer about this.  It would be great if a Symantec Employee actually looked at this.  Aliases are not necessary, but they sure make remote administration easier as a SEPM can be changed without necessitating a change in how an administrator accesses the web console or java console, both of which encounter this issue.

Hello,

I came across the below article yesterday and applied it, it seems to have fixed the issue:

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

Regards

Thanks a_alakash, I tried this, but it is still not working for me.  Guess it is time for a support case.

ragenkagen, is there any resolution to this? I am seeing the exact issue.

No Resolution yet.  In fact, even after upgrading to RU3, it is still broken.  I have been meaning to open a case with Technical Support, but have not been able to as I have not had time to yet as I have had a different case open with them for the last few months.  I plan to open a case about this after that one is resolved.  Unless someone else comes up with a resolution before then.

I actually was able to resolve this just now with the tech article (201873)