New Windows10 lockscreen/OES client/AutoAdminLogin problem

This week we encountered a problem when unlocking locked Windows 10 workstations where AutoAdminLogin is enabled for the Windows user. After entering the eDirectory credentials the unlock screen gets stuck and the workstation has to be rebooted. Normal Login is not affected.

The workaround we found to solve this problem is changing the "Unlock Workstation Credentials" in the Advanced Login Settings of the Client to "eDirectory only".

The affected workstations are Windows 10 Pro (64-Bit) version 22H2. Client for Open Enterprise Server 2 SP7 (both IR2 and IR3) is installed.
AutoAdminLogin is enabled (eDirectory prompt, Autologon to Workstation) for use with a generic local Windows user account.
This configuration has worked flawlessly for over a decade. Before the problem occurred both the cumulative Windows update for 22H2 KB5031356 and the current version of Avast Business Security were installed as part of routine maintenance.

I suspect that something in KB5031356 breaks the unlock credential mechanism in the OES client, but did not have the time to investigate further.

  • I believe the key may be the "eDirectory prompt, Autologon to Workstation" you mentioned.  Meaning in addition to the Microsoft AutoAdminLogon policy being configured, the Client for Open Enterprise Server's option for "Prompt for network logon during Windows AutoAdminLogon" is also enabled.  (Also known as the Client for Open Enterprise Server "AutoAdminQueryNDS" registry policy.)

    We are currently investigating a hang that occurs in the current client releases when both AutoAdminLogon and AutoAdminQueryNDS are both enabled. There is no known workaround for this issue at this time, other than to temporarily disable at least the "AutoAdminQueryNDS" policy which seemed to avoid the failure in our investigation thus far.  But the actual root cause has not yet been identified yet, nor is there a proposed fix at this time.

  • Has there been any progress on the issue? The problem persists on two of the affected workstations, even after moving to client version 24.1.

Reply Children
  • Suggested Answer

    It is something which is actively under investigation right now, and the design for the fix has been identified.  It was hoped that this fix might make it into the next available release such as 24.2, but the design as proven involved enough that it likely will not be completed and tested within a time frame suitable for 24.2.  But the work is actively occurring, and should be addressed as soon as it can be.

    Until then the only possible workaround in current shipping clients is still the disabling of the AutoAdminQueryNDS and Windows AutoAdminLogon policy.  The issue appears to have started with a change made in the Client for Open Enterprise Server 2 SP6 time frame, so it would require an SP5 IR2 or earlier client to attempt working around it in a manner which allows the AutoAdminQueryNDS policy to remain enabled.