NOTICE: Significant community changes coming soon
The header menu and the home page on our community will be changing soon. Get more information HERE.
New Member.

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?


Labels (1)
Tags (1)
5 Replies
New Member.

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

New Member.

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?

Micro Focus Expert
Micro Focus Expert

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
New Member.

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!
New Member.

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.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.