@tobydox Not technical enough! Does not the entire internet work through TCP/IP? That's like saying that you can listen to the radio, as long as your radio can pick up the electro magnetic waves. Though I suppose the caveat "directly" offers some clues. I suppose you mean to suggest that the IP route is unobstructed, and not behind NAT or firewalls, right? Can you elaborate on the security risks or design paradigm a bit? Is all I have to do is forward the 11100 and 11400 ports?

Are you using key file or logon authentication? In case of logon authentication the bottleneck could be your AD server since it has to handle authentication requests from all Veyon clients at the same time (since each client checks the credentials of the teacher to authenticate the connection).

@erict: indeed the authentication key name check is too strict at the moment since it only allows word characters (0-9, a-z, A-Z and underscore). I just committed a fix which will also allow the minus character (https://github.com/veyon/veyon/commit/768feeb53c11d7a1f5e5fa4d8378d795c73cc1ad). It will be part of Veyon 4.5.7 next month. In case you build packages on your own, you can simply do this for the latest 4.5 branch. Besides that, importing keys via veyon-cli should work with the following command: veyon-cli authkeys import veyon_master/public public-key.pem

A red screen usually indicates authentication problems, i.e. either the authentication keys have not been setup properly on both teacher and student computers or logon authentication fails due to invalid credentials entered on Veyon Master startup.

@stuartr Interesting! Does it work with 4.5.5? I'm asking because we upgraded the 3rdparty OpenLDAP library in 4.5.6 so the crash might be related to that.

@tobydox I don't see where to add the parameter. I switched to advanced mode, under "service" I don't see any place to add a parameter under the VNC server section.

Hello Tobydox I now know the problem of error 87 ... but I don't know how to solve it yet ... the error occurs if I am connected in RDP on the machine on which I am installing Veyon. if I am physically connected to the machine no more error 87 problem. From the information I could read, this is related to graphics driver problem ... But you have necessarily done something about the graphics settings since until version 4.5.4.3 this does not pose a problem in RDP. Fred

Have you installed all available Windows updates? The AcceptSecurityContext call has been an issue with certain updates 1 or 2 years ago. As a workaround you can enable the Use alternative user authentication mechanism option in the Windows configuration page in Veyon Configurator after enabling the advanced settings (View -> Advanced).

FYI: the issue has been fixed in Veyon 4.5.6.

As written elsewhere already, nested AD groups are supported by Veyon 4.5.6 and newer.

Hello @tobydox I will try to explain it correctly. So for example from my PC I need to connect to remotePC1 on IPrange1 port 5901 and in the same time on port 5902 where port 5902 on remotePC1 is forwarded to second network card with IPrange2 to remotePC2 where is running VNC server on port 5900. With two or more VNC servers inside Veyon I believe it would be possible to make connection to both remotePCs where remotePC2 would act just as second screen of remotePC1. Now I am able to make only connection to remotePC1 or only to remotePC2 with forwarded port not for both at the time. The most simple solution for this would be to connect remotePC2 to the same IP range as my PC and remotePC1 via switch (problem solved all working fine). However in my situaton this is not and will never be possible. I hope this explanation is OK if not I will try to make it cleaner for you to understand.

Mixing operating systems, architectures (32/64 bit) and OS versions should work flawlessly when running an identical version of Veyon on all computers so I wonder what's the issue here. Does the behaviour change when installing the 32 bit version on a student computer (even though it should not be necessary)? Please note that you have to import the settings again after switching to the 32 bit version since it uses a different section of the registry for storing the settings.

@ovkempen Good news: nested groups are supported starting with Veyon 4.5.6

It looks like there's a problem with the Veyon Server interacting with the internal VNC server (the failed to set socket timeout(0) message is also suspicious). Did you enable multi session mode in the Service settings? If so, can you disable it? Otherwise, try to enable it for testing. Can you alternatively install UltraVNC separately and configure the Veyon Service to use an external VNC server? Just to make sure it's not a problem with the builtin UltraVNC server. I also wonder that the thumbnails do work and remote control isn't. Both functions use the same technique and settings for connecting to the computer. Is there any TCP connection limit configured client side?

Hello, actually the Demo mode should work across subnets as long as long as computers can reach another via normal TCP/IP routing (NAT is not supported). Unlike other products, the demo mode in Veyon does not work with UDP broadcasts but TCP connections. When starting a demo on a computer in a different subnet, does it display the IP address of the teacher computer properly? Restricting access to computers is possible through access control rules. These rules also allow you to e.g. restrict access to computers at the same location as the teacher computer. Other scenarios are possible depending on your environment and AD structure.