View Single Post
Old 11-07-2005, 12:24 PM   #14 (permalink)
Khue
Thumbs Must Hurt
 
Khue's Avatar
 
Join Date: Sep 2005
Location: In a van down by the river.
Model: 8320
Carrier: T-Mobile
Posts: 101
Post Thanks: 0
Thanked 0 Times in 0 Posts
Default

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 havenxxx8217;t really seen any xxx8220;n00bies, this is how you do itxxx8221; 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 xxx8220;nicexxx8221; addition to what the BES can do but donxxx8217;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\applications\Test. You will need to create a xxx8216;testxxx8217; 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 xxx8216;testxxx8217; 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 xxx8220;Handheld Configuration Toolxxx8221; and navigate to the xxx8220;Configurationxxx8221; tab. Once you are here you will want to click on the link that says xxx8220;Add New Configuration.xxx8221; This will open up a new window titled xxx8220;Handheld Software Configuration.xxx8221;

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 xxx8220;Test App Install.xxx8221; You may optionally choose to add a description to this title. Next, add the xxx8220;Handheld Software Locationxxx8221; 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 xxx8220;Read & Executexxx8221;, xxx8220;List Folder Contentsxxx8221;, and xxx8220;Readxxx8221; permissions delegated to xxx8220;Authenticated Users.xxx8221; Once this has been setup successfully, in the xxx8220;Handheld Software Locationxxx8221; 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 xxx8220;Application Softwarexxx8221; tree you should see our test application listed. Check the checkbox mark next to the application and choose the delivery method as xxx8220;wireless.xxx8221;

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 xxx8220;Requiredxxx8221; 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 xxx8220;Disallowedxxx8221; 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 xxx8220;Applicationsxxx8221; 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 xxx8220;Disallowedxxx8221; through the desktop manager application they will not be allowed to.

Click on the xxx8220;Policiesxxx8230;xxx8221; button and then click xxx8220;Newxxx8230;xxx8221; This will take you to the xxx8220;Application Control Policyxxx8221; screen. Once you are here name this policy xxx8220;Push Appxxx8221; 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 xxx8220;OKxxx8221; button to both of the open dialogs which should take you back to the xxx8220;Handheld Software Configurationxxx8221; box. From the Policy column next to the application you wish to push select xxx8220;Push App.xxx8221; Sometime during this process you should create another policy called xxx8220;Remove Appxxx8221; and make the disposition xxx8220;Disallowedxxx8221; for the uninstall process.

Now that the xxx8220;Test App Installxxx8221; configuration has been made with the required disposition policy called xxx8220;Push Appxxx8221; we now must assign the configuration to a hand held device. Click on the xxx8220;Handheldsxxx8221; 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 xxx8220;Assign Software Configuration.xxx8221; Select the xxx8220;Test App Installxxx8221; policy. If you have this column added to your view you should see the xxx8220;Configuration Namexxx8221; column in the top pane say xxx8220;Test App Install.xxx8221; After applying the configuration make sure you hit the xxx8220;Update Configuration Check Statusxxx8221; link to complete the process (to uninstall you can either create an alternate configuration or you can reapply the xxx8220;Remove Appxxx8221; policy described to the current configuration; remember to xxx8220;Update Configuration Check Statusxxx8221; 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.

*edit: updated the package location to actually read c:\program files\common files\research in motion\shared\applicationS\test. Changed from application (plural is required).*

Last edited by Khue : 08-28-2006 at 08:47 AM.
Offline