- This topic is empty.
-
Posts
-
Good afternoon (Pacific Time…)
We are currently doing a demo on a Wyse V10L thin Client. We plan on (Hope to)simply booting them to the network (Active Directory domain) and allowing DHCP to assign IP addresses. Our desire is to have them connect to our Network Load Balanced terminal Servers (3) via RDP and be able to go straight to work. no ini files, etc. Out terminal servers all have 2 NICS, one for load balancing communication and one for network communications.So far we can connect directly to one TS IP with no problems and we stay connected until we log off the session.
If we try to connect to the load balanced TS IP we get connected and then 20 seconds later, either the terminal server or the Wyse terminal drops the connection and we end up back at the Wyse Desktop connection manager. Not sure which one is doing the “dropping”.
Does Wyse have a problem with MS Load balancing or did we miss something? Seems you should be able to boot out of the box and get connected via RDP. We are also testing an HP thin CLient and it does work using the FQDN of the load balanced TS farm.
We registererd the device in DNS and are able to ping out and back in, no problems.
Any help or suggestions would be greatly appreciated. This is our first Thin Client attempt.
If I can offer any more information please feel free to ask.
Thanks,
DDS
Hi,
I have used WTOS with NLB before without issues so it should work. Ideally use a .ini file for the setup but for a demo of one unit the GUI should be fine.
In my testing in the past I have used a FQDN for the host= connection and this worked fine for NLB or DNS round Robbin.
Can you tell me what firmware you are using? Maybe there is some kind of new bug, the only way to tell would be to do a packet capture and see what happened when the connection dropped. This I know is too much work for a simple demo.
So try this:
– Let me know what firmware you have
– Check so see if RDP encryption is on or offMaybe we can quickly test dropping back a version of firmware to see what happens,
Cheers,
-TTTT,
Thanks for the reply. As mentioned I am quite new to T Clients, but need to evaluate them. Our Hp demo as mentioned worked out of the box the way we wanted it to. I suspect it might be because it has the embedded XP Pro OS on it.
Version of firmware in the V10L is 6.0.1_04. We do have it setup with FQDN as host name, but will check to be sure there are no typo’s, etc. As mentioned, it does connect, just won’t stay connected to NLB IP. It is ok on the Non-NLB IP though. I will also check the RDP encrytpion status and get back to you.
I have a conf. Call with Wyse support scheduled for 11am Pacific time today so maybe they can also shed some light on it. I appreciate your taking time to answer. Nice to see knowledge shared.
Thanks,
DDS
TT,
All of our terminal servers have the same setting for encryption. They (including the NLB server settings) are set for Client compatible/RDP security level. No certificates have been loaded.
So if I can connect to a single TS IP and maintain a session, should I not be able to connect to a NLB session and maintain it if encryption settings are the same? (RDP V2) It seems (remember I am very new to this…) that in a single session the 2 NICs talk back and forth as they should but in a NLB session it is as though once connected, some network miscommunication occurs and dumps the session. Not a wildly technical explanation but that it what seems to be happening.
FQDN was correct and does not work. As mentioned, single IP of nonNLB server does work.
Do you have a “primer” on how to setup the .ini files on a server if we decide to try that? I know the sys admin wants an out of the box connection but maybe that won’t be possible?
Thanks,
DDS
Hi,
It sounds like you have everything correct to me. My suggestion would be to test and older version of firmware as I have seen NLB work without issues. My thought here is that if we use known firmware that works we can isolate if its environmental or not.
Take a back up of your firmware and then download the older 5.2 code from the Wyse web site and see how this goes. If the issue goes away then it looks like a bug. If the issue remains maybe its environmental.
Also, one other last thing to try before you downgrade the firmware. Go to the Start – System Setup – Network Setup – options tab and in the TCP Timeout box enter a value of 4.
Cheers,
-TTTT,
Thanks for the reply again. We worked with a Wyse engineeer yesterday for a while and upgraded the firmware to 6.1.0_06. We also set the unit to static IP. None of the above did anything to change our situation. Wyse says they are moving this issue to the “inside” to dig more deeply into it.” We shall continue to work it from out here though as I would like to resolve it.
I will see what happens once I set it to a TCP/IP timeout=4 setting. If that makes no difference I will try the older version of the firmware. The Wyse engineer did make a comment about “maybe the bug is back”….
I will let you know how it goes. Appreciate your continued assistance.
DDS
TT,
I changed the TCP/IP timeout to 4. No change. I downloaded the ver 5 firmware and was unable to load it. System log says “Firmware 5.2.0_35.05 is too old to ensure hardware compatibility. (Hitachi processor)”
Is there a way to force the firmware downgrade?
Thanks,
DDS
Hi dds,
there is no way to force a downgrade.
I had a similar issue a while ago. My customer was using MS Session Directory and his sessions got disconnected after a while. I got a fix from Wyse after some days which corrected this. It was 5.3.016. I know this is of little help as you cannot downgrade.
Maybe you should ask Wyse for a unit with that firmware on it and test it.
Are you using Session Directory at all?Cheers
CGHi CG,
We do not use Session Directory. We were hoping for an out of the box solution that we could just plug into the network and access our TS servers via NLB. We “purchased” the box from Lenovo on a 30 day trial. We are currently working with Wyse to try to find a solution, no joy so far.
I suppose I could ask them to ship me a box with a previous Wyse OS on it to see if it would work. I guess it depends on how badly they want to resolve it. We are not destined to be a big Thin Client site, maybe 30-40 units. But if we are having an issue with NLB, I suspect others with our same setup may have one too. Knowing that HP Thin client works right out of the box makes me think Wyse would want to resolve it.
Thanks for the reply. Every little bit helps.
DDS
I am pretty sure the Wyse Xpe based units (like the HP ones you are testing) will work perfectly also.
Let’s hope Wyse can fix WTOS also.Yep, I agree this needs to be fixed. Now you have a Wyse engineer on it I am sure it will happen (maybe not in time for you)
I can say I have definitely had this working on older code so it sounds like a new issue with the latest code. Bummer you had to be the one to find it but you have handled it really well letting the vendor know. Hopefully there will be a resolution soon. Post back if you get a result,
Cheers,
-TTTT & ConfGen,
Thanks to both for your replies. I have contacted Wyse again and they affirm the bug is present in the new code in the Wyse proprietary OS. They also told me that the embedded XP OS or the CE OS should work properly with NLB. I assume this is correct as we have tested an HP Thin Client that has embedded XP on it and it works flawlessly. The engineer at Wyse said she would post back to me when they found the resolution to this issue. They are very interested in getting it resolved.
We may see about getting a V90L demo unit from Wyse to see how well it works. If I hear of anything positive from Wyse I will try to get it posted back here.
Thanks again for the replies.
DDS
Update on V10L OS.
Wyse emailed back today via our vendor stating that they will probably send an engineer to our site to see the problem first hand in our operating environment. Sounds like they are getting serious.
I will advise if they find anything (assuming they show up).
Thanks for the update, let us know what the result was and if a fix was required,
Cheers,
-TT
- You must be logged in to reply to this topic.