Endpoint Protection

Recently I upgraded our SEPM's to 12.1 RU3.  I used the automatic client upgrade feature to update the clients in one location, as I've done with upgrades in the past.  Any client that was upgraded to RU3, no longer communicates with the SEPM.  They are active and pulling updates from Symantec, but under Help>Troubleshooting it shows the server status as "Offline".  12.1.2015.2015 clients are still talking to the SEPM without an issue.

Has anyone seen behavior like this with the RU3 upgrade?

What happens if you replace the sylink file on one affected RU3 client? Does it connect?

Hello,

What happens to these clients after they are restarted, do they communicate to the SEPM again?

Are the client machines cloned / imaged?

Could you try replacing the sylink.xml on one of the client machines to check if the client report back to the SEPM?

In case of SEP 12.1 RU2 and above, you can get the client communication by following the steps below:

Restoring client-server communications by using a client installation package

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

Hope that helps!!

Restarts have no effect.  I've exported a new Sylink.xml file and imported it to one of the affected clients with no effect.  Uninstalled the SEP client, exported a new installation package from the SEPM, and reinstalled on the workstation, no change.  RU3 clients still show the SEPM as offline. 

I'm going to try rolling back to RU2 on one workstation and see if it communicates with the server again, just to see.

Enable Sylink logging on the client and post it here please

Hello,

I agree, could you please upload us with the sylink.log from one of the client machines.

How to enable Sylink debugging for the Symantec Endpoint Protection 11.x and 12.1 client in the Windows Registry

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

Hope that helps!!

Here is the Sylink log (attached).  Also, a bit more info.  We've now built 2 clean machines from disk. 

Machine 1: Win 7, SEP 12.1 RU2   Connects to SEPM running RU3

Machine 2: Win 7, SEP 12.1 RU3   Fails to connect (SEPM shows offline in the SEP client)

Aside from the SEP version, both machines are identical.

Attachment(s)

Sylink_10.txt   54 KB 1 version

Follow this document as I see the same error message in the logs

http://www.symantec.com/business/support/index?page=content&id=TECH137402

The legacy proxy settings can be removed by performing the following steps:

1.   Open the registry (Start->Run->type "regedit").

2.  Go to HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\InternetSettings\connections

3.  Delete the registry keys "DefaultConnectionSettings" and "SavedLegacySettings".

4.  Reboot the machine.

No luck on the Legacy Proxy settings.  Removed those registry values, rebooted the machine, and still no connection.

Hello,

Upon checking your sylink.log, we found the following Errors:

07/24 12:46:09.195 [4056] 12:46:9=>Send HTTP REQUEST
07/24 12:46:39.181 [4056] AH: (InetWaiting) time out. Timeout period: 30000
07/24 12:46:39.181 [4056] Throw Internet Exception, Error Code=9;Internet Session Timeout
07/24 12:46:39.181 [4056] CInternetException: <GetIndexFileRequest:>: The storage control block address is invalid.

07/24 12:47:10.205 [4056] 12:47:10=>Send HTTP REQUEST
07/24 12:47:10.225 [4056] 12:47:10=>HTTP REQUEST sent
07/24 12:47:10.225 [4056] <GetIndexFileRequest:>SMS return=404
07/24 12:47:10.225 [4056] <ParseHTTPStatusCode:>404=>404 Not Found
07/24 12:47:10.232 [4056] HTTP returns status code=404
07/24 12:47:10.232 [4056] <GetIndexFileRequest:>RECEIVE STAGE COMPLETED
07/24 12:47:10.232 [4056] <GetIndexFileRequest:>COMPLETED
07/24 12:47:10.232 [4056] <IndexHeartbeatProc>GetIndexFile handling status: 404
07/24 12:47:10.232 [4056] <IndexHeartbeatProc>Switch Server flag=1
07/24 12:47:10.234 [4056] HEARTBEAT: Check Point 5.1
07/24 12:47:10.234 [4056] <ScheduleNextUpdate>new scheduled heartbeat=512 seconds

07/24 12:47:10.734 [4056] 12:47:10=>Send HTTP REQUEST
07/24 12:47:10.754 [4056] 12:47:10=>HTTP REQUEST sent
07/24 12:47:10.754 [4056] <GetIndexFileRequest:>SMS return=404
07/24 12:47:10.754 [4056] <ParseHTTPStatusCode:>404=>404 Not Found
07/24 12:47:10.754 [4056] HTTP returns status code=404
07/24 12:47:10.754 [4056] <GetIndexFileRequest:>RECEIVE STAGE COMPLETED
07/24 12:47:10.754 [4056] <GetIndexFileRequest:>COMPLETED
07/24 12:47:10.754 [4056] <IndexHeartbeatProc>GetIndexFile handling status: 404

Could you check if there is a Proxy on the Environment?

If yes, make sure you have proper exceptions created.

Could you check if the ports in conf.properties and httpd.conf are mismatching. (Port may be configured incorrect)

You can find - 

conf.properties - C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Tomcat\etc\conf.properties

httpd.conf - C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\apache\conf

conf.properties:

scm.webserver.http.port=8014
scm.iis.http.defaultsite=0

httpd.conf:

Listen 80

If yes, could you try following the steps below:

1. Go to C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Tomcat\etc\conf.properties

2. Edit conf.properties

3. Replace "scm.webserver.http.port=8014" by "scm.webserver.http.port=80"

4. Delete "scm.iis.http.defaultsite=0"

5. Save changes

6. Restart Symantec Endpoint Protection Manager and Symantec Endpoint Protection Manager Webserver services

Hope that helps!!

There is no proxy in the environment, we're NAT routed.

I checked the two config files.  The ports do indeed mismatch.

Conf.properties

scm.webserver.http.port=8014

smc.iis.http.defaultsite=0 does not exist

httpd.conf

Listen 80

When I made the change you suggested to the conf.properties file, restarted the services, the "Symantec Endpoint Protection Manager" service would not stay running.  It would stop after a couple of seconds.  Restarted services a couple of times, and also restarted the server itself, but the service kept stopping on it's own.  I finally changed it back port 8014

Hello,

Follow these steps:

1) Stop SEPM service
2) Delete all scm.iis entries from conf.properties
3) Run Management Server Configuration Wizard and reconfigure the client communication port 8014
3) Login to SEPM and replace the Sylink file

Secondly, Make sure that port used by Symantec Web Server is not used by another application.

Disable the SEPM IIS website and configure the Apache Web server to listen to custom ports that clients connect to using the below KB:

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

Hope that helps!!

I seem to be having a similiar issue. i have attached the sylink file from one of the clients

i have multiple clients who show offline, and have no green dot. though show they have connected recently. in some cases a minute ago, and i know they are on the network and live.

Attachment(s)

Sylink_3.doc   54 KB 1 version

Hi

Can you do the following

1. Delete the entry from SEPM.

2. On client side stop and start the service of the client

Let me know the update after that

Regards

Mithun: Did as you suggested, though there were no ISS entries in conf.properties....I'm guessing because we've never had SEP 11 in our environment?  At any rate, there was no change.

SameerU: Deleted my Active Directory synced OU's, and pulled down a new sync.  No change.  The 12.1.2015.2015 clients still connect, the 12.1.3001.165 clients do not. 

The sylink logs all seem to show issues communciating over https.  I don't suppose you've tested using the http over 8014 have you?

I'd just like to rule it out.

Also I'd recommend trying a MSL and sylink file that has only the internal addresses listed.  Essentially, I'd start troubleshooting by making sure that the SEP Client can communicate using the default methods, before we then move onto factoring in your customisations.

#EDIT#

Oh yeah, sylink logs from a working 12.1RU2 client would be useful too, so we can compare any differences

Correction.  "After reverting policies back to the default server list, exporting a new Sylink.xml, the new clients are NOW communicating with the server"

After reverting policies back to the default server list, exporting a new Sylink.xml, the new clients are now communicating with the server.  Thanks everyone for the suggestions and troubleshooting.

Unfortunately, between Tamper Protection being active, and there being a password on the stop/start command, updating the Sylink.xml file on 740 workstations is going to be tedious I'm afraid.  I don't suppose anyone has a suggestion on how to automate the push?  lol

Try using the sylinkdrop tool included in all SEP12.1 clients.  The below article walks you through creating a Tamper Protection exception, plus it can be passed the client protection password too:

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

Perfect!  Tested and working great, and is now running against all my affected clients.  Thank you so much for everyone's help!

Friends,

In my case i had also rebuild the OS.I had the same issue for 4 Different SEPM servers. And for me restoring the server certificates sorted out the issue.

Sai