Hi,
I finally did it "by hand", without using veyon-cli command :
Create directories in /etc, give required rights to key files, modify conf keys...
If it can be usefull to someone :

On all computers (teachers and students) :
veyon-cli config set Authentication/Method 1
veyon-cli config set Authentication/KeyAuthenticationEnabled True
mkdir -p /etc/veyon/keys/public/mykeyname/
cp my-public-key-file.pem /etc/veyon/keys/public/mykeyname/key
chmod 444 /etc/veyon/keys/public/mykeyname/key
chmod -R 755 /etc/veyon
chown -R root:root /etc/veyon

On teacher's computer only :
mkdir -p /etc/veyon/keys/private/mykeyname/
chmod -R 755 /etc/veyon
chown -R root:root /etc/veyon
cp my-private-key-file.pem /etc/veyon/keys/private/mykeyname/key
chmod 440 /etc/veyon/keys/private/mykeyname/key
chown root:myauthorizedgroup etc/veyon/keys/private/mykeyname/key

(.pem files were generated and exported in veyon-configurator, and "myauthorizedgroup" is the user group for users authorized to connect to veyon-master and remote to classroom computers)

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

@tobydox The session type for Ubuntu 18.04 is X11.

typing "echo $XDG_SESSION_TYPE" in the terminal returns "X11"

@tobydox said in veyon-server doesn't start (Qt::AA_ShareOpenGLContexts must be set before QCoreApplication):

-noshm

Wow -- I think that's the solution! I just added this option and restarted the Client -- now "htop" shows a running veyon-server ... I can't test it in our productive environment at the moment but it looks good so far! Thank you!

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.

The easiest way to disable access, regardless of the operating system is to simply remove the network interface hardware from the computer, or disconnect the computer’s LAN cable or wireless network.

@tobydox Thank you very much.

I don't know if this helps ... but when I start "veyon-server" as a login-Script I get this message: