Jabra has changed to a 64-bit build of Jabra Direct. For a long time the only build on offer was x86, the 32-bit version. When I spotted that they had changed architectures, I wanted to understand the update behaviour, my first question was how does the x64 installer behave when it lands on a device that already has the old x86 version? Nobody wants two copies of Jabra Direct sitting side by side.

So we tested it. Here is what we found.

Where each build lives in the registry

This is the part that matters for detection. On 64-bit Windows, the two architectures do not register in the same place.

The old x86 build writes its uninstall entry into the 32-bit hive:

HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall

The new x64 build writes into the native 64-bit hive:

HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall

So a device that has the old version looks different in the registry to a device that has the new one. Keep that in mind, it becomes important in a moment.

Testing the update from x86 to x64

We deployed the x64 build straight over an existing x86 install. The result was clean. The new build updated the app in place and removed the old 32-bit version on its way through. No duplicate entry, no orphaned 32-bit install left behind, nothing to chase up afterwards. From the end user side it is just Jabra Direct getting a version bump.

That is the behaviour you want from an architecture swap, and it is not always a given, so it was worth confirming before rolling it out.

Deploying it with Pckgr Update Only

We deploy the 64-bit build through Pckgr using the Update Only mode, so it only targets machines that already have Jabra Direct installed rather than pushing it onto every device.

Here is the catch. Because the old and new builds register in different hives, a requirement script that only checks one location will miss half your fleet. Check only the native hive and you skip every device still on x86. Check only the 32-bit hive and you skip every device that has already moved to x64.

The fix is to check both. Our Update Only requirement script looks across the native and the WOW6432Node uninstall keys, so it matches whether the device is sitting on the old x86 build or the new x64 one:

# Get the application properties
$registryPaths = @(
    'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
$AppProperties = foreach ($path in $registryPaths) {
    Get-ItemProperty -Path $path -ErrorAction SilentlyContinue |
        Where-Object { $_.DisplayName -eq 'Jabra Direct' }
}
# Check if the application is found
if ($AppProperties) {
    Write-Host "Application Found"
    exit 0
}
else {
    exit 1
}

The script exits 0 when Jabra Direct is found in either hive, which tells Pckgr the device is in scope for the update. It exits 1 when neither hive has it, so machines without Jabra Direct are left alone.

Wrap-up

Two takeaways from this one. The x64 build of Jabra Direct updates cleanly over the old x86 install and removes the 32-bit version for you, so the migration itself is painless. And when you target it, remember the architecture change moves the app between registry hives, so detection has to cover both. Once that is sorted, the whole fleet rolls over to the 64-bit build without any leftovers to clean up.