A quick guide to start deploying applications on windows

Version 3
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    BMC Client Management


    COMPONENT:

    Client Management


    APPLIES TO:

    Any version of BCM.



    QUESTION:

     

    How can I succeed into packaging an application?


    ANSWER:

     

     

     

    Build and send a package:
    If it's the first time you want to deploy a package you should first read the documentation BCM_DeploymentManager.pdf available on our support website or the documentation of the 12.0 section of docs.bmc.com (12.1 is here).

      


    1- Set the packager:

      

    By default, the master will be set as the packager, but you can set any windows device as a packager and even run several ones:

      

    add_pkger_windows.png

      

     

      

    2- Find the relevant command-line:

      

    If you don't already know which options to use, you should consider looking for that application name and version on ItNinja. This site is the best site i know to find options to use to deploy specific applications. You'll often find options there that are not even documented on the editor's website.

      

    You should first test to install this application manually by using these options on your test device, in order to validate they actually work.

      

     

      

    3- Choose the type of package:

      

    Once you have set up the options you'll have to think about the type of package you want to use:

      

    A- MSI Packages

      

    You can deploy an MSI package using:

      

    A1- the "MSI packages" factory:

      

    1-msipkgr.png

      

    It'll import the MSI package and you'll be able to set options instead of setting a full msiexec command.

      

     

      

    A2- The "Custom Packages" factory:

      

    This can be a good choice if you want to execute the msi command outside the package. Here you'll have to use the msiexec regular command lines, e.g: 'msiexec /i C:\Temp\SAPSSO.msi /quiet'.
    See next lines to learn more about custom packages.

      

     

      

    B- Custom packages

      

    Custom packages can either be .msi, .exe, .vbs, .bat .ps1 or .reg .

      

    To use it:

      

    - Add the files you need to put in the package in the sub-node "Contents".
    Note: The option "Enable Full Path" will also collect the full path where the files are, which probably won't be the path where you want to distribute the files
    - Set the options you need in the installation tab:

      

    3-custpkgr.png

      

    Note: If you want to install a:
    - .reg you'll have to set "regedit" in front of the command line.
    - .vbs you'll have to specify "cscript"  in front of the command line. You might have to specify the complete path to cscript if it's not in the path.
    - .ps1 (powershell) you'll probably have to specify the path to powershell.exe. e.g: "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe c:\users\public\Test.ps1"

      

     

      

    C- Snapshot Packager
    This packager only has to be used when you can't manage to install your application using other types of packages (some drivers or activeX maybe?) or if for some reason you really can't install your packages with the other packagers.
    To create this kind of package you need to:
    - find a device that is really similar to all of your devices
    - capture that device
    - install your application or whatever
    - capture again

      

    Then the packager will copy the files and registry keys that have changed since the first capture. The downside of this is that if you assign this package to a devices on which some file(s) conflict(s) with others on the target device you might create issues.
    You'll find more information in the documentation linked at the beginning of this document.

      

     

      

    4- Set the other tabs options:

      

    - Be careful with the "Overwrite" tab if you are updating files
    - You might need to check the option "Run in its context" to have the package work. This is the first thing you should check or uncheck if your package doesn't work right away.
    - It's almost never necessary to set an admin account in the "Run as" tab of the package properties as packages usually install correctly using the "system" account. Only set an admin account there if the package doesn't install properly during your tests. This is the second thing to test after (un)checking the option "Run in its context"

      

     

      

    5- Publish the package:

      

    publish.png

      

    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 advertise the package to a test device (group) or user:

      

    A- Assign Devices:

      

    Administrators usually use this method to execute operational rules/ install packages as it doesn't require any user action:
    - Select the Package or Operational Rules' sub-node "Assign Objects" > "Devices" and right click on "Assign Device" on the right window
    - Click on "Yes" when prompted to use the default schedule (Immediate execution if you haven't changed it yet)
    - Select the device you want to assign and wait for its execution

        

    B- Assign Users:

      

    There are two ways to use this functionality: the operational rule will either be assigned and executed on all the device this user is connected to, depending on the schedule that is set, or it will be available in MyApps on every device the user will be connected.
    This will only be possible to use if you synchronized your users from the active directory in the node "Users".
    - Select the Package or Operational Rules' sub-node "Assign Objects" > "Devices" and right click on "Assign User" on the right window
    - Choose the way you want to deploy it:

      

    1- Checking the option "Deploy to devices linked to users" will assign it to all devices the user is connected, or will be connected, depending on the schedule you will set
    2- Checking the option "On Demand My Apps" will make it available on MyApps

      

    - Some applications will need to be installed as the connected user, check this option if required. This document gives more information on this mode.
    Other options are clear enough, I think.

      

     

      

    C- Advertise to devices:

      

    You can also advertise packages to devices so your users can use MyApps to install operational rules or packages themselves:
    - assign the device (group) or a user (group) then click on "No" when it'll ask if you want to use the default schedule
    - right click on the device (group) or user (group) assignment and click on "Advertise Package":

      

    advertize_pkg_windows.png

      

    If you advertise it to a device the application will be available for any user that will connect to MyApps on that specific computer, not any other.

      

    To access to MyApps, simply go on the computer where you published the rule then double click on the agent's icon or type http://127.0.0.1:1610/MyApps to select the operational rule/package you publiched to the device (group) or user (group).

      

     

      

    Best practices:

      

    0- Always enable full logs on the devices you are going to test the package deployment, that'll help you to troubleshoot if the package installation fails.

      


    1- If the package doesn't work right away, start by:

      

    - checking the client's /client/log/operationalrules.log or simply click on "View Operational Rule Log":

      

    logs.png

      

    - tweaking its options (Run in its context, execute it as the current user etc) and double-checking the command line. Many issues will simply be solved this way. Don't forget to recompile the package after every change, then reassign it to your test device(s).
    - In some cases you'll have to check the option "run program in its context" but it's not mandatory
    - When using MSI packages, the option "ALLUSERS" option will often be needed to create shortcuts on the users desktops or even add the software in windows "Add/Remove Programs"

      

     

      

    2- The command line in custom packages IS NOT mandatory: most users will prefer to not to setup any command line there and to execute and to execute this using the step "Execute program". This has an advantage: you won't have to recompile your package every time you want to change anything in the command line, and believe me you'll probably make a lot of tests.

      

    - Create a new operational rule
    - Create a package containing your executable (or install folder) and do not set anything in the "Command Line" field:

      

    no_execution.png

      

    - Select it, click on the tab "Packages", right click on on the window and select "Add package" and select your package.

      

    This will create a step "Install Package in the tab "Steps"

      

    - Select the tab "Steps" and right click in the window to add the step "Process Management" > "Execute program" and set it to  execute the executable you have copied with the package, in our example:

      

    install_step.png

      

    This is how you'd set your msi to run as a custom package + an execute program OR:

      

    Sans titre.png

      

    Note that on this specific case you'll also need to run the OR as the connected user or it won't work.

      

     

      

    3- Do not publish packages to relays if you have a lot, it'll be harder to maintain the package and it can be tricky if you have 500 relays. If you want to be sure that the package is already on your relays the first time you assign it to devices, and/or that you want to send it at a time it'll not impact your bandwidth you can:

      

    - simply assign an OR without any execution scheduled on the device.

      

    disable_sched.png

      

    OR

      

    - copy the package manually on an alternative repository on the relays: this might be usefull on really slow connections, if you prefer to send it by mail. This can be set in your relays' "AlternativePackagesRepository" section  in their /client/config/Filestore.ini.

      

     

      

    Notes:

      

    - You can use packages to simply copy files, instead of:

      

    - storing the application/install folder on a share
    - mount the share using the dedicated step
    - copy the files using the dedicated step
    - unmount the share using the dedicated

      

    - How to write in a user profile, add/edit a registry key in HKCU or use user variables.

      

    - How to deploy multiple packages at once.

      

    - Deactivate the UAC before deploying on a Windows 7 device

      

    - Don't forget that some packages will never install if you havn't killed one or more processes before. Here is a good example Fabien made to kill the process prior to patching the device. This how-to was made to patch but the logic will apply to a package.

      

    - Gregory Tucker has made another interesting how-to to adding a shortcut to a desktop.

      

    - It's possible to send back a published package on a package factory if the device crashed or so.

     

     


    Article Number:

    000121358


    Article Type:

    FAQ/Procedural



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles