Which Communication Ports Does Symantec Endpoint Protection 11 155350
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report l4457
Overview 6h3y3j
& View Which Communication Ports Does Symantec Endpoint Protection 11 as PDF for free.
More details h6z72
- Words: 3,874
- Pages: 17
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 T 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 T SEP Clients between a SEPM manager and SEP clients and (IIS) Enforcers.
T
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
T
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. T or web SemSvc.exe All information and istrative console communication takes place using this secure port.
9090
Initial HTTP communication between a remote Remote web T SemSvc.exe management console and the SEPM manager console (to display the screen only).
8005
T
SEPM manager
39999
UDP
2967
T 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 .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 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 s. 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 ed for the SEP 11.0 release. o Content delivered by Symantec Endpoint Protection Manager (SEPM) will be cached. o The GUP will NOT initially 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 doesn’t 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 isn’t, 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 istration_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 interface - SEP UI -> Help and 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; ing 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:
Starting LU . 03/24 14:29:04 [2232]
Got a valid context from GetCurrentServerEx 03/24 14:29:04 [2232]
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]
IIS URL: /content/{C60DC234-65F94674-94AE-62158EFCA433}/80324005/delta80323019.dax 03/24 14:29:04 [2232]
http://192.168.2.5:2967/content/{C60DC234-65F9-467494AE-62158EFCA433}/80324005/delta80323019.dax 03/24 14:29:04 [2232]
NEW : C:\Program Files\Symantec\Symantec Endpoint Protection\LiveUpdate\LUF5.tmp 03/24 14:29:04 [2232]
Updating existing File List with : {C60DC234-65F9-4674-94AE-62158EFCA433}80324005 03/24 14:29:04 [2232]
Updating existing 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 LU file 03/24 14:29:05 [2232] 14:29:5=>HTTP REQUEST sent 03/24 14:29:05 [2232]
IIS return=200 03/24 14:29:05 [2232] <mfn_DoGetLUFile200>ing 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]
Updating existing File List with : {C60DC234-65F9-4674-94AE-62158EFCA433}80324005 03/24 14:29:05 [2232]
Updating existing 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 ed. Moniker: {C60DC234-65F9-4674-94AE-62158EFCA433} Target Seq:80324005 Full version:0 Delta Base Seq:80323019 03/24 14:29:05 [2232]
going to post
8 | Page
event=EVENT_LU__COMPLETED 03/24 14:29:25 [2224] <:mfn_now> 03/24 14:29:25 [2224] 03/24 14:29:30 [2232]
done post event=EVENT_LU__COMPLETED, return=0
Below is what you will see in the Sylink if the GUP is off line: 03/25 00:38:01 [2232]
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]
IIS URL: /content/{812CD25E-10494086-9DDD-A4FAE649FBDF}/80324040/delta80321051.dax 03/25 00:38:01 [2232]
http://192.168.2.5:2967/content/{812CD25E-1049-40869DDD-A4FAE649FBDF}/80324040/delta80321051.dax 03/25 00:38:01 [2232]
NEW : C:\Program Files\Symantec\Symantec Endpoint Protection\LiveUpdate\LUF140D.tmp 03/25 00:38:01 [2232]
Updating existing File List with : {812CD25E-1049-4086-9DDD-A4FAE649FBDF}80324040 03/25 00:38:01 [2232]
Updating existing 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 LU file 03/25 00:38:24 [2224]
<:mfn_now>
03/25 00:38:24 [2224]
03/25 00:38:24 [2232] 0:38:24=>HTTP REQUEST sent 03/25 00:38:24 [2232]
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]
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]
COMPLETED 03/25 00:38:24 [2232]
- 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 failed due to HTTP error:0
9 | Page
03/25 00:38:24 [2232] <: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] 03/25 00:38:24 [2232] <:wait> 03/25 00:38:24 [2232] CExpBackoff wait time in seconds: 32 03/25 00:38:56 [2232] 03/25 00:38:56 [2232]
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]
IIS URL: /content/{E5A3EBEE-D580421e-86DF-54C0B3739522}/80324040/delta80321051.dax 03/25 00:38:56 [2232]
http://192.168.2.5:2967/content/{E5A3EBEE-D580-421e86DF-54C0B3739522}/80324040/delta80321051.dax 03/25 00:38:56 [2232]
NEW : C:\Program Files\Symantec\Symantec Endpoint Protection\LiveUpdate\LUF140E.tmp 03/25 00:38:56 [2232]
Updating existing File List with : {E5A3EBEE-D580-421e-86DF-54C0B3739522}80324040 03/25 00:38:56 [2232]
Updating existing 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 LU file 03/25 00:39:18 [2232] 0:39:18=>HTTP REQUEST sent 03/25 00:39:18 [2232]
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]
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]
COMPLETED 03/25 00:39:18 [2232]
- 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 failed due to HTTP error:0 03/25 00:39:18 [2232]
<: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]
10 | P a g e
03/25 00:39:18 [2232] <:wait> 03/25 00:39:18 [2232] CExpBackoff wait time in seconds: 64 03/25 00:39:26 [2224] <:mfn_now> 03/25 00:39:26 [2224] 03/25 00:40:22 [2232] 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 . 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 interface, click on the Help and 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 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 s policies to the client at regular intervals (heartbeat). You can change the heartbeat interval so that policies are ed 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, 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. 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 istration 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, the client's DNS service and check its routing path.
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. publirofile - 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.l, 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 , 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 or confirmation, type the 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.
Which Communication Ports does Symantec Endpoint Protection 11.0 use? Solution
Port Port Initiated by Number Type
Listening Process
svchost.exe 80, 8014 T 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 T SEP Clients between a SEPM manager and SEP clients and (IIS) Enforcers.
T
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
T
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. T or web SemSvc.exe All information and istrative console communication takes place using this secure port.
9090
Initial HTTP communication between a remote Remote web T SemSvc.exe management console and the SEPM manager console (to display the screen only).
8005
T
SEPM manager
39999
UDP
2967
T 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 .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 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 s. 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 ed for the SEP 11.0 release. o Content delivered by Symantec Endpoint Protection Manager (SEPM) will be cached. o The GUP will NOT initially 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 doesn’t 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 isn’t, 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 istration_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 interface - SEP UI -> Help and 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; ing 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:
8 | Page
event=EVENT_LU__COMPLETED 03/24 14:29:25 [2224] <:mfn_now> 03/24 14:29:25 [2224] 03/24 14:29:30 [2232]
Below is what you will see in the Sylink if the GUP is off line: 03/25 00:38:01 [2232]
9 | Page
03/25 00:38:24 [2232] <: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] 03/25 00:38:24 [2232] <:wait> 03/25 00:38:24 [2232] CExpBackoff wait time in seconds: 32 03/25 00:38:56 [2232] 03/25 00:38:56 [2232]
10 | P a g e
03/25 00:39:18 [2232] <:wait> 03/25 00:39:18 [2232] CExpBackoff wait time in seconds: 64 03/25 00:39:26 [2224] <:mfn_now> 03/25 00:39:26 [2224] 03/25 00:40:22 [2232] 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 . 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 interface, click on the Help and 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 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 s policies to the client at regular intervals (heartbeat). You can change the heartbeat interval so that policies are ed 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, 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. 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 istration 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, the client's DNS service and check its routing path.
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. publirofile - 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.l, 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 , 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 or confirmation, type the 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.
Related Documents 543cg
Which Communication Ports Does Symantec Endpoint Protection 11 155350
November 2019 79
Remove Symantec Endpoint Protection 2p1q4t
November 2022 0
Symantec Endpoint Protection - Installation Guide 4h6sw
August 2022 0
Uninstall Symantec Endpoint Protection Without A 3i6i1c
December 2019 54
Endpoint-protection-for-dummies.pdf 6l3b2u
November 2021 0
How To Manually Uninstall Symantec Endpoint Protection 12 4m35b
November 2019 73More Documents from "Karthick Muralidharan" 2or2q
Cisco Ip Subnetting 101 4k1s6l
December 2019 27
Which Communication Ports Does Symantec Endpoint Protection 11 155350
November 2019 79
A Note On Religious Endowments Act 1863 Application To Ap g4n6n
November 2021 0
Government Rules Hindu Temples 3ve6g
October 2019 90
Vak Jan. 18 Pdf (2) 536q4p
October 2019 171