So I spend the next couple weeks making a change, uninstalling, reinstalling. But again, we go to connect to the machine and it prompts for a password. The client usually looks fine, and has our branding, and has the settings password protected as we want. Tried different formatting (Single quotes instead of Double where applicable).Nope! Basically what's happening is the client goes through the three steps above successfully, with an exit code of 0. Well, that would have been nice to know previously, especially since when you create your custom host file and download the MSI, the guide that is included is for version 12.1.Īfter reviewing the Mass Deployment link above, I changed up the script and redistributed to the DPs. We open a ticket with support in which case they inform me that in 13.2 they completely changed how account assignment and deploying works ( See Here). We notice that all of a sudden, clients are prompting for a password when we go to connect.Well that's not right. We basically used the same script and just updated the MSI file. Recently 13.2 came out so we started rolling that out. We have "Easy Access" turned on for clients so there is no password to connect, but it does require the end user to confirm they want to show their screen. For the most part all the clients are working fine. So what does the policy do then? We wound up getting a version 13 license upgrade for free. After screwing around with support, they told us we also needed to add registry keys to the machine for this policy to work. We had clients upgrade to version 13 (while still in beta mind you), at which point we couldn't remote to them anymore. We setup a policy to only allow minor updates within the same version. Now a bit of backstory, we originally started out with a trial of Version 12. Installing TeamViewer, and assigning it to our account. Removing existing registry keys associated with TeamViewer We're leveraging Powershell App Deployment Toolkit (PSADT) to perform the install.
0 Comments
Leave a Reply. |