How can I deploy applications or software to my devices?
How to build a package?
I made a package but it's not working, can you explain the options?
Applications can be distributed through packages in BCM. Packages can contain binaries, scripts or any file there would be to distribute, whether it's executable or not, and whether there's a command line to execute or not.
Packages are built in a package factory, there are three types of package factories, Windows, linux and Mac OS X (as the OS the agent can be installed on). A Window package must be built in a Windows package factory, a linux package from a linux devices and a Mac OS package from a Mac OS device. This Knowledge Article (KA) covers the creation of a Windows package.
1- Set the packager:
By default, the master will be set as the package factory but any windows device can be set as a packager. In the SaaS, the master being a linux device the package factory is usually the First Relay.
It is also possible to set several package factories:
(1) is the new package factory that was added in the previous screenshot, (2) is the the master (that was set by default as a packager).
2- Find the command-line:
If the package is meant to run a command-line (from the package itself or from another step) then one must find the command line to run, and test that it runs when executed manually first. BCM does not make miracle: if the command line doesn't run manually, it will most likely not work when set in a package or in an operational rule step.
To find the proper command-line, either contact the manufacturer of the application, or use a search engine to find it on the internet. ItNinja is one of the best resources on the internet to find these command lines and/or advice on how to deploy a specific application. e.g for Notepad ++. Options that are not even documented on the editors sites can sometimes be found there.
3- Choose the type of package:
The type of package to use has to be chosen once the proper command-line has been validated manually:
A- MSI Packages
Msi can be installed within two different types of packages:
A1- the "MSI packages" factory:
The msi packager imports an msi and simplifies it settings by taking care of the most common switchs, such as installation vs uninstallation, silent or not etc. It builds the command line itself from these options and from the extra options that the user could set in the package configuration as well.
More information on the MSI packages in this KA: Client Management: How to create and deploy an msi using an msi package through the wizard.
A2- The "Custom Packages" factory:
This would be the recommended method to deploy msi because it allows to run the command line into operational rules through the steps "Execute Program" and "Execute Program As User" instead of setting the command line into the package.
This is the preferred method because if the command line is set in the package and that it's found that it is wrong, then the package has to be modified, then republished, which takes time and bandwidth. At the contrary if the command line is executed in a step, only the step has to be updated.
More information on how to deploy MSI through Custom packages in this KA: Client Management: How to create a custom package to deploy an msi
B- Custom packages
Custom packages can either be .msi, .exe, .vbs, .bat .ps1 or .reg. The KA above can be adapted as deploying an msi or an exe is actually the same thing in custom packages: Client Management: How to create a custom package to deploy an msi
There are some specifities though:
- to run a .reg "regedit" needs to be set in front of the command line.
- to run a .vbs "cscript" needs to be set in front of the command line. It might be a good idea to set the complete path to cscript if it's not in the path.
- to run a .ps1 (powershell) the path to powershell.exe. needs to be set in front of the command line. e.g: "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe c:\users\public\Test.ps1"
More information on how to deploy a powershell script in this KA: Client Management: How to deploy any application using a Powershell script in a package.
C- Snapshot Packages
This packager should only be used when it's absolutely not possible to install an application using msi or custom packages e.g some drivers? activeX?
To create this kind of package:
- find a device that is really similar to the type of devices to which the package will be deployed to
- capture that device
- install the application or whatever
- capture again
Then the packager will copy the files and registry keys that have changed since the first capture. The risk is that if the package is assigned to (a) device(s) on which some file(s) conflict(s) with other(s) already present on the target device it might create issues.
More information in the official documentation here (12.9).
4- Set the other tabs options:
- "Overwrite": Proceed with caution as the package could contain a windows dll in a older version than the actual version of the system, as an example.
- Destination: Set the path to which the files stored in the package should be extracted before the installation starts.- "Run as": Never set it by default. It's almost never necessary to set an admin account as packages usually install correctly using the Windows "System" account. Only set an admin account there if the package doesn't install properly during the tests. This is the second thing to test after (un)checking the option "Run in its context"
- Run command: Add the command line to it or leave it empty and run the command line though the steps "Execute Program" and "Execute Program As user". For more information follow step B- of the following KA: Client Management: How to create a custom package to deploy an msi.
- Run in its context: This option allows the installer to run in its own environment (if checked) or not (if unchecked). This has an impact on the variables it could use to run. The first thing to do if a package fails at installing although the command line works manually is to go to the package in the package factory, change the status of the option "Run in its context" then republish the package and test it again. This is often the cause of the issue, along with the possible failure because the package should actually run as the current user and not as System as by default.
5- Publish the package:
This will make it available in the main node "Packages" and be ready to be assigned to devices.
It might take a while to publish it, wait for the "Package Status" line in the "General" tab of the package to be set to the status "Package successfully published to target device".
The files will be copied from the packager to the master. The package archive can be found in ../master/data/Vision64database/Packages once the package has been published in the console.
6- Assign or Publish to MyApps to device(s) (groups) or user(s):
The scheduler is available to the right-click, then Properties of any assignment, e.g:
More information on assignments here: Client Management: What are the different types of assignments?
- If a package has disappeared from the packager since it was published, it's possible to send it back from the published version to any packager. More information in this KA: Client Management: How to modify a published package when the sources on the packager or the packager itself are lost?
- The following KA explains how to deploy several packages at a time: Client Management: How can I deploy several applications at once?
Best practices / Troubleshooting:
The following KA provides some hints to succeed at using software distribution in BCM: Client Management: Packages and Operational Rules best practices and troubleshooting.