1E 8.1 (on-premises)

1E Client installed on Windows 11 device reports Operating System value as "Windows 10 21H2"

1E Client installed on Windows 11 device reports Operating System value as "Windows 10 21H2".

None

1E Client UI runs even when the Tachyon module is not enabled (e.g. Nomad only install)

Installing the 1E Client without enabling the Tachyon Module (only Nomad or Shopping module is enabled) enables and displays the survey notifications in 1E Client notification icon.

In order to suppress this, the Module.Interaction.Enabled=false can be set in the config file on the 1E Client or use the corresponding MSI property (i.e. MODULE.INTERACTION.ENABLED=false).

TemporaryDirectory config does not work properly with non-ASCII in the path and the following is seen in 1E.Client.logs:

ERROR - Temporary directory: Cannot create file in 
overriding path 'c:\t€mp\acme€'; using default location

The error is seen if the TEMPORARYDIRECTORY MSI property for the 1E Client contains a non-ASCII value such as "c:\t€mp\acme€" and the directory exists.

The same applies if this is added directly to 1E.Client.conf.

Please provide a path that only uses ASCII values.

Manually uninstall of 1E Client using Programs and Features displays dialog "The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup."

Running the 1E Client MSI manually with the Remove option displays the following: "The setup was unable to automatically close all requested applications. Please ensure that the applications holding the files in use are closed before continuing with the installation."

These messages appear as the services that are about to be removed are running, but the 1E Client handles the shutdown so this message can be ignored.

Silent uninstall does not present this issue.

None

1E Client installer adds the Nomad registry settings even when the Nomad module is NOT enabled during installation. If someone deletes those registry settings and enables the Nomad module later, Nomad will not function correctly.

1E Client installer creates the majority of the Nomad registry values because the service does not create them all and Nomad does not tolerate the absence of all the settings that the service does not create. If these settings are deleted and the Nomad module is enabled later, then Nomad is unable to function correctly.

In such a scenario, 1E Client will need to be reinstalled with a new set of properties / transform that enables the Nomad module with the appropriate configuration.

When upgrading an existing 1E Client, none of the manually added configuration file properties in the *.conf file have been retained.

1E Client does not retain any configuration file property values that have been added as the upgrade process currently only checks the default values that exist in the old Tachyon.Agent.conf or new 1E.Client.conf.

This includes the Module.Inventory.ProcessUsage.Enabled=false values that was included in Tachyon Agent v4.0. After an upgrade this configuration file property will no longer appear and 1E Client uses the default (true).

The additional configuration file property values need to be added to the 1E.Client.conf file if they are required.

Please refer to Tachyon client settings for list of the available configuration options.

When upgrading an existing 1E Client that has been installed to a non-default installation directory, installation folder reverts to the default path.

If the previous Tachyon Agent was installed anywhere other than the default location "%ProgramFiles%\1E\Tachyon\Agent", then the Installation folder in the wizard will revert to the new default path "%ProgramFiles%\1E\Client".

The same applies to silent upgrades where the Tachyon Agent was installed to another path, the installation folder will revert to the default unless the required directory is specified using INSTALLDIR.

Please upgrade by specifying the required Installation folder in the wizard or using the installer property: INSTALLDIR

Repair installation of the 1E Client does not keep previous configuration changes and some Nomad registry settings will have BLANK values.

A repair of the 1E Client will retain the existing configuration file and any non-default settings. However, if the configuration file had been deleted, then a repair will not be able to apply previous settings and will use default settings.

Also a repair will set any properties passed in the command line, but will leave some Nomad properties like KnownMobileDevices and LocalCachePath as blank.

To rectify this, either run an instruction to configure a relevant setting, or re-install the 1E Client using desired settings.

Use a 1E Client configuration instruction in Explorer for centralized post-installation configuration. Please contact 1E if you require the Product Pack that has this instruction.

Potential blue screen of death (BSOD) with Windows 7 SP1 and Tachyon inventory capture.

If Tachyon inventory is enabled on Windows 7 SP1 (without updates) there is the potential for BSOD issues on systems using out of date Windows drivers. Microsoft investigated the issue and confirmed the usbccgp.sys driver has a potential issue where it can fail to complete a power IRP in a timely manner.

Microsoft recommends the following fix:

1. Update the usbccgp.sys driver as follows:

Prerequisites: To apply this update, you must first install:

2. Update tdx.sys to 6.1.7600.21050 to address TDI driver response issues as per: KB2028827

Tachyon features of the 1E Client cannot read private key for a Trusted Platform Module (TPM) protected certificate.

The client uses the Windows certificate store but is currently unable to access the private key of a client certificate that is protected using the Windows Trusted Platform Module (TPM).

This issue was seen when a customer used Microsoft Intune for client certificate deployment and the Simple Certificate Enrollment Protocol (SCEP) certificate profile included 'Enroll to Trusted Platform Module (TPM) KSP'.

The 1E Client was unable to extract a handle to the private key in the Windows Certificate Store; 'NCryptExportKey failed with 0x8009000a' (NTE_BAD_TYPE) was reported as an error in the 1E Client log.

Use a client certificate that is not protected using Windows Trusted Platform Module (TPM).

Examples of Microsoft cryptography providers that do not use TPM are:

Also, Microsoft Software Key Storage Provider is the only CNG provider supported by this version of the client.

1E Client fails to connect to the Switch with following error: ERROR - Failed to connect to tachyon.acme.local: invalid padding (138)

During the establishment of an https connection between the client and the Switch, the client receives and verifies the Switch certificate. This is received from the Switch as an X.509 certificate chain, from which the 1E Client will extract the Switch's public key and verify the certificate chain. On a successful SSL handshake where the CRL is checked, it will report both the serial number of each certificate as it walks the chain and the Authority Key Id (AKID) of the CA that issued that certificate. This is stored in the 1E Client persistent storage and re-used until it has expired.

If the 1E Client connects to another Switch where the certificate chain is different (e.g. CA certs have been re-issued), the 1E Client may log the following warning since there is a mismatch of the Authority Key Id (AKID) saved in the persistent storage from previous CA:

WARN - X509: error:04067072:rsa routines:rsa_ossl_public_decrypt:padding check failed

WARN - X509: error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib

WARN - X509: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

Delete the cached certificate entries in the 1E Client persistent storage (default location is C:\ProgramData\1E\Client\Persist) and restart the 1E Client.

Non-Windows clients may disconnect due to the keep-alive period being too high.

Clients on Non-Windows may disconnect if the keep-alive period is too high.

Non-Windows clients need to have a maximum keep-alive time of 4 minutes (240s).

The keep-alive time needs to be updated in the 1E.Client.conf file: ConnectionKeepaliveTimeInSecondsMin should be set to 120 (default) and ConnectionKeepaliveTimeInSecondsMax should be set to 240 (default is 600).

These settings can be set during installation or changed post-install.

A client does not start and the 1E Client log shows: ERROR - Certificate Verification failed : CRL path validation error. This occurs even when CRLChecks=soft.

The client will not connect if it is unable to create a trust chain, despite having the correct root CA certificates. This is due to the local computer certificate store containing "CrossCA" certificates.

Please ensure the client certificate store does not contain any "CrossCA" certificates in the local Trusted Root or Intermediate CA stores.

The client is unable to start on the Root CA.

A client attempting to run on a Root CA server will log the following error:

WinTrustVerify returns 0x800b010a (CERT_E_CHAINING) “A certificate chain could not be built to a trusted root authority”

A Root CA sits at the top of the public key infrastructure (PKI), there are no higher authorities, and so it effectively self-signs its certificates, which Tachyon is specifically prevented from using.

It is not good security practice to have a Root CA online therefore do not install the Tachyon client.

You could configure your system to not use client certificates.

Resetting Hyper-V Agents can cause the Switch to become unresponsive and log erroneously.

Powering off or resetting a guest Hyper-V virtual machine without shutting it down, can cause the Switch to refuse connections from the client when it restarts, and the Switch starts spurious logging.

To rectify this issue restart both the Switch and the 1E Client service.

The client fails to start and the 1E Client log shows errors relating to Certificate Revocation List (CRL).

See Tachyon client settings.

An error is logged if CRLChecks=hard and the client is unable to locate a valid HTTP-based CRL Distribution Point for a certificate.

An error is logged if CRLChecks=soft and the client is able to get a CRL from the CRL DP, but the CRL indicates revocation of the device certificate or a certificate in its trust path.

The client requires a valid SSL certificate presented by each server it connects to. This includes any Switch, Background Channel or other HTTPS server from which the client downloads content. The client does not connect to a server if it knows a certificate is invalid.

CRLs are obtained by contacting the CRL Distribution Point(s) whose URL is embedded within the certificates. At present, the client supports only HTTP-based CRL Distribution Points. It ignores any non-HTTP CRL DPs that may be included in a certificates, such as file or LDAP, and does not support OCSP.

If the machine is not be able to contact a HTTP-based CRL Distribution Point, please ensure CRLChecks=soft within the 1E.Client.conf file. This will prevent the client from failing in the event of being unable to locate a CRL Distribution Point

Enabling, disabling, adding or removing network adapters on the 1E Client Server computer will cause issues with Switches issuing instructions or unable to use features like "Export All Results".

The 1E Client Server Core web applications have access restricted by the IIS feature IP Address and Domain Restrictions. All connections are denied, except for local connections. Changing adapter configuration after installation can cause the entries in the IIS feature to become incorrect and cause issues with 1E Client Server.

If for example the IPv6 address assigned is different from the one which was installed by 1E Client, then Tachyon.Workflow.log is likely to contain errors:

"Posting Housekeeping to Core API 1 failed 'Forbidden'"

"Delete with ID 22 to Core API 1 failed 'Forbidden'"

Or Tachyon.ConsumerAPI.log may have "Data export fail" errors when attempting to "Export All Results".

Please update entries in the IP Address and Domain Restriction feature of the CoreInternal and the Core website to include all local IP v6 and v6 addresses.

Please refer toIP Address and Domain Restrictions.

Microsoft InTune cannot be used to deploy the 1E Client package for macOS.

By design, Microsoft InTune can only be used to deploy macOS packages to the /Applications folder. However, the 1E Client must be installed to /Library/Application Support since that is a secure location, writable only by root. Also the associated launch property list file must be installed under /Library/LaunchDaemons.

Use an alternative deployment method for the 1E Client macOS package.

The 1E Client on macOS may not be able to validate the switch certificate if there is a cacert.pem in the .sslcerts folder that does not contain the relevant list of CA public keys. The following is logged:

ERROR - Either the Switch certificate or the client certificate is not trusted, use the 1E Client debug log setting to obtain certificate details.

If the 1E Client for macOS finds a valid cacert.pem in the hidden directory: /Library/Application Support/1E/Client/.sslcerts, then the Keychain Access is not checked.

This cacert.pem is then used to validate the trust chains for the client certificate the client will submit and also the Switch certificate received. The client will be unable to connect to the Switch if it does not contain the relevant list of CA public keys to do the validation.

Ensure the cacert.pem contains all the public keys for all the intermediate CAs, up to and including the Root CA required. Alternatively, remove the cacert.pem if the 1E Client for macOS is to use the certificates from the Keychain Access.

1E Client installer adds Nomad registry settings even when Nomad module is NOT enabled while installation. If someone deletes those registry settings and enables the module later, Nomad won't function correctly.

The installer is currently creating the majority of Nomad registry values because the service doesn’t create them all and Nomad doesn’t tolerate the absence of all the settings that the service doesn’t create. If someone deletes those settings and enables the Nomad module later, Nomad won't function correctly.

In such a scenario, we recommend reinstalling the 1E Client with a new set of properties / transform that enables the Nomad module.

This will be fixed in a future release of 1E Client.

On Windows XP, 1E.Client.log displays a warning "Unsupported OS version. Will not install Nomad." however the very next log lists that "Module 'Nomad' has been installed".

Nomad is not supported on Windows XP therefore when 1E Client is installed with the Nomad module, the module is not enabled, and the Nomad Branch service is not installed.

None.

Nomad may be downgraded by active Application deployments in CM, which may cause issues with behaviour of the 1E Client Nomad module.

If there is an active Application deployment in CM of an earlier version of Nomad, clients that have been upgraded with the 1E Client with the Nomad module enabled may be downgraded when the Application Enforcement cycle runs. In this scenario, if the Nomad module is subsequently disabled in the 1E Client, the Nomad service will be removed. This is because once the Nomad module has been enabled, it is not aware nor does it check for older versions. If the Nomad module is subsequently disabled, the service is removed as the Nomad module believes it is not longer required.

To avoid this situation, always define Application Supersedence on the 1E Client Application such that it supersedes any Applications that install previous versions of Nomad (and the 1E Client when introducing new versions of the 1E Client).

To resolve this issue should it occur, first address the Application Supersedence to prevent it from recurring. Then run the following command from the 1E Client installation directory on the affected devices.

1E.Client.exe -reconfigure MODULE.NOMAD.ENABLED=false -restart & 1E.Client.exe -reconfigure MODULE.NOMAD.ENABLED=true -restart

This will disable the Nomad module and remove the Nomad service, then re-enable the Nomad module, which will, in turn, uninstall the earlier version of Nomad and install the Nomad module. The settings defined by the earlier Nomad install will be migrated - these may differ from the settings with which the Nomad module was initially configured.

1E Nomad Branch and 1E Client Health services may be stopped if upgrading to Nomad 8.0 if previous version of Nomad installer is no longer in source folder or the Windows Installer cache.

The 1E Client installer stops the 1E Nomad Branch and 1E Client Health services if the Nomad module is enabled. The 1E Client installation completes successfully, after which the Nomad module attempts to uninstall the older version of Nomad. The uninstallation fails as Windows Installer cannot find the original source installer. The Nomad module is not enabled and the Nomad and Client Health services remain stopped.

In this scenario, to immediately restore Nomad functionality simply start the services. To fix it completely you will need to remediate the installer source for the old version of Nomad on the affected client, then run the following command from the 1E Client installation directory to restart the 1E Client service.

1E.Client.exe -restart

Uninstalling 1E Client doesn't delete Nomad's P2P server certificate.

When P2PEnabled value was set to 79 then NomadBranch server certificate does not get deleted after uninstallation.

NomadBranch - 1E Client - Creation of Nomad COM object failed with 0x80070424

Install the latest build with Nomad. Creation of Nomad COM object failed with 0x80070424-

Disable the Nomad module and restart the 1E Client service. Enable Nomad again and restart the 1E Client service. Nomad should install successfully.

Nomad users see the 1E Client UI in the device system tray even when the Tachyon module is not enabled.

The 1E Client UI runs despite only the Nomad or Shopping modules being installed, without the Tachyon feature enabled.

None.

PXE Everywhere is not responding as expected. Log file shows messages similar to:

Error: failure to bind to 192.168.18228:69. 
The specified address is already in use
TFTP: retry in 1000ms
Error: failure to bind to 192.168.18228:4011. 
The specified address is already in use
DHCP: retry in 1000ms

PXE Everywhere Agent and PXE Everywhere Responder cannot co-exist on the same computer and are not supported together. Whilst it is possible to install them together, they will not work and will have issues such as failure to bind to ports.

Either uninstall PXE Everywhere Responder, or disable PXE Everywhere module in 1E Client. Then restart the computer, or restart the relevant service (PXE Everywhere or 1E Client).

PXE Everywhere Agent fails to connect to PXE Everywhere Central.

An incorrect URL has been specified during installation of PXE Everywhere Agent. The installer wizard does not validate the PXE Lite Central URL is provided during the PXE Lite Local GUI installation.

Ensure you specify the correct URL when installing PXE Everywhere Agent.

PXE Everywhere does not support RISC based architecture.

PXE Everywhere does not support RISC based architecture and therefore not able to PXE boot clients using RISC. For instance, architecture being used by Microsoft Surface Pro 10 LTE Models is ARM 64-BIT UEFI (11) which is a RISC architecture and not recognized by PXE Everywhere.

None.

PXE Everywhere Agent installation fails when an unprivileged user installs it after providing administrator credentials (UAC prompted) for installation.

PXE Everywhere Agent installation fails with error when an unprivileged user initiates PXE Everywhere Agent installation even after validating credentials after UAC prompt.

When installing the agent interactively, run the installer from a command prompt with elevated permissions.

No issues known.

Shopping module does not send machine details on a TLS enabled Windows 7 environment

The Shopping module in the Tachyon 3.2 Agent fails to send machine details on a TLS enabled Windows 7 (32 and 64 bit) environment.

Firefox prompts you to restart the browser when connecting to the Shopping website. After restarting you are no longer prompted.

Firefox must be restarted to allow changes made by Shopping client to take effect. The Shopping Console has a setting for WSAFirefox support enabled. The Shopping client module reads this setting from Shopping Web and if enabled (default is true) then it does the following:

This Console setting for WSA is only required if using Firefox and HTTPS because Firefox is stricter in which certificates it accepted on an HTTPS connection and by default uses its own certificate store. The WSA setting can be disabled in the Shopping Console if only using other browsers, or not using HTTPS.

1E Client log shows entries:

INFO - Added '1E Ltd CA Certificate' certificate to ROOT certificate store

INFO - Added '1E Ltd localhost Certificate' certificate to MY certificate store

If you are using Shopping HTTPS then use Internet Explorer or Chrome browsers to login to Shopping.

If you are using Firefox browsers with a Shopping HTTTPS website then you will need this.

If you are using Shopping HTTP website then you can disable the Shopping Console setting for WSA Firefox support enabled.