Please refer to Tachyon 5.2 - Troubleshooting for issues with other components of Tachyon.
Client installation issues on Windows
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 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.|
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
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 add directly to 1E.Client.conf.
|Please provide 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 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.
1E Client installer adds the Nomad registry settings even when Nomad module is NOT enabled during installation. If someone deletes those registry settings and enables 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 1E Client 5.1 - 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 specify 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 an 1E Client configuration instruction in Tachyon 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.|
Tachyon client uses Windows certificate store, but is currently unable to access the private key of a client certificate that is protected using 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 Tachyon client.
Editing a Guaranteed State rule that has already been deployed causes its history to be lost upon re-deployment.
Editing an existing Guaranteed State rule, deletes the existing rule Id ignoring all historic compliance data and is recreated with a new Rule Id and modified payload.
Clone the existing rule, which requires you to modify and deploy the same, either by including the newly cloned Rule to an existing Guaranteed State policy or new Guaranteed State policy.
This retains the history of the original rule and creates new history for the new rule.
Client connection issues
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 Tachyon 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
|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.
Tachyon 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:
These settings can be set during installation or changed post-install.
A Tachyon 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 Tchayon 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 Tachyon client certificate store does not contain any "CrossCA" certificates in the local Trusted Root or Intermediate CA stores.
The Tachyon client is unable to start on the Root CA.
A Tachyon 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 Tachyon 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 Tachyon client when it restarts, and the Switch starts spurious logging.
|To rectify this issue restart both the Switch and the 1E Client service.|
The Tachyon client fails to start and the 1E Client log shows errors relating to Certificate Revocation List (CRL).
An error is logged if CRLChecks=hard and the Tachyon client is unable to locate a valid HTTP-based CRL Distribution Point for a certificate.
An error is logged if CRLChecks=soft and the Tachyon 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 Tchayon client requires a valid SSL certificate presented by each server it connects to. This includes any Tachyon Switch, Tachyon Background Channel or other HTTPS server from which the Tachyon client downloads content. The Tachyon 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 Tchayon 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
Enabling, disabling, adding or removing network adapters on the Tachyon Server computer will cause issues with Switches issuing instructions or unable to use features like "Export All Results".
The Tachyon 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 Tachyon Server.
If for example the IPv6 address assigned is different from the one which was installed by Tachyon, 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 to Implementation issues: IP Address and Domain Restrictions.
Client issues specific to non-Windows
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:
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 Tachyon client will submit and also the Switch certificate received. The Tachyon 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.|
Please refer to Nomad 7.1 - Troubleshooting for issues with other components of Nomad.
Client installation issues
|1E Client installer adds Nomad registry settings even when Nomad module is NOT enabled while installation. If someone deletes those registry settings and enables Nomad module later, Nomad won't function right.|
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 Nomad module later, Nomad won't function right.
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 support on Windows XP therefore when 1E Client is installed with 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 1E 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.
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 with.
|1E Nomad Branch and 1E Client Health services may be stopped if upgrading to Nomad 7.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 remains stopped.
In this scenario, to immediately restore Nomad functionality simply start the services. To fix 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 1EClient service.
|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 - 1EClient - 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.
Please refer to Troubleshooting for issues with other components of PXE Everywhere.
Client installation issues
PXE Everywhere is not responding as expected. Log file shows messages similar to:
|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.|
Client installation issues
|No issues known.|
Shopping and WSA
Client installation issues
|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 WSA Firefox 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:
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.