- 06 Jun 2022
- 10 Minutes to read
- Contributors
- DarkLight
- PDF
Release 4.11.2 Client
- Updated on 06 Jun 2022
- 10 Minutes to read
- Contributors
- DarkLight
- PDF
New Features and Enhancements
- Drive Mapping Support has been enhanced to notify Windows Explorer that a drive has been mapped or un-mapped for quicker response times for mapped drives to appear in the Explorer window.
- Installation update to pre-configure Internet Explorer as a valid application in the eXactACCESS Applications List Registry so that Web enabled SnapAPP applications do not need further deployment configurations performed before they will function.
- The client installation will now preserve settings from previously installed versions so that settings do not have to be re-configured during an upgrade.
- pubLauncherSF and sfConnect have been updated to use TLS 1.2 for secure communications to Store Front via HTTPS.
Issues Resolved
XA-5053 - After the RDP session is closed without using the XALock application, tapping into standard mode results in an instant lock of the session
Observed
Tapping into a workstation will briefly show the Windows desktop, then the workstation will lock the current session, forcing the user to tap a second time to retrieve the session.
Resolution:
The autologoff application will now treat an RDP disconnect the same as a session lock, indicating to the XA application that the system is locked.
Affects Versions:
4.11 and above
XA-5052 - Standard mode lock notification/status is not displayed with the appropriate style
XA-5040 - PublauncherSF hangs when attempting to launch published resource when the EndoSoft application is running for non-administrative users
Observed
When the EndoSoft application is running, non-administrative users are unable to launch published resources from Store Front, as the application hangs during the launch.
Resolution:
Using the Windows automation API while the EndoSoft application is running presented a deadlock. This application error has been resolved by using the standard Windows API instead of the automation API to find the published resource application window.
Affects Versions:
4.11 and above - only while the EndoSoft application is also running by non-administrative users
XA-5027, XA-5036 - Standard Mode credential provider hangs when logging in (unresponsive to badge tap), or logging off (please wait)
Observed
Occasionally, when a user taps out of a session, the Microsoft message "please wait" will be displayed indefinitely. Additionally, after a reboot, the user is unable to use the badge to initiate login until after manually logging in and locking or logging off the session.
Resolution:
Prior attempts to correct the hang at logoff resulted in disabling the badge reader thread during startup if the credential provider was not able to communicate with the badge service. The hang during logoff appears to be a deadlock caused by COM communication to the logging service. This deadlock has been resolved in the logging thread by delaying COM initialization during the startup phase of the credential provider to give the provider sufficient time to complete initialization.
Affects Versions:
4.11 and above
XA-5032 - Debug Logging for Kiosk Mode is enabled by default after installing XA
Observed
When XA is installed on a workstation in kiosk mode, xahid_kiosk information logging is enabled by default.
Resolution:
The install correctly updates the xahid_kiosk.exe.ini file to disable logging when the file is installed.
Workaround:
Edit the xahid_kiosk.exe.ini file with a text editor and set these settings under the [debug] section: informational=0 and methodentryexit=0 to disable logging.
Affects Versions:
4.11 and above - only while the EndoSoft application is also running by non-administrative users
XA-5046 - Daylight savings time causes issues during time change when the time is set ahead one hour
Observed
After the spring DST time change, several applications report errors in the event log, or indicate a time problem with a popup dialog, preventing proper behavior of these applications. This can include stopping threads in HCIDeploy client, XAHID_Kiosk.exe, HCLFOAuditing service, HCLFOLogging service, WatchForLogoff.exe, XAUCM.exe AutoLogoff.exe, and HCHIDScan service and other applications or services.
Resolution:
Conversion from local time to UTC time was not properly wrapped in exception handling for recovery, thus allowing a recoverable error from being appropriately treated to re-adjust the time check. The conversion is now repeated until the correct time is successfully returned from the UTC conversion routine instead of returning the error condition.
Affects Versions:
4.11 and above
XA-5043 - From standard mode workstations, PublauncherSF sometimes launches duplicate sessions on a Citrix server when a session is unlocked
Observed
PublauncherSF fails to locate the currently running application window title, and determines it must launch the application again when the system is unlocked.
Resolution:
Several issues with the Automation API have been addressed by switching to direct Windows API calls to find the window or child windows of the launched process when determining if the application is already running. The existing instance will be activated and brought to the foreground when it is located, and a new instance will not be launched. Additionally, it is now possible to specify multiple window titles to search for in the AppTitle registry setting ie: AppTitle=title1;title2;title3
Affects Versions:
4.11 and above
XA-4856 - Access denied error for a user when Connector XML file does not contain a tag ParameterList when using pass-through authentication
Observed
If the ParameterList tag is NOT in Connector's XML file for Connectors that do not require access checking or those that don't utilize username and password parameters - users get an access denied error message.
Workaround:
- Add the following XML tag set to blank
- <ParameterList></ParameterList>
- Re-deploy the updated Connector XML to client workstations.
Alternate Workaround:
- If the connector SERVER XML has been imported, instead of using SnapAPP integration:
- Use the eXactACCESS administrator and edit the application.
- Ensure the Library setting is enabled
- Enable the Active Directory Passthrough check box if necessary.
- Press OK after editing - even if no changes needed to be made
- Use the eXactACCESS administrator and edit the application.
Resolution:
There is no resolution to this issue - see workarounds.
Affects Versions:
4.11 and above
XA-5001 - Logging fails for several multi-threaded components
Observed
Attempting to enable logging on the following client applications results either in no logs, or incomplete logs:
AutoLogoff.exe, QwickSTART.exe, HCIDeployConsole.exe, HealthCastWLLSvc.exe, XARFIdeasAdmin.exe, XAClientConfigure.exe
Resolution:
Corrected an error in the threads where they expected a global COM Initialization flag to be set, that was not set at startup. The COM flag is now properly set to a valid value during startup so the threads are able to properly initialize COM so that the logging service objects can be obtained.
Affects Versions:
4.11 and above.
XA-5003 - When a client is configured for non-locking kiosk mode, a user is unable to tap out of the client.
Observed
When tapping out, nothing appears to happen. The XA client remains logged in.
Resolution:
An error has been addressed that caused the tap-out process to be interrupted or hung before the logoff could be issued to the client.
Affects Versions:
4.11 and above - non-locking kiosk mode
XA-4868 - Appsense/Ivanti functionality is disabled after installing the eXactACCESS client or changing modes of operation of the client.
Observed
Some functionality of the Appsense (now Ivanti) product suite for endpoints, such as profile management services are unavailable after switching from SUM to KM, or KM to SUM, or when uninstalling the eXactACCESS client.
Resolution:
AppSense/Ivanti requires that the Windows shell registry key be set to explorer.exe (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon) - the Shell name/value must exist, and the value must be explorer.exe. The install has been corrected so that this key is not deleted. The client configuration tools have been updated to create the key if it doesn't exist during a mode switch, and ensure it is set to explorer.exe when the Shell Replacement option is not used, or is switched off during re-configuration.
Affects Versions:
4.11 and above
XA-4998 - When the client device is configured for TrueSUM, the credential provider can crash during login.
Observed
The credential provider will crash with an AV when the system is supporting locking (as opposed to disconnecting) the active session. The screen may turn black, and Windows will re-load the credential provider. This access violation may then cause a repeated crashing scenario, preventing the user from logging in.
Resolution:
The source of the access violation has been resolved.
Affects Versions:
4.11.1
XA-4991 - When a client is configured for TrueSUM, and the user's password is expired, the user is unable to provide a new password
Observed
Attempting to log in with a user that is required to change the password at the next login results in a screen "flash" and the user is returned to the login screen.
Workaround:
In Windows 7, select the Switch User option. The user may now change their expired password and log in.
Resolution:
Incorrect memory allocation and de-allocation during the change password tile change have been resolved.
Affects Versions:
4.11.1
XA-5013 - When a client is configured for TrueSUM, attempting to tap over an active session with a different user should result in an error message but does not.
Observed
When an active session is locked and the client is configured for TrueSUM, tapping a card of a different does not result in the user being notified that they may not perform tap over operations on this workstation.
Resolution:
The message will now be displayed with a different user attempts to tap over either an active or locked session and the workstation is configured for TrueSUM.
Affects Versions:
4.11 Kiosk Mode
XA-5002 - When an active session is tapped out, the session remains open for an extended period of time, and may or may not lock.
Observed
When a user taps in but then attempts to quickly tap out, the computer may appear non-responsive to the tap, or takes an excessive amount of time before the tap out is processed.
Resolution:
When Microsoft's LogonUI.exe process is running from the login, Windows rejects all lock commands until the LogonUI.exe process is terminated indicating a session has been fully created. This prevents the system from being locked for up to 60 seconds. Previously addressed issues that affected XA-5013, XA-4991, and XA-4998 would sometimes prevent LogonUI.exe from closing after the user authenticated. These issues address the problem of locking the workstation, as LogonUI.exe no longer stays running for extended periods of time after the user session has been logged in.
Affects Versions:
4.11.1 and above
XA-5026 - In standard mode, setting the limit maximum sessions does not log off inactive sessions when new sessions are created.
Observed
The user has XA set to SUM, with the Limit to Maximum Sessions field set to "2" (or any other value). When the user taps in and locks each session, XA will not log off any session over 2 (or the max amount) and leaves all sessions active.
Resolution:
Corrected the issue with the credential provider not being able to identify eXactACCESS user sessions and allow the correct inactive session to be logged off when a new session is created.
Tip
Non-XA sessions (sessions where XAUCM is NOT running) are not counted in this active number, allowing local accounts to be logged in for administrative or maintenance reasons and not get logged off. This behavior is been corrected to conform to the same rules applied to previous versions of the XA client older than 4.11.
Note: The administrative user logging in may log off a previous XA session, even though the new session will not be counted toward the maximum session limit.
Affects Versions:
4.11 and above
XA-5021 - SnapAPP integration of specific websites can get stuck in a login/submit loop if the user didn't provide a valid username or password for the site.
Observed
On a website, change the user's password in the application, then attempt to use SnapAPP that had previously captured a user's old password. The username and passwords are filled in and submitted. This often presents a notification to the user that the password is invalid, but SnapAPP then tries to re-submit the same credentials, not recognizing that the last attempt was invalid.
Affects Versions:
4.11.1
XA-5028 - Kiosk mode fails to register a badge for a user on a domain other than the primary domain configured
Observed
When a workstation is configured in Locking Kiosk mode, and a user from a second domain (other than the primary domain configured) attempts to authenticate and register a card by entering domain\username, the card is not enrolled.
Resolution:
Incorrect parsing of the domain\username resulted in the client determining the user is a local workstation user instead of a domain user and did not pass the card enrollment to the server. The parsing now determines that when a domain is entered as part of the user name, and it doesn't match the local system name or is not the dot (.) indicating the local workstation, the enrollment should be passed to the server to save the card. Additionally, the login button is disabled during the authentication attempt to prevent re-entrance of the login function while the account is being authenticated
Affects Versions:
All previous versions
XA-5021 - SnapAPP integration of specific websites can get stuck in a login/submit loop if the user didn't provide a valid username or password for the site.
Observed
On a website, change the user's password in the application, then attempt to use SnapAPP that had previously captured a user's old password. The username and passwords are filled in and submitted. This often presents a notification to the user that the password is invalid, but SnapAPP then tries to re-submit the same credentials, not recognizing that the last attempt was invalid.
Affects Versions:
4.11 and above