Symantec Endpoint Encryption Client communication and SEE Client Creation troubleshooting steps

book

Article ID: 155127

calendar_today

Updated On:

Products

Endpoint Encryption

Issue/Introduction

This article describes how to troubleshoot Symantec Endpoint Encryption (SEE) client communication issues where the SEE client is not communicating with the Symantec Endpoint Encryption Management Server (SEEMS), or if you are unable to create a SEE Client package from the SEEMS.

The concepts for both are related, so it is good to review all of these steps to troubleshoot SEE Client communication as well as SEE Client package creation.

TIP: For information on configuring TLS for SEE Clients, see the following article:
https://knowledge.broadcom.com/external/article/178609

Environment

Symantec Endpoint Encryption 11.0 and above.

Resolution

Item 1: Check the Last Check-In

It is useful to check when the Symantec Endpoint Encryption client last checked in to the server to see if you can pinpoint a specific event that may have occurred that triggered the issue with the client-server communication. To see this, check the following registry key on affected clients that are using Endpoint Encryption Drive Encryption. Note that this key does not exist if the clients are running Removable Media Encryption only:

HKEY_LOCAL_MACHINE\SOFTWARE\Encryption Anywhere\Hard Disk\Client Database\LastContactTimestamp

This will provide you an entry where it will display the LastContactTimestamp value in Epoch time (1559212526):

You can convert from epoch time using the awk utility which is part of all popular Linux distributions:
# echo 1559212526 |awk '{print strftime("%c",$1)}'
Thu 30 May 2019 10:35:26 AM GMT

There are various conversion options available via google search you can use as well.

This can help pinpoint certain events that may have happened to trigger the issue, such as the IIS password having changed or expired, or potentially Root Certificates expiring (SEE 

 

Item 2: Check the CA Certificate

Symantec Endpoint Encryption usually uses HTTPS to communicate with the management server. Check that the certificate is still valid. For further information please see article https://knowledge.broadcom.com/external/article/178609.

If you check on the SEE Management Server and the Root CA certificate is still valid, check the actual server cert for SEE Management Server.  If it has expired, you can simply renew it.

Important note: Make sure if you do renew/replace the existing SEE Management Server certificate that the certificate is signed by the same Root CA.  Look at the thumbprint in the SEE Configuration Manager and make note of it. This needs to be the same Root CA for the SEE Clients to continue to communicate.  You can cross-check on a few SEE Client systems in the registry and make sure the thumbprint values match:

HKEY_LOCAL_MACHINE\SOFTWARE\Encryption Anywhere\Framework\Client Database\CommunicationCertificateID

Once an expired SEEMS certificate expires and has been renewed by the same Root CA, replace the cert in SEEMS configuration manager, and the SEE Clients will again start to communicate.

If the Root Certificate Authority expired, it is necessary to create a new SEE Client once the certificates have been assigned again in the SEE Management server.  The new SEE Client will need to be redeployed over preexisting clients.

 

Item 3: Check the Windows Application Log in Event Viewer

  1. Open the Event Viewer and check the Windows Application Log. Check for events with a Source of Symantec Encryption.
  2. This event indicates a communication problem:
    Event ID: 254
    Description: Program Action: Report sent to Server failed. The operation has timed out
  3. This event can indicate a network related problem such as a failure to connect through a proxy server:
    Event ID: 254
    Description: Program Action: Report sent to Server failed. WebService Rejected the connection - returned False
  4. This event can also indicate a network related problem such as a failure to connect through a transparent proxy server:
    Event ID: 254
    Description: Program Action: Report sent to Server failed. The remote server returned an error: (409) Conflict.
  5. This event indicates a name resolution or network issue:
    Event ID: 254
    Description: Program Action: The request failed with HTTP status 504: Unknown Host.
  6. This event indicates communication is working:
    Event ID: 253
    Description: Program Action: Report sent to Server successful.

 

Item 4: Check the client communication log file

As an alternative to checking the Windows Application Log, you can instead check the most recent EACommunicatorSrv*.log file in the folder "C:\Program Files\Symantec\Endpoint Encryption Clients\Management Agent\TechLogs". The log file only contains errors and warnings. It does not log successful connections. For example, this log entry corresponds to the first Event ID 254 in the Application Log above:

[06/03/19 14:58:03][ERROR][1772][0xA30][EAFRCliADSIComm][SYSTEM][SubmitReport failed with error - The operation has timed out][EAFRCliADSIComm.cpp:1489]

The Description entries in the Windows Application Log are identical to the error messages in the log file. For further information regarding debugging Symantec Endpoint Encryption, see article https://knowledge.broadcom.com/external/article/161042.

 

Item 5: Verify whether the client is communicating

If the clients are using Endpoint Encryption Drive Encryption:

  1. Open the Symantec Endpoint Encryption Management Agent from the start menu.
  2. Click the Check-in button and observe whether the check-in was successful.

 

Item 6: Verify whether the client computer is able to connect to IIS on the Management Server

When the Symantec Endpoint Encryption client is installed, it includes the credentials of the IIS account for the management server. These credentials must remain unchanged for the clients to be able to communicate with the Management Server. For more information on this, see article https://knowledge.broadcom.com/external/article/152429.

  1. Open the registry and browse to HKEY_LOCAL_MACHINE\SOFTWARE\Encryption Anywhere\Framework\Client Database
  2. Check the value of the key Server Location. For example, https://see.example.com:443/GECommunicationWS.asmx
  3. Check the value of the key AccountDomain. This is the domain name of the IIS Client Authentication Account. Confirm it is what you expect. For example, mydomain.
  4. Check the value of the key AccountName. This is the username of the IIS Client Authentication Account. Confirm it is what you expect. For example, seeiisuser.
  5. Check the value of the key CommunicationMinutes. This is how frequently the client will try to check-in to the Management Server in minutes. For example, decimal 60.
  6. Enter the value of the key Server Location into the address bar of a web browser. If you are able to connect to the page, the client computer is able to reach the management server.
  7. If the client can connect, it will be prompted for a username and password. The Endpoint Encryption client will use the AccountDomain and AccountName values to connect. For example, mydomain\seeiisuser. If you know the password, you can logon using the browser.

 

Item 7: Check basic network connectivity

  1. Assuming that the value of the key Server Location is a FQDN (fully qualified domain name), ensure that the client can resolve the name using nslookup. For example, if the FQDN is see.example.com:
    nslookup see.example.com
  2. If nslookup cannot resolve the FQDN to an IP address then check your DNS settings.
  3. Ensure that the client can ping the Management Server.
  4. Enable the telnet service on the client and check whether it can connect. For example, if the FQDN is see.example.com:
    telnet see.example.com 443
  5. If the telnet command fails, disable the Windows and third party firewall applications and test again.
  6. Also run a trace route from the SEE client to the server to check if any latency exists, as well as firewalls/proxies that may be getting in the way.

    TIP: Database latency from the SEEMS could cause SEE Client communication issues.

 

Item 8: Check proxy settings

The Endpoint Encryption client will automatically use the Windows proxy settings. Symantec recommends that so long as the clients are capable of connecting to the Management Server without a proxy then, in order to simplify the client configuration, the FQDN of the Management Server is added to the list of proxy exceptions. Note that this is a recommendation and not a requirement:

  1. In Windows 10, click on Settings / Network & Internet / Proxy and if the proxy is enabled, add the FQDN of the Management Server to the section Use the proxy server except for addresses that start with the following entries. Use semicolons (;) to separate entries.
  2. In Windows 7, open Control Panel then click on Network and Sharing Center / Internet Options / Connections / LAN Settings / Advanced and add the FQDN of the Management Server to the Exceptions section.
  3. It is best to include the FQDN of the Management Server rather than rely on a wildcard entry. For example, use see.example.com rather than *.example.com.
  4. In environments that use a *.pac file for the proxy settings, the *.pac file will need to be modified by your networking team.

 

Item 9: Verify settings under IIS

  1. On the Management Server, open IIS and check for the existence of Symantec Endpoint Encryption AppPool.
  2. Right click and go to the properties of Symantec Endpoint Encryption AppPool. Under Identity, the service should be running under the Network Service if SQL Server authorization is being used for the database or the Windows user if Windows authorization is being used.
  3. Under Authentication check that Basic Authentication and Windows Authentication are being used.

 

Item 10: Check SEEMS Configuration Manager

  1. Make sure the username and password is correctly entered in the Web Server Configuration tab.
  2. Make sure the port is correctly configured.

 




Item 11: Check IIS Security or Other Security Software


Check if IIS security options or other security software may be causing problems or blocking connectivity.  In some cases, it may not be possible to create a SEE Client using alias hostnames due to an IIS security feature.  If it is possible to browse to the communications URL as mentioned above, but it is not possible to create a SEE Client from the management server, even though using FQDNs for the SEEMS hostname itself is possible, check if Anonymous Authentication allows the creation of the client. 

The scenario for this is using a hostname alias so that SEEMS host "seems1.domain.dom" and "seems2.domain.dom" will be behind a DNS pointer so that if going to "seems.domain.dom", this alias will resolve to either seems1.domain.dom or seems2.domain.dom FQDNs.  If using "seems.domain.dom to create the SEE Client, this security feature may think this is a problematic connection and block.  Rather than disable this security feature, enabling Anonymous Authentication temporarily is the recommended option.

This means that the IIS credentials will not be validated when creating the SEE Client, but as long as the credentials are in fact correct, this is a good workaround.  If so, temporarily enable Anonymous Authentication in IIS when creating the clients, and then set back to Windows auth.

This is the Default Configuration for IIS with SEEMS:



This is setting to Anonymous Authentication temporarily to create the SEE Client if the IIS Security Setting is preventing creation:



Once the SEE Client was created, set Anonymous Authentication back to "Disabled", and Windows Authentication back to "Enabled".  Install the SEE Client on your test machine and ensure the client checks in successfully to be sure.

Because MSFT recommends *not* using this feature, it is recommended to set to "Anonymous Authentication" temporarily, and then set back:
"Warning This workaround may make your computer or your network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend this workaround but are providing this information so that you can implement this workaround at your own discretion. Use this workaround at your own risk."

 

Item 12: Communications URL shows as Blank or Unable to create the SEE Client package due to missing extensions


 

Symantec Endpoint Encryption uses a communications URL that has a .asmx extension.  Although this is typically not an issue for most environments, some environments may have to add an "allow" manually for this to work. 

Sample URL: https://SEEMS.domain.dom:443/GECommunicationWS.asmx

See the following article for information if IIS Web Extension filtering is potentially preventing this from being displayed:

https://knowledge.broadcom.com/external/article/174615

Additional Information

Keywords: SEE Client Creation Troubleshooting

Attachments

Powered by Wolken Software