Software Config How To
I can't take credit for this documentation as I copied it from an article somebody else posted here. I will repost with apologies to the original author for not saving his handle along with the post. I would think that you would need to do this on all of your BES servers.
Software Config Post-
I had to do a write up of this for SOX because this has some security implications but there were some questions about this and this was a painful experience having to work this out. And i know a lot of you might not have nice dev environments. Admins feel free to do whatever with this post. And sorry to keep bringing this back to the top of the list for the forum. Feel free to correct me where I am wrong as I just started doing BES work less then a month ago.
I have been messing around with the PUSH technology for some time now and because I haven’t really seen any “n00bies, this is how you do it” posts I have decided to make the first. A lot of the BES manual information is rather convoluted and difficult to understand for new administrators or administrators who have simply not been exposed to this side of the BES software. Most consider this as a “nice” addition to what the BES can do but don’t seriously consider this a feature that they have to have.
For the duration of this post I will refer to a test application that hypothetically exists. It is composed of an .alx file and a single .cod file. A .cod file is usually a compiled java application file and an .alx file is usually an index or record keeping file that appears to be XML. If you view the .alx file you will see it has information like what version number the software is, what files compose the complete software package, and company information. If an application is composed of several .cod files they will be recorded here as well. A good example of a multiple .cod supported .alx file is ShapeServices IM+ application. Typically there should be only one .alx file per software application (no matter how many .cod files there are) however on rare occasion because of different development environments it is not unusual to see a single .alx file per .cod file. There can sometimes be issues with this instance as well but usually it just requires cleaning up some of the XML in the individual .alx files. If requested I can amend this post with details about that.
From what I could tell there is no file structure system that applications on the BlackBerry rely on. For example in windows most programs are buried several directories deep and require references to different folders that exist somewhere else in the file tree. On a BlackBerry from my observation all you need to do is simply make sure the files are present on the device.
Now that Test application is ready to go, meaning we have the files we need, it is necessary to place the application in the appropriate directory for delivery. Copy the software, in our case test.cod and test.alx, to <whatever letter:\>program files\common files\research in motion\shared\application\Test. You will need to create a ‘test’ folder there for the 2 files.
The files are now in the appropriate directory to be sent out to wireless devices. Even though they are in this directory they will not be present to the BES Handheld Configuration Tool (the app used to actually do the push). In order to make the files available for the Handheld Configuration Tool to properly send you must index the files with the loader application. The loader application can be found <whatever letter:\>program files\common files\research in motion\apploader\loader.exe. You will need to run loader.exe from a command prompt. You may want to consider adding this to the environment path to make things easy on yourself but as a BES Admin this is completely up to you. At the command prompt, navigate to that directory on the BES and type the following: loader /index. The flag /index will create 2 files within the previously established ‘test’ folder. It will create a PkgDBCache.xml and a specification.pkg file. Once these files have been created, you can then move on to creating the configuration.
The configuration is the actually information that packages the files up and prepares them to send. Open up the “Handheld Configuration Tool” and navigate to the “Configuration” tab. Once you are here you will want to click on the link that says “Add New Configuration.” This will open up a new window titled “Handheld Software Configuration.”
Because we are starting from scratch, I will go through an entire process example install to reinstall. The first configuration we will create will be Test App Install. Title the configuration “Test App Install.” You may optionally choose to add a description to this title. Next, add the “Handheld Software Location” to the configuration. This wants the share name of that directory. To begin with make sure the share is setup. Refer back to the <whatever letter:\>program files\common files\research in motion folder is shared out and has “Read & Execute”, “List Folder Contents”, and “Read” permissions delegated to “Authenticated Users.” Once this has been setup successfully, in the “Handheld Software Location” line you will need to type the share name of that directory in. For example, if our test BES is BESTest the directory should be listed as \\BESTest\Research In Motion.
Once you have selected the proper UNC path for the application directory, you should then see the application listed in the grid below. If you expand the “Application Software” tree you should see our test application listed. Check the checkbox mark next to the application and choose the delivery method as “wireless.”
To complete the configuration you will need to assign the configuration a policy. This policy governs the properties of the application. If disposition is marked “Required” the BES will push the application to the units with the configuration. If a user attempts to delete a file that is listed as required, they will have access denied to deleting it. If an application is listed as “Disallowed” it will uninstall any application that the policy is designated to govern. An odd thing about this is when wirelessly removed, the application will still remain listed in the “Applications” options menu however the modules will be removed as well as the application icon (I have not yet found an explanation for this). If a user attempts to install something that is explicitly marked as “Disallowed” through the desktop manager application they will not be allowed to.
Click on the “Policies…” button and then click “New…” This will take you to the “Application Control Policy” screen. Once you are here name this policy “Push App” and change the disposition to required. For details on what the other options do see Appendix B: Software application control out of the BES admin guide. Once you have set the proper settings for the application simply hit the “OK” button to both of the open dialogs which should take you back to the “Handheld Software Configuration” box. From the Policy column next to the application you wish to push select “Push App.” Sometime during this process you should create another policy called “Remove App” and make the disposition “Disallowed” for the uninstall process.
Now that the “Test App Install” configuration has been made with the required disposition policy called “Push App” we now must assign the configuration to a hand held device. Click on the “Handhelds” tab in the BlackBerry Handheld Configuration Tool and highlight the handheld device you wish to assign the configuration to. Once you have done this click the link in the bottom pane that says “Assign Software Configuration.” Select the “Test App Install” policy. If you have this column added to your view you should see the “Configuration Name” column in the top pane say “Test App Install.” After applying the configuration make sure you hit the “Update Configuration Check Status” link to complete the process (to uninstall you can either create an alternate configuration or you can reapply the “Remove App” policy described to the current configuration; remember to “Update Configuration Check Status” when done).
After you have done this allow up to 4 hours to deploy the software configuration. In a 400 BlackBerry BES environment to wirelessly push an application to 10 test units using the same configuration applied at the same time it has taken me anywhere from 15 minutes to one full hour and has rarely take the full 4 hours to push out. During the actual PUSH action the BlackBerries will be inoperable for approximately 15 minutes (with a 224kb application). At the completion of the push a BlackBerry unit will restart itself and you should see the application available on the BlackBerry unit.
|
