cancel
Showing results for 
Search instead for 
Did you mean: 

AU2 policies/auto-update not working as expected

DDIT
Explorer
Explorer

I deployed 6.0.10 to an endpoint with the following...

 

msiexec.exe /i "ZoomInstallerFull.msi" zConfig="AU2_EnableAutoUpdate=true;AU2_SetUpdateChannel=1;AU2_EnableShowZoomUpdates=true;AU2_InstallAtIdleTime=true;AU2_EnableUpdateAvailableBanner=true;AU2_EnablePromptUpdateForAU2=true;AU2_EnableUpdateSuccessNotification=true" ALLUSERS=1 /qn /norestart /log output.log

 

Zoom installed successfully. This version was intentionally chosen as it is slightly older than the current version 6.2.5. The option above AU2_SetUpdateChannel=1 was included as I understand this should install the latest available version.

 

After waiting a few days, nothing happens on the endpoint. Zoom is open and has been running for hours, even overnight. Zoom has certainly been "idle" enough to trigger the update, but nothing is happening.

 

Separely, we also have GPO's applied to this computer (not user), which are shown below

RemoteDesktopManager_2024-10-24_09-59-57.png

What am I doing wrong? The documentation is unclear when talking about deprecated policies and the introduction of the newer AU2 policies.

 

I have read elsewhere that the auto-update won't work if Zoom is installed in the system context (ie C:\Program Files), not the user context (ie %appdata%). Is that correct?

 

The problem with the user context is when users don't login to that same computer for a few months (our workforce is very mobile) they will have an outdated version of Zoom in their profiles. I know, this isn't a major concern, but it plays havoc with vulnerabilities scanners. 

 

I would prefer Zoom to be installed in the system context, which is easier to manage on shared workstations. Chrome manages it by having a service or scheduled task to update itself. Heck, even Adobe has worked some black magic to allow users to upgrade Creative Cloud apps installed on the system without needing admin rights.

0 REPLIES 0