What is our primary use case?
We use TeamViewer for support, controlling our ~2,500 end-user computers and our ~60 servers. Our environment is primarily macOS, with about 95% of end-users on Macs, but our servers split between Windows and macOS. We also have some digital signage devices that run Linux, and we use TeamViewer to control them as well.
We ran TeamViewer concurrently with LogMeIn for about year as we evaluated TeamViewer as a replacement. TeamViewer's superior remote quality (especially in low-bandwidth situations) and ease of mass deployment, combined with LogMeIn's serious and longstanding bugs led us to recently discontinue LogMeIn in favor of TeamViewer.
How has it helped my organization?
Coming from LogMeIn, TeamViewer's remote control quality, Host reliability, file-transfer capabilities and ability to support multiple simultaneous controllers on a Host have been a great improvement.
TeamViewer's simultaneous-controller/tech licensing is better for us than LogMeIn's device-based licensing, because we don't have to worry as much about maintaining devices in the list as a driver of licensing costs.
What is most valuable?
TeamViewer's cross-platform nature is important to us, as we are about 95% macOS, and our IT organization is all-Mac, so we often use our Macs to control Windows machines.
TeamViewer is very fast, with very high fidelity and visual quality, in both high- and low-bandwidth situations, far better than our experience with LogMeIn.
TeamViewer's support for multiple Controllers on a Host is very convenient, allowing multiple techs to collaborate to help an end-user or to look at a server. With LogMeIn, additional techs attempting to control a Host would either just mysteriously not be able to connect (there was no message or other indicator that the Host was already being controlled by someone else), or they would accidentally kick off the first Controller on the Host, which was inefficient and confusing.
Mass-deployment options for Hosts are excellent, making it easy to mass deploy on both macOS and Windows, and you can pre-configure the Hosts with settings and custom branding as needed. Having said that, the experience with individual installations is nowhere as slick as LogMeIn, however: installing TeamViewer manually and getting everything configured is much more annoying and time-consuming than LogMeIn.
TeamViewer's file-transfer features are useful and comprehensive, with two options: 1) a drag-and-drop transfer mechanism for small files, and 2) a full-fledged file-transfer dialog that allows file tree browsing on both the Host and Controller.
TeamViewer is also free to try for personal use; as a result of that, myself and many of my staff were already familiar with the product from our experience supporting friends and family. That feature directly led to us being able to test TeamViewer extensively in everyday use, and as we looked for alternatives to LogMeIn, our familiarity with TeamViewer from personal use helped. LogMeIn previously offered the same free personal-use license but they discontinued that offering, which in my opinion was a very shortsighted move...and one that made me appreciate TeamViewer even more.
What needs improvement?
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.
For how long have I used the solution?
One to three years.
What do I think about the stability of the solution?
TeamViewer is very reliable. Our major problem with LogMeIn was that it would just turn itself off randomly on Hosts, and LogMeIn Support could never explain for fix it... we literally tried for about two years with them. When we implemented TeamViewer, it was very refreshing to regain a reliable solution that we can always count on working.
TeamViewer seems very stable. It doesn't just crash or randomly turn itself off in our experience so far.
The central TeamViewer service does have issues from time to time, but the longest we've seen it last is a few hours, and it seems to be mostly in the middle of the night, and they're all over it, including transparently showing the status of all services on the TeamViewer Status website.
What do I think about the scalability of the solution?
TeamViewer seems to scale well in one sense, being easily mass-deployable to thousands of Hosts.
But the badly-designed Groups and kludgy nature of the central management, combined with significant missing features on the macOS Host and lack of support for dynamic MAC addresses on VMs is a problem with scalability in a complex organization, and TeamViewer should address these major problems ASAP...right now they're just lucky that the other available cross-platform remote control solutions actually suck more than they do. ;-)
How are customer service and technical support?
Technical support is excellent; they do a nice job and have high-quality support techs. The times that I've submitted tickets or called in, it's always been somebody who knows what they're talking about, friendly and knowledgeable. They can't make up for some of the flaws in the product, but they do the best they can with the product that they have, trying workarounds and even testing things in their lab while we're on the phone with them. It's a pretty impressive support group.
Which solution did I use previously and why did I switch?
We came to TeamViewer from LogMeIn and, before that, we had an older product called Timbuktu.
LogMeIn's main issue that caused us to switch was that the Hosts would just randomly turn themselves off: the icon would grey out and the LogMeIn Control Panel would show that the Host was off. This of course disabled access to Hosts in a random and widespread manner, and troubleshooting with LogMeIn Support over the period of a year resulted in no fixes or workarounds, and it was causing enormous problems in our environment.
LogMeIn also did not allow multiple controllers on a Host, had no file-transfer capabilities (in the affordable "LogMeIn Central" version that we licensed), was licensed based on the number of devices, and had annoyances with Control/Command-Tab mapping from Controller to Host. These weren't showstoppers, but they helped to push us elsewhere.
How was the initial setup?
TeamViewer deployment is fairly straightforward: knowledgeable techs can configure Host settings, brand the Host, and mass-deploy it pretty easily. Manual setup on individual Hosts is very clunky and time-consuming compared to LogMeIn, however.
We deployed it very quickly. We had not made a final decision on LogMeIn until very close to when our LogMeIn's licenses were expiring. So very quickly, within a couple of days, they were able to push out the TeamViewer Host to all of our devices.
Initial setup and ongoing management of Groups and other central management tasks is messy, time-consuming, inelegant and makes no sense. TeamViewer needs to take a hard look at their hodgepodge and take a good long peek at how LogMeIn Central works and....be more like LogMeIn in central management.
What about the implementation team?
We evaluated and deployed completely in-house.
What was our ROI?
ROI-wise, the savings from licensing have more than been eaten up by the soft costs involved in dealing with and working around TeamViewer’s feature deficiencies on the macOS Host, the terrible central management design, and the lack of support for dynamic MAC addresses. If the TeamViewer developers get their act together and improve the product in those areas, the ROI will improve significantly.
Ultimately, however, even with all of its warts and problems, it's still the best, most reliable and most affordable remote control product, at least for our environment.
What's my experience with pricing, setup cost, and licensing?
TeamViewer pricing is reasonable.
It's licensed by simultaneous controlling tech, rather than by the device. I like that because previously it was always a struggle to keep the device list maintained. If we got rid of a device and we didn't remove LogMeIn properly, the device would remain in our LogMeIn Central account and use a license.
That's not a problem with TeamViewer's licensing, plus you can have as many techs as you want, but it monitors their simultaneous remote control usage with Hosts. It can be a little tricky in the sense that you have to plan for the maximum simultaneous usage during busy times, and initially I didn't purchase enough licenses, but when we started hitting the limit, TeamViewer detected that and sent emails notifying us, then our sales rep very quickly added another license (allowing us to pay later via purchase order) to get us back in business.
In our environment, TeamViewer turns out to be less expensive than LogMeIn, at least so far. We’re currently saving about 30 percent on licensing costs, and we don’t have to worry about maintaining/pruning the list of machines in the LogMeIn. TeamViewer's automatic emails telling us that we've hit the simultaneous limit includes stats on how many times it has happened recently, which helps in deciding whether to purchase an additional license.
This type of licensing does have a downside: with LogMeIn, my staff were accused to controlling a client or a server and staying connected as needed, sometimes for hours if they were doing maintenance on a server or assisting a user with an intermittent issue. But with TeamViewer, that chews up a simultaneous-use license and drives additional licensing costs, so we all have to remember to disconnect from Hosts.
Which other solutions did I evaluate?
We tested a number of other remote control solutions hoping for one that would stand out, because of the problems we had seen during our testing with TeamViewer on macOS. Unfortunately, they were all actually worse than TeamViewer.
In the end, before moving to TeamViewer, we evaluated LogMeIn, ConnectWise Control, Royal TSX, Devolutions, Dameware Remote, Goverlan Reach, and Radmin.
What other advice do I have?
Make sure that you're okay with the simultaneous tech licensing. In my environment that works out great but I'm not sure if that's appropriate for all environments. And, if you have macOS Hosts, just understand what you're getting into and carefully map out how you're going to give granular control for Hosts if you have techs that need to control the same Host from different departments/groups.
In terms of how many end-users we can support with one tech,TeamViewer is about the same as LogMeIn. TeamViewer did increase efficiency in multiple ways, but at the cost of some significant management headaches because of the multiple issues mentioned above. So it may be pretty much a wash, at least until they fix some of the issues.