Package Zoom (the latest version) with winget as an Win32 App in Intune (2/2)
Вставка
- Опубліковано 31 гру 2022
- In this video, we package Zoom client with always the latest version with help of a command line update tool called winget.
(to see first video go: • Package Zoom (specific... )
We package it as a Win32 app in Intune and put it in the company portal.
The problem is since we don't know what is the latest version we cannot hardcode the detection rule to a specific version to check for. Instead, we create a detection script that does the checking for us.
I did pretty many errors in this video, so be sure to copy the scripts from this description that are correct and working, the logic and thoughts in the video are however correct.
==Install script (PowerShell)==
Install Zoom latest version using winget
Author: John Bryntze
Date: 20th December 2022
Find path to winget.exe
$JBNWinGetResolve = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe\winget.exe"
$JBNWinGetPathExe = $JBNWinGetResolve[-1].Path
$JBNWinGetPath = Split-Path -Path $JBNWinGetPathExe -Parent
set-location $JBNWinGetPath
Run winget.exe
.\winget.exe install -e --id Zoom.Zoom --scope=machine --silent --accept-package-agreements --accept-source-agreements
==Detection Script (PowerShell)==
Purpose: Checking that local installed Zoom is equal or greater to the latest online
Author: John Bryntze
Date: 20th December 2022
Find path to WinGet.exe
$JBNWinGetResolve = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe\winget.exe"
$JBNWinGetPathExe = $JBNWinGetResolve[-1].Path
$JBNWinGetPath = Split-Path -Path $JBNWinGetPathExe -Parent
set-location $JBNWinGetPath
What is the latest version of Zoom online
$JBNSearch = .\winget.exe search -e --id Zoom.Zoom --accept-source-agreements
$JBNOnlineVersion = (-split $JBNSearch[-1])[-2]
What is the version installed
$JBNLocalSearch = .\winget.exe list -e --id Zoom.Zoom
$JBNCheckIfAvailavbleExist = (-split $JBNLocalSearch[-3])[-2]
if($JBNCheckIfAvailavbleExist -eq "Available")
{
$JBNLocalVersion = (-split $JBNLocalSearch[-1])[-3]
}
else
{
$JBNLocalVersion = (-split $JBNLocalSearch[-1])[-2]
}
if($JBNLocalVersion -eq "input")
{
write-host "Zoom is not installed"
exit 1
}
if($JBNLocalVersion -ge $JBNOnlineVersion)
{
Write-Output "The Device got the latest version of Zoom installed"
exit 0
#Detection success
}
else
{
exit 1
#Detection failed
}
Sir - You are freaking awesome. I am so glad I found your channel and I have sent your channel to my whole team. Very, very informative!
happy to hear sir, and thank you very much for spreading the content. I usually post at least one video per month, due to sickness and such in family been a bit slow this month, but more content is coming regulary :)
Big fan of your videos, really helpful!
thank you so much Patrick! I currently released 7 videos about Oracle Java which I don't think will attract so many, but got some videos coming up soon about more information about Autopilot and Win32 videos that I believe might be more intersting.
thanks for share! :)
Zoom versions are actually interesting. Probably not affecting much an Win32 app, but detection for proactive remediation for example will be tricky. Example at the moment I'm writing this message if you search with winget for latest Zoom.Zoom you will find "5.14.5.15287". When you install it and check (list) local version with winget or control panel or reg key, it will miss the build version ".5" and it's seen as "5.14.15287". So, comparing the full strings will never work. I'm basically using the revision number which are the last 5 digits "15287", but based on the version in your video, looks like we will always have to play with detection script. I did open a ticket with Zoom and Microsoft. Zoom said this is by design and MS doesn't look to be willing to update it on there side.
Getting into this .....
Hi everyone, sorry I did (another) mistake in the Detection Script, if you followed along with this one and it is not working, keep your intunewin file that one is fine, but the Detection Script had a flaw where I forgot to check if no version is installed at all... thanks Abdul for providing me test files to test this out.
Recopy the Detection method Script from the Description of this video, I have updated it, the missing part is, that is since if the software isn't installed the variable gets the first word that says "input" :)
if($JBNLocalVersion -eq "input")
{
write-host "Zoom is not installed"
exit 1
}
I was looking at this. What if you have multiple language computers ?
In French, for example, we don't have "input" neither in German or Dutch. How could we make it? Is there a way to do it?
Available = Disponible (in French) = disponibile (in Italian) = verfügbar (in german)
Is there a way to have winget always in english?
good question, if it is not an English base OS and like French MUI on top, let's say a French-only install there is no known way for me to make the output in English since the OS only knows French.
But if you know your OS languages, it is very easy to modify the script to look for multiple things, just add a
#Check English
if($JBNCheckIfAvailavbleExist -eq "Available")
{
$JBNLocalVersion = (-split $JBNLocalSearch[-1])[-3]
}
#Check French
elseif ($JBNCheckIfAvailavbleExist -eq "Disponible ")
{
$JBNLocalVersion = (-split $JBNLocalSearch[-1])[-3]
}
#Check Italian
elseif ($JBNCheckIfAvailavbleExist -eq "disponibile ")
{
$JBNLocalVersion = (-split $JBNLocalSearch[-1])[-3]
}
#Check German
elseif ($JBNCheckIfAvailavbleExist -eq "verfügbar")
{
$JBNLocalVersion = (-split $JBNLocalSearch[-1])[-3]
}
Hello, I will try this to change temporally the language into US:
# Get current language and save it
$OldLG = Get-WinUserLanguageList
$RestoreLG = $OldLG.LanguageTag
# Language I want to use in my script
$USLG = "en-US"
#Set Language to my preferred language
set-WinUserLanguageList -LanguageList $USLG -force
#Run script with winget in my preferred language
Winget list vlc
#Restore initial Language
set-WinUserLanguageList -LanguageList $OldLG -force
Do you think it could work?
I will edit my comment if it works.
@@IntuneVitaDoctrina I have 27 languages to manage, so I don't think it's a solution, I probably can't test winget in all languages to have the result for each one :)
I'm glad to tell you that my workaround to manage computer language with winget did work !
Great video. Appreciate the detail. Question for you, my understanding was that the new MS Store backend is Winget now and if the app is available there, doesn't MS Store auto update it whenever there are updates available? In other words, if the app is published via new MS Store there is no need for remediation?
You are totally right! but look out if it exists as MS Store, if it does, use that, but right now not all are visible, you can see it in winget cmd output, here is an example for MS Teams, can see the ID is totally different and also and source is either msstore/winget.
Name Id Version Available Source
--------------------------------------------------------------------------------------
Microsoft Teams XP8BT8DW290MPQ 1.6.00.24873 msstore
Teams Machine-Wide Installer Microsoft.Teams.Preview 1.6.00.26163 winget
Think that could be another video for my channel :) thanks!
Hi John, I was thinking about the Apps you can configure as "Available" under Assignments, how to automatic update does apps if the user has installed them?
I haven't tried it my self but is it possible to run an upgrade for the app in the Detection script if winget finds "Available" or will Intune deny that?
Hi IT-Flex :) yes I do that a lot at my work, I have 50+ scripts that looks if the software is installed, and if it is installed check if it is Available meaning a newer software and then runs Remediation script, so if you follow this video doing it for VLC that does the trick
ua-cam.com/video/ea0g1Y1zaek/v-deo.html
@@IntuneVitaDoctrina The problem with Remedation is that it's only available to Enterprise customers.
I didn't think of that. Can you still push normal Powershell script under Devices/Scripts ? if so you could do a Schedule Task to run winget upgrade for a few software every second week or alike, you wont get the reporting other than in Software Inventory but it should work fine
@@IntuneVitaDoctrina I have now tested adding the upgrade line into the Detection script, if Available exist it will upgrade direct and then exit, and it seems to be working fine.
Hi John, when I upload the PowerShell script to Intune I see some garbage characters appear at the beginning but when I look at your video -- you don't have this issue. How did you fix this?
Hi Datoo, EXCELLENT question, and in some of my videos I fix it and in some I forgot.
This is 100% because edited in PowerShell ISE, you can fix it easily by opening your .ps1 script in Notepad++ and there do the following:
1. Menu item "Encoding" -> change from "UTF-8 BOM" to just "UTF-8"
2. Save (CTRL + S)
The issue is PowerShell ISE save with encoding UTF-8 BOM and Intune wants only UT-8
Very annoying that there doesn't seem to be a way to change PowerShell ISE default encoding, luckily Notepad++ fixes it quickly :)
Hey, when i run the Install Skript via Powershell as Admin, i get this Error:
Error browsing source: winget
Unexpected error while executing the command:
0x8a15000f: Data required by the source is missing
When i run it as non Admin, it works.
So winget.exe can exist in some different places, in user profile, so the admin one probably got a path to a bad winget.
The admin account, if you locate winget path, check path, try to run this command from that path
winget source reset --force
and
winget source update
You can be sure you done it right and it is a local profile/file issue,.
is it Windows 11?
@@IntuneVitaDoctrina yes its win 11. i couldnt start it from my local PC but the rollout with intune worked. now, after 2 weeks, my package doesnt work anymore, but i did no changes there. Any ideas?
Hi John, I tried following your video but using Postman app instead. I couldn't get it to work. So I tried to break it down by opening the cmd prompt in a system context, then navigating to the winget.exe in C:\Program Files\WindowsApps\microsoft.desktop...bbwe\ from PowerShell CLI and executing the command: .\winget install -e --id Postman.Postman --scope=machine --silent --accept-package-agreements --accept-source-agreements then error message I received: "No applicable installer found; see logs for more details." I was not sure where to see the logs or what else to do.
Cool that you try with another app, that what the purpose of the video because Zoom is not the best example.
Seems Postman.Postman only wants to install under user profile, so you will have to remove the "--scope=machine" switch and it works (tested on my device)
.\winget install -e --id Postman.Postman --silent --accept-package-agreements --accept-source-agreements
Thank you so much! I setup the software deployment in Intune with a User context and removed "scope=machine" from the WinGet install command. The installation went through. However, I got the notification that installation failed even though the detection script seemed to be fine. I tried copying the the detection script directly on the test computer and it detected the Postman app.
Well done, cool it worked, well sort of the detection script fails when running in Intune but not when you run it manually.
I wonder if the detection script runs always under SYSTEM (not sure here) however in your case you could nearly change and NOT use detection script, and instead change to look for a "File" and you look into %Userprofile%\ and the path to postman.exe and just check if it exists, that would work as well in this case
@@IntuneVitaDoctrina Thanks John, I tried to deploy the app to a standard user (non-admin) from Intune and Postman would not get deployed. By any chance, could you do a video for deploying an app (user context) to a non-admin user from Intune?
That is a great idea, Postman needs to install as user so --scope=user or alike is needed, and script should not run as SYSTEM but logged in user, I think I might use Postman as example for the video, good idea
I'm trying to implement this on Win10 machines without progress. Winget isn't installed by default and if I push out "App Installer"-app from Intune it is installed on the user so the Path does not work for the system.
Any ideas?
What version of Windows 10? the later should have it. Where exactly is the path, user path like c:\users\ ?
Sounds interesting and I think you are on right path to troubleshoot, if it is in users path SYSTEM will not find it
@@IntuneVitaDoctrina It's a Win 10 22H2, WinGet doesn't work/exist but I can install "App Installer" from Store then I can Run WinGet. The Path goes to %Appdata%.
The SYSTEM path doesn't exist.
But I searched around how install Winget for computer and found a PS1 that will do that but I haven't had the time to test it yet.
I have Win10 22H2 with winget in the good location, is it Windows 10 Enterprise/Professional? as long as it is not Home edition it should be good, but I could be wrong, so used to Windows 11 now, but I got Win10 a few at work and it works there
@@IntuneVitaDoctrina It's a Pro.
I pasted the script in a comment here an hour ago but now it's gone...
sad to hear, maybe a UA-cam filter or alike, I would love to have see the script
22:50 "The Device got the latest version install", how does Intune know what that means or is it just an "Output" it needs to know it is installed no matter what the Output say?
Excellent question, it looks for TWO things,
1. That there is an output, anything, you can even write "This Device does NOT have the latest..." so the text doesn't matter in this case
2. Exit code is 0
Both those must be true, if it is only exit 0 and no test output it fails to detect, and if only text output and no exit 0 it also fails
A bit long article that explains this well, but just scroll down to the matrix that shows this, that one is very good
call4cloud.nl/2022/08/the-ballad-of-buster-exitcodes/
Exit code Data read from STDOUT Detection state
0 Empty Not detected
0 Not empty Detected
Not zero Empty Not detected
Not zero Not Empty Not detected
@@IntuneVitaDoctrina Thank you for the answer and for the video.
Another question, is this line necessary, I got the same result without it: "$JBNWinGetPathExe = $JBNWinGetResolve[-1].Path"
the last line should give the path without the parent (parent = winget.exe) and the first line get with the file winget.exe in it, but we don't want that as our line specify it with switches.
Not sure what I wrote makes sense but they should give little different output, as the first first one give three lines, and we want only the last line in the variable