@ltsepp Found the problem.Wrong settings under object attributes User = sAMAccountNAme Group = member Computer display = cn computer hostname = cn That worked for me

Unfortunately we do not have packages for Redhat 8 (since CentOS 8 is EOL) but I would recommend building an RPM file manually as described in the README.md file in the sources.

I guess you enabled Multi session mode in the Service configuration page. When enabled, the Veyon Service uninstalls the Interception driver since it's known to cause problems in terminal/remote desktop server environments. If you do not need multi session mode, simply switch back to Local session mode. Otherwise the Veyon Service has problems with accessing the Interception driver so it tries to reinstall it manually.

Simply enter the password of your user account. If you configured a different (domain?) account for accesing the clients, you can change the password of that user in your AD/LDAP server management UI.

I guess it's either the LDAP bind password or the external VNC server password which is stored in the configuration and likely hasn't been set before. You can simply ignore that warning unless you have actual problems with configuring one of these passwords.

I'm sorry for the problems you had with managing your network objects through the CLI. I guess veyon-cli didn't identify the location(s) properly in which to import the computers. It would be interesting to see the output of veyon-cli config get BuiltinDirectory/NetworkObjects before and after the import. May be you can reduce the import to a minimal case with just one entry? Next I would also recommend to clear all objects before the import.

Have you tried enabling the Query nested user groups (supported by AD only) option in the Advanced LDAP settings tab? When enabled, Veyon uses the LDAP_MATCHING_RULE_IN_CHAIN search filter rule which tells the server to also return indirect members for a certain group. Access control should then allow access also for indirect memberships. For debugging this, you can change the Veyon log level to Debug (config page General), click on the Test button in the access control page and search for lines containing AccessControlProvider in C:\Windows\Temp\VeyonConfigurator.log – there should be a line with a list of all groups of the user entered in the test dialog.

I guess most of the messages are related to outdated/mixed Veyon versions on master and student computers. I recommend updating all of them to 4.7.4 and issues such as ping should be gone (4.7 doesn't use the ping process any longer for example). We have similar reports of users which can't get the demo mode work reliably but we're working on it, especially regarding the performance and network bandwidth.

For some reason the (Ultra)VNC server inside veyon-server seems to crash when accessing/processing your display. It's hard to debug that but you could try playing with the VNC server options in the Service configuration tab in Veyon Configurator. For doing so switch to the advanced view in the window menu and select Builtin UltraVNC in the VNC server drop down menu. May be changing the options Enable Desktop Duplication Engine on Windows 8 and newer or Enable capturing of layered (semi-transparent) windows have a (positive) impact on the behaviour. Also make sure to update to the latest version of Veyon (4.7.4).

How do you launch the websites? Using the context menu or using the global toolbar at the top?

This sounds like an authentication issue client-side. May be your AD server prevents too many logins for the Admin account in parallel? When accessing clients, every client authenticates the accessing user, so if you have 30 clients, the AD server will see 30 login/authentication requests for the Admin user. In that case check our AD settings or try using the key file authentication. Are you using access control groups or rules?

On Zorin OS you should be able to use our Ubuntu PPAs so there's no need to build and install Veyon manually. Even after installing the veyon package, you can simply remove /usr/bin/veyon-master and /usr/share/applications/veyon-master.desktop manually. If you performed a manual build and installation, you can remove the corresponding files in /usr/(local/)bin/veyon* and the veyon directory /usr/(local)lib/*/veyon. You can also install the DEB and remove it again which should remove the files as well (unless you installed in /usr/local).

Helllo @Neetie you can choose between obtaining a license for the entire schole school/site or licensing a certain number of computers (attractive for very small schools with just one lab). In your case I would recommend buying a school/site license. Just send us a quotation request using the form on our website (https://veyon.io/en/addons/#inquiry) and we'll send you a quote. Based on that quote you can easily place a purchase order.

@fcortes as it turns out my master on zorin was using an old version of veyon I removed the old version I added the repository listed on download webpage and I re-installed using apt-get install veyon and now demo works fine.

Hi, I've just read in the Add-ons section of Veyon's web site: "While the LDAP Basic plugin offers all functionalities required to integrate Veyon with LDAP/ActiveDirectory servers, it's however limited to a single server/domain and flat object hierarchies. The Veyon LDAP Pro add-on is able to fetch network objects from multiple servers/domains. Also location hierarchies in your LDAP directory (buildings, floors, rooms etc.) are represented 1:1 in Veyon Master. Especially central support teams for school districts love having all computers of all schools in one network tree." Maybe that's the answer, change to LDAP Pro.

OpenSUSE Tumbleweed is the first distribution which we build Qt6-based packages so there may still be some compatibility issues. Thank you for sharing the log file entries which allowed us to find and fix the issue quickly. Please find an updated package at https://github.com/veyon/veyon/releases/download/v4.7.3/veyon-4.7.3.6-opensuse.tumbleweed.x86_64.rpm Let us know if you encounte rany other issues.

@lyc-appert-44 Visiblement on est tout les deux en France donc je vais répondre en français Ce matin le problème a disparu. Je suis sur un serveur Sambaedu. Je n'ai pas fait le test de ping par le nom la semaine dernière. Il se peut donc que cela soit bien la cause. Certe je fais une réservation IP par PC, mais sambaedu lui derrière utilise des taches cron pour la synchronisation AD DNS etc, hors quand j'ai eu le problème je venais juste de faire l'intégration de ces postes. Merci pour ta réponse. Bon courage

@ctasd Do you have permission to write to the machine registry? Have you tried to right clic on cmd.exe and run as administrator?