"There are no bugs if you don’t write any code."

This document details some of the known minor issues customers may experience when using Avantra 23. As known issues, they will be fixed in the upcoming 23.x.x patches over the coming weeks. We apologize for any inconvenience caused and encourage customers to review this document in detail before deciding to complete an upgrade to Avantra 23.0.

Overview of known issues

XAN-4296 - Notifier behaves incorrectly on MSSQL Avantra installations after update to 23.2.2

For Avantra Server installations on Windows using an MSSQL database, after upgrading to Avantra 23.2.2 the notifier behaves incorrectly in some scenarios.

This issue has been fixed in Avantra 23.2.3 and above.

XAN-4276 - Disabling/Enabling the Notifier doesn't update the UI

The issue occurs when the user disables the Notifier - the UI will not display the changes. However, the Notifier will still be disabled in the background. Similarly, when the customer re-enables the Notifier, the status at first will not show in the UI as enabled, but the Notifier will be re-enabled.

Workaround

Wait until local caches are refreshed and the status is displayed in the UI.
This issue has been fixed in Avantra 23.2.2 and above.

XAN-3280 - Manual agent update on Windows fails

This issue occurs when a user attempts to upgrade their Windows-based Avantra agent using a manual method using the Avantra agent .exe file. The upgrade will appear to complete successfully; however, the agent will be uninstalled.

Workaround

Please use the recommended approach of automated agent updates via the Avantra UI. This uses the agent .bin file to perform the update and therefore is not affected by this issue. However, this is the recommended way to perform agent updates anyway.

If you encounter the issue

If you encounter this issue, please run the "uninstall_agent.exe" file within the agent install directly and then reinstall the agent from scratch using the .exe file. This will perform a fresh install of the Avantra agent. Rest assured, this will not affect data already transmitted and stored within the Avantra server.

This has been fixed in Avantra 23.1 and above.

Please note that if you have any special JVM settings or similar that had been set using the "%%AGENT_DIR%\agent\bin\prunmgr //ES//sxagent" command, then these settings will be lost. If performing a reinstall of your agent, please take note of these settings prior to your upgrade and reapply them manually after.

XAN-3825 - SAPTemseConsistency check is disabled

With the introduction of new checks on Avantra 23.0, we introduced several new SAP System checks - including a SapTemseConsistency check with a new "prollector" behavior that collects and processes data at the same time, which may take a very long time to execute on established SAP systems with a large number of transactions and data (more than 45 minutes in several observed cases).

The issue occurs because the SapTemseConsistency check is part of the Daily (Full) Check and it takes over 30 minutes to complete. By default, the Daily (Full) Check has a hard-coded timeout of 30 minutes. After the timeout, the Daily (Full) Check cycle terminates. Any results reported after the 30-minute window on the agent/server running it will report back as UNKNOWN back to the Avantra Master, resulting in an incomplete daily check overview and an incomplete Service Level Report.

Due to the issue below (XAN-3809), even if the SapTemseConsistency check is disabled, the check is still executed on the agent, but it does not report back the results to the Avantra Master. 

Workaround

Update to Avantra 23.0.4 or above.

XAN-3809 - Some checks cannot be disabled

With the introduction of new checks on Avantra 23.0, we introduced several new SAP System checks with a behavior that collects and processes data at the same time, which may take a very long time to execute on established SAP systems with a large number of transactions and data (more than 45 minutes in several observed cases).

The issue occurs whenever there are any checks or custom checks that form part of the Daily (Full) Check that take over 30 minutes to complete. By default, the Daily (Full) Check has a hard-coded timeout of 30 minutes. After the timeout, the Daily (Full) Check cycle terminates. Any results reported after the 30-minute window on the agent/server running it will report back as UNKNOWN back to the Avantra Master, resulting in an incomplete daily check overview and an incomplete Service Level Report.

Workaround

Update to Avantra 23.1 or above.

XAN-3686 - Minimum Avantra-managed password complexity changes

In Avantra 23.0, on the advice of our regular security analysis, we introduced a new mandatory requirement that all Avantra-managed passwords should be a minimum length of 12 characters. It was also made impossible to reduce this required length in the password policy. This caused some issues with customers who integrated into legacy systems. 

In Avantra 23.0.3, we kept the default at 12 characters but allowed the possibility for customers to manually lower the required length to 8. However, we strongly recommend that customers keep a minimum of at least 12 characters.

In Avantra 23.1 we have introduced a new functionality to check if a password is a commonly used password. 

If a user attempts to login with a password that doesn't meet this policy, they will be forced to change it.

XAN-3624 - Default secure application cookie flags can prevent login

In Avantra 23.1 we have changed the default settings for the cookies that Avantra uses for each user session. These are now secure by default.

For the vast majority of installations, Avantra will continue to work as normal and you will benefit from increased security when accessing Avantra. If, after upgrading to Avantra 23.1 you experience a login loop (repeated request for credentials) please see the following solution article - Configure SameSiteCookie and Secure cookie in Avantra UI

XAN-3465 - Behaviour of the AgentListenerPort monitoring parameter has changed after 23.1

In Avantra 23.1 we have changed how the AgentListenerPort monitoring parameter behaves to simplify its use for customers. Previously this parameter controlled the port that the server used to communicate with the agent and also, if present in the agent configuration, changed the port the agent used to listen on.

After updating to 23.1, this behaviour has changed and now the monitoring parameter only affects which port the server uses and doesn't affect the agent. This means that customers using non-standard ports for the agent must ensure that they have updated the `agent.cfg` on the agent to reflect the correct port.