Chocolatey’s publicly-available community packages are a great resource for personal use and help you quickly install just about all the software you’d ever need on Windows. But they’re definitely not suitable for organizational use and can open your company up to legal, security, and all sorts of other hassles if you’re not careful.

Fortunately, there are two easy things you can do to help: “privatize” and “internalize”.

In this article, we’ll cover how to do both, as well as explain:

• How Chocolatey works behind-the-scenes
• Why “Community Packages” aren’t for Organizations
• Difference Between Privatizing and Internalizing 
• 3 Chocolatey Internalization Options

Let’s get into why privatizing and internalizing Chocolatey community packages allow you to meet your organization’s security and control needs.

Chocolatey Behind-the-Scenes

A first glance, Chocolatey seems like a kind of “app store” where you can download and install Windows software packages with just a single command:

However, this is a common misconception. Chocolatey is not an “app store”, and Chocolatey packages are not “apps” like you might expect. Whether you’re using Android or Debian, “apps” are almost always self-contained packages.

Chocolatey packages are not self-contained. It’s impractical and impossible to make self-contained packages due to the Chocolatey client’s technical limitations when dealing with massive files. Not to mention the legal and licensing limitations of redistributing software.  

Instead, most Chocolatey packages on chocolatey.org (i.e. Community Packages) are simply PowerShell scripts that are packaged in a .zip file. When “installed”, Chocolatey will execute the script, which will usually download an installer file from the internet and run it.

Basically, Chocolatey downloads a file to download the file. 

Why “Community Packages” aren’t for Organizations 

Community packages from chocolatey.org are fine for most individual users, just a regular “app store” is suitable for most individual users. The packages on chocolatey.org will install software users could download themselves on the internet, just in a more convenient way.

Very few organizations allow users to install any software they’d like on their workstations at any time. There’s a good reason for this: controlling which software is installed on machines reduces operational and security risks, as well as maintains productivity. 

Because of the way Chocolatey works – i.e. downloading scripts to download installers – the lack of control is effectively doubled. 

This also amplifies the concerns of users installing their own software: 

•  Reliable Workstations; there’s a lot that can go wrong during installing  an application, and adding automation scripts to the process adds complexity
• Use Old Versions; download URLs for third-party software can change, and it’s very unlikely that old versions of Community packages will be updated
• Protect from Malware; the risk of unwanted code running on machines is effectively doubled, as there’s now the Package Script and Installer File to worry about 
• License Compliance; automating software installation means that users can’t read license agreements, or verify the software is acceptable for use 

On top of this, Chocolatey.org has strict rate-limiting policies in place,  which means that your entire organization might be temporarily blocked if more than a few users behind your firewall try to consume packages at the same time.  

Fortunately, it’s relatively easy to control Chocolatey packages, as well as provide offline accessibility by privatizing and internalizing your Chocolatey packages. 

Privatization + Internalization

Given the various concerns with providing users unfettered access to Chocolatey community packages, many IT Administrators will set up a private Chocolatey repository to host the Chocolatey packages that users are authorized to install. This is what Chocolatey.org recommends as well, and it also provides users with a list of software they can use.

How to Privatize Chocolatey Packages

“Privatizing” Chocolatey packages works similarly to “privatizing” permitted installer files to a shared drive. Just download the package file from Chocolatey.org, and upload it to your own repository.

Users will then need to change the default package source from Chocolatey.org to the private repository’s web address. The package source is what the Chocolatey client uses to look for packages and can be changed with just a simple command.

choco source add
  -n=private
  -s="https://proget.corp.local/nuget/private-choco"

After that, users will only be able to access the packages you’ve “privatized”. However, as I mentioned earlier, only privatizing your Chocolatey packages isn’t enough.

⚠ Private Chocolatey Packages are Meaningless

Remember that Chocolatey packages are not self-contained: they simply contain a script that downloads an installer file from the public internet. 

A repository with privatized-only Chocolatey packages is like having a wiki page with a list of public URLs that users can download software from. There’s no guarantee that the installer files behind those URLs will still be available when users need them – or worse, that someone won’t replace them with malware in the future.

This is why you also need to internalize your private Chocolatey packages.

How to Internalize Chocolatey Packages 

“Internalizing” means modifying Chocolatey packages so that it does not need to download an installer file from the public internet. There are two ways to go about this: 

1. Embed the Installer Files in the package, and then modify the package script to use the embedded files instead of downloading from the Internet
2. Privatize the Installer Files by putting them on an internal server, and then modify the package script to download from your internal server

Both of these approaches will give you control of which software is installed with Chocolatey, as well as making older versions work when needed – and all of this without internet access.

Privatizing Installer Files is Preferred 

Generally speaking, privatizing the installer files is the better approach for two reasons:

• Chocolatey wasn’t designed to have large package files, but instead contain scripts that downloads and run installer files; this means performance or other issues may happen with large package files 
• Users can still access the installer files directly if they want to use something other than Chocolatey 

In either case, if the package scripts and installer files aren’t both on your private server, then they’re not in your control. 

3 Ways to Internalize Chocolatey Packages

As I mentioned before, internalizing Chocolatey packages involves modifying a package by either embedding the installer files inside the package or privatizing the installer files.  There are three ways you can go about this. 

Option 1: Manually Internalizing

It’s relatively easy to internalize a Chocolatey package by privatizing the installer files.

1. Download the package file from Chocolatey’s community feed
2. Rename the downloaded file to end with .zip, and then unzip it
3. Open the tools\chocolateyInstall.ps1 script
4. Locate the installer file’s url, and download it to your private file server
5. Edit the tools\chocolateyInstall.ps1 script to point to your private file server instead of reaching out to the internet.
6. Zip the file back up and rename it 
7. Upload the new file to your private package server

For example, if you wanted to internalize the  Notepad++ package, you’d see the tools\chocolateyInstall.ps1 script looks like this:

Install-ChocolateyZipPackage 'notepadplusplus.commandline' 'https://notepad-plus-plus.org/repository/6.x/6.8.7/npp.6.8.7.bin.zip' "$(Split-Path -parent $MyInvocation.MyCommand.Definition)"

It’s pretty obvious where Chocolatey would download the installer file from. You’d just need to download that installer file to your private server, and then modify the script: 

Install-ChocolateyZipPackage 'notepadplusplus.commandline' 'https://proget.corp.local/endpoints/private-installers/notepad-plus-plus/npp.6.8.7.bin.zip' "$(Split-Path -parent $MyInvocation.MyCommand.Definition)"

Embedding the installer files is a bit more complex, and the Chocolatey documentation provides a step-by-step guide for embedding installer files in Chocolatey packages.

Final verdict? While you certainly get minute control over the steps, it’s a slow and tedious process if you have a lot of packages to internalize often. 

Option 2: Automated C4B 

Chocolatey for Business (C4B) is a paid service that comes with an automated internalizing system intended for business and organizational use. C4B can automatically download packages and resources, edit the scripts, and recompile packages to internalize and remove internet dependencies from those packages.

The entire process takes about as long as it takes to download the remote resources and goes through some steps: 

• It downloads a package locally.  
• Looks at the install script to determine if there are remote resources.
• Those remote resources are downloaded to a directory in the package (or with another switch that will be placed on a file share or set up for an HTTP location).  
• Edits the install script to use the local resources instead and recompiles the package.  

Final verdict? Automates an otherwise lengthy and tedious process but at a premium. 

Option 3: Automated Choco-Remixer

Choco-Remixer provides free internalization automation. It automates some tasks involved in maintaining a private Chocolatey repository, specifically focusing on repositories hosted on Nexus and ProGet. Choco-Remixer checks for packages that are out of date and updates them. However, it is still being actively developed and may not be 100% stable.

Choco-Remixer’s setup follows these steps: 

• Clone the Choco-Remixer repository.
• Note that installed and working Chocolatey is required.
• Copy .xml.template files to .xml and edit them. 
• If you are using the automatic pushing, make sure Chocolatey has the appropriate API key setup for that URL. 

Final verdict? It’s free! But it also may not be stable. 

Conclusion & Next Steps

Chocolatey is a fantastic resource and makes installing software on Windows just as easy as using an app store. But, as discussed, Chocolatey is not quite like an “app store”, and community packages aren’t at all suitable for the enterprise.

Fortunately, you can mitigate the risks of community packages by privatizing and internalizing them before rolling them out in your organization.  This is one important best practice, but there are many more things you’ll need to do before implementing Chocolatey.

Sign up below to receive your free Chocolatey for the Enterprise eBook below.