which communication ports does symantec endpoint protection 11

25
1 | Page Which Communication Ports does Symantec Endpoint Protection 11.0 use? Solution Port Number Port Type Initiate d by Listening Process Description 80, 8014 TCP SEP Clients svchost.e xe (IIS) Communication between the SEPM manager and SEP clients and Enforcers. (8014 in MR3 and later builds, 80 in older). 443 TCP SEP Clients svchost.e xe (IIS) Optional secured HTTPS communication between a SEPM manager and SEP clients and Enforcers. 1433 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.ex e Communication between the Embedded Database and the SEPM manager. 8014, 8443 TCP Remote Java or web console SemSvc.ex e HTTPS communication between a remote management console and the SEPM manager. All login information and administrative communication takes place using this secure port.

Upload: karthick-muralidharan

Post on 12-Nov-2015

302 views

Category:

Documents


7 download

DESCRIPTION

Ports Does Symantec Endpoint Protection 11

TRANSCRIPT

5 | Page

Which Communication Ports does Symantec Endpoint Protection 11.0 use?Solution

Port NumberPort TypeInitiated byListening ProcessDescription

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

443TCPSEP Clientssvchost.exe (IIS)Optional secured HTTPS communication between a SEPM manager and SEP clients and Enforcers.

1433TCPSEPM managersqlservr.exeCommunication between a SEPM manager and a Microsoft SQL Database Server if they reside on separate computers.

1812UDPEnforcerw3wp.exeRADIUS communication between a SEPM manager and Enforcers for authenticating unique ID information with the Enforcer.

2638TCPSEPM managerdbsrv9.exeCommunication between the Embedded Database and the SEPM manager.

8014, 8443TCPRemote Java or web consoleSemSvc.exeHTTPS communication between a remote management console and the SEPM manager. All login information and administrative communication takes place using this secure port.

9090TCPRemote web consoleSemSvc.exeInitial HTTP communication between a remote management console and the SEPM manager (to display the login screen only).

8005TCPSEPM managerSemSvc.exeThe SEPM manager listens on the Tomcat default port.

39999UDPEnforcerCommunication between the SEP Clients and the Enforcer. This is used to authenticate Clients by the Enforcer.

2967TCPSEP ClientsSmc.exeThe Group Update Provider (GUP) proxy 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)ProblemHow do I use debug logs to troubleshoot a GUP?SolutionHow does the GUP get defined? 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) Every SEP client contains mini-HTTP server code that allows it to potentially become the GUP. 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.) 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. HTTPS will NOT be supported for the SEP 11.0 release. Content delivered by Symantec Endpoint Protection Manager (SEPM) will be cached. 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 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. 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.. 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 communication or content will be proxied. Getting index files and profiles, posting state and logs, etc. will be done directly with server. 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. 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. 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,\49"LastGoodSession"=hex:68,13,c8,94,d1,8b,c8,01

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 -stopOnce 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 connectionis bad and the GUP rejecting the connection:

03/21 23:00:59 [2628:1908] GUProxy: thread [1908] accepted on socket 222803/21 23:01:03 [2628:1908] GUPROXY - GUProxy HTTP in - H03/21 23:01:03 [2628:1908] GUPROXY - malformed or misdirected request03/21 23:01:03 [2628:1908] GUProxy - closing accepted socketSuccessful Connection and update from a client:

03/23 11:06:01 [2640:2088] GUProxy: thread [2088] accepted on socket 201203/23 11:06:01 [2640:2088] GUPROXY - GUProxy HTTP in - GET /content/{C60DC234-65F9-4674-94AE-62158EFCA433}/80322021/delta803203/23 11:06:01 [2640:2088] GUPROXY - GUProxy File - /content/{C60DC234-65F9-4674-94AE-62158EFCA433}/80322021/delta80322003.dax03/23 11:06:01 [2640:2088] GUProxy content cached - sending to client03/23 11:06:01 [2640:2088] GUProxy - closing accepted socket03/23 11:06:01 [2640:2088] GUProxy thread [2088] acceptingBelow is what you will see in the debug.log when a GUP is first configured:

03/21 20:03:05 [2628:3124] GUProxy: PolicyUpdateCallback called03/21 20:03:06 [2628:3124] GUProxy system event - type 0 - desc -extra 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 - extra 03/21 20:03:06 [2628:3124] GUProxy: Policy Change - Client will start serving as a local proxy server @ 192.168.2.4:296703/21 20:03:06 [2628:3124] GUProxy: SetUpGUPListenSocket03/21 20:03:06 [2628:3124] GUProxy: Create new GUP socket03/21 20:03:06 [2628:3124] GUProxy: creating GUP listen socket with port 296703/21 20:03:07 [2628:1908] GUProxy: listenthread [1908] starting03/21 20:03:07 [2628:1908] GUProxy thread [1908] acceptingExample 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 240403/24 13:26:08 [1436:1796] GUPROXY - GUProxy HTTP in - GET /content/{C60DC234-65F9-4674-94AE-62158EFCA433}/80324005/delta803203/24 13:26:08 [1436:1796] GUPROXY - GUProxy File - /content/{C60DC234-65F9-4674-94AE-62158EFCA433}/80324005/delta80323019.dax03/24 13:26:08 [1436:1796] GUProxy new cache entry03/24 13:26:08 [1436:1796] GUPROXY - GUProxy mangled file -#content#{C60DC234-65F9-4674-94AE-62158EFCA433}#80324005#delta80323019!dax 03/24 13:26:09 [1436:1796] Lock held for 47ms03/24 13:26:09 [1436:1796] GUPROXY - GUProxy - Requested file not in cache; contacting the SEPM server at - L-L3F352603/24 13:26:09 [1436:1796] GUPROXY - GUProxy Response - HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 X-Powered-By: ASP.NET Dat03/24 13:26:09 [1436:1796] GUProxy - sending response to client03/24 13:26:09 [1436:1796] GUProxy - closing accepted socket03/24 13:26:09 [1436:1796] GUProxy thread [1796] acceptingExample of a Sylink log from a client to a GUP requesting an update:

Starting LU download.03/24 14:29:04 [2232] Got a valid context from GetCurrentServerEx03/24 14:29:04 [2232] Setting the session timeout on LUSession to 2 min.03/24 14:29:04 [2232] Requested Content Path is:/content/{C60DC234-65F9-4674-94AE-62158EFCA433}/80324005/delta80323019.dax03/24 14:29:04 [2232] IIS URL: /content/{C60DC234-65F9-4674-94AE-62158EFCA433}/80324005/delta80323019.dax03/24 14:29:04 [2232]http://192.168.2.5:2967/content/{C60DC234-65F9-4674-94AE-62158EFCA433}/80324005/delta80323019.dax03/24 14:29:04 [2232] NEW download: C:\Program Files\Symantec\Symantec Endpoint Protection\LiveUpdate\LUF5.tmp03/24 14:29:04 [2232] Updating existing Download File List with : {C60DC234-65F9-4674-94AE-62158EFCA433}8032400503/24 14:29:04 [2232] Updating existing Download File List Temp file name from: to C:\Program Files\Symantec\Symantec Endpoint Protection\LiveUpdate\LUF5.tmp03/24 14:29:04 [2232] 14:29:4=>Sending HTTP REQUEST to download LU file03/24 14:29:05 [2232] 14:29:5=>HTTP REQUEST sent03/24 14:29:05 [2232] IIS return=20003/24 14:29:05 [2232] 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:\ProgramFiles\Symantec\Symantec Endpoint Protection\LiveUpdate\LUF5.tmp03/24 14:29:05 [2232] Content Length => 3540303/24 14:29:05 [2232] Updating existing Download File List with : {C60DC234-65F9-4674-94AE-62158EFCA433}8032400503/24 14:29:05 [2232] 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.tmp03/24 14:29:05 [2232] LU Content Downloaded. Moniker: {C60DC234-65F9-4674-94AE-62158EFCA433} Target Seq:80324005 Full version:0 Delta Base Seq:8032301903/24 14:29:05 [2232] going to post event=EVENT_LU_DOWNLOAD_COMPLETED03/24 14:29:25 [2224] 03/24 14:29:25 [2224] 03/24 14:29:30 [2232] 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] Setting the session timeout on LUSession to 2 min.03/25 00:38:01 [2232] Requested Content Path is:/content/{812CD25E-1049-4086-9DDD-A4FAE649FBDF}/80324040/delta80321051.dax03/25 00:38:01 [2232] IIS URL: /content/{812CD25E-1049-4086-9DDD-A4FAE649FBDF}/80324040/delta80321051.dax03/25 00:38:01 [2232] http://192.168.2.5:2967/content/{812CD25E-1049-4086-9DDD-A4FAE649FBDF}/80324040/delta80321051.dax03/25 00:38:01 [2232] NEW download: C:\Program Files\Symantec\Symantec EndpointProtection\LiveUpdate\LUF140D.tmp03/25 00:38:01 [2232] Updating existing Download File List with : {812CD25E-1049-4086-9DDD-A4FAE649FBDF}8032404003/25 00:38:01 [2232] Updating existing Download File List Temp file name from: to C:\Program Files\Symantec\Symantec Endpoint Protection\LiveUpdate\LUF140D.tmp03/25 00:38:01 [2232] 0:38:1=>Sending HTTP REQUEST to download LU file03/25 00:38:24 [2224] 03/25 00:38:24 [2224] 03/25 00:38:24 [2232] 0:38:24=>HTTP REQUEST sent03/25 00:38:24 [2232] Send Request failed.. Error Code = 1202903/25 00:38:24 [2232] 12029=>The attempt to connect to the server failed.03/25 00:38:24 [2232] IIS return=003/25 00:38:24 [2232] 12029=>The attempt to connect to the server failed.03/25 00:38:24 [2232] COMPLETED03/25 00:38:24 [2232] - GETLUFILE_CONNECTION_ERROR getting content moniker: {812CD25E-1049-4086-9DDD-A4FAE649FBDF}; revision: 80324040 from server: 192.168.2.503/25 00:38:24 [2232] LU file download failed due to HTTP error:003/25 00:38:24 [2232] 03/25 00:38:24 [2232] Backoff index incremented03/25 00:38:24 [2232] Backoff wait index: 103/25 00:38:24 [2232] 03/25 00:38:24 [2232] 03/25 00:38:24 [2232] CExpBackoff wait time in seconds: 3203/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] Requested Content Path is: /content/{E5A3EBEE-D580-421e-86DF-54C0B3739522}/80324040/delta80321051.dax03/25 00:38:56 [2232] IIS URL: /content/{E5A3EBEE-D580-421e-86DF-54C0B3739522}/80324040/delta80321051.dax03/25 00:38:56 [2232] http://192.168.2.5:2967/content/{E5A3EBEE-D580-421e-86DF-54C0B3739522}/80324040/delta80321051.dax03/25 00:38:56 [2232] NEW download: C:\Program Files\Symantec\Symantec EndpointProtection\LiveUpdate\LUF140E.tmp03/25 00:38:56 [2232] Updating existing Download File List with : {E5A3EBEE-D580-421e-86DF-54C0B3739522}8032404003/25 00:38:56 [2232] Updating existing Download File List Temp file name from: to C:\Program Files\Symantec\Symantec Endpoint Protection\LiveUpdate\LUF140E.tmp03/25 00:38:56 [2232] 0:38:56=>Sending HTTP REQUEST to download LU file03/25 00:39:18 [2232] 0:39:18=>HTTP REQUEST sent03/25 00:39:18 [2232] Send Request failed.. Error Code = 1202903/25 00:39:18 [2232] 12029=>The attempt to connect to the server failed.03/25 00:39:18 [2232] IIS return=003/25 00:39:18 [2232] 12029=>The attempt to connect to the server failed.03/25 00:39:18 [2232] COMPLETED03/25 00:39:18 [2232] - GETLUFILE_CONNECTION_ERROR getting content moniker: {E5A3EBEE-D580-421e-86DF-54C0B3739522}; revision: 80324040 from server: 192.168.2.503/25 00:39:18 [2232] LU file download failed due to HTTP error:003/25 00:39:18 [2232] 03/25 00:39:18 [2232] Backoff index incremented03/25 00:39:18 [2232] Backoff wait index: 203/25 00:39:18 [2232] 03/25 00:39:18 [2232] 03/25 00:39:18 [2232] CExpBackoff wait time in seconds: 6403/25 00:39:26 [2224] 03/25 00:39:26 [2224] 03/25 00:40:22 [2232] Symantec Endpoint Protection: Troubleshooting Client/Server ConnectivityProblemHow to troubleshoot client to manager connectivity issues.

SymptomsA client is notreceiving definition updates. Client is notreceiving 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.SolutionAbout communication problemsCheck 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 serverIf 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 communicationbetween the client computer and the management server.

Viewing the client status in the management consoleYou 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 consolefor the client status.

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 clientstatus.About the client status icon on the clientYou 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 numberYou 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.

About performing a manual policy update to check the policy serial numberYou 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 serialnumbers 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 serverYou 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 server1. 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 serverYou 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: http://:/reporting/index.php

If the reporting log-on Web page appears, the client can communicate with the management server. http://: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 serverYou 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.

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 =disableWindows 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 state off

Values for 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 XP1. Click Start, click Run, type Firewall.cpl, and then click OK.2. On the General tab, click Off3. Click OK.Windows Vista/Windows 7Note: The Windows Firewall should be under control of the SEP client, however this is still a good check regardless.

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 serverYou 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 Properties2. 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\W3SVC15. 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.