Chocolatey on Windows Server: Install and Update Software from the Command Line

Every Windows Server administrator has spent an afternoon clicking through the same installers: Git, 7-Zip, Notepad++, .NET runtimes, Sysinternals tools. Chocolatey — a package manager for Windows — turns that into one command per package, or one command for everything. This guide covers installing Chocolatey, the commands you will use daily, and the packages that matter on a server.

Install Chocolatey

You need PowerShell 5.1 or later and outbound HTTPS access. The official install script is a single PowerShell command (run it in an elevated console):

Set-ExecutionPolicy Bypass -Scope Process -Force
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072
iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

Before you pipe any remote script into an elevated shell, download it and read it first — the same advice applies to this one. Chocolatey installs to C:\ProgramData\chocolatey and adds choco to the system PATH; open a new console after installing.

Core Commands

CommandWhat it does
choco search <name>Search the community repository
choco info <name>Show versions, description, and dependencies
choco install <pkg> -yInstall silently (no prompts)
choco upgrade <pkg> -yUpgrade a single package
choco upgrade all -yUpgrade every installed package
choco listList installed packages
choco outdatedShow packages with newer versions available
choco uninstall <pkg> -yRemove a package

Packages Worth Installing on a Server

Install several packages in one go — Chocolatey resolves and installs them sequentially, and -y keeps everything silent:

choco install git 7zip sysinternals dotnet-8.0-runtime nuget.commandline curl -y --no-progress
  • git — source control and Git Bash on Windows.
  • 7zip — archive handling for logs and backup files.
  • sysinternals — Process Explorer, Autoruns, and the rest of the troubleshooting kit.
  • dotnet-8.0-runtime or dotnet-sdk — run or build .NET applications without hunting for offline installers.
  • nuget.commandline — restore packages inside build scripts.
  • openssl — inspect certificates and keys from the command line.

Export, Import, and Reproduce a Server

choco export saves your entire package list to a file, and choco install accepts that file, so you can recreate a known-good server state on a fresh box:

choco export C:\packages.config
# on the new server:
choco install C:\packages.config -y

Combine export with version pinning for reproducible builds: a new server ends up with the same tools, same versions, same flags as the one it replaces. This is the closest Windows gets to a requirements.txt for system software.

Sources and Private Feeds

By default, Chocolatey uses the community repository at community.chocolatey.org. choco source list shows your configured sources, and you can add a private feed — for example an internal NuGet server or a Chocolatey for Business repository — with:

choco source add -n=internal -s https://packages.example.com/repository/choco -p

Keep the community source enabled unless your organization requires full isolation. Packages from both sources are installed the same way; the source only determines where the package and its scripts are fetched from.

Keep Everything Updated

The command that pays for itself is choco upgrade all -y. Pin anything you do not want touched — for example a runtime your application depends on:

choco pin add -n=dotnet-8.0-runtime
choco upgrade all -y --except="'dotnet-8.0-runtime'"

Schedule the upgrade as a weekly task so patching is not a manual chore. A scheduled PowerShell task that runs choco upgrade all -y and writes the log to a file is enough for most single-server setups.

Run choco outdated before each maintenance window to see exactly what will change, and skim the Chocolatey log afterwards for failed packages — one pinned package failing should not stop the rest of the upgrade from completing.

Security Considerations

  • Community packages run install scripts with administrator rights — check choco info <pkg> and read the package’s install script before deploying to production.
  • Prefer packages published by verified software vendors where available, and pin versions instead of always taking the latest.
  • Run choco audit to scan installed packages for known vulnerabilities.
  • For stricter control, Chocolatey for Business adds private repositories, package approval workflows, and audit reporting.

If your server hosts .NET applications, remember that Chocolatey keeps runtimes updated but does not manage IIS application pools or recycling settings — those stay your job.

Troubleshooting Common Failures

  • “choco is not recognized”: the PATH change needs a new console; close and reopen it, or re-run the install script.
  • Access denied or exit code 1603 during MSI installs: the shell is not elevated, or a Group Policy blocks Windows Installer — see our guide to enabling program installation on Windows Server.
  • An install hangs: check C:\ProgramData\chocolatey\logs\chocolatey.log — it records every step and the exact failing command.
  • “Package not found”: verify the exact package ID with choco search; some tools ship under suffixes such as .portable or .install.

Chocolatey shines when you provision servers repeatedly. If you are setting up a fresh Windows box, review the configurations in our Windows server feature overview and compare Windows server plans on our comparison table so the hardware matches the workload you are about to install.

Compare Windows server plans with enough storage and RAM to run your toolchain comfortably.

Leave a Comment