Chocolatey packages contains powershell scripts that manage the desired software. It's a very flexible and powerful way to do it, since the scripts can deal with all kinds of checking and tweaking.
Also take a look at package feed.
Chocolatey is a solid package manager, but the question with Chocolatey is the quality of the packages. Not the architecture of the package, 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, not restart the computer, close programs, etc. This is a common challenge Regardless of the deployment method.
The web portal helps you manage
- Package creation and package uploads
- Computer applications
- License inventory
- Wake computers (WOL)
Note: to get the latest version of the Web portal, remember to clear your browser's cache.
Groups makes it easy to deploy applications on multiple computers simultaneously.
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.
the applications you add in a group can only be managed by the group, and lock the ability to change it separately in the computer view. This has changed. The package will be applied with the "force" flag, and the group package will be ignored.
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. Repeat (only for upgrades) means that the schedule will run the upgrade again if a new version is available and schedule is matching.
Here's an example of keeping an application up to date.
This schedule is probably not be a good idea to use in production since the whole idea is to delay installations to a time when the user is not affected. Setting the time range outside of the office hours would be wiser.
Collects licenses for some applications like Microsoft Windows, Microsoft Office, AutoCAD etc.
It also provide 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 double click on the application and edit the license for manual input (double click again to save). In the view of all computers, a collective view appears that makes it easy to see all computers that have that program.
The installation package contains a pairing key that will be generated when you are downloading it from the Web portal.
MSI installation package will:
- Copy files to %programfiles%\JAHA IT\Deployment client\
- Install Deployment client as a service
- Create two users, one named "deployment client", and one named "dpshare". First user is for chocolatey, and second is for sharing packages with other deployify clients in the same network (only authenticated in the same domain).
- Generate a strong, random password, for the user.
- Add user to local administrators group.
- Start the service
Note that the 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 software deployments.
- Install Chocolatey
- Pair client with server
Web portal generates an MSI file that contains a key 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 client gets a unique key that is used for authentication against the server. But, even if someone copied this key to another computer, it would not be valid because it's bound to the specific computer.
So in the end, when the pairing is done, the real authentication is via a token (valid for a short time) that gets invalid the moment it is used. This makes it almost useless if it'd get into other hands.
The only way it would be to any use, would be if someone miraculously sniffed the token and used it before the original computer's authentication is complete, and within the timeframe it is valid. If you’d have that kind of an attack in your network, you'd probably have other more serious security issues than the authentication method of the Deployment Client.
- Managing Chocolatey
- Synchronizing existing software
- Keeping track of schedules
- Managing local network sources
- Feed protecting mechanism
Makes sure that Chocolatey is installed.
Synchronizing existing computer software with packages that exists in your package feed(s). Eg. 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.
A valuable feature that helps you not to choke the internet connection at the site of multiple computers.
Let's say you want to deploy an application with a size of 1 GB on 10 computers. If all of them would pull down the package at the same time, both the internet connection of the site, and the feed for that matter, would choke. Deployment client solves this by letting one computer install the package first, and then let the other computers get the package from that computer when the installation is done. It also makes sure that the computer that is downloading the package are the computer on the network with most resources.
So, as long as the package exist at some computer in the local network, it will be fetched locally by the other computers in the same network.
Just remember that it has to be a self-containing package to be beneficial.
Note that this feature only applies for the feed that is included in Deployify.
If you are managing applications for multiple organizations, you may not want the organization to be able to access your feed. The url to your feed can be logged or sniffed when Chocolatey installing packages, but with this feature that's not a problem. The url contains a token that is only valid a short time and only have read permissions. The API key is never exposed.
The Deployment client generates the token, containing time and a signature.
What's a package feed?
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, 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 our Web portal. This let you access all packages through one portal. The url to the feed are stored in the Deployify database and pushed to the client on connection, but never stored (except in RAM). See Feed protection mechanism in the section above.
There's also a community feed that contains 5200+ packages that is automatically added into your portal.
Note that most of the packages in the community feed doesn't contain the actual software due to the lack of rights to distribute them. And since the packages doesn't contain the software, you don't have any use of the local network source feature we provide with the Deployment client. That's why we have made it really easy to create your own self-contained packages.