Forum Replies Created
Did you find the fix for this issue? I’m experiencing the same issue currentlyJune 29, 2022 at 7:24 am in reply to: RDP Shortcut Key (CTRL + Shift + Down) not working #107698
Thanks for the update, that’s the setting I have enabled thinking this would work, however the screen is minimizing on CTRL SHIFT and down instead of CTRL ALT and down and excel isn’t working as needed – I wonder if it’s a locale/keyboard layout issueJune 23, 2022 at 6:37 am in reply to: RDP Shortcut Key (CTRL + Shift + Down) not working #107687
Hello, I have tried that and checked over and none of those settings appear to affect this, they are for things like Client lock Menu and generally if they are disabled (which they are) then the commands are passed to the RDP session which is what I want in this situation but isn’t happening
ConfGen, do you have any ideas? I would like the Ubuntu device to utilise NTLM sign on to allow password resets and then the ability to sign into an RDS session broker via NLA.
A further update on my post- if i disable NLA both on the RDS host and on the RDS connection broker it works as intended. However, for security purposes i would like to be able to force the Wyse Thin Client to use NLA, how can i do this? As above, i have tried putting in NLA=yes onto the wlx.ini to no avail.
I have resolved the issue by using the Merlin image along with V2.1 rather than V3 of the Wyse USB Imaging software
What type of support agreement would this be covered under? I have recently purchased the Wyse but that would have just come with hardware warranty?
I also have the same problem using WTOS 8.4_110. I really need users to be able to enter their UPN and proceed without any warnings. Currently a warning pops up stating “SMB: Emtpy or blank domain not allowed” once the users presses OK it proceeds. Anybody know the fix for this?
Legend! That’s working perfect.
One to remember!
I must be going crazy! Is there any chance you could run me through your lab environment? This might be cheeky but is there any chance of a remote session to your lab environment for me to compare alongside mine?
Here’s a link to my wnos.ini https://lloydsbusiness-my.sharepoint.com/personal/alex_derbyshire_lloyds-ip_co_uk/_layouts/15/guestaccess.aspx?guestaccesstoken=ssPAZpnqhFb53vRmm%2b0gEohUYugYCAmJ%2b2uorIR%2bwU8%3d&docid=0bec37426a5c049848f95bd0bbabbf8b
I’ve now built 4 test labs based on the above designs and each one doesn’t play ball with the password being set to expire in AD. Would be great to see how your lab goes and then working out what differences i have
Thanks for your help in this.
I have now spent quite a lot of time on this fault and i’m still no where closer to fixing it.
I have setup two test labs of the following:
Test Lab 1 – 1 x WS 2012 R2 Domain Controller, 1 x WS 2012 R2 RDS connection broker / rdweb & 1 x WS 2012 R2 RDS session host
Test Lab 2 – 1 x WS 2008 R2 Domain Controller, 1 x WS 2012 R2 RDS connection broker / rdweb & 1 x WS 2012 R2 RDS session host
In both of the above test labs, without any changes made to the initial setups my Wyse device says RD broker sign on failed when logging on with a user that has the AD account password set to expire.
I don’t suppose you could try the above in a test lab for me?
I have spent the last 5 days comparing one domain another and for the life of me i can’t figure out the difference, in answer to your points:
– Firmware Version – 8.0_510
– BIOS Version – N/A we are using Wyse T10’s
– settings on the client – Wyse have confirmed my config is correct and i have copied the exact config to the site where the function isn’t working
– settings on the server – The core servers DC & RDS are identical
– are working and non-working clients in the same subnet? – The clients are on the same subnet as the server infrastrucure
– are working and non-working clients connect to the same DC? No, i have two separate sites. One site works and the other doesn’t.
– does this happen to all user accounts or only some? Is it client or user dependent? – All user accounts.
I’m pretty certain that the problem is down to the Wyse (on the non working site, as seen in the first wireshark image) not using SMB for authentication. On the site where it works (seen in the second image) the Wyse can be seen logging onto Active Directory via SMB authentication which in turns prompts the user for a new password if expired.
I have been through the domain controller policies and they are exact.
Thanks for the reply, I have been down the path of making sure the time is set correctly. Originally it was way off but I set it to use the same time server and the problem still exists.