Skip to main content

1E 8.1 (on-premises)


For a general methodology for investigating issues, as well as identifying key issues and their resolutions, and for known issues relating to specific components, please refer to their troubleshooting pages, refer to 1E Troubleshooting.

Known issues

Lists of the current known issues with implementing, configuring, and using Guaranteed State.

If you cannot find an issue and its workaround on this page:

If you need further help, please refer to the Troubleshooting page for how to contact 1E Support and the technical support process.




Any pending changes in Guaranteed state and/or Experience applications that are deployed during upgrade process from Tachyon Platform v5.1 to v5.2 or v8.0. This is also true if there is an already deployed unlicensed rule/recondition/check or fix.

Tachyon Setup runs a post installation action to automatically deploy all policies and event subscriptions.

Ensure any pending deployment changes under review are either deployed prior to upgrade process is initiated or respective rule/policy/Survey should be marked as disabled to prevent deployment during upgrade process

Guaranteed State Overview pages show incorrect devices when Policy with no Rules have been assigned to a Management Group.

On the Guaranteed State Overview page, the Online, Online last 7 days and Last seen per Criticality Level charts all show incorrect counts when a Policy is assigned to a Management Group, but no Rules have been assigned yet.

This will display correct values once Rules are assigned and devices have responded to the events.


Opening an instruction or fragment that has been exported using the Consumer API displays the following message when viewed in TIMS:

"This instruction definition was signed by CN=Tachyon Explorer Instructions but the content has been tampered with.

An instruction exported through Postman can generate file with whitespace differences and file size between the original file which is not accepted by TIMS as it's considered to be tampered.

Use alternative API tools (e.g Fiddler).

"Ensure Nomad can communicate through the Windows Firewall" remediation is being executed even when firewall is disabled from the GPO.

"Ensure Nomad can communicate through the Windows Firewall" remediation is being carried out when there is a firewall policy which has been disabled through group policy. This means that when firewall policy has been disabled explicitly, instead of ignoring the fix, the firewall is being set to enabled and the firewall exceptions are set for Nomad.


On a ConfigMgr Distribution Point, the Rule to "Check the Nomad has a virtual directory on ConfigMgr distribution points to perform LSZ generation" always passes even though a failure reason may be returned in the Data field.

The check fragment should verify that the LSZFILES website setup by Nomad on a DP has certain characteristics, but even when errors are found the check status is "Passed".

The logic in the PowerShell parts of the fragments uses a $errorOccurred variable to set the exit code, but this variable is initialized to $false and then never changed even when an error is detected.

e.g Data field returns: "Windows authentication not enabled. Require SSL flag is not disabled. Directory browsing not correctly set."


1E Client logs several unsuccessful remediation attempts within a 24hr period.

There is currently no longer a cap on the number of time a remediation step can occur on a machine within 24hrs. This differs from 1E Client Health where after 3 failures to remediate an issue, further remediation would not occur until 24hrs have passed.