Preface

My company made a global decision to get rid of Radmin and some other products used in the EMEA region, and go with Teamviewer as a way to remotely support our fleet of Desktops, Laptops, etc. Especially for our mainly remote users. Why not just use SCCM to do this? Short answer, I don’t know, but we didn’t. So here we are, deploying Teamviewer and trying to use this instead. There will be a tl;dr at the bottom

Deployment

We’re leveraging Powershell App Deployment Toolkit (PSADT) to perform the install. To break it down simply, we’re:
  1. Uninstalling previous versions
  2. Removing existing registry keys associated with TeamViewer
  3. Installing TeamViewer, and assigning it to our account.
Now a bit of backstory, we originally started out with a trial of Version 12. We setup a policy to only allow minor updates within the same version. Sounds good right? Apparently not. We had clients upgrade to version 13 (while still in beta mind you), at which point we couldn’t remote to them anymore. After screwing around with support, they told us we also needed to add registry keys to the machine for this policy to work. So what does the policy do then? We wound up getting a version 13 license upgrade for free. So all is right with the world. We have version 13.1 installed. For the most part all the clients are working fine. 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.
Recently 13.2 came out so we started rolling that out. We basically used the same script and just updated the MSI file. We notice that all of a sudden, clients are prompting for a password when we go to connect…Well, that’s not right. 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). 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.
After reviewing the Mass Deployment link above, I changed up the script and redistributed to the DPs. Still doesn’t work. 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. The client usually looks fine, and has our branding, and has the settings password protected as we want. But again, we go to connect to the machine and it prompts for a password. So I spend the next couple weeks making a change, uninstalling, reinstalling. Running it manually and then running it through SCCM. Using VMs, Desktops, Laptops, etc. On multiple occasions, I think I’ve found the issue. First I see that a registry value “OwningManagerCompanyName” that seems to be missing from the clients that don’t work properly. Perfect! That makes sense why it wouldn’t work. So I change the detection method to include this key…it must exist! Still no luck, I’m prompted for a password.
So I fire up a VM, run a registry comparison product to capture registry changes during an install. In our script we originally used the msi installer to run a msiexec /x to uninstall previous versions of Teamviewer, then we ran a Remove-MSIApplications, which is part of the PSADT to uninstalling anything left. This essentially (to my knowledge) grabs the Uninstall string from the registry an executes it. This essentially is redundant of the previous command except it uses msiexec /x {GUID}. I noticed in the registry captures that when running the first command only and reinstalling, not all of the registry settings are in the registry. But, when I do the Remove-MSIApplications and a reinstall, they are. A-HA! I’ve found it. I comment out the first uninstall command, redistribute, and push to our clients…Still getting a password prompt.
I open a ticket with TeamViewer support that basically goes back and forth with what I should have in the command line. “Oh change this to that”…Doesn’t work…”Oh, you’re doing it that way, then change that to this”…Doesn’t work. The ticket is still open btw. I complained on twitter and the twitter support engages me and asks for the ticket number. I provide it and they basically tell me “Oh you’re working with someone on the case, we’ll leave you alone then”. Well WTF?
I compare the registry values of working clients and non-working clients. Everything is matching up, except for this one key, DeviceManagement. On clients that don’t work, I only see 4 values [pic]. On clients that do work there is about 30 values [pic]. These values appear to be completely random (blurred because I don’t know if they can be translated) per computer, so I can’t use them as a detection method. I get an idea to leverage a Configuration Baseline with PowerShell and just find computers that don’t have “enough” of these values to be working. Then, I’ll create a non-compliant collection and send an Uninstall of Teamviewer to those clients. Once, SCCM picks up that the client isn’t installed anymore It will reinstall, hopefully properly this time. Brilliant! Code below:
if ([System.Environment]::Is64BitOperatingSystem) {
$path = 'HKLM:\Software\WOW6432Node\TeamViewer\DeviceManagement'}
Else {
$path = 'HKLM:\Software\TeamViewer\DeviceManagement'}
$TVSettings = (Get-Item -Path $path).ValueCount
if ($TVSettings -gt '7') {Write-Output 'Installed'}
Well, guess what? That creates a conflict. One collection says install, the other one says uninstall. I should have thought about that more, but I didn’t. Well, what happens if I exclude the “Non-Compliant” collection from the collection that I’m deploying Teamviewer to. That creates a loop in case you didn’t know. So I abandon this idea, but I’m still reporting on clients that don’t have enough of those values. So how do I tell SCCM via the Detection Method that TeamViewer isn’t installed so it triggers an install? The idea I came up with was to check for the log that PSADT generates (C:\Windows\Logs\Software) and check the timestamp. If the timestamp isn’t equal or greater than the time I redistribute the files, since I’m doing change after change, then the client should reinstall TeamViewer. I found that there was a new version of the host file (13.2.14327) so I was hoping this would fix my issue.
As of right now I still have a ticket open, Teamviewer still isn’t properly installing, and I’m losing all patience. Support has been abysmal. I’ve been using SCCM and deploying applications since SCCM 2007. I feel like I have a pretty good grasp on SCCM and packaging and this has been probably the worst experience I’ve had deploying something. AND…it’s a damn MSI…it should be easy as hell. I will update this once I get it working in hopes I can help someone else and possibly deter you from purchasing TeamViewer. Maybe it’s my stupidity, but it should not be this hard.
tl;dr – TeamViewer changed the install method from 13.1 to 13.2. Installing this through SCCM has been a terrible experience and doesn’t work how we want it. Support has been unsupportive.

[UPDATE] 2018-08-21

I spent 3 hours on the phone uninstalling and reinstalling teamviewer with my colleague and other SCCM admin. We discovered that even with the command line in 13.2, the teamviewer accounts wouldn’t get assigned properly. We then started watching the Program Files (x86)\Teamviewer folder as we were uninstalling and reinstalling, and we noticed that the AssignmentData.json file stays put during some, but not all installs. This file is basically like an RSVP for the assignment data. If you don’t “use it” you’re not invited….or something like that…you think of a better analogy. Anyway, what my coworker found out, was that you can run the actual Teamviewer.exe from the Program Files folder with some assignment switches (see code below). So long story short, if that AssignmentData.json file exists in your installation folder, you’re going to have a bad time. We also saw that the –alias switch doesn’t work if the computer is already in the C&C, as they call it. If no information is specified for the alias switch, it will use the Teamviewer ID as the alias. Now it does say in their documentation that if the computer is in the C&C that the alias switch will be ignored. This is a little problematic if you want to rename as you upgrade. Anyway, we’ve now implemented a code block in PSADT that will, in short, take 30 seconds and see if the AsssignmentData.json disappears on it’s own (which it damn well should). If it doesn’t run the assignment using the TeamViewer.exe executable, and give that 30 seconds. If the AssignmentData.json STILL exists after that, exit with a 69696 Error code (basically it didn’t assign properly). We also confirmed that the registry values and keys I mentioned above are not present if AssignmentData.json exists.

Show-InstallationProgress -StatusMessage "Account assignment in progress..."

If ($Is64Bit) {
$tvInstallPath = $envProgramFilesX86
}
else {
$tvInstallPath = $envProgramFiles
}
$xCount = 0
Write-Log -Message "Waiting 30 seconds before attempting account assignment..." -Source 'Execute-Process' -LogType 'CMTrace'

While ((Test-Path "$tvInstallPath\TeamViewer\AssignmentData.json") -and ($xCount -ile 6)) {
Start-Sleep -Seconds 5
$xCount++
}
Write-Log -Message "Automatic account assignment timed out; attempting manual account assignment" -Source 'Execute-Process' -LogType 'CMTrace'
Execute-Process -Path "$tvInstallPath\TeamViewer\TeamViewer.exe" -Parameters "assign --api-token --group --grant-easy-access --reassign --alias %COMPUTERNAME%"
While ((Test-Path "$tvInstallPath\TeamViewer\AssignmentData.json") -and ($xCount -ile 12)) {
Start-Sleep -Seconds 5
$xCount++
}
If (Test-Path "$tvInstallPath\TeamViewer\AssignmentData.json" ) {
# Report back to ConfigMgr that the account assignment failed
Exit-Script -ExitCode '69696'
}

[Update] 2018-08-28

Still issues with clients not assigning properly. I was provided uninstall scripts from TeamViewer support (Link Here). I reviewed the scripts and there really isn’t any difference in the scripts and the way we remove TeamViewer prior to install. The only subtle difference is cleaning up the %temp% folder. Which should not cause the level of frustration that this install has caused. We’ve opened an additional ticket to try and pinpoint how to correctly determine if a client has the proper assignment and settings. We all make mistakes, but between two seasoned SCCM Admins, you’d think we could handle an MSI install.

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *