Symantec Endpoint Encryption Client communication and SEE Client Creation troubleshooting steps
search cancel

Symantec Endpoint Encryption Client communication and SEE Client Creation troubleshooting steps

book

Article ID: 155127

calendar_today

Updated On:

Products

Endpoint Encryption Drive Encryption File Share Encryption Policy Based Encryption Desktop Email Encryption Encryption Management Server Gateway Email Encryption PGP Command Line PGP Key Management Server PGP Key Mgmt Client Access and CLI API PGP SDK

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.

 

Potential Errors observed:

"Error: Communication is taking too long. try again later."

 

New! Symantec Endpoint Encryption 11.4 and above can now use a new communications method called OAuth that no longer requires the use of a Windows Authentication credential. 
See the following article for more information on this topic:

240321 - OAuth Communications with Symantec Endpoint Encryption 11.4 and above



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

 

This article also describes what a "check in" means and how it relates to Policy Updates.

 

 

Environment

Symantec Endpoint Encryption utilizes two policy types, "Local" and "Server" based policies. 

When the SEE Client is created on the server all the settings that are built in to the client are called "Local" policies. 

The SEE Management Server has Groups that machines are assigned to and each Group is assigned a SEE Native Policy, which is a configuration of all the settings mentioned above.  These SEE Native Policies are "Server" policies and are applied when the client performs a SEE Client "Check In" operation.

Once you install the client on a system, before the SEE Client performs a "check in" operation, these "Local" policies are applied.  The SEE Client has a regular interval such that every X minutes the client will automatically check in with the SEE Management Server; when this happens, the "Last Check-In" value is updated on the SEE Management Server with the date this happened.   When the clients "Check In" with the SEE Management Server, these Server policies are downloaded and applied to the machines.

Manual Check In operations can also be performed by opening the SEE Management Agent application and clicking the "Check In" button:

 

Resolution

SEE Clients are created to communicate with the SEE Management Server.  Symantec Encryption recommends using port 443 for SEE Client communications.

Port 8080 (HTTP) can be used, but should be done only for testing purposes.  Once testing is finished, create a new SEE Client with port 443 and HTTPS with a proper TLS certificate configured going forward.


For machines already deployed with the SEE Client - How to tell which port is being used?

You can tell by another registry value and noting if it's using HTTPS for the URL prefix:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Encryption Anywhere\Framework\Client Database\ServerLocation

For example:  https://SERVER-FQDN-HERE:443/GECommunicationWS.asmx

This is an example that shows port 443 and HTTPS are being used.

Note: It is critically important to know which port is being used because although the URL may be correct, if the port is incorrect, the SEE Client Communications will not work.
See Item 17 for more information on ports.

 

Although the SEE Client Check In intervals for "SEE Native Policy" are automatic and should happen it is possible to force a "Check In" to download policy from the SEE Management Server.

"To force a native policy update
On the client computer, access the Management Agent console and in the Check-in panel, click Check-in."


For GPO Updates, policy updates work differently and are not controlled by this update interval.  The SEE Polices are applied to actual GPOs for the domain (Configured on SEE Management Server via the GPO editor), and when a machine updates local Windows GPO policy, the SEE policies are then updated via local GPO policy files.  In this way, the intervals mentioned above for SEE Native do not apply, rather, whenever a local GPO update happens (Default is typically every 90 minutes), as per the SEE Online Help, running "gpupdate /force" will force a GPO update, which will then apply the policies.

 

Table of Contents

 

Important Note: If SEE Clients are unable to check in to the SEE Management Server, before checking any of the items below, make sure the Web Service is running and is enabled:

If you stop the Symantec Endpoint Encryption Services, this will effectively stop all communications.  Ensure it is up and running to be able to allow the SEE Clients to communicate.
Additionally, if stopping this service, the Web Portal will not be available to serve up Recovery Keys, so stopping this service would have critical implications to this.
Make sure the web service is always up and running to ensure proper operation of both the SEE Clients and the Helpdesk Recovery Portal.

 

Item 0: Check in Functionality via Command Line

Starting with Symantec Endpoint Encryption Client 11.4 MP2, there is an application "SEEMAUIApp.exe" that will allow a client to check in manually.
This can be useful if you would like to have your deployment solution, such as "Altiris" (Symantec IT Management Suite) force a check in of the client.

To do this, you will have the application run from the directory where it is located:

C:\Program Files\Symantec\Endpoint Encryption Clients\Management Agent>SEEMAUIApp.exe --check-in

This can be useful if you have a policy-interval time set and need to have it update without waiting the extended period of time.

 

Item 1: Check SEEMS Configuration Manager

*Make sure the username and password is correctly entered in the Web Server Configuration tab.
*Make sure the port is correctly configured.
*Check if OAuth is enabled, and if so, you may need to enable "Both" for Authentication.   See the following KB for more information on OAuth:

240321 - OAuth Communications with Symantec Endpoint Encryption 11.4 and above

 

 

Item 2: 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 (1608374128):

You can convert from epoch time using the awk utility which is part of all popular Linux distributions:
# echo 1608374128 |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


Note: SEE Clients check in with the server in a "Pull" fashion so the Symantec Encryption Management Server will not "push" updates, but rather the SEE Clients will pull updates from the server.



Item 3: Check the CA Certificate and Server Certificate

Symantec Endpoint Encryption uses TLS to communicate with the SEE Management Server.  Due to this all the rules of TLS apply and therefore proper certificates are needed.


Check that the certificate is valid.  For a certificate to be considered valid, the following apply:

*The Server Certificate must be signed by a Valid Root Certificate Authority.
*The CA must not be expired.
*The Server Cert must not be expired.
*The CA could be from a Trusted Certificate Authority, such as Digicert or an Internal CA.
*The Server Certificate must be configured with a Fully Qualified Domain Name (FQDN).
An example of an FQDN is seems.domain.dom.  If you are using only a NETBIOS name, such as "seems" in this example, TLS will not be possible.

For further information please see the following article:

178609 - How to create an SSL certificate to be used to secure Client Communication with the Symantec Endpoint Encryption Management Server

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: If you do renew/replace the existing SEE Management Server certificate, ensure that the certificate is signed by the same Root CA (CA Certificate). 
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 continue to communicate.

If the Root Certificate Authority is expired, or you change the Root Certificate Authority (CA Certificate), it is necessary to create a new SEE Client once the certificates have been assigned again in the SEE Management server. 
The new CA Certificate will then be embedded into the new SEE Client and will need to be redeployed over preexisting clients.


Important Note on SANs and Certs:

If your Windows clients for SEE are checking in, but your SEE Clients for macOS are not, it is likely related to the certificate.  Check the following information for guidance:

1. Most browsers and operating systems now require TLS certificates to use a Subject Alternative Name (SAN) for the host.  If you are using an internal CA, and the certificate does not have this particular attribute, then the operating system and/or browser could reject the cert.  Due to this requirement, when generating certificates, make sure the SAN is also added. This is especially critical on macOS for SEE File Vault. 

2. macOS no longer supports SHA1 certificates so when you generate a TLS cert, make sure it is using SHA256 in addition to the SAN.

EPG-26304
EPG-23670

If you generate a SEE Client that had an old Certificate Authority and you generate a new certificate, make sure the SAN is applied, but also a new SEE Client will need to be created, which will include the new Root Certificate assigned to the SEE Management Server.

WARNING: Using Self-Signed certificates is highly discouraged due to the loss of communication that occurs when the certificate expires and no option to renew.  It is handy to use a self-signed certificate for testing purposes only, but once you move to production, ensure the self-signed certificate is not used. Windows systems will typically accept a self-signed certificate, however, once this certificate expires, the SEE clients will no longer communicate with the SEE Management Server--the **only** way to get these SEE Clients communicating again is to create a new SEE Client and re-deploy.  This is a difficult situation that is best avoided by using an internal CA and keeping the Root the same.  Changing the server cert is just fine.

For macOS systems, self-signed certs are not allowed by the operating system.  Using a self-signed cert will result in errors from the SEE Daemon logs stating TLS has been unsuccessful: 

"SEEd: [com.symantec.encryption.SEEd:general] Can not ping the server please check if the server is alive. SSL_ERROR_SYSCALL
Error observed by underlying SSL/TLS BIO: Connection reset by peer"

Replacing a self-signed certificate with a valid CA cert, also meeting the SAN requirement mentioned above will require creating a new SEE FV Client once assigned to the server.

EPG-22069.  

If you are still running into issues with this after trying the above, please reach out to Symantec Encryption Support for further guidance. 

 

If you get the following error message, this means either the Keypair of the SEEMS Server Certificate is missing, or the cert was created without a FQDN:

"Invalid Server Location.  The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."


To solve this error, get a new Server certificate that has the FQDN.  While you are doing so, it is a good idea to use a SAN with the FQDN added as mentioned in the important note above.
Also, make sure the "CN" attribute has been configured--if this is not, essentially the certificate could be viewed as not having any FQDN associated to it.

 

Item 4: Invalid Server Location when trying to create the SEE Client - Or Requires IIS Integrated Pipeline Mode Error

Item 4: Scenario 1:

"Invalid Server Location"


When browsing to the SEE OAuth URL, you may receive the following:

"This operation requires IIS integrated pipeline mode."

 

If this is the case, open IIS and click on "Application Pools" and look at the "SymantecEndpointEncryptionAppPool" and make sure it is set to "Integrated".

If it is set to "Classic", change this to Integrated and then restart all the services. 

Note: If you are using SQL Authentication in the SEEMS Configuration Manager, "NetworkService" should be the Application Pool Identity.

It may be necessary to save the SEEMS Configuration Manager again once this is done. 

 

Item 4: Scenario 2:

You may also receive an error such as the following:
Invalid Server Location, The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

If you are receiving this error message, ensure the FQDN of the certificate complies with the hostname of the SEE Management Server.

Also, make sure DNS is configured to resolve this host associated to the SEE Management Server.

 

Item 5: 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.

    Other tools, such as netstat -an can show ports running (netstat -anb could also be run, but requires elevated permissions)

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



Item 6: Verify whether the client is communicating (or if other clients are 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.


Important Note:  Currently it is not possible to check-in outside of the UI for the SEE Client.  A request to allow check-in via CLI has been logged (ISFR-1744).  To be added to this request, please contact Symantec Encryption Support and provide this ID.

 

 

Item 7: 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 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, example\seeiisuser. If you know the password, you can logon using the browser.

 

Item 8: 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 9: 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.

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. 

 

 

 

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

Sample URL: https://SEEMS.example.com: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




Item 11: 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 12: 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 13: Check IIS Security, the IIS Components, and any Security Software

If you suspect there may be security software at play that prevents the SEE Client from either checking in, or creating the client, we can actually disable Windows Auth altogether just to create the client and then use the new OAuth feature included in 11.4. 
OAuth is a new feature that is better for security and offers more flexibility.  


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. 

 

In some of these scenarios, it may be possible to browse to the communications URL as mentioned above, but still not possible to create a SEE Client from the management server--even when the FQDNs is correct as well as the Windows credentials entered. 

One other scenario at play to enable Anonymous Auth is you would like to create a client with a hostname alias.  In this scenario you may have a SEEMS host "seems1.example.com" and "seems2.example.com" host that would be behind a DNS pointer so that if going to "seems.example.com", this alias will resolve to either seems1.example.com or seems2.example.com FQDNs.  If using "seems.example.com 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:


To allow us to create the SEE Client, we will disable Windows Authentication temporarily, and Enable Anonymous Authentication.

 

Symantec recommends using the new OAuth feature in SEE 11.4 rather than depending on Windows Authentication.  Once you have made this change, look at the following article for OAuth:

240321 - OAuth Communications with Symantec Endpoint Encryption 11.4 and above

Once the SEE Client was created with OAuth enabled in the SEE Client and the Policy, and the SEEMS Configuration Manager is set to Both, then set Anonymous Authentication back to "Disabled", and Windows Authentication back to "Enabled".  Install the SEE Client on your test machine  with OAuth Enabled and ensure the client checks in successfully to be sure.

Leaving the IIS configuration with Anonymous Auth enabled is not recommended security practice.  Once you create the client, be sure to disable Anonymous Authentication.


In addition to the above, sometimes IIS does not have all the proper components listed.  The following screenshots will show you all the default components of a working environment:

Symantec Endpoint Encryption Services Site:

SEEOAuthServer Site:

WebConsole Site:

If any of the above components are missing, the server may not function properly.

 

 

 

Item 14: Load Balancers in use causing client creation to fail - Use BackConnectionHostNames

If you are using a Load Balancer, the client creation may fail and complain about connectivity issues when there really are not any.  When you are creating the client, the process does a lookup on the FQDN used for the communications URL and if that FQDN resolves to a DNS server, the connection may get thwarted by a local lookup that is being performed. 

Enable BackConnectionHostNames for DNS resolution to bypass local name resolution and force to use the local name.
For example, seems.domain.dom is the LB entry, but this is not the name of the actual SEE Management Server, instead, it is seems1.domain.dom and there may be another SEE Management Server called seems2.domain.dom that the load balancer will redirect traffic to.   When the client package is created, it may be trying to resolve seems.domain.dom instead and creating a BackConnectionsHostNames to seems1.domain.dom so that the client remains local and does not go to the load balancer.   For more information on this, see the MSFT Help Doc.

EPG-23923

Along the lines above where the Windows Server may be checking the security of the URL, sometimes adding a hostfile entry will help allow the SEE Client communication to be created.

 

Item 15: SEE Client Creation is crashing the MMC for Symantec Encryption Management Server

If you are seeing this issue, reach out to Symantec Enterprise Support for further troubleshooting steps.
EPG-24602, EPG-25272



Item 16: SEE Client Check Ins not working on 11.3.0 MP1 and older

There is an issue resolved in 11.3.1 MP1HF1 and above.  If you are seeing the SEE Management Agent services running, but not checking in, update the client.

If updating the client is not immediately possible, reach out to Symantec Encryption Support for further guidance.
EPG-26964

See also Scenario 5 of the following article for the SEE Bitlocker client:
173846 - Troubleshooting Symantec Endpoint Encryption for BitLocker
EPG-25274

 

Item 17: SEE Client Generation failing with error "Value does not fall within the expected range"

If this has happened, it's possible the SEE Client port is incorrect.
When the SEE Client is deployed, the typical port is 443 for secure TLS communications.
If a custom port was used to generate the client, check the SEEMS Configuration Manager for the Web Communications and ensure the port is the same.
If the ports do not match, you may run into issues with this not working and the client will not communicate

 

 

 



Additional Information

Keywords: SEE Client Creation Troubleshooting

ISFR-1744/EPG-25939 - Check in Via CLI
ISFR-1943/EPG-25940 - Checksum for Policy Updates

240321 - OAuth Communications with Symantec Endpoint Encryption 11.4 and above

178609 - How to create an SSL certificate to be used to secure SEE Client Communication with the Symantec Endpoint Encryption Management Server

240649 - Symantec Endpoint Encryption 11.4 Dashboard and Reports

227219 - Making Symantec Endpoint Encryption Management Server Public Facing

227509 - Migrating from Symantec Encryption Desktop to Symantec Endpoint Encryption (Drive Encryption components)

235981 - Symantec Endpoint Encryption Client Creation Wizard

Powered by Wolken Software