Chocolatey packages contain PowerShell scripts that manage the desired software. It's a very flexible and powerful solution, since the scripts can deal with all kinds of checking and tweaking.
Also take a look at repository.
Chocolatey is a solid package manager, but the question with Chocolatey is the quality of the packages. Not the architecture of the package or Chocolatey, but the scripts inside the package.
The challenge with building a good package is to collect the information that is necessary to make the deployment silent, to not restart the computer, close programs, etc. This is a common challenge regardless of the deployment method. Chocolatey helps with this too.
The web portal helps you manage:
- Global settings (server settings)
- Package creation and package uploads
- Application and license inventory
- Wake computers (WOL)
- Remote PowerShell
On the start page, there's a "Global settings"-link up in the right section of the page. On that page, you can change the global settings for your server.
Note that if no user has claimed the "Global admin"-role, any user can. This is the first thing to do after setting up your own server, and if you didn't have this feature before you updated to new Deployify server version, this feature will now be added and the same principle applies.
- *emailEnabled = Enables or disables the email service. This setting must be activated to be able to use 2FA and reset password!
- *resetPasswordEnabled = Enables or disables the reset password functionality.
- *twoFactorAuthEnabled = Enables or disables the 2-factor authentication functionality. If enabled, users can enable 2FA in their user settings.
- webUnsealEnabled = Enables or disables the Web Vault unseal functionality. If enabled, the server won't unseal the Vault on start-up.
- !*publicSignupEnabled = Enables or disables the Public sign up functionality. If enabled, the option to sign up is not available, and users with the "Global admin"-role can add user accounts (link will appear on the start page).
- *removeOldUninstallCommands - Enables or disables the optimization that removes old uninstalled packages with status "uninstall" and "done" that are more than a year old.
- *removeOldUninstalledApplications - Enables or disables the optimization that removes uninstalled applications that are more than a year old from the database. This keeps the database in good shape.
* = recommended to enable this is setting
!* = recommended to disable this is setting
E-mail settings to be able to use the email service.
Here you can add your license from the License portal.
Users and roles
A list of users and their roles. Here you can add the "Global admin"-role to other users.
Each domain has its own space. A domain contains all information, like computers, groups, etc. Domains are isolated from each other. This is to be able to separate for example one company from another, or however you want to separate these. Computers in a domain can communicate with each other (locally) to share packages etc.
Every domain also has a separate computer Installer (MSI) that contains a secret key (pairing key). That key is changed every time a new computer installer is being generated in the web portal, so that a lost computer Installer doesn't work for future installations.
Groups contains a selection of computers, and packages for these computers.
For example, you can:
Name a group “My Office”, add all computers in your office to that group, and add multiple applications to it like 7zip, Adobe Reader etc.
Or, add a group named “Office 2016” and add all computers you want to have Office 2016, and then only add the app Microsoft Office 2016 to that group.
The nice thing with this is that when you later add a computer to one of your groups, that computer will automatically get all the apps that you have added to that group.
Consider group packages as policies. An installed group package will tell your computers to install that package according to your schedule (if any), but the actual deployment status of that package is in your computer view or in the group stats.
For example, if a group package says “Command: Install”, it means that the policy for that package and selected version is to install that package on the computers in that group, when possible.
Group package schedule
The schedule will be active between the start date and end date. It will run if the time range and week days are matching the current time of the computer.
Here's an example of keeping an application up to date (every day between 00:01 and 23:59, until year 10 jun. 2022).
Application and license inventory
Collects all applications for all computers, and licenses for some applications like Microsoft Windows, Microsoft Office, AutoCAD etc. This was dependent on ProduKey.exe, which was being flagged by antiviruses. Not that ProduKey is unsafe, but it was too inconvenient. Now Deployify has its own implementation of reading the product key of the Windows OS and adding that to the computers inventory.
The website provides a complete list of all installed applications, and applications ever existed since installation of the Deployment client. This is handy if you are reinstalling a computer but lost the license key, or just want to keep track of what is installed on the computers.
There are two views, one for a single computer and one for all computers. In the view for a single computer, you can right click on the application (license field) and edit the license. In the view of all computers (link is in the domain view menu), a collective view appears that makes it easy to see all computers that have that program.
It can have some false flags, but that should not come as a surprise as the Deployment client can add a new user (to set itself up), receive remote commands, run PowerShell commands, and so on.
Download the MSI package in the domain view.
Installation package will:
- Copy files to %programfiles%\JAHA IT\Deployment client\.
- Install Deployment client as a service.
- Create a user named "deployment client". The user is for running deploymentclient.exe as a service.
- Generate a strong, random password, for the service user.
- Add service user to local administrators group.
- Start the service.
Note that the service password is not stored. We don't know the password and you don't know it. No one does. The local system account could be an alternative, but that is less secure and also doesn't work for some deployments.
- Install/upgrade Chocolatey.
- Pair client with server.
- Open ports in firewall (local network socket - 44444, local NuGet server - 44445, multicast - 44446).
- Check settings etc.
The installation package (MSI) contains a pairing key that is generated when you are downloading it from the Web portal. The pairing key is bound to the specific domain with a chosen expire date. After the MSI is installed on the computer, the service will start and pair the client with the server.
Pairing means that the computer gets a new unique key from the server with the help of the pairing key. The new key is bound to that specific computer (while the pairing key is not). The pairing key will be deleted after the pairing is completed.
Now that the computer has the computer-bound key, the first step to connect the computer to the server socket is to get a temporary authentication key. To do this, the computer first generates a time-limited token with hashed computer information that is used for asking the server for the temporary authentication key. When this is done and the temporary key is received, the connection socket connection can be made. The temporary key is invalidated the moment it is used.
This is a complicated authentication procedure that makes it hard to replicate for bad intentions. Not only for the process itself, but because of the information, timings and other information involved.
- Managing Chocolatey
- Synchronizing existing software
- Keeping track of schedules
- Managing local network sources
- Repository protection mechanism
Makes sure that Chocolatey is installed.
Synchronizing existing computer software with packages that exists in your package feed(s). E.g. if 7-zip is installed on a computer and exists in any of your feeds, then it will show on the website as installed. This means that you gain control of your software so that you can manage it immediately.
Keeping track of schedules, so that commands are being executed in the desired time window.
This is a beautiful feature that free up your internet connection.
Let's say you want to deploy an application with a size of 1 GB on 10 computers. If all of them would download the package from the repository at the same time, the internet connection of your repository would choke (or at least be awfully slow). Deployment client solves this by letting one computer install the package first, and then tell the other computers to install the package from that computer when the installation is complete. It also makes sure that the computer that is downloading the package is the computer on the network with most resources.
So, as long as the package exist on some computer in the local network, then that computer will be the source for other computers in the same network.
This feature use secure communications and many measures to make sure that the package is the right one, and will only use computers in the same Deployify domain, with local authentication.
This is how to install a package on multiple computers simultaneously (group package).
There are two computers in the group, and the first computer first installs the package, and then the other computer install the package with the first computer as a package source, locally.
Note that this feature only applies for the repos that are included in Deployify.
If you are managing applications for multiple organizations, you may not want the organization to be able to access your repo. The URL to your feed can be logged or sniffed when Chocolatey installing packages, but with this feature that's not a problem.
First, the API key is never sent to your computer. The computer generates a token based on information that only the Deployment Client and the repo server has. The token is then baked into the URL that is passed to Chocolatey as a "source". That token is only valid a short time period and only have read permissions. The generated URL can still be used to download packages from the repo but only for a limited time period, and since there is only read permissions, no changes can be made with the generated URL.
What's a package feed/repo?
It's simply a web service that contains information about packages, where to download them, and the packages themselves. Sometimes it's called a repository, repo, feed or just a source.
Chocolatey doesn't need a package feed, it can install packages directly from a file, or just a folder with package files (.nupkg).
You can have multiple feeds added in the Web portal. This let you access all packages through one portal. The URL to the feed is stored in the Deployify database and pushed to the client on connection. See Repository protection mechanism in the section above.
Deployify provide you with a private and secure package feed automatically when you are signing up, but you can add as many as you want.
There's also a community feed that contains 5200+ packages that is automatically added to your portal.
It's easy to create a new package. Choose a file, fill the form, and then upload. The engine detects fields from the uploaded file, if not, you will get a notice of what fields are missing and get a chance to correct them.
The most important fields are id, version and silent install argument (default is /S).
Easier than creating a package. All fields but the version field is be pre-filled, based on the package are updating.
How to Get Started