Hello everyone,
I am an IT administrator currently working on streamlining our TeamViewer Host deployment using an automated software deployment tool (PDQ Deploy). Our goal is to migrate away from legacy .tvopt configuration files and rely on TeamViewer Cloud Policies for managing our endpoints. However, we have run into significant feature gaps and deployment conflicts that are actively preventing a seamless zero-touch rollout.
1. Missing "Personal Password" in Policies (Crucial for LAN Connections)In our environment, we frequently use direct IP-to-IP connections over our local network. Because Easy Access relies on internet broker servers, it cannot authenticate direct LAN IP connections. With random password generation disabled for security, the system prompts for a password. However, there is currently no way to centrally configure and push a static "Personal Password" via Cloud Policies, leaving us without a way to authenticate offline/LAN sessions natively from the cloud.
2. Missing LAN and Power SettingsSimilarly, the options for "Incoming LAN connections" (Accept / Accept exclusively) and "Power settings" are absent from the central policy management console. To properly configure our endpoints for our specific network requirements, we are forced to fall back on injecting .tvopt files during the MSI installation because the web policies simply do not cover these necessary settings.
3. The Automated Assignment Catch-22 (The Password Protection Error)Because we are forced to use the .tvopt file during the MSI installation to apply the missing Personal Password and administrative lock-downs, we hit a deployment wall.
Applying a .tvopt file that contains an Options Password locks the agent immediately upon installation. When our deployment script subsequently runs the official CLI assignment command (TeamViewer.exe assignment --id...), we get a bizarre "split-brain" result:
- The device does successfully appear in our Management Console.
- However, the local Host application does not recognize that it is fully managed. The "Manage this device" button remains visible on the GUI.
- The local GUI throws an error stating: "Unable to assign this device. You do not have enough permissions, or your TeamViewer settings are password-protected."
4. Post-Installation Import is Not a Viable WorkaroundTo bypass the error above, we theorized installing the bare MSI, running the CLI assignment, and then applying the .tvopt file. Unfortunately, there is no command-line parameter to import a .tvopt file after the application has been installed. Being forced to manually navigate the GUI (Advanced -> Import) to apply critical LAN and password settings across 100+ machines is a massive administrative bottleneck and completely defeats the purpose of automated, zero-touch deployments.
Summary:This creates a frustrating deployment loop:
- We cannot use Cloud Policies because they lack critical LAN and Password features.
- If we use the
.tvopt file during installation to apply those missing features, it locks the agent and breaks the local CLI account assignment. - We cannot apply the
.tvopt file via CLI post-assignment.
Are there any plans to bridge this gap by adding Personal Passwords, LAN settings, and Power configurations to the Cloud Policies? Alternatively, is there a supported method to securely assign a device via CLI while applying a password-protected .tvopt file during a zero-touch deployment?
Thank you in advance for any insights or roadmap updates.
Attached are screenshots of features/Issues/Errors
