1 | Page

Which Communication Ports does Symantec Endpoint Protection 11.0 use?

Solution

Port
Port
Initiated by
Number Type

Listening
Process

svchost.exe
80, 8014 TCP SEP Clients
(IIS)

443

1433

Description
Communication between the SEPM manager
and SEP clients and Enforcers. (8014 in MR3
and later builds, 80 in older).

Optional secured HTTPS communication

svchost.exe
TCP SEP Clients
between a SEPM manager and SEP clients and
(IIS)
Enforcers.

TCP

SEPM
manager

sqlservr.exe

Communication between a SEPM manager

and a Microsoft SQL Database Server if they
reside on separate computers.

1812

UDP

Enforcer

w3wp.exe

RADIUS communication between a SEPM

manager and Enforcers for authenticating
unique ID information with the Enforcer.

2638

TCP

SEPM
manager

dbsrv9.exe

Communication between the Embedded

Database and the SEPM manager.

8014,
8443

HTTPS communication between a remote

Remote Java
management console and the SEPM manager.
TCP
or web
SemSvc.exe
All login information and administrative
console
communication takes place using this secure
port.

9090

Initial HTTP communication between a remote

Remote web
TCP
SemSvc.exe management console and the SEPM manager
console
(to display the login screen only).

8005

TCP

SEPM
manager

39999

UDP

2967

TCP SEP Clients

SemSvc.exe

The SEPM manager listens on the Tomcat

default port.
Communication between the SEP Clients and
the Enforcer. This is used to authenticate
Clients by the Enforcer.

Enforcer

Smc.exe

The Group Update Provider (GUP) proxy

2 | Page

functionality of SEP client listens on this port.

The Symantec Endpoint Protection Manager (SEPM) uses two web servers: Internet
Information Services (IIS) and Tomcat. IIS uses port 80 (or 8014) and 443. Tomcat uses
port(s) 9090 and 8443. The communication between IIS and Tomcat uses the HTTP protocol.
IIS uses port 9090 to talk to Tomcat, Tomcat uses port 80 to talk to IIS.
Client-Server Communication:
For IIS SEP uses HTTP or HTTPS between the clients or Enforcers and the server. For the
client server communication it uses port 80 (or 8014) and 443 by default. In addition, the
Enforcers use RADIUS to communicate in real-time with the manager console for clients
authentication. This is done on UDP port 1812.
Remote Console:
9090 is used by the remote console to download .jar files and display the help pages.
8443 is used by the remote console to communicate with SEPM and the Replication Partners
to replicate data.
Web Console:
8443 is used by the web console to communicate with the SEPM.
8014 is used by the web console to communicate with SEPM Reporting component.
Client-Enforcer Authentication:
The clients communicate with the Enforcer using a proprietary communication protocol. This
communication uses a challenge-response to authenticate the clients. The default port for this
is UDP 39,999.
Troubleshooting the Group Update Provider (GUP) in Symantec Endpoint
Protection (SEP)
Problem
How do I use debug logs to troubleshoot a GUP?
Solution
How does the GUP get defined?
o A setting will be added to the LiveUpdate (LU) policy specifying one member
of the client group as a content proxy. This machine will be the Group Update
Provider (GUP)
o Every SEP client contains mini-HTTP server code that allows it to potentially
become the GUP.

3 | Page

o The LU Policy will specify a hostname/IP and port of the GUP HTTP server
machine that will default to port 2967, but can be reconfigured to an alternate
port. The administrator can specify either the host name of the machine or the
IP. (The reason for using port 2967 is that Symantec customers already have
routing and firewalls set up for this. Symantec AntiVirus (SAV) Corporate
Edition 8/9/10 and SEP 11.0 will not coexist on the same machine, and in the
case of a SAV environment, will not have the same parents. In most instances,
it is known that there are no conflicts with port 2967, or those conflicts were
already sorted out by the administrators. Port 80 is a collision prone port.)
o The file transfer will be over HTTP and contained within the HTTP Response
payload. This is exactly the same as the existing transport. The protocol will
be the SyLink protocol.
o HTTPS will NOT be supported for the SEP 11.0 release.
o Content delivered by Symantec Endpoint Protection Manager (SEPM) will be
cached.
o The GUP will NOT initially support the patch and update channel. It was
considered to be out-of-scope for SEP 11.0. There are no plans to address this
yet.
When a client becomes the GUP
o The mini-HTTP server code will be a DLL extension to the SMC Agent. The
design has the GUP running independently of the internal content handling.
GUP is loaded by the SMC Agent when configured. When it starts up it begins
listening on the configured port. It continues listening until it is shut down.
o All the clients in the group receive the same proxy policy configuration. The
one that matches the proxy address/hostname is the proxy and loads the micro
web server..
o The machine that is designated as the GUP will create a directory, if it doesnt
already exist, at the following location:
(Client install location)\SharedUpdates
Default location: C:\Program Files\Symantec\Symantec Endpoint
Protection\SharedUpdates
This SharedUpdates folder will cache all proxied files. For the first round of
implementation this will only be managed LU content. No other

4 | Page

communication or content will be proxied. Getting index files and profiles,

posting state and logs, etc. will be done directly with server.
o The SharedUpdates directory will not immediately be populated, but rather,
when the GUP receives a request it checks to see if the requested file(s) are
present in the local cache. If it is, it responds to the request with the file. If it
isnt, then GUP holds the pending request, and reissues the same GetLUFile
SyLink request to the server. When that file arrives it is added to the GUP
cache.
o The GUP code can only get content updates from SEPM. As far as the GUP is
concerned, it does not know about the client it resides on, so even if the client
were to get updated via alternative means - Intelligent Updater or
Symantec/Internal LiveUpdate - the GUP would not be able to use those
updates to proxy for other clients.
o For more information regarding GUP see the SEP Administration_Guide.PDF
on SEP Install CD1.

Below is an example of a system registry after the GUP is activated:

[HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint
Protection\LiveUpdate]
"Description"="Created automatically during product installation."
"Enabled3rdPartyManagement"=dword:00000000
"MasterClientHost"="192.168.2.4"
"MasterClientPort"="2967"
"UseLiveUpdateServer"=dword:00000000
"UseManagementServer"=dword:00000001
"UseMasterClient"=dword:00000001
"HttpEncrypt"=dword:00000001
"HttpProxyMode"=dword:00000000
"HttpProxyRequireAuthentication"=dword:00000000
"FtpEncrypt"=dword:00000001
"FtpProxyMode"=dword:00000000
"FtpProxyRequireAuthentication"=dword:00000000
"AllowLocalScheduleChange"=dword:00000000
"AllowManualLiveUpdate"=dword:00000000
"EnableProductUpdates"=dword:00000000
"LastLuProductInventoryHash"=hex:72,59,31,36,a8,3f,47,02,70,5f,bd,52,29,d0,25,\4
9
"LastGoodSession"=hex:68,13,c8,94,d1,8b,c8,01

5 | Page

There is a debug.log file saved to the "%ProgramFiles%\Symantec\Symantec Endpoint

Protection" folder by default. If the default logging is disabled you can enable it with the
following registry setting:

To enable debugging for the GUP, you can either enable it through the SEP user
interface - SEP UI -> Help and Support button -> Troubleshooting -> Debug
Logs -> Client Management section -> Edit Debug Log Settings button -> check
the Debug On box -> Debug level: 0 -> Log level: 0 - Debug -> Log file size (KB):
10000 -> OK -> Close, or modify the following registry keys:
[HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint
Protection\SMC]
"smc_debuglog_on = dword:00000001"
[HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint
Protection\SMC\Log]
"debug_log_filesize = dword:0x00002710 (10000)"
The SMC process (the executable for the "Symantec Management Client" service) must be
stopped and restarted for changes in debug logging to take effect:
From a Run line type in the following:
smc -stop
Once the SEP shield icon disappears from the System Tray, then type:
smc -start
You also should be able to telnet to Port 2967 on the GUP and see the connection in the
GUP logs.

Below is an example of a GUP receiving a connection from another machine and the
connection working but the data in the connection
is bad and the GUP rejecting the connection:
03/21 23:00:59 [2628:1908] GUProxy: thread [1908] accepted on socket 2228
03/21 23:01:03 [2628:1908] GUPROXY - GUProxy HTTP in - H
03/21 23:01:03 [2628:1908] GUPROXY - malformed or misdirected request
03/21 23:01:03 [2628:1908] GUProxy - closing accepted socket
Successful Connection and update from a client:

6 | Page

03/23 11:06:01 [2640:2088] GUProxy: thread [2088] accepted on socket 2012

03/23 11:06:01 [2640:2088] GUPROXY - GUProxy HTTP in - GET /content/
{C60DC234-65F9-4674-94AE-62158EFCA433}/80322021/delta8032
03/23 11:06:01 [2640:2088] GUPROXY - GUProxy File - /content/{C60DC23465F9-4674-94AE-62158EFCA433}/80322021/delta80322003.dax
03/23 11:06:01 [2640:2088] GUProxy content cached - sending to client
03/23 11:06:01 [2640:2088] GUProxy - closing accepted socket
03/23 11:06:01 [2640:2088] GUProxy thread [2088] accepting
Below is what you will see in the debug.log when a GUP is first configured:
03/21 20:03:05 [2628:3124] GUProxy: PolicyUpdateCallback called
03/21 20:03:06 [2628:3124] GUProxy system event - type 0 - desc <Start using
Group Update Provider (proxy server) @ 192.168.2.4:2967.> -extra <(null)>
03/21 20:03:06 [2628:3124] GUProxy: Start using Group Update Provider (proxy
server) @ 192.168.2.4:2967.
03/21 20:03:06 [2628:3124] GUProxy system event - type 0 - desc <Start serving as
the Group Update Provider (proxy server).> - extra <(null)>
03/21 20:03:06 [2628:3124] GUProxy: Policy Change - Client will start serving as a
local proxy server @ 192.168.2.4:2967
03/21 20:03:06 [2628:3124] GUProxy: SetUpGUPListenSocket
03/21 20:03:06 [2628:3124] GUProxy: Create new GUP socket
03/21 20:03:06 [2628:3124] GUProxy: creating GUP listen socket with port 2967
03/21 20:03:07 [2628:1908] GUProxy: listenthread [1908] starting
03/21 20:03:07 [2628:1908] GUProxy thread [1908] accepting
Example of a File request "not in cache", but being retrieved by the GUP from
the server:
03/24 13:26:08 [1436:1796] GUProxy: thread [1796] accepted on socket 2404
03/24 13:26:08 [1436:1796] GUPROXY - GUProxy HTTP in - GET /content/
{C60DC234-65F9-4674-94AE-62158EFCA433}/80324005/delta8032
03/24 13:26:08 [1436:1796] GUPROXY - GUProxy File - /content/{C60DC23465F9-4674-94AE-62158EFCA433}/80324005/delta80323019.dax
03/24 13:26:08 [1436:1796] GUProxy new cache entry
03/24 13:26:08 [1436:1796] GUPROXY - GUProxy mangled file #content#{C60DC234-65F9-4674-94AE62158EFCA433}#80324005#delta80323019!dax
03/24 13:26:09 [1436:1796] Lock held for 47ms
03/24 13:26:09 [1436:1796] GUPROXY - GUProxy - Requested file not in cache;
contacting the SEPM server at - L-L3F3526
03/24 13:26:09 [1436:1796] GUPROXY - GUProxy Response - HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1 X-Powered-By: ASP.NET Dat
03/24 13:26:09 [1436:1796] GUProxy - sending response to client

7 | Page

03/24 13:26:09 [1436:1796] GUProxy - closing accepted socket

03/24 13:26:09 [1436:1796] GUProxy thread [1796] accepting
Example of a Sylink log from a client to a GUP requesting an update:
<LUThreadProc>Starting LU download.
03/24 14:29:04 [2232] <LUThreadProc>Got a valid context from
GetCurrentServerEx
03/24 14:29:04 [2232] <LUThreadProc>Setting the session timeout on LUSession to
2 min.
03/24 14:29:04 [2232] <mfn_MakeGetLUFileIISUrl:>Requested Content Path is:
/content/{C60DC234-65F9-4674-94AE62158EFCA433}/80324005/delta80323019.dax
03/24 14:29:04 [2232] <GetLUFileRequest:>IIS URL: /content/{C60DC234-65F94674-94AE-62158EFCA433}/80324005/delta80323019.dax
03/24 14:29:04 [2232]
<GetLUFileRequest:>http://192.168.2.5:2967/content/{C60DC234-65F9-467494AE-62158EFCA433}/80324005/delta80323019.dax
03/24 14:29:04 [2232] <GetLUFileRequest:>NEW download: C:\Program
Files\Symantec\Symantec Endpoint Protection\LiveUpdate\LUF5.tmp
03/24 14:29:04 [2232] <UpdateLUFileList:>Updating existing Download File List
with : {C60DC234-65F9-4674-94AE-62158EFCA433}80324005
03/24 14:29:04 [2232] <UpdateLUFileList:>Updating existing Download File List
Temp file name from: to C:\Program Files\Symantec\Symantec Endpoint
Protection\LiveUpdate\LUF5.tmp
03/24 14:29:04 [2232] 14:29:4=>Sending HTTP REQUEST to download LU file
03/24 14:29:05 [2232] 14:29:5=>HTTP REQUEST sent
03/24 14:29:05 [2232] <GetLUFileRequest:>IIS return=200
03/24 14:29:05 [2232] <mfn_DoGetLUFile200>Downloading LU file from server.
Moniker: {C60DC234-65F9-4674-94AE-62158EFCA433}Server File Path:/content/
{C60DC234-65F9-4674-94AE-62158EFCA433}/80324005/delta80323019.daxLocal
Path:C:\Program
Files\Symantec\Symantec Endpoint Protection\LiveUpdate\LUF5.tmp
03/24 14:29:05 [2232] <mfn_DoGetLUFile200>Content Length => 35403
03/24 14:29:05 [2232] <UpdateLUFileList:>Updating existing Download File List
with : {C60DC234-65F9-4674-94AE-62158EFCA433}80324005
03/24 14:29:05 [2232] <UpdateLUFileList:>Updating existing Download File List
Temp file name from: C:\Program Files\Symantec\Symantec Endpoint
Protection\LiveUpdate\LUF5.tmp to C:\Program Files\Symantec\Symantec Endpoint
Protection\LiveUpdate\LUF5.tmp
03/24 14:29:05 [2232] <mfn_DoGetLUFile200>LU Content Downloaded. Moniker:
{C60DC234-65F9-4674-94AE-62158EFCA433} Target Seq:80324005 Full
version:0 Delta Base Seq:80323019
03/24 14:29:05 [2232] <PostEvent>going to post

8 | Page

event=EVENT_LU_DOWNLOAD_COMPLETED
03/24 14:29:25 [2224] <CSyLink::mfn_DownloadNow()>
03/24 14:29:25 [2224] </CSyLink::mfn_DownloadNow()>
03/24 14:29:30 [2232] <PostEvent>done post
event=EVENT_LU_DOWNLOAD_COMPLETED, return=0

Below is what you will see in the Sylink if the GUP is off line:
03/25 00:38:01 [2232] <LUThreadProc>Setting the session timeout on LUSession to
2 min.
03/25 00:38:01 [2232] <mfn_MakeGetLUFileIISUrl:>Requested Content Path is:
/content/{812CD25E-1049-4086-9DDDA4FAE649FBDF}/80324040/delta80321051.dax
03/25 00:38:01 [2232] <GetLUFileRequest:>IIS URL: /content/{812CD25E-10494086-9DDD-A4FAE649FBDF}/80324040/delta80321051.dax
03/25 00:38:01 [2232]
<GetLUFileRequest:>http://192.168.2.5:2967/content/{812CD25E-1049-40869DDD-A4FAE649FBDF}/80324040/delta80321051.dax
03/25 00:38:01 [2232] <GetLUFileRequest:>NEW download: C:\Program
Files\Symantec\Symantec Endpoint
Protection\LiveUpdate\LUF140D.tmp
03/25 00:38:01 [2232] <UpdateLUFileList:>Updating existing Download File List
with : {812CD25E-1049-4086-9DDD-A4FAE649FBDF}80324040
03/25 00:38:01 [2232] <UpdateLUFileList:>Updating existing Download File List
Temp file name from: to C:\Program Files\Symantec\Symantec Endpoint
Protection\LiveUpdate\LUF140D.tmp
03/25 00:38:01 [2232] 0:38:1=>Sending HTTP REQUEST to download LU file
03/25 00:38:24 [2224] <CSyLink::mfn_DownloadNow()>
03/25 00:38:24 [2224] </CSyLink::mfn_DownloadNow()>
03/25 00:38:24 [2232] 0:38:24=>HTTP REQUEST sent
03/25 00:38:24 [2232] <GetLUFileRequest:>Send Request failed.. Error Code =
12029
03/25 00:38:24 [2232] <ParseErrorCode:>12029=>The attempt to connect to the
server failed.
03/25 00:38:24 [2232] <GetLUFileRequest:>IIS return=0
03/25 00:38:24 [2232] <ParseErrorCode:>12029=>The attempt to connect to the
server failed.
03/25 00:38:24 [2232] <GetLUFileRequest:>COMPLETED
03/25 00:38:24 [2232] <LUThreadProc> - GETLUFILE_CONNECTION_ERROR
getting content moniker:
{812CD25E-1049-4086-9DDD-A4FAE649FBDF}; revision: 80324040 from server:
192.168.2.5
03/25 00:38:24 [2232] LU file download failed due to HTTP error:0

9 | Page

03/25 00:38:24 [2232] <CExpBackoff::Increment()>

03/25 00:38:24 [2232] Backoff index incremented
03/25 00:38:24 [2232] Backoff wait index: 1
03/25 00:38:24 [2232] </CExpBackoff::Increment()>
03/25 00:38:24 [2232] <CExpBackoff::Wait()>
03/25 00:38:24 [2232] CExpBackoff wait time in seconds: 32
03/25 00:38:56 [2232] </CExpBackoff::Wait()>
03/25 00:38:56 [2232] <LUThreadProc>Setting the session timeout on LUSession to
2 min.
03/25 00:38:56 [2232] <mfn_MakeGetLUFileIISUrl:>Requested Content Path is:
/content/{E5A3EBEE-D580-421e-86DF54C0B3739522}/80324040/delta80321051.dax
03/25 00:38:56 [2232] <GetLUFileRequest:>IIS URL: /content/{E5A3EBEE-D580421e-86DF-54C0B3739522}/80324040/delta80321051.dax
03/25 00:38:56 [2232]
<GetLUFileRequest:>http://192.168.2.5:2967/content/{E5A3EBEE-D580-421e86DF-54C0B3739522}/80324040/delta80321051.dax
03/25 00:38:56 [2232] <GetLUFileRequest:>NEW download: C:\Program
Files\Symantec\Symantec Endpoint
Protection\LiveUpdate\LUF140E.tmp
03/25 00:38:56 [2232] <UpdateLUFileList:>Updating existing Download File List
with : {E5A3EBEE-D580-421e-86DF-54C0B3739522}80324040
03/25 00:38:56 [2232] <UpdateLUFileList:>Updating existing Download File List
Temp file name from: to C:\Program Files\Symantec\Symantec Endpoint
Protection\LiveUpdate\LUF140E.tmp
03/25 00:38:56 [2232] 0:38:56=>Sending HTTP REQUEST to download LU file
03/25 00:39:18 [2232] 0:39:18=>HTTP REQUEST sent
03/25 00:39:18 [2232] <GetLUFileRequest:>Send Request failed.. Error Code =
12029
03/25 00:39:18 [2232] <ParseErrorCode:>12029=>The attempt to connect to the
server failed.
03/25 00:39:18 [2232] <GetLUFileRequest:>IIS return=0
03/25 00:39:18 [2232] <ParseErrorCode:>12029=>The attempt to connect to the
server failed.
03/25 00:39:18 [2232] <GetLUFileRequest:>COMPLETED
03/25 00:39:18 [2232] <LUThreadProc> - GETLUFILE_CONNECTION_ERROR
getting content moniker:
{E5A3EBEE-D580-421e-86DF-54C0B3739522}; revision: 80324040 from server:
192.168.2.5
03/25 00:39:18 [2232] LU file download failed due to HTTP error:0
03/25 00:39:18 [2232] <CExpBackoff::Increment()>
03/25 00:39:18 [2232] Backoff index incremented
03/25 00:39:18 [2232] Backoff wait index: 2
03/25 00:39:18 [2232] </CExpBackoff::Increment()>

10 | P a g e

03/25 00:39:18 [2232] <CExpBackoff::Wait()>

03/25 00:39:18 [2232] CExpBackoff wait time in seconds: 64
03/25 00:39:26 [2224] <CSyLink::mfn_DownloadNow()>
03/25 00:39:26 [2224] </CSyLink::mfn_DownloadNow()>
03/25 00:40:22 [2232] </CExpBackoff::Wait()>
Symantec Endpoint Protection: Troubleshooting Client/Server Connectivity
Problem
How to troubleshoot client to manager connectivity issues.
Symptoms
A client is not receiving definition updates.

Client is not receiving policy updates.

Client is not showing a green dot in the Taskbar.

Client is not showing a green dot in the Symantec Endpoint Protection Manager
console.

Solution
About communication problems
Check network connectivity before you call Symantec Technical Support. Once that
has been verified, check the communication between the client and the server. For
example, the client may not be receiving Policy updates or it may not be receiving
Content updates. It is important to gather as much information as possible about
which communications are working and which are not.
About checking the communication between the client and the management server
If you have trouble with the client and the server communication, you should first
check to make sure that there are no network problems. You can test the
communication between the client and the management server in several ways.
Table 2-1 describes the steps that you can take to check the communication
between the client computer and the management server.

11 | P a g e

12 | P a g e

Viewing the client status in the management console

You can check the client status icon in the management console as well as on the
client directly to determine client status.
Table 2-3 shows the various icons that might appear in the management console
for the client status.

13 | P a g e

To view the client status in the management console:

1. In the management console, on the Clients page, under "View Clients",
select the group in which the client belongs.
2. Look on the Clients tab.
The client name should appear in the list next to an icon that shows the
client
status.
About the client status icon on the client
You can find the client status icon in the notification area of the taskbar on the client
computer. The icon appears as a yellow shield icon with a green dot when the client
can communicate with the management server.
Viewing the policy serial number
You should check the policy serial number on the client to see if it matches the serial
number that appears in the management console. If the client communicates with the
management server and receives regular policy updates, the serial numbers should
match.
If the policy serial numbers do not match, you can try to manually update the policies
on the client computer and check the troubleshooting logs.
To view the policy serial number in the management console
1. In the management console, click Clients.
2. Under "View Clients", select the relevant group, and then select the Details
tab.
The policy serial number and the policy date appear at the bottom of the details list.
To view the policy serial number on the client
1. On the client computer, in the client user interface, click on the Help
and Support button, select Troubleshooting.
2. In the Management section, look at the policy serial number.

The serial number should match the serial number of the policy that the management
server pushes to the client.

14 | P a g e

About performing a manual policy update to check the policy serial number
You can perform a manual policy update to check whether or not the client receives
the latest policy update. If the client does not receive the update, there might be a
problem with the client and server communication.
You can try a manual policy update by doing any of the following actions:

In the client click on the Help and Support button, click

Troubleshooting. Under Policy Profile, click Update. You can use this
method if you want to perform a manual update on a particular client.

For the clients that are configured for pull mode, the management
server downloads policies to the client at regular intervals (heartbeat).
You can change the heartbeat interval so that policies are downloaded
to the client group more quickly. After the heartbeat interval, you can
check to see if the policy serial
numbers match. (For the clients that are configured for push mode, the
clients receive any policy updates immediately.)

After you run a manual policy update, make sure that the policy serial number that
appears in the client matches the serial number that appears in the management
console.
Using the ping command to test the connectivity to the management server
You can try to ping the management server from the client computer to test
connectivity.
To use the ping command to test the connectivity to the management server
1. On the client, open a command prompt.
2. Type the ping command. For example:
ping name
Where name is the computer name of the management server. You can use the
server IP address in place of the computer name. In either case, the command
should return the server's correct IP address.
If the ping command does not return the correct address, verify the DNS service for
the client and check its routing path.
Using a browser to test the connectivity to the management server

15 | P a g e

You can use a Web browser to test the connectivity to the management server.
To use a browser to test the connectivity to the management server:
1. On the client computer open a Web browser, such as Internet Explorer.
2. In the browser command line, type a command that is similar to either of the
following commands:
o http://<management server IP address>:<port used by the SEPM
website>/reporting/index.php
If the reporting log-on Web page appears, the client can communicate
with the management server.
o http://<management server name>:9090
If the Symantec Endpoint Protection Manager Console page appears,
the client can communicate with the management server.
3. If a Web page does not appear, check for any network problems. Verify the
DNS service for the client and check its routing path.

Using Telnet to test the connectivity to the management server

You can use Telnet to test the connectivity to the IIS server on the management server.
If the client can Telnet to the management server's HTTP or HTTPS port, the client
and the server can communicate. The default HTTP port is 8014 (80 for the earlier
builds of SEP); the default HTTPS port is 443.
Note: You might need to adjust your firewall rules so that the client computer can
Telnet into the management server.
For more information about the firewall, see the Administration Guide for Symantec
Endpoint Protection and Symantec Network Access Control.
To use Telnet to test the connectivity to the management server
1. On the client computer, make sure the Telnet service is enabled and
started.
2. Open a command prompt and enter the Telnet command. For example:
telnet ip address 8014
where ip address is the IP address of the management server.

16 | P a g e

If the Telnet connection fails, verify the client's DNS service and check its routing
path.

Verify the Windows Firewall is not enabled on the management server (SEPM) or the
client.

Windows Server 2003:

Use the netsh command line to disable the firewall:
netsh firewall set opmode mode = disable
Windows Server 2008
Server 2008 uses a profile based approach to the firewall settings. Again, use the netsh
command but you will need to specify profile you want to configure (or disable in this
case):
netsh advfirewall set <profile> state off
Values for <profile> are as follows:
allprofiles - change the settings for all the profiles.
currentprofile - change the setting for just the current profile.
domainprofile - change the settings for the domain profile.
privateprofile - change the settings for the private profile.
publicprofile - change the settings for the public profile.
If SEPM and its associated processes (Tomcat, IIS, etc..) are the only applications on
this server, we recommend using the "allprofiles" profile for the command line;
otherwise choose the appropriate profile.
Windows XP
1. Click Start, click Run, type Firewall.cpl, and then click OK.
2. On the General tab, click Off
3. Click OK.
Windows Vista/Windows 7
Note: The Windows Firewall should be under control of the SEP client, however this
is still a good check regardless.

17 | P a g e

1. Click Start button , Control Panel, Choose Security (System and Security in
Windows 7), and then click Windows Firewall.
2. Click Turn Windows Firewall on or off. If you are prompted for an administrator
password or confirmation, type the password or provide confirmation.
3. Click Off, and then click OK.

Checking the IIS logs on the management server

You can check the IIS logs on the management server. The logs show GET and POST
commands when the client and the server communicate.
To enable logging in IIS:
1. In the IIS manager, right click each site where you wish to have the
logs (such as Reporting, Secars, etc.) and select Properties
2. On the Virtual Directory tab: ensure a check in the box that
corresponds to Log visits.
3. Click OK.

To check the IIS logs on the management server:

4. On the management server, go to the IIS log files directory. A typical
path to the directory is:
\WINDOWS\system32\LogFiles\W3SVC1
5. Open the most recent log file with a text application such as Notepad.
For example, the log file name might be ex070924.log.
6. Review the log messages.
The file should include both GET and POST messages.