You can try to set up https://docs.veyon.io/en/latest/admin/access-control-rules.html and play with the conditions regarding computer locations. This way you can prevent users easily from accessing computers at a different location (room).

Problem solved. Username is Student with no password. A password is not required when using key file authentication. Computer name is used to identify machine.

The upgrade works with a caveat or two. On the Veyon Master machine, it lost all of the location and PC data. Having a .csv file on hand with that info made it almost painless to get them back. The "almost" is due to misinformation in the Veyon-Cli help information:

veyon-cli.exe networkobjects help import

show this as one of the examples:

* Import simple CSV file to a single room: networkobjects import computers.csv location "Room 01" format "%name%;%host%;%mac%"

The above is exactly what I needed to do but it gave an error saying it failed to parse line 1. With no additional info available, I presumed something was wrong with my file... "Does it need a header row?", "Are certain keywords needed in a header row?", and other questions like that came up. After a few experiments, none successful, I noticed the ";"s in the format section of the sample line - changing those to to ","s fixed the problem:

networkobjects import computers.csv location "Room 01" format "%name%,%host%,%mac%"

And for those wondering, a header row in the import file is seen as data, so a new PC is created using the info it contains.

In the old config, I was using keys for authentication. The old keys still work, although I had to configure the Master and Clients to use key file authentication, as they both defaulted to logon auth. As I recall using the old keys may not have been possible back in the 4.1 days, which is what prompted my question here in the first place. It seems that if I'm remembering correctly, that has been addressed and fixed.

So the short answer to my question is "Yes". I hope this helps some else down the road...

~bd

Hi,
It is possible that the italk service in not uninstalled (conflict with veyon service) or another old vnc still running.

@clash Hi,
I do experience the same issue with the standard VNC with windows 7 64bits since veyon 4.2.4 and now 4.3.0.

Thank you

Hi,

If you're talking about tests in veyon-configurator : no, they don't.
But the conf is exactly the same as in previous version (I used the same file, imported with veyon-cli).
That's why I asked about what could have changed in veyon's way to interact with Active Directory between the two versions.

That's an interesting observation! Which version have you used before? It's likely caused by too much data being fetched from the LDAP/AD server, caused by either non-optimal LDAP settings in Veyon or too many computers in your directory which Veyon tries to load. Can you try to drop the settings for the MAC and/or hostname attribute?

As indicated correctly you don't need AD or LDAP for Veyon to work. Using key files is the right solution here. Is the private key file readable by the user of the Veyon Master application? Maybe https://docs.veyon.io/en/latest/admin/troubleshooting.html#authentication-settings contains some additional hints for you. Are the key pair IDs identical on all computers?

We recently completed the documentation (https://docs.veyon.io/en/latest/user/features.html#run-program) to include the information that you can simply move the mouse over the according item and press the Del key.

Please make sure the input Interception driver is installed properly. In doubt try to run "install.bat" from the "interception" subdirectory in the Veyon installation directory manually with administrative privileges.