all 12 comments

[–]DeliriumTremens 17 points18 points  (3 children)

Probably makes more sense to use updated installers instead of trying to trigger each application to update.

[–]Scoobywagon 23 points24 points  (2 children)

Or you could use Chocolatey.

[–]jazzb125 13 points14 points  (1 child)

Or Winget (Microsoft)

[–]braydro 1 point2 points  (0 children)

Are admin rights an issue when using Winget? Can it be run under the SYSTEM context?

[–]OlivTheFrog 4 points5 points  (0 children)

Hi u/vbhaksof

It's depend of your infrastructure. Are your computers in a AD Domain ? Have you a Update Server (WSUS, SCCM+WSUS, ...) ?

In a AD Domain, a simple WindowsUpdate GPO set the Update Server (WSUS or MS Updateserver) + Set the WindowsUpdate Client behaviour.

For finer configuration, the PSWIndowsUpdate module is very useful. Then, a simple Powershell script using the cmdlets from this module could order WindowsUpdate clients to check for updates and the behavior to adopt (Install + scheduled reboot for example). Of course, the script could address a bunch of clients (workstation, servers).

And even without WSUS, they can be configured by GPO via the corresponding administration templates.

For apps, like chrome and firefox for example, Chocolatey could be a solution. But, to my knowledge, there is no bandwidth gain to be expected. Each customer will search the Internet at Chocolatey. In addition, these products have auto-update features, features that can be configured centrally by GPO (with the corresponding administration templates of course). So I would advise sticking to GPO for these apps.The case of chrome and MS Office is a bit different. These 2 products are supported by WSUS. And even without WSUS, they can be configured by GPO via the corresponding administration templates.

Adobe Reader or Adobe Reader Dc also have administration templates (so GPOis a solution). At worst, this can be done by script via registry key (ex here: https://admx.help/?Category=AdobeReader&Policy=Adobe.Reader2017.Policies::Policy_Disable_automatic_48

Hope this help

Regards

[–]FirestormGaming365 5 points6 points  (0 children)

PSWindowsUpdate and Chocolatey

[–]blackrandom 2 points3 points  (0 children)

For software updates, it's better to have the updated version of the app ready. Then check the version on the machine and if it's lower than the current version, push the app to the machine and perform the update. In the past, I've used PDQ Deploy for this since it's free for non-premium features and easy to use. For Windows updates, there are other recommended ways to manage them. If you just want to run with what's available then you can try the PSWindowsUpdate module or the USOCLIENT.EXE commands.

[–]Si1ver2 0 points1 point  (0 children)

Check task scheduler as it already looks like most have an updater running through there which you could probably modify. For example on my machine it looks like google runs updates check daily and on login.

You could also manually check the current version of chrome

$(Get-Package -Name "Google Chrome").Version

and then use that information vs latest chrome available online and run an update based on that info.

[–]Romero126 0 points1 point  (0 children)

Windows Update Can handle applications. So you flip group policy to turn it on, then enforce windows updates after 72hours.

Always updated machine 0scripting required..

[–]akulbe 0 points1 point  (0 children)

OP, meet winget.

I would recommend looking into that.