TeamViewer Design Change Request
So yet again we have more issues. Since TeamViewer is designed in the way that it is we now have discovered an oversight in it’s design and thus it’s design in broken in proof of concept.
Deploying TeamViewer is very device centric, opposite of where most other software companies are going. This being user centric. Since TeamViewer is applying policies based on devices and not users it become very difficult to manage user behavior from one device to another. This brings deploying TeamViewer in a cloud environment, such as Office 365/Azure AD using a variety of MDM tools, in our case Intune, is a disaster. I can see how this would translates into a Active Directory environment as well.
Intune can deploy based on devices or users, but when you need to know who gets the Host or Full version this is nearly impossible at best when deploying to devices. If a user changes device how can we ensure they get the correct version of TeamViewer? This generates a lot of overhead in management.
Ok so deploy the full version of TeamViewer and forget the Host version. Sounds like this would solve the issue. Afraid not! Since the Full version is deployed in such a way that it requires not only that the user click “Allow and finish” but there is nothing preventing them from signing in using their own personal TeamViewer account and connecting to other computers outside of the company. You still have way to many holes that are easily circumvented by amateurs.
TeamViewer seriously needs to reconsider their approach on how that design and allow people to deploy TeamViewer. You are making this far more difficult than it needs to be. A simple MSI complied from our account for our account only and user based policies.
I would hate to say get your head out of the clouds as this be the opposite of my suggestion. We live in a world of “Stranger Things”, so get your head out of the “upside down”.
Suggestions for a cloud first world:
1. Single installer that is complied from out TeamViewer account that includes all the IDs and/or tokens required to assign that installer to our account. Preferably an MSI so that it can be deployed with Intune.
2. Policies should be based on users. Thus the TeamViewer that is installed, this being the Full version, would get the policies set forth for the user that logs into the TeamViewer software. This would control what function would be available based on that user’s policy
3. Suggestion #2 would provide better control as to who can access who’s device. (e.g. C-Level employee). If user is logged into more than one device a prompt would be presented to the initiator listing the current devices that the user is requesting support for.
4. Do away with the Host version as it is not needed.
Comments
-
I recently opened a ticket with TeamViewer to try and resolve an issue that I have with one of my users. The user TeamViewer installation was stuck in "Trial" mode and would not allow the user to connect to our Whitelist as the Host was not getting the policies applied. We did a full uninstall using the both the TeamViewer reconnmened way and eventually using Revo Uninstaller. Neither resolve the issue.
So I was informed by the effected user that this issue has been resolved and that the “Trial” indication would not affect the operation of the product. Unfortunately this is incorrect. The device that the user is using is registered with our TeamViewer account, however it is not getting policies applied to it. Thus the Whitelist is not being applied. We block all free version of TeamViewer and only allow access to registered devices.
Since TeamViewer is so advent on setting policies in a device centric fashion this type of issue will have a higher probability of failure due to localized corruption and/or modification by the user. Policies should be based on users not devices."
0 -
To add, to this already big mess, the TeamViewer portal is starting to get cluttered with stale devices that either no longer exist or have been wiped and renamed. Again, generating a lot of management overhead.
0
