Video Screencast Help

SEP Clients showing SEPM as "Offline" after upgrade to 12.1 RU3

Created: 23 Jul 2013 • Updated: 02 Aug 2013 | 20 comments
This issue has been solved. See solution.

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?

Operating Systems:

Comments 20 CommentsJump to latest comment

ᗺrian's picture

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

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Mithun Sanghavi's picture


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

Hope that helps!!

Mithun Sanghavi
Associate Security Architect


Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

trav531's picture

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.

Mithun Sanghavi's picture


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

Hope that helps!!

Mithun Sanghavi
Associate Security Architect


Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

trav531's picture

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.

Sylink.txt 54.19 KB
Rafeeq's picture

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

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.

trav531's picture

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

Mithun Sanghavi's picture


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 and httpd.conf are mismatching. (Port may be configured incorrect)

You can find - - C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Tomcat\etc\

httpd.conf - C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\apache\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\

2. Edit

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!!

Mithun Sanghavi
Associate Security Architect


Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

trav531's picture

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

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


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


Listen 80

When I made the change you suggested to the 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

Mithun Sanghavi's picture


Follow these steps:

1) Stop SEPM service
2) Delete all scm.iis entries from
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:

Hope that helps!!

Mithun Sanghavi
Associate Security Architect


Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

jpatel's picture

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.

Sylink.doc 54.2 KB
SameerU's picture


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


trav531's picture

Mithun: Did as you suggested, though there were no ISS entries in'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. 

SMLatCST's picture

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.


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

trav531's picture

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

trav531's picture

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

SMLatCST's picture

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:

trav531's picture

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

Sai Venkates's picture


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.