Windows 10 does not always find tree or server during login or map the login script.

During login with Client for Open Enterprise Server 2 SP4 (IR12) on Windows 10 64bit (1703-1809) sometimes it cannot find the Tree or Server. Especially if you are quick to login, like as soon as you possible can during a startup. And sometimes if you do the really fast login, no network drives are mapped. But, if you wait a min or so, windows gets things started and it works.

Is there a way to stall the login until Windows is more ready?

We have the Local GPO set to wait for all networks services before attempting logon enabled.

We are also getting some startups without the OES client, even though it is installed, and then a restart is needed to solve that. Mostly, it's a very strange behaviour.

Anyone else seen this or have any good tips for help?




Kim Åmark


Nykvarn Municipal, Sweden




  • Hello, Kim.  Yes, I am currently dealing with this very issue.  I am still in the process of deploying Win10 and this issue has been a major hurdle.  Here are our workarounds:

    • Wait five minutes AFTER the login prompt presents before attempting to sign on
    • Computer Only Logon  → Wait until the desktop loads →  Logoff →  Observe you are now able to sign-into the OES client without problems

    Our environment:

    • OES 2015SP1 servers
    • Win10 1511 (Build 10240)
    • Duplicated this issue with OES Clients 2 SP4 IR7a, IR8, and IR10

    It's worth noting that—at least in our environment—we are only seeing this issue on devices with traditional HDDs; those with SSDs do not exhibit this problem.

  • 5 minutes seems long, especially fora a user that does not know patience.

    But doing a computer only login and then logoff, for a new OES login does work, we use that as a"fix" but still not ok for the users to have to do that. They get annoyed and it makes a lot of tickets for us.

    We have OES 2018 servers and ZenWork.

    And most Win10 are 1803 or 1809 builds, now. But had it in previous builds too. 

    Going to Client ir 10 help with some issues, but not all.

    I have searched for a way to delay the start screen from showing, but to no avail.

  • Take a look at the workaround in KB7006626.  It did not resolve the issue in my own environment, but might be worth trying, if you haven't already.

  • Yes, that we have already done. It does not really seem to help much at all.

  • Does it do any better if you specify an ip address instead of a tree name?

    Did you try with any kind of firewalling disabled?

    Have you ever grabbed a trace of a failed login attempt?


  • Yes, if you specify one of the OES servers that has the eDirectory, it works better, but not all the time.

    Could that be something weird with our DNS?


    Windows firewall is turned off, no other installed.


    No, we have not tried any trace things? Not sure how to do that.

  • Seems there are several things working together to mix up the issues you're facing if logging in via ip address doesn't completely resolve them for you. Generally you should look at your client config first. Wipe away or at least unbind anything you don't need. If you don't really need "client for M$ networks", server service and all this pretty useless stuff: remove them. If you're not using IPv6: bye. Same applies to the OES client itself: if you e.g. don't use SLP: untick it. IF you use it: take care it's configured properly on both servers' and clients' side. "Bad address cache" and "Bad name cache", while very useful in and out of themselves, can lead to funny situations if e.g. a ressource shall be resolved and the physical part isn't fully up yet. In this case, despite of the fact that the physical part might be ready in the meanwhile, your box wouldn't even try to connect to / resolve the ressource unless the corresponding cache has timed out. VERY popular issue in the XP / ZfD7 days. You'll might want to temporarily disable these features, just to see whether this makes any difference. Check that the switchport is configured as a hostport or (for testing) plug a "dumb" switch in between.

    If you want to trace this (and that's the preferred method), you'll have to do so concurrently on client and servers. You'll have to configure a monitor port for the port of the client in question for a clean startup trace.



  • I've been having the same issue, with Windows 7 as well since rolling out the Client for Open Enterprise Server 2 SP4 (IR12). If the client waits 3 minutes or more, the login to the network is always successful. If the client logs in locally first, then to the network, it always works. The previous client didn't do this. We have the network card configs hardened to disable unneeded services and protocols; eDirectory servers are 9.03 on OES 2018 and 8.8 sp8 on OES11. Windows 10 clients are 1803 thru June patching. Windows 7 systems are fully patched as well. SLP is configured properly (in fact it was just reconfigured by Micro Focus during a support call and those changes made no affect on this issue). It's just weird. I have postponed further rollout of the client until this is figured out. You're right in that I cannot get people to not immediately login.
  • I did just turn off the bad cache item in the client, and will see if that helps. If not, I'll try the TID info and let you know.
  • Ok, so just as an FYI in my case: turning off the bad cache didn't seem do to anything. I then followed TID 7006626 and added the suggested registry key. I thought the 900 second setting was way too high; I set mine initially at 190 seconds and that made me wait about 58-60 seconds and then it gave me the "Welcome" message. So I whittled it down from there and have it set at 120 and it won't throw the error and the wait time is still about 58-60 seconds for the "Welcome" to show. So to me it's really 6 of one, 1/2 dozen of the other with this workaround. Either way (whether I login immediately upon boot up and then I login again after the error w/o the registry key OR I add the registry key and login immediately and wait 60 seconds) the time to login success is essentially the same. Val