Endpoint Protection

Hello,

I can no longer get any SEP clients to communicate back to the SEPM server.  Please read my findings and also what I think I may have done to cause it at the very end.

Here's my findings:

- Server PC successfully pings from client

- Client PC successfully pings from server

- SECARS test from client PC fails with "This page can’t be displayed"  (I'm using:  http://avconsole:8014/secars/secars.dll?hello,secars)

- Telnet fails from Client PC to server with "Could not open connection to the host, on port 8014: Connect failed"  (I'm using:  telnet avconsole 8014)

- Running netstat -a | findstr LISTENING from Server PC shows:  TCP     0.0.0.0:8014     AVCONSOLE:0     LISTENING

- I'm not using the Symantec Firewall at all.

- I have a Windows Firewall Rules for both Inbound and Outbound allowing TCP 80, TCP 139, TCP 443, TCP 445, TCP 1100, TCP 1433, TCP 2638, TCP 2967, TCP 8014, TCP 8045, TCP 8443, TCP 8444, TCP 8445, TCP 8446, TCP 8447, TCP 8765, TCP 9090, TCP 49152 - 65535, UDP 137, UDP 138, UDP 1812, UDP 39999 

- Open Symantec Client, going to Troubleshootling, under Management the Server is listed as Offline

- Open Symantec Client, going to Troubleshootling, under Connection Status, the Status is listed as Not Connected with Error listed as WinInet error 9

- I've attached my Sylink log

What I think I may have done to cause it:

My system was working fine last week.  Green dots on all clients.  But I made two changes where I think one or both could be the issue(s) but I'm not exactly sure how to fix them.

My 1st bone-headed mistake:  I accidentally linked a GPO to the Server PC that reconfigured it's firewall rules and made them more complicated/broken (before the GPO was applied they were the generic initial firewall rules that comes with a typical Windows install).  I then unlinked the GPO and in the Windows Firewall settings on the Server PC I hit "Restore Default Policy"

2nd bone-headed mistake:  I re-organized my Active Directory structure the same week.  The Symantec Management Console had the old hierarchy so I did a "sync now" and it reflected the new hierarchy.

One or likely both of these actions caused my issue.  Please weigh in on what you think it is based on the Sylink log and my messed-up actions.  :)  I've spent hours looking through the archives here to solve my own issue but I'm missing something.  Please help! 

Attachment(s)

sylink_log.txt   208 KB 1 version

Sylink just gives a generic "can't connect to server"

Can't really see how #2 would cause this. #1 seems likey but it sounds like you have 8014 opened already.. Out of curiosity what happens if you replace the sylink on one affected client?

Thanks for asking.  :)

Ok, so I went to the SEPM on the server, I selected the appropriate sync'd folder, right-clicked and used "Export Communication Settings".  I then took that sylink file to the specific affected client that was listed uEC)nder the sync'd folder, opened up the SEP client on it (entered the password to open interface) went to Troubleshooting, went to Management, and hit the Import under Communication Settings and loaded the sylink file from the desktop.

It looked to load it in.  I then did a smc -stop and smc -start, reopened the client and reviewed the Troubleshooting area again.

The Server still says Offline, the Group has the generic "My Company\Default Group" listed as opposed to the actual sync'd folder location.  The Connection Status area still states Not Connected and Error: WinInet error 9.  Also saw that the serial Policy Number is different for the client PC on the SEPM (39EC) versus on the actual client's Troubleshooting / Management area (D419).

Also here's the Sylink log from the affected PC where I tried to Sylink drop.  Looks slightly different to me, maybe less generic...

Thanks,

Noigel

Attachment(s)

NewDiffSylink.txt   28 KB 1 version

Hi Noigel,

The log is captured for a just 2 minutes and there is no data to analyze. can you collect the log for atleast 2 heart beat interval and share us the log to provide additional suggestions.

Regards,

Praveen

DUPE POST, DELETE IF DESIRED.

(Thanks for letting me know I didn't let the log run long enough Praveen I will know that for next time.)

With the help of a co-worker I got the issue fixed.  Turns out it was my boneheaded mistake number 1) the modification of the firewall rules.

Even though I had created a rule to set 8014 to be open... it wasn't.  We ended up using a few programs to portscan 8014 from a client PC and we saw that it indeed wasn't open/communicating.  Turning the firewall off completely allowed the communication between the SEPM and client and now I just need to restructure my firewall rules. 

My takeaways from this:

1) There are different functions available between the "Windows Firewall" program and the "Windows Firewall with Advanced Security" programs... namely the ability to turn the firewall off and also turning if off on the individual sections (Domain, Private, Public) which are found in the more general "Windows Firewall" setup.  I always thought "Windows Firewall with Advanced Security" had ALL the firewall functionality and was comprehensive... but no... you should troubleshoot and test with both interfaces.

2) Turning off the Windows Firewall in the "Window Firewall" window is DIFFERENT from stopping the Windows Firewall service entirely (say by using services.msc).  I had no success by stopping the service entirely.

3) Use port sniffing software to truly determine the state of the ports you think you've opened on the SEPM server.  Port 8014 had to be open for my (configured fairly typical) SEPM/Clients setup to work.

Thanks again Brian and Praveen for the responses and help!