Teamviewer Host Old Version

0 views

Skip to first unread message

Imelda Matchett

unread,

Aug 3, 2024, 11:12:43 AM8/3/24

to senterpdestmes

Same issue as here. We were using an image but one engineer wasn't familiar with host so installed full TV instead. Due to security issues RDP is disabled even though devices are on the domain (not necessarily at the same site)

Bump (apologies if this against the rules). I'd imagine a lot of admins aren't on the remote sites. If an engineer installs full version and sends you the credentials you cannot change to host remotely.

Please know that it is possible to uninstall TeamViewer Remote to install TeamViewer Host remotely; however, it isn't possible to do it unattended - someone must be on the other side to accept the connection via TeamViewer QuickSupport.

I am preparing the upgrade from TV 15.4 to TV 15.8 and we will do it with a batch file. Is there any way I can determine if I have a host or a full version installed using any kind of command in the batch file?

After some discussion, people changed their minds... just a quick question, if you know the answer... I prepared a test policy that allows updates within the main version and will check weekly. Can I force the update from the client? If I use "Help" - "Check for new version", it does not work.

Once you enable the policy for weekly updates, it means that an update will be triggered within the next week. It can be at the same say, but also in the worst case 7 days later. There is, unfortunately, no possibility to trigger it immediately with a manual action.

when I configure our Hosts with version 14 of Teamviewer by default is enabled option with random passwords. In the earlier versions (for example 12) there was no this option by default.

I can't see how to disable this option in our hosts by default.

If you want to disable a random password, you have to make sure to define Easy Access or a personal password within the reg.-file you deploy in order to be able to connect to the relevant device. Afterwards, no password will be displayed in the Host application.

thanks for fast reply but like I wrote I don't want to create policies for this. Please read again what I wrote. In hosts by default there was always no random password. On the instalation step I always type my own password. Everything was OK when I using Teamviewer hosts version 12, problem started when I choose new 14 version of app.
Here is what my host is configured (there are no many options).

So here we go again. Unfortunately my TeamViewer 10 post was incorrect and I did not test the deployment enough. Using those instructions you will have trouble putting the password on another system as well as issues with the helper. TeamViewer 11 is of course no exception. It seems TeamViewer doesn't seem to understand how deployable software should work and there continues to be no improvement to the software. After a lot of testing, I have been able to make it somewhat deployable.

Are you ready for this process? It is quite the doozy and unfortunately is not an ideal model for a software that is cross-platform and labeled as deployable and customizable. Let's begin by highlighting this process:

Create com.TeamViewer8.Settings.plist with the settings we like initially such as the remote control password, settings password and turning off updates
Install TeamViewer Host (Version 8)
Install TeamViewer Host (Version 9)
Run a post install script that will perform the following
Unload the Launch Daemon for TeamViewer to run as a service
Cleanup TeamViewer 8's folder as it is now just in applications as TeamViewerHost.app
Convert the TeamViewer 9 Plist to XML so we can manipulate it
Read in the TeamViewer 9 Plist as it is created by the setup
Set some additional settings that may not have carried over from version 8
Load the LaunchDaemon so the password is converted.
Run a Preinstall script that will copy the newly converted password with "special" encryption to the new plist for version 11
Install Version 11
Run a post install script that will set the custom attribute for your custom module from the website and run the application before we apply customization of the Main Menu in the Menu Bar
Finally, apply the MainMenuHost.NIB file that will remove the pieces we want from the menu that appears by clicking the menu bar item

This is obviously no easy process but thankfully we have Munki (or insert software deployment service here). With Munki, we will require that when we install TeamViewer 11 that 8 and 9 be installed first. So let's get started.

First we will install TeamViewer version 8 and utilize a pre install script. This will allow us to set our configuration settings before TeamViewer launches which will allow the unattended host password to be set. I have gone ahead and scripted it in python so go ahead and use the script below.

Remember to get SecurityPasswordAES and OptionsPasswordAES you will need to do a manual install on a system and use OS X's built in defaults to read out these binary values. (Of course you will need to remove the spaces)

Now that we have TeamViewer 8 setup let's go ahead and get 9 ready for deployment with our script as well. Once imported into your repo you will want to go ahead and add the script below as a post install script:

Still following along? Good! Now we are going to finally install the version that we want. TeamViewer version 11. Once imported into the repository we will use a pre instal and post install script in order to achieve full deployability. Check below for those scripts:

Now that we have all the scripts in place, Munki will install in order, version 8, version 9 and finally version 11. You could use this same process for version 10. The last step is to insert our special MainMenuHost.NIB file. Thanks to a GitHub project located at I was able to look at the actual NIB file for TeamViewer and then export and modify it. To modify a NIB file you will need to use xCode however if you are lazy I have gone ahead and attached my modified NIB file to this post for your use. You can download it here. My file has removed the following from TeamViewer:

Finally the moment of truth - testing. My extensive testing with these scripts has shown when setup in Munki correctly that Munki will install all three versions of TeamViewer and the customization. Upon completion the user will log in and TeamViewer will launch properly and your password will work. One last tidbit of information I'd like to add is I always require logout to install TeamViewer just to be safe. I would suggest that you do as well.

As you can see this process is very lengthy and complex for a cross-platform deployable remote control solution. It is my belief that our college will probably begin exploring other options since the deployability of this software has not changed since version 8 and has only gotten worse. I have called in and complained to TeamViewer with each software release and they seem to reiterate the same answer. "Mac deployment just isn't important". For those of you using TeamViewer and this process I suggest you also call in and voice your concerns for this software's inability to be deployed correctly without some major work on Mac. It is my hope that they begin to change their stance and make the software a better solution for Mac. If you have questions on this process please be sure to drop me a line.

No there is not that is actually why i posted this for TX1 as well but I JUST noticed I am getting an error on my system relating to QT:WindowState. This could be due to my system as I just built QT 5.11.1 from source and this may be causing a conflict. Please post your results here.

Hi.
I did the above installation on the Jertson Tx2.
Teamview worked fine on the Jetson Tx2.
But there is one strange problem.
I used a Windows PC to remotely view the Jetson Tx2 screen.
But I can not operate the Jetson Tx2 on a Windows PC.
I can not see any mouse or keyboard movement on the remote Jetson Tx2.
Do you know about this situation?
Have you had this problem with Jetson TK1?
Why does this happen?

Quite often such an issue would be one of permissions. After the error occurs, or while the program is trying to run, what user is it running as (who tried to start the teamviewerd daemon)? When do you see from:
ls -ld /var/run
ls -ld /var/run/teamviewerd.*

It is very likely someone from the TeamViewer community knows about those permissions, and probably knows of cases specific to running TeamViewer on Ubuntu. This looks like it is a security setup issue, and not actually an issue of the architecture. Is there anywhere you can specifically ask the TeamViewer people about how the daemon security is set up, and why there might be an issue with that PID file?

I understand what you are saying. But if this is the permission set during the installation then why does it also affect the application. There is a confusion. It worked once and then not again after restart, I need this, actually millions are waiting for this.

In theory TeamViewer could handle more than one session, and thus spawn more than one PID for each session. I do not know the specifics of how TeamViewer handles sessions, and how the daemon (running as root) hands off to a new user as a session starts.

I am not going to kid you and say this would be easy. To reiterate, most debugging with strace would be using programs started on the command line and crashing or having a known stop point. I do not know much about TeamViewer, and for this to work you must be able to start the service on the command line with the same parameters as the daemon version (except it should end after a failed login instance instead of respawning and starting over).

Having a global deployment to add an app (TeamViewer host), then a tenant deployment to not add the app but a tenant deployment to add the full version (TeamViewer) then a tag deployment to not add TeamViewer then a tag deployment to add TeamViewer Host it mess and a pain