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.
-
A Windows package must be built in a Windows package factory.
-
A Linux package on a Linux device
-
A Mac OS package on a Mac OS device.
This Knowledge Article covers the creation of a Windows package using Custom Package type.
Components required for software deployment:
-
Software Distribution License
-
The administrator must be having View, Manage and Assign Capabilities for the Application Management Module
-
The installation file for software (.exe,.msi,.vbs, etc) that is provided by the manufacturer.
-
A command line to install the software manually.
If the package is meant to run a command line (from the package itself or from another step) then the command line is a must to run, It is recommended to test the command line manually first, if the command line doesn't work manually, it will most likely not work when set in a package or in an operational rule step of BCM.
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 ++.
It is recommended to use the package creation wizard as takes through the one by one step.
1. Set the package Factory:
By default, the master will be set as the package factory but any windows device can be set as a package factory. In the SaaS environment, the master being a linux device, the package factory is usually the First Relay. The executable file must be kept on the package factory device
It is also possible to set up several package factories. Right-click on Package Factory>Add Device, and select the required device.
In the same window, 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. Custom packages:
Custom packages can either be .msi, .exe, .vbs, .bat .ps1 or .reg. In this article, custom package deployment using exe is covered. The KA below 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
B. MSI Packages
Msi can be installed within two different types of packages:
B1. The 'MSI packages' factory:
The msi packager imports a msi and simplifies it settings by taking care of the most common switches, 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.
B2. The 'Custom Packages' factory:
This would be the recommended method to deploy msi because it allows running 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. On 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
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 devices on which some files conflict with others already present on the target device, it might create issues.
More information is in the official documentation here
2. On the next window, name the package and leave the other parameters as it is.
3. Installation Options:
The next window is about defining the destination path and command line.
-
Destination Path: Set the path to which the files stored in the package should be extracted before the installation starts.
-
Run Command: Put the correct command line to run the file remotely. Make sure the command line consists of the path where the file is copied on target. If it is left empty run the command line through the steps "Execute Program" and "Execute Program As user". For more information on this follow the KA: Client Management: How to create a custom package to deploy an msi. In this example, the destination path is C:\temp and hence the command line is C:\temp\npp.8.4.2.Installer.x64.exe. For silent installation, give the appropriate option.
-
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 installation although the command line works manually is to go to the package in the packaging 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 the System by default.
-
Overwrite: Proceed with caution as the package could contain a windows dll in an older version than the actual version of the system, as an example.
4. Then Add the executable file. Add files option opens the file explorer of the Package factory device where the file is placed.
5. Publish the package:
This will make it available in the main node 'Packages' and be ready to be assigned to devices. It can be published to the master or the respective Relay of the target devices. In this example, the package is published on Master.
6. Select the 'Deploy the Package' option
7. The package distribution wizard will be opened. Select the target type as required. Device Groups/Devices.
Choose the required assignment type:
In this example, the package is installed on the devices. If the schedule for the installation is required, uncheck the 'Default Schedule' box.
Assign the required Devices/Device Groups on the next page and package transfer will start on them followed by the execution.
More information on assignments here: Client Management: What are the different types of assignments?
Additions:
- The following KA explains how to deploy several packages at a time: Client Management: How can I deploy several applications at once?
- 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?
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.
See also: BEST FAQ on BMC Client Management Package Deployment Issues
