Teamviewer Host

[Bok Wykes]

Sameissue 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've tried re-'assigning' the host to our account. This requires our main account's userid and password. This sort of works...but it's not clear that TeamViewer is picking up the new registration, or somehow the old registered connection still works in the TeamViewer client. Also unclear whether it's picking up any policy that I had applied to the modules through Groups; many of the hosts now ask the end-users if they want to rotate the password after disconnection....something we haven't trained them to know how to answer, I thought I had policy telling it to 'keep the current password'.

@LenCCS I'm having the same problem the past few days. We have computers set up in a group for multiple techs to see and connect to. Out of the blue, many hosts are no longer showing "easy access" as being set up. When we try to connect, it prompts for a password.

Teamviewer Corporate licensing. Teamviewer Host version, installed anytime between this week and months ago. We're using the silent installation string to set up easy access and place the computers in a specific group within our* account.

So that makes 4 different people reporting the same problem. For my company, it is getting more widespread. It seems like every time I want to connect to a remote user, within my TV console their host is either reporting as offline or has lost easy access and I have to ask them for the TV client ad-hoc password.

I have not been able to get this fixed through the support ticket routine because it is taking too long between replies, and every time I have a "live one" in my office, I'm not able to get someone to look at it within several days, which is after I've already turned the computer back around to the end user.

Folks, I'd highly recommend that you put in an official support request so that we can stress this is happening to no less than 5 organizations. I have been working through support for many weeks without much satisfaction, and it was stated in a support response today that "First, we (the support team) don't work with users on forums or community websites. Those kinds of sites are there for free users."

I wanted to step in to correct what the representative told @TConard - The TeamViewer Community is not only for free users. While it is true that the TeamViewer Community is user-driven, meaning many answers and conversations occur between users such as yourself, we as moderators, our support representatives, and other TeamViewer employees are also active here, providing guidance, answers, and direction to both free and licensed users alike.

That being said, as @Ying_Q mentioned in her reply, we do recommend that licensed users affected by this issue reach out to our support teams directly, as further investigation is required to determine the exact cause of the issue. Such cases usually require analysis of logs and other information; for the security and privacy of our users, any log requests must occur through a support ticket.

Just an update from me on this one.. my company is still having this problem despite setting a TeamViewer policy to automatically update all TeamViewer Host instances to the latest. The efforts to get TeamViewer Support to fix this have been fruitless, as they believe it is an environmental issue. This is affecting many computers quite randomly, but only a relatively small percentage of our total installation base.

This is extraordinarily annoying, because we don't know that the problem exists until we go to initiate a connection through our console (Computers & Contacts section.) At that point, we normally see this:

Or otherwise, TV shows as offline for many days. At this point we realize that Teamviewer has lost its account assignment, or in the case of the screenshot here, it has lost its Easy Access setting and other settings to make it "ours" in nature.

Yes, this is still happening for many people and the TeamViewer support team is not offering any working advice on how to resolve. This is due to it being a problem with the application programming itself, not an environmental or customer problem.

I've lost most of my systems over the past week. I also couldn't get the most recent versions to authenticate with my easy access (wouldn't even get to the point where they could prompt for my 2-factor code) and ultimately had to roll back to an older version of teamviewer-host for Linux, set a temporary password through the terminal, and then was able to get it to enable easy access through the GUI. But that doesn't fix all of my other systems that I no longer can access.

In the "Design & Deploy" - "Assignment" part of the console, all users will be set as managers. This is because we also put the freshly installed devices in a group XXX and the local IT teams are supposed to move the devices into their local groups ZZZ.

What happens currently quite frequently is that directly after installation, while the device is still in group XXX, they can connect. Then the device gets moved to group ZZZ and Easy Eccess is not available anymore, but they are being asked for a password (which does not exist). In group ZZZ the users are getting the management rights via User Groups and not directly via their user accounts. So other groups will have only Easy Access as they only need to connect to the devices.

Easy access is greyed out and inactive. Still if I use "ID and Password" it will user Easy Access for me... not for others though. Also, when I add my user directly to a device and grant Easy access explicitely, I will get shown Easy access as well as a "Connect with" option in the TeamViewer client.

Probably no chance of getting open and transparent communications about the problem, though, as I worked diligently for almost a year to have this fixed and they seemed powerless to do anything about it. Put me through the wringer entirely.

Possibly the best part is that they don't even bother to reply to these threads anymore, because they know their software is buggy trash that they cannot fix, and that they work for a low tier, crummy company that would rather spend tens? hundreds? of millions of dollars sponsoring sports teams instead of putting a couple hundred grand into bringing in a couple people to fix the mess. Miserable.

The problem is that the teamviewer_linux_x64.deb, the package that was aimed to 64-bit systems, uses a obsolete package that tried to achieve multiarch previously in Debian based systems called ia64-libs. Although, that package scheme changed and now Teamviewer distribute the native build for both i386 and amd64 architecture, as they don't need anymore multiarch.

Simply downloading the appropriated package for Debian/Ubuntu and installing it using your favorite method, should be enough. This package also installs a repository, so it should also automatically upgrade itself when you upgrade your system.

All I had to do to amend this problem was do dpkg --force-all -i *.deb to install that package. Note that the only dependency it couldn't resolve was libpng12-0, so after forcing the install it has no images in the interface but it is still runnable. The other solutions did not solve the problem for me. I'm hoping the Teamviewer developers will get to this soon.

TeamViewer 14.0 is out for Linux and it's no longer based on Wine. TeamViewer 14.0 features native 64-bit support and a Qt front-end. .deb packages for TeamViewer 14.0 for Linux are available from the official TeamViewer website.

On Ubuntu 17.10 some features of TeamViewer require Xorg to be selected instead of the default Wayland at the login screen. In Wayland only outgoing remote control and incoming file transfer are supported. If you need incoming remote control you have to login to classic Xorg. In order to enter an X session from the GDM login screen select Ubuntu on Xorg.

So I have a scenario and am curious if anyone has come across this. Upon startup, I have teamviewer host loading up. Yet, I would prefer TeamViewer Desktop (Full version or whatever its called) to start instead, which i already have selected in the options for that version to start on startup.

I don't seem to have anywhere where I can disable Host at startup. I've check my startup apps in windows settings, task manager>startup, and even the TeamViewer Host options. There's nothing there to stop it on startup.

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.*

3a8082e126