Windows 10 - Login Hang - Failed Drive Map Screen

OS: Windows 10 1803
Client: Client for Open Enterprise Server 2 SP4 (IR10)


New logon / user creation with ZENworks to a workstation (Have not tested with pre-existing account), if a mapped network drive fails. The logon hangs at "Preparing Windows" during the first initial logon.

It may eventually timeout and come forward, however I hit if I hit CTL ALT DEL it brings up the login script and I can click OK and bypass the failed drive mapping. I have waited 2-5 minutes without it prompting. (Side note, I see similar behavior with password changes, slow to show)


It may be simple, but any pointers on where to look at changing this behavior?


Maybe allowing the window to come to the foreground?
Maybe to "auto" bypass login errors so it does not hang?

Or any other ideas?

Thanks!

Patrick
  • Would adding (If its still valid) "MAP ERRORS OFF" at the beginning of the login script keep the login script from pausing on errors?


    ~Patrick
  • Guess I answered my own question, It does ignore the errors


    Is there anyway to keep the error and have them display to the foreground instead of being hidden behind the "Preparing Windows" Screen?

    Thanks
  • The overall behavior and issue you're describing here sounds like its
    occurring because the "Run logon scripts synchronously" group policy
    is set for Microsoft's userinit.exe.

    I don't know if its by Microsoft's intention or maybe by mistake, but
    there has been more than one report recently of the logon script
    command lines being "in the background" (behind the post-credential
    provider LogonUI display) when the "Run logon scripts synchronously"
    policy is set, and interaction was required. (e.g. Expired password,
    press the close button to continue, etc.)

    This policy does intentionally wait for any logon script command line
    (whether Client for Open Enterprise Server or anything else) to
    complete before userinit.exe proceeds to allow the desktop instance of
    explorer.exe (or the configured shell) to be started.

    But our experience in the past has been that the interactive user was
    able to see these logon scripts occurring, and not "hidden behind a
    LogonUI status screen."

    Its not clear that "just make the window foreground" applies here,
    because I don't believe these two things are even happening on the
    same desktop (in the Windows technical sense). LogonUI is showing on
    a secure pre-login desktop, and the logon script command lines are
    happening on the user's desktop. That would have to be investigated.

    But in the short term, try forcing the "Run logon scripts
    synchronously" policy to off. That's the "RunLogonScriptSync"
    registry policy available in HKEY_CURRENT_USER or
    HKEY_CURRENT_MACHINE. But of course if you have a group policy
    setting this, you'll have to remove it from the group policy rather
    than just changing the registry value (which will get overwritten).

    Alan Adams
    Client for Open Enterprise Server
    Micro Focus
    alan.adams@microfocus.com
  • Thanks for the direction,


    Will take a look and try the GPO Change. I will be out for a few days before I can give it a go.

    Thanks again!
    ~Patrick
  • Just following up (Took me a little while).

    Changing the GPO does seem to resolve the issue of the hang for login scripts and password changes.

    Not sure if it will create additional issues yet with other GPO settings for redirected folders, etc which I typically enforce before explorer is loaded..... we will see.

    ~Patrick