cases

Packaging without a domain

A TeamViewer Host packaging project exposed hidden assumptions in an MSI transform about stale domain infrastructure, leading to implementation of an Intune-ready package and detection model that restored visibility across multiple cloud native tenants.

Date
Area
Application packaging and remote management
Status
Case record

The gap

Around fifty cloud kiosk devices had no remote management capability.

They functioned otherwise, but when support was needed there was no practical way to reach them despite TeamViewer being installed. From the management side they were effectively invisible. Because they were kiosk devices, end-user interaction was limited to Microsoft Edge. Getting to the installed TeamViewer instance to relay a code required administrator access and physically attaching a keyboard and mouse.

This had been an accepted state for nearly two years: no reliable remote access, limited management visibility, and every support issue requiring a physical visit. The devices mostly continued to perform their primary function, which meant the underlying management problem rarely rose high enough in organisational triage to receive sustained attention.

The objective sounded straightforward:

  • correctly package TeamViewer Host
  • restore remote management
  • standardise deployment across the fleet

What looked like a deployment exercise quickly became an investigation into assumptions embedded inside an installer that had survived multiple infrastructure changes.

Installer analysis

Inside Intune, and across other systems I could verify that TeamViewer was in fact installed on the devices. During provisioning I had also seen TeamViewer present on the devices, so I knew this was not simply a management-side problem. That helped narrow the focus to the packaging side.

Since TeamViewer was functional in other tenants that were AD-based rather than cloud native, I selected a handful of environments where it was working as expected: devices showed up in the correct groups and could be accessed with the expected credentials.

The deployment consisted of three files:

  • the TeamViewer Host MSI itself
  • an options configuration file, tv.tvopt
  • an MST file

The TeamViewer Host package was a known good as long as the versioning was current, so I focused on the .tvopt and MST files.

I generated and compared file hashes and saw that the .tvopt files in use were identical across implementations. That pushed the focus onto the MST files.

I then used ORCA to inspect how the TeamViewer Host MSI interacted with those transforms.

The first discovery was that the client-specific packages were quite similar. The differences mostly came down to:

  • the location from which the installer retrieved the TeamViewer settings file (tv.tvopt)
  • the group assignment identifier used during registration

Relevant registration and API information was also present in the MST, but that became more important later in the investigation.

The hardcoded locations of the .tvopt files were the first real smoking gun. Each environment specified a location on a domain server for its options file.

That pointed directly to the broken architectural assumption: the installer expected a domain-connected environment with access to a network share during deployment.

The deployment process had been designed around infrastructure that did not exist for these devices.

When the install was implemented in Intune, it was effectively a copy-and-paste of settings that were functional in one environment into an environment with a completely different foundation.

The first fix

So the TeamViewer installs were reaching out to a domain share to retrieve their options file. That was a reasonable explanation of the failure.

At that point it became clear that the install and uninstall behaviour needed to be scripted, the .intunewin package needed to contain all required files itself, and the install path needed to call those local files directly at runtime.

I made the decision to package all required configuration alongside the installer and make sure the package contained:

  • TeamViewer Host MSI
  • client-specific transform (MST)
  • TeamViewer settings file (tv.tvopt)
  • assignment parameters for automatic group registration

The installer no longer depended on a domain, network share, or external configuration source.

Everything required for successful deployment travelled with the package.

The first test

I built the install logic that would be contained within the .intunewin package and validated the behaviour in a test VM before moving to production devices.

It worked as expected. I ran the install script as admin, the options and transform were passed at install time, and the test VM showed up in the management environment.

I then packaged the setup into .intunewin format, uploaded it to Intune as a Win32 app, and deployed another test to a physical kiosk I had set up in the lab.

I forced a restart of IME on the device to kick the install off. I saw the TeamViewer icon show up on the desktop of the administrator account and initially thought the work was done.

Then I checked the management console.

The device name was not there.

The install worked when run locally, but something broke when the application was handed off to Intune.

Fix part 2

At that point I turned to where I probably should have checked earlier: TeamViewer's own deployment documentation.

That ended up explaining the difference.

The important point was not that the MST had completely failed. The MST was still carrying ordinary installer customisation correctly. The problem was narrower than that: TeamViewer's Intune Win32 guidance treats installation and assignment as separate steps.

In TeamViewer's Win32 deployment model, the MSI install handles the application and custom configuration, but assignment is expected to happen afterward by explicitly calling the TeamViewer executable. In other words, values like CUSTOMCONFIGID and ASSIGNMENTID do not behave like ordinary static MSI properties in every context.

That explained the split I was seeing:

  • the package worked when run locally
  • the transform still applied normal installer behaviour
  • the device still failed to appear correctly when the deployment ran through Intune Win32

The likely issue was not that the MST syntax was wrong. It was that the TeamViewer-specific registration and assignment path was sensitive to execution context and timing under IME.

Once I understood that, the fix became clearer. I rebuilt the package so that the install and the assignment were handled in the pattern TeamViewer documents for Intune Win32 deployments. The configuration and assignment values were passed as command-line parameters at install time and in the post-install path instead of being left to the transform alone.

After that change I tested again on the physical lab kiosk, and the result was what I had expected from the start: the kiosk appeared in the system, was accessible, and was functioning correctly.

Phased rollout

At that stage I got the go-ahead to roll this out to a pilot group in production.

At that point, installation was no longer the main hurdle. Remediation strategy was.

I decided to use supersedence logic from the old TeamViewer package to the one I had just implemented.

On the pilot group, all installs reported successful. Only a few were actually functional.

That led to another round of analysis.

I was relying on weak detection behaviour.

Because TeamViewer was already present on the production devices, albeit misconfigured, some devices were auto-updating, and the detection rule for the package I created was a single check for the presence of the desired version.

That was not enough.

I combed through the registry of the kiosk I had in the lab looking for keys that could only be present if the options file, the MST, and the runtime parameters had all been passed correctly.

I then expanded the detection rules.

The deployment would only report success when the device was genuinely operational.

After allowing time for state convergence, the devices in the pilot group gradually settled into a functional state.

As I expanded to each successive rollout ring, functionality continued to be restored as more devices converged.

Some days later, remote management capability had been restored across the kiosk fleet.

The outcome

The deployment restored remote access and management visibility to approximately fifty kiosk devices that had been effectively unmanaged for nearly two years.

The solution also proved reusable. The same packaging principles were later applied in two more cloud-native client environments experiencing inconsistent TeamViewer connectivity, producing a more consistent and supportable deployment model.

What this taught me

  • A package can be installed and still be operationally useless. Presence alone is weak evidence.
  • If a deployment behaves differently across environments, inspect the installer and transform before assuming the management platform is the root cause.
  • Copying a deployment pattern out of one tenant into another can reproduce hidden infrastructure assumptions along with the settings.
  • Vendor-specific deployment parameters do not always behave like ordinary MSI properties once Intune Win32, IME timing, and post-install assignment are involved.
  • Detection logic has to prove the end state you actually care about, not just confirm that a version number or executable exists.
  • In phased remediation work, "reported success" and "functional state" are not the same thing. Time for convergence and better verification both matter.