Forum Replies Created
-
Posts
-
Thanks for the suggestion, unfortunately it didn’t fix the issue. At this time, we have already conditioned all of the users to log in using domainusername and it’s not that high on the priority list.
All questions regarding WTOS answered 🙂
I will eliminate the spaces and see if that has corrected the solution! I would think though even with the spaces, it would input the correct information but just with a space at the end, but I could be wrong.
It doesn’t happen for our windows CE thin clients or from the remote desktop connection built into windows(it remembers the last domain the user was pulled from, even if we put other user it defaults to the correct one)
When we use the NLA login (where it prompts with the wyse window to login) it inputs the correct domain, but when a user logs off (since we have it to connect after disconnect) it automatically logs in the same user without prompting for the credentials again. So we have disabled NLA authentication from the server. I should clarify, we are using the server to log in.
Keep in mind, we were just testing things out, this had no intention on disabling vnc requests… yet:
;*************************************************************
;* *
;* This wnos.ini file was generated with the *
;* Configuration File Generator 6.3.05 *
;* Copyright by Thomas Moellerbernd *
;* *
;* https://technicalhelp.de *
;* *
;*************************************************************
;*************************************************************
;* General 1 *
;*************************************************************
autoload=2
AdminMode=yes Admin-Username=OGCMOHCEMGAGMN Admin-Password=OGCMOHCEMGAGMN
Privilege=None
;*************************************************************
;* Network *
;*************************************************************
SignOn=No
;*************************************************************
;* RDP *
;*************************************************************
;
;- RDP Session 1 -
;- Each line but the last must end with a '' -
;
CONNECT=RDP
Host={IP ADDRESS of SERVER}
Description="ARC Test"
Domainname=scslab
LocalCopy=no
However, upon RDP into the server, the domain it tries logging into is: UEORGNET (which is the domain of the server). It suggests that the host is correct as it wouldn’t even be able to establish a connection if it weren’t.
I got the FTP server to work, the problem seems to be that the FTP server the company provides is an SFTP server and it won’t make the connection.
However, one question maybe you can help. When we connect to the windows 2008 R2 Server through RDP, no matter what we set the domain to log into, it also uses the domain of the server. So if we wanted to pull people from a different domain, they first have to type DOMAINuserID. Any solutions?
We go to properties and set the domain, but it’s not actually making any changes.
Thanks again for the reply,
Sorry for the little questions; there is no way to store the configurations locally without having to create an FTP server? Anyway to modify the firmware to incorporate these settings? Can we plug in a USB drive that has the Wnos.ini config settings (maybe a configuration option to store locally) then sequent boots to keep these changes without the USB drive?
The main reason why we have objected to using an FTP server is because we couldn’t get it to work. We have a an FTP server and we spent weeks trying to get it to work. We were using a range of thin clients ranging from old neoware ones to the newer wyse R10L and just couldn’t get it to read from an FTP server (of course the neoware ones were not trying to read a WNOS.ini as they used neolinux OS). Is it possible the reason why it was not working was because it was an SFTP? Did they require an anonymous login?
Is there a way to do this without FTP maybe by a network drive. Could we create an account that can be used by the thin clients:
FileServer Path: \ServerPath
Username: DomainThinClient1
Password: PasswordWnos.ini located in \ServerPathWNOSwnois.ini
Where the user from a domain ThinClient1 has access to the folder?As you can see, my knowledge about the ThinOS is not the greatest.
Thanks in advance again,
BrandonAfter some research, as you probably know, VNC requests through port 5900 is what causes the remote shadow prompt. Whether it’s a legitimate request or some other software on the server (I believe the requests are coming from the server) information sent to port 5900 TCP will trigger it.
Since we are running Windows Server 2003 on these few check in clients and under the assumption that they are only prompted when they have a session on the server, then we were thinking blocking inbound connections to TCP 5900 on the windows firewall would prevent the clients from receiving any activity on 5900 as long as they are connected to the server (which is the only time they would receive the remote shadow prompt).
However, we are not experts at thin clients; it’s could be the case that the TCP 5900 connections are managed by the Wyse thin OS and even blocking within windows cannot block 5900 from the thin OS.
The issue is that it happens to the thin clients one at a time, it doesn’t happen to all of the thin clients at the same time which is weird.
If I had to guess, it’s that it maximizes the bandwidth to be used on the wireless interface kicking off the resources used to connect to the server itself. Maybe it’s how resources are allocated in the newer builds.
I wish we had access to newer firmwares; but we do not have the maintenance plan with Wyse to be eligible for firmware upgrades.
I’m leaning that it’s the firmware. I had set the thin client to automatically connect to the server once it disconnects, I found the remote shadow prompt up and it not connecting to the server automatically until an action was taken. I doubt it’s anything hardware related as this would be handled by the firmware.
So looks like we either start setting up an FTP server with a configuration or buy a maintenance plan to get upgrades? How about blocking inbound/outbound port 5900 tcp with Windows Firewall?
Wow, the Wyse forums fail in comparison to the FreeWyseMonkeys forums. That was an amazingly fast response (considering I haven’t heard anything from the Wyse forums yet).
I had a feeling something like that can only be altered through the configuration file.
Here is our setup: We have 4 computers that are used to log in and out of an application. Connecting with the windows server 2003, it loads the sign in/out application in full screen. The only known way to disconnect from the server is if someone presses ctrl alt delete and clicks log off on the pop-up screen. Occasionally we will find on one of the monitors to have the remote shadow prompt and the session to be disconnected. We know that no one is pressing ctrl alt delete then selecting log off as the average person wouldn’t know to do that and anyone on one of these thin clients for more than 10 seconds would be seen as suspicious.
However, there is no pattern to what causes it to disconnect (maybe something in group policy for inactivity)?
The V10L’s are on 6.3.0_12
The R10L’s are on 7.0_113It’s only the V10L’s on 6.3.0_12 that are having this issue.
If you are sure that it has nothing to do with the remote shadow prompt, then we can investigate deeper into group policy to see if something there is disconnecting the sessions.
