- This topic is empty.
-
AuthorPosts
-
May 1, 2012 at 5:10 pm #7300
Hi there,
We have a few thin clients (I think they are V10L’s) that will randomly get a a “Someone is trying to remote shadow… do you accept” prompt and it interrupts their connection with the server and needs to accept/deny in order to continue.
However, we have a lab full of R10L’s on Windows Server 2008, when they receive this prompt, it doesn’t interrupt that connection
We think the cause of it is Sophos on the server with a port scanning type of behavior (TCP 5900) which causes it to prompt. However, individuals on Sophos forums says that Sophos does not do this. Other AV like McAfee have caused problems like this.
We have a few questions:
1) Any way to prevent this from occurring (Will blocking inbound connections on port 5900 with Windows Firewall do it) without having to set up a wnos.ini config file. Or can we configure Wyse devices without setting up an FTP server?2)Is it the new Wyse thin OS that is designed so when it does prompt, it doesn’t interrupt the connection or the new server (I believe the V10L’s are on Windows Server 2003).
Thanks in advance,
BrandonMay 2, 2012 at 6:10 am #22196Normally the prompt should not interrupt the connection. Which firmware are you running on the V10Ls and which on the R10Ls?
That kind of configuration is only possible via wnos.ini.CG
May 9, 2012 at 6:00 pm #22300Wow, 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.
May 10, 2012 at 8:06 am #22306But, if it would has to do with GPO, why is it only affecting the V10L?
Looks more like a firmware issue on the V10L.
Do you have access to the 7.0_113 firmware for V10L? Can you test this?CG
May 10, 2012 at 4:36 pm #22326I 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?
May 11, 2012 at 2:45 pm #22337Which firewall? There is none on the client and blocking it on the server will not help.
Looks like upgrading is the best and easiest way to solve this.
Maintenance is very cheap.CG
May 11, 2012 at 4:18 pm #22345After 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.
May 15, 2012 at 7:11 am #22354You can add “Service=VNCD disable=yes” to your wnos.ini to disable the prompt completely.
CG
May 15, 2012 at 6:00 pm #22365Thanks 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,
BrandonMay 16, 2012 at 7:32 am #22366You can use ftp, http or https to read the wnos.ini.
sftp is not supported.
Create a folder called wnos in the ftproot. Copy the wnos.ini to that folder.
Enter servername or IP address of the ftp server in the Fileserver field on the client – no folder – no suffix – no prefix- nothing more.
Reboot the client and you are done.
Very simple.USB storage for the wnos.ini is not supprted either.
CG
May 17, 2012 at 5:58 pm #22369I 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.
May 18, 2012 at 8:06 am #22371Can you post your wnos.ini?
CG
May 18, 2012 at 5:46 pm #22373Keep 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.
May 20, 2012 at 7:50 pm #22379It may be the way the post is displayed, but make sure you have no spaces after each in the RPD section (the page is showing a space after each one)
Regards
James
May 22, 2012 at 12:43 pm #22380Does this also happen when you connect to that server from a Windows PC with mstsc.exe?
CG
-
AuthorPosts
- You must be logged in to reply to this topic.