Install packages at setup

When onboarding a new user we have a setup script to install chocolatey packages, then as determined by the policy the third-party patch management will keep them up to date.

Is it possible for the third-party patch management to install all listed applications when the agent is first installed as well as its scheduled update time?

I am interested in this too. At least give us the ability to fire off a third-party update manually or in the script scheduler.

Kind of, not really, workaround! On the 3rd party policy, you can choose items for Install and Update, but that may not work for every system. The other option is to script it, which is what most of us do. The environmental variable Choco will be available after a reboot. You can then push installs via scripts. Here’s one I use for one off installs. The app variable has a list of apps I’ve added to be able to choose from. If you want to install multiple apps at once, you separate them with a ; such as firefox;googlechrome;microsoft-edge. You only need line 3 to make the script work, the rest is to log installed packages to a custom field.

Yea, we’re doing exactly the same thing only with multiple dropdowns so that we can install multiple packages at once.
It would just make sense for the patch management to do it all.

EDIT: We don’t have that wee $action dropdown, might steal that idea! thanks!

For anyone wanting to try the multiple dropdowns, the code is:

$chocoApps = @(

$chocoApps | ForEach-Object {
    if ($PSItem -ne "") {
        choco install $PSItem -y

(If a package isn’t selected it’ll ignore it)

1 Like

I add packages to the dropdowns in multiples, haven’t had a need to choose outside this list. So if I wanted to update FF/Chrome/Edge, I’d choose that dropdown. Uninstall all versions of flash, I choose that dropdown list. Your way is more flexible, I just haven’t had any reason to go that complex. $action is nice because you only need one script to install, update, or uninstall.

Have you uploaded this to the Community Script Library?

Totally stealing this :slight_smile:

Most of the packages you would install via Choco you can set in a big group. Use the Policy / Policy Modules dropdown (upper right) / Third Party Library Patch Management library. Add custom group, then select Additional Apps Manage to add all the Choco packages you would want for this type of user.

For example if you support developers, you can add Git, Putty & VScode in a group and have it auto deploy with the policy. Just note this is not additive like the new nested policies. You will need to list all the packages you need. Then for other single packages use the script above.

I have done this, and its GREAT! The only thing is its reliant on a schedule to run (Daily/Weekly/Monthly), where as I want it to run on command (like when im actually setting up the device). I worked around this my changing it to daily and just ahead of what my current time is, but sorta annoying. Or by doing what Jimmie said and “app;app;app” the variable.

Anyways, this thread has completely changed my workflow for the better. Thanks All!

Thanks for the tips here as well, all. I’m goofing around with app script installs and trying to refine how I want to do this standard in the future. I’m looking at getting away from the built-in method of choco app patching, as we get a lot of users that complain about new icons on the desktop.

I found this tidbit earlier, in case it helps anyone else with Desktop icon clutter. My initial testing shows it works just fine. Wrap these lines around your choco action line:

$StartTime = Get-Date
choco $action $app -y
$Desktops = “$env:PUBLIC\Desktop”, “$env:USERPROFILE\Desktop”
$Desktops | Get-ChildItem -Filter “*.lnk” -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -gt $StartTime } | Remove-Item

If it installs or updates an app, no icon is left behind on the desktop. (Uninstalls should be irrelevant to this code)

Also looking at adding a choco update all -y script to our policies, wrapping the same code around the choco line. That was the main reason that set me down this path, there’s no way to wrap the built-in code with desktop cleanup routines.

I can see where this may cause a problem with certain apps where the user wants a desktop icon…this is all still testing on my side so any input on that line of thought would be appreciated!

1 Like