Highlighted
Kim_Nykv Contributor.
Contributor.
817 views

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?

 

Sincerely

 

Kim Åmark

IT-technician

Nykvarn Municipal, Sweden

 

 

 

Labels (1)
Tags (2)
0 Likes
20 Replies
benjaminhare Respected Contributor.
Respected Contributor.

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

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.

0 Likes
Kim_Nykv Contributor.
Contributor.

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

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.

0 Likes
benjaminhare Respected Contributor.
Respected Contributor.

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

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.

https://support.microfocus.com/kb/doc.php?id=7006626

0 Likes
Kim_Nykv Contributor.
Contributor.

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

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

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

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

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?

 

0 Likes
Kim_Nykv Contributor.
Contributor.

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

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.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

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

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.

 

 

0 Likes
iliadmin Valued Contributor.
Valued Contributor.

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

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.
0 Likes
iliadmin Valued Contributor.
Valued Contributor.

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

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.
0 Likes
iliadmin Valued Contributor.
Valued Contributor.

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

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
0 Likes
hschoene Super Contributor.
Super Contributor.

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

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.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

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

Have you ever traced this?

0 Likes
hschoene Super Contributor.
Super Contributor.

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

no, I saw this this on multiple installations in the last year. When I add the DNS-Record, it works. In earlier times and installation  i had every time configured SLP with one ore two DA's on the servers and on the clients with dhcp, but in small environments its so sufficient.

0 Likes
iliadmin Valued Contributor.
Valued Contributor.

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

Unfortunately we are very small and do not run an internal DNS server.

I do have SLP setup with 2 DAs, so it sounds like that should be working to prevent this delay.  The current SLP and DAs were very recently configured by Micro Focus  support after we lost one in a server down (hardware) issue that messed up some other stuff. While troubleshooting logins (they were working but not the mappings) they recognized the issue was related to the downed server and re-did the SLP config to point to another server and build in redundancy by adding another SLP DA and made sure the times were all syncing the same.  That seemed to fix the mapping issue but had no affect on the login problem

Again, it is only a problem with the latest Client for Open Enterprise Server 2 SP4 (IR12) ; I have 6 other system in my office and 3 in the server room all running the IR11 or earlier clients and none have this error.  It is only my two IR12 clients that seem to show this issue. So I haven't rolled it out to any other systems as a result.

0 Likes
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.