TeamViewer Room for Improvement

John DeMillion
Director of IT at Chester County Intermediate Unit
While TeamViewer has some great benefits, there are also some significant challenges and bugs. The biggest problem in our environment is that it's difficult, or sometimes even impossible, to properly manage granular access to a Host. It's a huge problem that mostly affects the Mac platform, but even with Windows Hosts the entire concept of how access to Hosts is configured centrally is a bit of a mess, especially compared to the true elegance of how LogMeIn worked. With LogMeIn, we could centrally assign techs to a Group of Hosts, and those Techs could control that entire group of Hosts. Even a one-off contractor could be temporarily or permanently given access to a Host, just using their email address. In addition to Group-based assignments, you could assign additional Hosts individually to a tech, so that they could control a single additional Host in addition to the main Host Group(s) that they had access to. It was extremely elegant, easy ton configure, made instant sense, and worked perfectly. For example, I could have a group called "Servers" in LogMeIn, and I could give my infrastructure staff access to all of those servers. If I also wanted one of my Developers to be able to access a couple of those servers, I just gave them access to those individual Hosts in LogMeIn Central. By comparison, TeamViewer is a complete mess. The way they do it is a total nightmare, and it does not work well. In TeamViewer, Techs can be given access to Host Groups...but a TeamViewer Host can't be in more than one Group...and Groups is the only way that you can give access to a user. So the kind of granular control, giving access to Group(s) but also being able to give access to individual Hosts, is completely missing. The workarounds for this are messy: you can either split off any Hosts that may need individual control by other users into separate Groups, or you can have the Techs that need individual access manually add the Hosts to their "My Computers (Local)" Group in their own client, having to know the Host ID, etc. In addition, the administration of Groups and access to Hosts in general is fragmented and confusing, with strange limitations. For example, let's say one of my departments needs to create a Group of Hosts. Only the individual tech who created the Group can control it: no one else can change the name or make other changes...only that tech that created it and therefore "owns" it can. TeamViewer's "best practice" recommendation is to use a generic "Master" account to create and manage all Groups, having to login with that Master account rather than your own individual account, which is bad for many reasons, including making MFA more difficult and it has serious security and management implications. By contrast in LogMeIn, when a privileged administrator creates a Group, it just belongs to the organization, other similarly-privileged administrators can manage the Group, other techs can see it, and it all makes total, elegant sense. Hosts can be assigned to multiple Groups or individual Techs, etc: it's extremely flexible and straightforward. TeamViewer's macOS Host is unfortunately not up to scratch with the Windows Host: it's missing some extremely important features. I sincerely hope that the TeamViewer macOS development team is going to address the problems in the near future. For example, you can't configure multiple "unattended control" passwords on the macOS Host, to give Host access to different departments or individual users but using different passwords. The Windows Host, by contrast, allows multiple unattended control passwords. Another way to accomplish this on the Windows Host is via Windows OS authentication, allowing users with either Windows local or central Active Directory (AD) credentials to authenticate to TeamViewer. This feature is also missing on the macOS Host: there's no way to authenticate using local macOS accounts (which LogMeIn allowed), nor can you authenticate using AD credentials, even if the Mac is bound to AD. So on the macOS Host, there's exactly one unattended-control password to control that Host, which is a big problem in my environment with giving granular control to server Hosts. There is a workaround, but it's completely obnoxious: TeamViewer has an automatic Host-generated password, one that usually changes after every session. It's designed for the local user who's using the Host machine to be able to give a tech a one-time password for a single support session, and the password changes the next time. There is a Host setting, however, that instructs the Host to keep that random password the same after each session, so I can use that as a bad hack to allow individual techs to control Hosts where they shouldn't know the main unattended-control passsword (after they add the Host manually in their "My Computers (Local)" Group....sigh). Unfortunately, this workaround breaks when you restart the Host or relaunch TeamVIewer on the Host, as even with the "Don't Change" setting for the random password, it still changes whenever TeamViewer Host launches. So after every update or reboot, we have to distribute the new random password to some techs...time-consuming and messy. Another big issue with the macOS Host is that it does not have a method of avoiding locking the screen at the end of a session. The setting to lock the Host's screen after a control session seems fairly random, and if the controlling tech forgets to manually disable that "feature" during the session, the user (or server) gets the screen locked in their face when the tech finishes. That causes a lot of problems, especially with some of our servers that need to remain unlocked and by annoying the heck out of users. On the Windows Host, there is an Advanced setting to instruct the Host to never lock its screen after a remote session, but that setting is missing on the macOS Host. There are some miscellaneous features missing on the macOS Host, like auto-hiding the TeamViewer panel and preventing accidental quitting of TeamViewer. These features were deemed necessary (and they are) in the past and thus were implemented on the Windows Host: they should also be available on the macOS Host. Another issue concerns Windows virtual machines. Unfortunately, TeamViewer has historically depended on the Host's MAC address as part of generating the unique TeamViewer ID, because the MAC address was a fairly immutable thing back in the day. However modern virtual machines (VMs) have dynamic MAC addresses, which means that suddenly a Host gets a new TeamViewer ID, and you have no idea what it is, with no way to control the VM. TeamViewer Tech Support tried to help with some workarounds to try to assign static TeamViewer IDs, but none were successful. Their recommendation is to manually manage MAC addresses on VMs, which is a non-starter in clustered environments where dynamic MAC addressing is needed. TeamViewer needs to stop depending on MAC addresses as a part of generating the TeamViewer ID: LogMeIn figured it out and so TeamViewer should be able to. A final concern is the accidental renaming of Hosts with an unattended-control password. As we've increased the use of TeamViewer, we've found that our techs accidentally rename Hosts in the background while they think they're entering the unattended password for that Host. The Host actually gets renamed with the unattended control password, which is obviously a huge security issue. We're trying to be mindful of that bug to prevent it from happening, but it's extremely problematic. View full review »
Link Porterfield
Founding Member at
Since TeamViewer version 13 introduced a Native Linux rather than running the Windows version through an emulation layer, that has been great. However, certain features didn't make it into the initial two releases. So far, the Linux version no longer has support for meetings. It wasn't a feature, and very often a group that we put together recently was looking for a way to do online meetings. I thought, "I have a subscription to TeamViewer that includes that." I do, but that function no longer works in Linux version. I am sort of waiting for that to come back. Support for mobile devices from Linux has been missing since the Native client was rolled out. This was a nice option, especially when trying to walk somebody who was struggling to understand something on their phone. I don't do a whole lot of support for mobile devices, but if I could just direct them to the Google Play Store to go grab the TeamViewer app, they could give me a number to connect to and I could see the screen with them. I'm very grateful that there is a Native Linux client. That is a step forward and in the right direction. It shows TeamViewer's commitment to the Linux platform. I am very pleased about it, but there are some things that I used to have when the Linux version was just the Windows version packaged with the necessary emulation layers to make it work. I miss some of those features which used to be there prior to the Native Linux version. Hopefully, they will make it back into the product in the not too distant future. It would be nice to see some of those other features that we used to have come back, using them on Windows and Mac. I can no longer connect via web links, which is not the end of the world, but it's a mild annoyance. I used to be able to click something from my browser, then boom, there you go. At the time, it was the old TeamViewer that was based on the Windows software. I had to take some initial steps to configure an environment where those links worked, but once Linux was up, it was no different than on Windows. I could be on the web or in a remote monitoring platform, and if I needed to connect with one of my client devices. I would select from there, and say, "Connect to TeamViewer," and it would jump right in. I can't do that anymore. View full review »
Dan Wilkening
Network Administrator at Parksite
If they could figure out a little better solution for the iOS stuff other than just a screen share, even though it's an Apple thing, and Apple doesn't like to give up control of their devices. If they ever got to that point, and I could manipulate an iPad or iPhone, that would be awesome. Since we have a bunch of iPad users who are struggling with doing different things, it would be nice to be able to just jump on and actually show them, "Here, do this, this, and this." Similar to what we do with the laptops, e.g. for training. View full review »
Find out what your peers are saying about TeamViewer, Microsoft, LogMeIn and others in Remote Access. Updated: October 2019.
379,343 professionals have used our research since 2012.
Jason Miller
Application Engineer at AirTies
The remote connection process is reliable, good, and fast. On occasion, when it can't connect to a machine, the error messages aren't always helpful to tell you why you can't connect, as the message doesn't help troubleshoot whether it is too slow, too much interference, etc. I usually have to run to another computer and figure out what is going on, then restart it. The diagnostics could be improved. View full review »
Tawanda Sibanda
Sponsorship at a non-profit
Wish it would support multiple support persons at the same time to assist a client for situations that need team collaboration. View full review »
Associate General Counsel at a energy/utilities company with 1,001-5,000 employees
Only the paid version allows for file transfer. Also, it is annoying that I have to upgrade every time they release a new version because I can't use an older version to access a new one even if my version is paid and their version is a trial. View full review »
Joe Millon
Executive Director at a non-profit with 1-10 employees
* The business interface is clunky and not well-documented. * It should have ability to display notes in the computer list. View full review »
Avesh Meena
There is nothing to improve; TeamViewer already works perfectly. But still, I think the price factor for small business. View full review »
The price is a killer for the amount I normally use it. View full review »
Find out what your peers are saying about TeamViewer, Microsoft, LogMeIn and others in Remote Access. Updated: October 2019.
379,343 professionals have used our research since 2012.
Sign Up with Email