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 PGP Encryption Suite

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.  Starting with SEE 12.0.1, OAuth is the only method available when generating clients, which should greatly simplify client-server communications.  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.

Because TLS is directly related to client communication and generation, see the following article for more details on this topic:
178609 - How to create an SSL certificate to secure SEE Client Communication with the Symantec Endpoint Encryption Management Server (SEE)


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/install-time" 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/install-time" 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 1: 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. 


Note 2: 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.  See Item 1 in the list below for more details on this. 


Note 3: Because the SEE Clients rely on a check-in procedure to receive policy from the server, it's important to make sure the SQL services are always running.  If the services stop, the communications will stop.  Before everything else, we recommend installing with the full version of SQL (not SQL Express), and make sure the SQL Server service is set to "Automatic", so that if the server is ever restarted, the SQL will immediately restart. 

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).
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.
Instead, whenever a local GPO update happens either automatically or manually, then the SEE policies will be applied to the machine.

TIP: Symantec recommends using the SEE Native policy for many reasons, but the main reason is ease of use.  It does not require you to be an Enterprise or Domain admin to affect GPO polices on the DC.
If you are using GPO Policy and want to consider changing this method, see the following article:

243136 - Migrating to Symantec Endpoint Encryption Policy Methodologies to SEE Native Policies (From Active Directory 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: Manually/Forced 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.   

If you have changed the credentials for the account used for IIS, it's typically necessary to deploy a new client if you are not on SEE 12.0.1 and using OAuth.
If you have not yet started to use OAuth, the credentials need to be properly configured on the SEE Client.  If they are not, it's best to create a new SEE 12.0.1 client and deploy to each endpoint.
After the SEE Clients are deployed with 12.0.1, the windows credentials are no longer inbuilt to the client and OAuth is used going forward.

See the following KB for more information on OAuth and how to start taking advantage of this significant improvement!
240321 - OAuth Communications with Symantec Endpoint Encryption 11.4 and above

___________________________________________________________________________________

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

When Symantec Endpoint Encryption client versions 12.0.0 and older are generated, it includes the credentials used at the time of creation.
These credentials must remain unchanged for the clients to be able to communicate with the SEE Management Server.

If you suspect the credentials have changed, this is likely why the SEE Clients are unable to communicate with the server.

As mentioned in Item 1 of this article, it's best to upgrade to SEE 12.0.1 where OAuth is inbuilt and windows credentials are no longer inbuilt.  
This greatly simplifies the deployment and use of the SEE Client and will never have issues when credentials are changed/rotated. 

See the following steps to check if you are using credentials on the client:

  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.

    SEE 11.3.1 and older: For example, https://see.example.com:443/GECommunicationWS.asmx
    SEE 11.4.x: Uses either the above URL, but for OAuth, it uses: https://see.example.com:443/OAuthServer
  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, example.
  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.

If you see these values, you may have embedded the credentials and it's better to upgrade to SEE 12.0.1 to start using OAuth and avoid this issue completely. 

See the following KB for more information on OAuth and how to start taking advantage of this significant improvement!
240321 - OAuth Communications with Symantec Endpoint Encryption 11.4 and above

For more information on this topic, see the following article:
152429 - Symantec Endpoint Encryption clients fail to check in if the credentials of the Client Authentication Account change


___________________________________________________________________________________

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.example.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 1: If the Root Certificate Authority is expired, or you change the Root Certificate Authority (CA Certificate), normally you need to create a new SEE Client once the certificates have been assigned again in the SEE Management server.  If you are changing the Root Certificate for SEE Management Server, please reach out to Symantec Encryption Support to obtain a CA Cert Replacement Utility that can help replace the cert without having to deploy a new SEE Client.
Ref: EPG-35561, EPG-22069

The new CA Certificate will then be embedded into the new SEE Client and will need to be redeployed over preexisting clients.


Important note 2: 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.

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 (Two Scenarios): 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: Validation Failed when trying to create the SEE Client in Web Console

When trying to create the SEE Client, the following error appears:

"Validation Failed: The Server URL validation failed.  Do you want to proceed anyway?"
"Validating the Server URL...Unable to locate Server URL"



When attempting to generate the SEE Client, the URL is validated. Make sure the FQDN (Fully Qualified Domain Name) is entered, and this URL matches the TLS Certificate.
If the certificate is generated for the wrong FQDN, then the validation could fail.  In addition to this, make sure DNS is resolving. 

You can skip the page in some cases where you know the URL will check out externally, but you know it will not be validated internally.  Use caution when skipping.
After skipping, install the SEE Client on a test machine and ensure it is checking in, before deploying to the general population. 

If you generate a SEE Client by skipping this URL validation, the SEE Client may not check in properly.

Also ensure your TLS certificates have a trusted Root and Intermediate Certificate in the local certificate store of all your systems.

Reach out to Symantec Encryption Support for further clarification.

___________________________________________________________________________________

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.

___________________________________________________________________________________

 

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.

    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 8: 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 SEE 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 9: 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 10: 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 11: 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 12: 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 13: 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 14: 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 15: 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 16: 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 17: 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 18: 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

 

___________________________________________________________________________________

Item 19: Unable to login to the SEE Web Portal "The Server is currently inaccessible.  Try again later"

 

For more information on this, see the following article:
154190 - The transaction log for database 'SEEMSDB' is full - Symantec Endpoint Encryption Web Console Not Accessible



Item 20: Browser won't load the SEE Management Web Portal with error Inadequate Transport Security


If you are going to the helpdesk page and receive an error from the browser:

ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY

It may be that your ciphers on the machine are not configured.  Check your Windows Server where SEE Management Server is installed and make sure no ciphers are needing to be enabled.  TLS 1.0 and 1.1 should not be enabled as TLS 1.2 is used. 

Additional Information

 

TLS:

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

214267 - Enable TLS/SSL for the Database on Symantec Endpoint Encryption Configuration Manager (SEE)

176302 - Renewing the Symantec Endpoint Encryption Management Server TLS certificate (SEE)

155127 - Symantec Endpoint Encryption Client communication and SEE Client Creation troubleshooting steps

155218 - HOW TO: Generate a new self-signed Organization Certificate for PGP Server for SMIME Email Encryption (PGP)

180416 - How to Install an SSL Certificate for Symantec Encryption Management Server (PGP Server)

257339 - How to Create and Assign a Subordinate/Intermediate Certificate for SMIME/Certificate Signing with PGP Server (PGP)

180143 - HOW TO: Work with Trusted Keys and Certificates on the PGP Encryption Server (Symantec Encryption Management Server (PGP)

Powered by Wolken Software