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?
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
- 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.
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.
Add an A-Record to your DNS with the treename. nslookup against the treename, with or without dns-domain, should work. You can add multiple DNS-records. This it an easy way for flat environoments.
Another way is to configure clients with an SLP-DA, for a complex environments.