Skip Headers
Oracle® Beehive Administrator's Guide
Release 2 (2.0.1.8)

Part Number E16648-07
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

7 Managing Oracle Beehive Mobility Services

This module describes how to perform administration tasks relating to Oracle Beehive Mobility Services. The module contains the following topics:

Introduction

Oracle Beehive Mobility Services are available for use by end-users immediately following Oracle Beehive installation. Although additional configuration is not required for users to retrieve their e-mail and synchronize their calendar data, Oracle Beehive administrators may want to control certain actions, impose restrictions, or update applications.

This module explains how to perform administrative tasks for Oracle Beehive Mobility Services using the beectl command-line tool. You can also perform most of these tasks using Oracle Beekeeper.

See Also:

Controlling Mobile Device Types

By default, Oracle Beehive allows a specific list of mobile device types to synchronize with the Mobile Services. The following topics describe how to manage the list of device types:

Uploading a Device Profile

Occasionally, you may need to upload a new device profile file to accommodate new device types that are available in the mobile market, or apply changes after updating an existing device profile file. Device profile files contain device identification information, and various configuration parameters specific to a device or device family.

To upload a device profile file to the Device Management Service using beectl:

  1. Save the device profile XML file in a directory accessible by the Oracle user.

  2. Use the beectl upload_device_profiles command to upload the new device profile:

    beectl> upload_device_profiles --file <file>
    

    Where <file> represents the full path and file name of the device profile file saved in Step 1.

Note:

New Oracle Beehive device profiles may be made available periodically by Oracle in subsequent patches.

Customizing Device Profiles

Device profile files are located in the $ORACLE_HOME/beehive/seed/oma directory of your Oracle Beehive deployment. You can customize the default values in these files to accommodate users' needs.

To customize the device profile defaults using beectl:

  1. Open the $ORACLE_HOME/beehive/seed/oma/<deviceprofile>.xml file with a text editor.

    Where <deviceprofile> represents the name of the device profile file that you want to configure.

  2. Locate the <Configuration> section of the file. Within this section various <PreferenceSet> sections exist. Each configurable attribute is defined in an <AttributeDefinitionName> XML tag. Table 7-1, "<Configuration> Attributes in a Device Profile File" lists the configurable attributes in the <Configuration> section.

    Caution:

    Only make changes to the content in the <Configuration> section. Making changes to other parts of the file may be harmful.
  3. To change the value of an attribute, modify the value surrounded by the <DefaultValue> XML tag within the appropriate <AttributeDefinitionName> section.

  4. Repeat Step 3 for any configurable attribute that you want to customize.

  5. Save and exit the device profile file.

Table 7-1 <Configuration> Attributes in a Device Profile File

Preference Set Attribute Description Accepted Values

Oma

max_object_size

Maximum object size allowed in bytes.

Positive integer

Oma

max_message_size

Maximum message size allowed in bytes.

Positive integer

Event

sync_range_back

Specify number of days in the past that should be synchronized.

See Also: sync_range_forward, del_out_of_range.

Positive integer

Event

sync_range_forward

Specify number of days in the future that should be synchronized.

See Also: sync_range_back, del_out_of_range.

Positive integer

Event

del_out_of_range

Delete events on the mobile device that appear outside of the boundaries of the sync_range_back and sync_range_forward attributes.

See Also: sync_range_back, sync_range_forward.

true, false

Event

want_refused_entries

Allow refused events to be synchronized with your mobile device.

true, false

Event

want_default_alarms

Assign the default alarm to events.

See Also:default_alarm.

true, false

Event

default_alarm

The time before an event begins, in minutes, when an alarm should be triggered.

See Also: want_default_alarms.

Positive integer

Event

conflict_resolution

Specify the what entry should take precedence if two entries have been modified between a synchronization.

When set to SERVER, the entry on Oracle Beehive will take precedence over the entry on the device.

SERVER, CLIENT

Task

sync_range_back

Specify number of days in the past that should be synchronized.

See Also: sync_range_forward, del_out_of_range.

Positive integer

Task

sync_range_forward

Specify number of days in the future that should be synchronized.

See Also: sync_range_back, del_out_of_range.

Positive integer

Task

del_out_of_range

Delete tasks on the mobile device that appear outside of the boundaries of the sync_range_back and sync_range_forward attributes.

See Also: sync_range_back, sync_range_forward.

true, false

Task

want_refused_entries

Allow refused tasks to be synchronized with your mobile device.

true, false

Task

want_default_alarms

Assign the default alarm to tasks.

See Also: default_alarm.

Positive integer

Task

default_alarm

The time before a task is due, in minutes, when an alarm should be triggered.

See Also: want_default_alarms.

Positive integer

Task

confict_resolution

Specify what entry should take precedence if two entries have been modified between a synchronization.

When set to SERVER, the task on Oracle Beehive will take precedence over the task on the device.

SERVER, CLIENT

Email

sync_range_back

Specify number of days in the past that should be synchronized.

Positive integer

Email

limit

The limit, in bytes, of e-mail that can be synchronized.

Positive integer

Email

want_attachements

Allow synchronization of attachments.

true, false

Contact

categories

Specify the contact categories that should be synchronized.

When a asterisk (*) is specified, all categories are synchronized.

To specify a single category or multiple categories, the values must be surrounded by quotes, and separated by commas. For example, if only the business and corporate type categories should be synchronized the argument for this attribute should be "business, corporate".

*, Category names separated by commas (,) surrounded by quotes ("")

Contact

conflict_resolution

Specify what entry should take precedence if two entries have been modified between a synchronization.

When set to SERVER, the contact on Oracle Beehive will take precedence over the contact on the device.

SERVER, CLIENT


Adding a New Device Type to a Profile

A device type is a specific model in a family of devices, and is defined in a device profile file. For example, a new model of a mobile phone that a particular vendor has recently released.

By default, Oracle Beehive does not allow uncertified devices to access the Mobility Services. However, it is possible to add a new device to a device profile file.

Note:

As an alternative to manually adding new device types to a profile, Oracle recommends uploading new device profiles made available through certified Oracle Beehive patches. For more information about uploading new device profiles see "Uploading a Device Profile".

To add a new device to a device profile file using beectl:

  1. Temporarily allow uncertified devices to access Oracle Beehive Mobility Services by executing the following command:

    beectl> modify_property --component _DeviceManagementService --name UncertifiedDeviceAllowed --value true
    
  2. Temporarily enable SyncML logging to discover the device information by executing the following command:

    beectl> modify_property --component _OmaService --name SyncmlLogRequired --value true
    
  3. Run the following command to activate your proposed configuration changes:

    beectl> activate_configuration
    

    Note:

    Oracle recommends waiting a few minutes before proceeding to the following step to ensure that the changes have been applied.
  4. Synchronize the new device with Oracle Beehive. To ease the retrieval of device information in Step 7, take note of the time the synchronization was initiated.

  5. Retrieve recent SyncML log messages using the following command:

    beectl> download_syncml_messages --directory <path> --date <YYYY-MM-DD>
    

    Where <path> represents the path to the directory where the SyncML messages will be stored, and <YYYY-MM-DD> represents the current date.

  6. Open the SyncML messages file downloaded in Step 5. The file will be located in the --directory <path> argument specified in Step 5.

  7. Locate the device SyncML message in the file by looking for the time at which the synchronization attempt was initiated. The device information will be presented in a way similar to the following example:

    <Item>
            <Source>
              <LocURI>./devinf12</LocURI>
            </Source>
            <Data>
              <![CDATA[<DevInf><VerDTD>1.2</VerDTD><Man>MySync Client</Man><Mod>MySync Client 123</Mod><OEM>Synthesis AG</OEM><FwV>5.1.195</FwV><SwV>3.0.2.4</SwV>.....</DevInf>]]>
            </Data>
    </Item>
    
  8. Take note of the values associated with the following XML tags: <VerDTD>, <Man> <Mod>, and <SwV>.

  9. Close the SyncML message file.

  10. Open the $ORACLE_HOME/beehive/seed/oma/<deviceprofile>.xml file with a text editor.

    Where <deviceprofile> represents the name of the device profile file of the family of the device that you are adding.

  11. Within the <DeviceTypes> section of the file, add a new <DeviceType> section, including the information noted in Step 7.

    For example, using the information gathered in Step 7, the following entry could be added to the <DeviceTypes> section:

    <DeviceType>
                            <DeviceProfileName>MySyncClient</DeviceProfileName>
                            <Name>MySync Client</Name>
                            <DeviceClass></DeviceClass>
                            <Processor/>
                            <OS/>
                            <Dev_inf_dtd_version>1.2</Dev_inf_dtd_version>  
                            <Model>MySync Client 123</Model>
                            <Manufacturer>MySync Client<</Manufacturer>
                    </DeviceType>
    
  12. Save and close the device profile file.

  13. Disallow uncertified devices from accessing Oracle Beehive Mobility Services by executing the following command:

    beectl> modify_property --component _DeviceManagementService --name UncertifiedDeviceAllowed --value false
    
  14. Disable SyncML logging by executing the following command:

    beectl> modify_property --component _OmaService --name SyncmlLogRequired --value false
    
  15. Run the following command to activate the proposed configuration changes applied in Steps 13 and 14:

    beectl> activate_configuration
    
  16. Upload the device profile file saved in Step 12. For more information about uploading a device profile file, refer to the instructions in "Uploading a Device Profile".

Controlling Mobile Applications

You can make use of the Oracle Beehive mobility services to deploy third-party applications to users' mobile devices. You can also use alternative methods of deploying Oracle Beehive mobile client components.

This section contains the following topics:

Adding a New Mobile Application for Use

Occasionally, you may want to upload and provision new applications to allow users access to more recent versions. New mobile software, for example, is periodically made available by third-party vendors and can be uploaded to Oracle Beehive to allow users to retrieve the software.

To upload new applications to Oracle Beehive using beectl:

  1. Create a new application ZIP archive in an Oracle Beehive directory accessible by the Oracle user.

    The application ZIP file must contain the following items:

    • The application

    • A metadata.xml file describing the application

    Note:

    For a sample XML file, view the metadata.xml file supplied within an existing ZIP file in the $ORACLE_HOME/beehive/seed/dm directory. The file should only be used as a guideline. The values within the XML file should be replaced with appropriate values pertaining the application that you want to upload.
  2. Execute the following command to upload the new application software:

    beectl> upload_client_application --file <file>
    

    Where <file> represents the full path and file name of the new application software saved in Step 1.

  3. Using the list_enterprises beectl command, determine the identifier of the Oracle Beehive enterprise:

    beectl> list_enterprises
    
  4. Take note of the identifier of the enterprise to which the application will be provisioned.

  5. Using the add_client_application_provisioning beectl command, provision the application to the enterprise:

    beectl> add_client_application_provisioning --community <id> --all
    

    Where <id> represents the enterprise identifier noted in Step 4.

After completing the steps above, the application will be available to all users on the enterprise.

Deploying Oracle Beehive Mobile Client Components using Storage Cards

You can deploy Oracle Beehive mobile client components to users' devices using storage cards. This allows you or your users to install the software without requiring users to download over a network or the Internet.

To deploy Oracle Beehive mobile software using storage cards:

  1. On any Oracle Beehive server, copy the file $BEEHIVE_HOME /beehive/bootstrap/mobile/ommc.exe to a computer running Microsoft Windows

  2. Run the following command from the Windows computer:

    ommc.exe --storagecard <drive>: --username <username> --dmserverurl http://<server:port>/mobiledm/
    

    For example, if the storage card drive is F, username is john.doe, and the server and port is beehive1.example.com:7777:

    ommc.exe --storagecard F: --username john.doe --dmserverurl http://beehive1.example.com:7777/mobiledm/
    

    The application will be copied to the storage card and is ready to be used in a mobile device.

  3. Insert the storage card into the device, and then access the applications and run them from the storage card. The various Oracle Beehive mobile client components will install with the correct configuration to access your Oracle Beehive server.

    See Also:

    ""Configuring your Apple iPhone or iPad", "Configuring your BlackBerry", Configuring your Windows Mobile Professional (Pocket PC) and Standard (Smartphone)", and "Configuring your Nokia Series 60" in the Registering and Configuring Mobile Devices Help, available on the Oracle Technology Network website at the following URL:

    http://www.oracle.com/technology/products/beehive/beehive_users/2_0/mobile.htm

Managing Language Packs for Oracle Beehive Mobile Client Applications

Oracle Beehive mobile client applications include language packs and their translation files, which are automatically uploaded during the Oracle Beehive installation process. You can customize the language packs that Oracle Beehive provides as well as others that it does not.

This section contains the following topics:

Mobile Client Application Language Packs Provided by Oracle Beehive

Oracle Beehive provides the following language packs for its mobile client applications:

  • Chinese (Simplified)

  • Chinese (Traditional)

  • French

  • German

  • Italian

  • Japanese

  • Korean

  • Portuguese (Brazilian)

  • Spanish

To customize the translation files of a language pack, refer to "Customizing Language Packs and Translation Files for Oracle Beehive Mobile Client Applications".

Customizing Language Packs and Translation Files for Oracle Beehive Mobile Client Applications

To customize a language pack, you modify one or more of its translation files. You then upload the customized translation files using one of the following containers:

Note:

For the list of language packs that Oracle Beehive provides, please refer to "Mobile Client Application Language Packs Provided by Oracle Beehive".

Creating and Uploading a Patch Set for a Language Pack Provided by Oracle Beehive

To customize the translation files for a language pack provided by Oracle Beehive, you create and upload a patch set.

To create and upload a patch set:

  1. Modify the translation file of a supported language pack, as follows:

    1. Access the zip file of the mobile client application, located in the $ORACLE_HOME/beehive/seed/dm directory. For example, the translation files for the Mobile Mail plug-in for Windows Mobile devices appear in pushmail_release.PPC5.0_ARM.element.zip.

    2. From the zip file, open the XLIFF file for one of the languages that Oracle Beehive supports by default. For example, the French translation file for the Mobile Mail plug-in is oracle.ocs.mobileclient.wince.pushmail_fr.xlf.

    3. Modify the translation strings in the file, as needed.

    4. Save the file in UTF-8 encoding. All XLIFF files must be UTF-8 encoded.

    5. Repeat these steps as necessary for the translation files for other languages.

  2. Create a new zip file that contains all customized translation files. Ensure that the new zip file is located in an Oracle Beehive directory that is accessible by the Oracle user.

  3. Create a new metadata.xml to describe the new patch set, as follows:

    1. Access the existing zip file of the mobile client application, located in the $ORACLE_HOME/beehive/seed/dm directory.

    2. From the zip file, open metadata.xml.

    3. Increment the value of the <patchsetnumber> attribute so that it is higher than the current value. All other attributes under the <property> element should remain the same as distributed in the original metadata.xml file.

      For example, a metadata.xml for a patch set targeted towards Windows Mobile 5.0 devices and that contains customized French and Japanese translation files will look similar to the following:

      <?xml version="1.0" encoding="UTF-8"?>
      <application>
          <property>
              <name> Mobile Mail </name>
              <description> MobileMail Client </description>
              <os> wince5.0  </os>
              <processor>ARM </processor>
              <deviceclass> Smartphone </deviceclass>
              <language> all </language>
              <version> 1.4.0.0.0. </version>
              <versionnumber> 4 </versionnumber>
              <patchsetnumber> 1 </patchsetnumber>
              <vendor> Oracle </vendor>
              <isPlatform> false </isPlatform>
          </property>
          <modules>
              <module>
                  <name> oracle.ocs.mobileclient.wince.pushmail_fr.xlf </name>
                  <src> . </src>
                  <dest> %CSIDL_WINDOWS% </dest>
                  <contenttype> text/xml</contenttype>
              </module>
              <module>
                  <name> oracle.ocs.mobileclient.wince.pushmail_ja.xlf </name>
                  <src> . </src>
                  <dest> %CSIDL_WINDOWS% </dest>
                  <contenttype> text/xml</contenttype>
              </module>
          </modules>
      </application>
      
    4. Save the new metadata.xml.

    5. Add the new metadata.xml to the zip file created in Step 2.

  4. Upload the new patch set, as follows:

    1. Launch the beectl command line utility.

    2. Issue the upload_client_application command, as follows:

      beectl> upload_client_application --file <file>

      Where <file> represents the absolute path of the zip file that you created in Step 2.

Creating, Uploading, and Provisioning a Language Pack Not Provided by Oracle Beehive

To customize the translation files for a language pack not provided by Oracle Beehive, you create a new language pack based on an existing one. Once created, you can upload and provision the new language pack.

To create, upload, and provision a new language pack:

  1. Modify the translation file of a supported language pack with the strings required in the new language pack, as follows:

    1. Access the zip file of the mobile client application, located in the $ORACLE_HOME/beehive/seed/dm directory. For example, the translation files for the Mobile Mail plug-in for Windows Mobile 5.0 devices appear in pushmail_release.PPC5.0_ARM.element.zip.

    2. From the zip file, open the XLIFF file for one of the languages that Oracle Beehive supports by default. For example, the French translation file for the the Mobile Mail plug-in is oracle.ocs.mobileclient.wince.pushmail_fr.xlf.

    3. Modify the translation strings, as needed.

    4. Modify the target-language attribute to specify the new target language and country. For example, if you modify the French translation file for the Mobile Mail plug-in with Danish strings, change the target-language attribute from "fr-FR" to "dk-DK".

    5. Rename the XLIFF file by replacing the original language code with the new language code and, if appropriate, the new country code.

      Note:

      XLIFF file naming conventions follow the Java standard, which supports a two-letter lowercase language code (ISO 639) and a two-letter uppercase country code (ISO 3166). For example, if you modify the French translation file for the Mobile Mail plug-in with Danish strings, rename the file and save it in UTF-8 encoding as oracle.ocs.mobileclient.wince.pushmail_dk.xlf. Or, if you create a Canadian French translation file, save it as oracle.ocs.mobileclient.wince.pushmail_fr_CA.xlf.
  2. Create a new zip file that contains all customized translation files. Ensure that the new zip file is located in an Oracle Beehive directory that is accessible by the Oracle user.

  3. Create a new metadata.xml to describe the new language pack, as follows:

    1. Access the existing zip file of the mobile client application, located in the $ORACLE_HOME/beehive/seed/dm directory.

    2. From the zip file, open metadata.xml.

    3. Replace the values of the <name> and <description> attributes with the name and description of the new language pack. All other attributes under the <property> element should remain the same as distributed in the original metadata.xml file.

      For example, a metadata.xml for a language pack targeted towards Windows Mobile 5.0 devices and that contains customized Danish translation files will look similar to the following:

      <?xml version="1.0" encoding="UTF-8"?>
      <application>
          <property>
              <name> Mobile Mail Langugage Pack - DK </name>
              <description> MobileMail Client Danish Language Pack</description>
              <os> wince5.0  </os>
              <processor>ARM </processor>
              <deviceclass> Smartphone</deviceclass>
              <language> all </language>
              <version> 1.4.0.0.0. </version>
              <versionnumber> 4 </versionnumber>
              <patchsetnumber> 0 </patchsetnumber>
              <vendor> Oracle </vendor>
              <isPlatform> false </isPlatform>
          </property>
          <modules>
              <module>
                  <name> oracle.ocs.mobileclient.wince.pushmail_dk.xlf </name>
                  <src> . </src>
                  <dest> %CSIDL_WINDOWS% </dest>
                  <contenttype> text/xml</contenttype>
              </module>
          </modules>
      </application>
      
    4. Save the new metadata.xml.

    5. Add the new metadata.xml to the zip file created in Step 2.

  4. Upload the new language pack, as follows:

    1. Launch the beectl command line utility.

    2. Issue the upload_client_application command, as follows:

      beectl> upload_client_application --file <file>

      Where <file> represents the absolute path of the zip file that you created in Step 2.

  5. Provision the new language pack, as follows:

    1. In the beectl command line utility, issue the list_enterprises command to determine the identifier of the Oracle Beehive enterprise:

      beectl> list_enterprises --entity_format id

    2. Take note of the identifier of the enterprise to which the language pack will be provisioned.

    3. Issue the add_client_application_provisioning command to provision the language pack to the enterprise:

      beectl> add_client_application_provisioning --community <id> --all

      Where <id> represents the enterprise identifier

Configuring Mobile Services

You can control the service-level configuration of the Mobile Services by making adjustments to service properties. This section contains the following topics related to managing Mobile Services properties:

Listing Mobile Services Configurable Properties

To list the configurable properties of a service, the component identifier is required. To obtain the component identifier, use the list_components command with the --type option. The mobile service component types are:

  • OmaService: the Mobile Data Sync Service

  • PushMailService: the Mobile Mail Service

  • MobileDmService: the Mobile Device Management Service

  • PushService: the Mobile Push Service

To list the configurable properties for a service:

  1. Determine the component identifier by running the beectl list_components command, using the component identifier for the --type option. For example, to list the component identifier of the Mobile Data Sync Service:

    beectl> list_components --type OmaService
    -----------------------------------------------
    | Component Type       | Component Identifier |
    -----------------------------------------------
    | OmaService           | _OmaService          |
    -----------------------------------------------
    
  2. Using the component identifier determined in Step 1, list the configurable properties for the service by running the beectl list_properties command. For example:

    beectl> list_properties --component _OmaService
    

    The command will return a list of properties for the service.

    See Also:

    For more information about managing component properties, and a complete list of the properties for each component, see Chapter 4, "Oracle Beehive Property Reference," of the Oracle Beehive Administrator's Reference Guide.

Configuring the Mobile Data Sync Service

Oracle Beehive allows you to configure certain Mobile Data Sync Service properties. This section explains how to modify Data Sync properties using beectl commands, and contains the following topics:

Controlling Sychronized Data Types

Oracle Beehive administrators can control the type of data that users are allowed to synchronize. By default users are allowed to synchronize e-mail, calendar (including events and tasks), and contacts.

The items listed in Table 7-2 represent data type properties that can be modified using the modify_property command with the --component, --name, and --value options.

Table 7-2 Data Type Properties

Data Type Properties Accepted Values

CalendarSyncEnabled

true

Enables event and task synchronization.

false

Disables event and task synchronization.

ContactsSyncEnabled

true

Enables contact synchronization.

false

Disables contact synchronization.

EmailSyncEnabled

true

Enables e-mail synchronization.

false

Disables e-mail synchronization.


To enable or disable synchronization of data types:

  1. Enable or disable the synchronization of data types using the following command:

    beectl> modify_property --component _OmaService --name <DataTypeProperty> --value <value>
    

    Where <DataTypeProperty> represents a data type property listed in Table 7-2, and <value> represents either true (to enable) or false (to disable).

  2. Activate the proposed configuration by executing the following command:

    beectl> activate_configuration
    

Example 7-1 displays how to disable the contacts synchronization data type property. The resulting output of the command is also displayed.

Example 7-1 Disabling the Contacts Synchronization Data Type

beectl> modify_property --component _OmaService --name ContactsSyncEnabled --value false
Changes to configuration repository are not activated.
Successfully stored the property for component id 1e54ba56-7448-4849-b987-8dda59d26f4d.

Note:

You must run the beectl activate_configuration command after modifying a property, to apply your proposed configuration changes to the active configuration.

Controlling MD5 Authentication

The Mobile Data Sync service supports MD5 and basic authentication. Basic authentication is clear text-based authentication whereas MD5 authentication is more secure. By default, basic authentication is used with Mobile Data Sync.

Many devices support MD5 authentication; however, by default, the Mobile Data Sync service does not allow MD5 authentication. The Mobile Data Sync service can be configured, globally or per device profile, to accept MD5 authentication requests.

This section contains the following topics:

Note:

The Oracle Beehive Authentication service may not be able to support MD5 when configured with certain third-party LDAP servers.

If it is not supported, then the Mobile Data Sync service Md5Supported property should be set to false.

Controlling MD5 Authentication for all Devices

There are two service properties that control authentication requirements at the Mobile Data Sync service-level: Md5Supported and Md5Required.

See Also:

For a complete list of properties specific to the Mobile Data Sync service, see "Listing Mobile Services Configurable Properties".

The Md5Supported property controls whether MD5 authentication is allowed. The Md5Required property, when set to true, enforces MD5 authentication for all devices.

To enforce MD5 Authentication for all devices using the Mobile Data Sync service:

  1. Allow MD5 authentication using following command:

    beectl> modify_property --component _OmaService --name Md5Supported --value true
    
  2. Force all devices to use MD5 authentication using following command:

    beectl> modify_property --component _OmaService --name Md5Required --value true
    
  3. Activate the proposed property changes by executing the following command:

    beectl> activate_configuration
    

Note:

When using the above settings, if a device does not support MD5, it will not be able to authenticate with the Oracle Beehive Mobile Data Sync service.

To allow MD5 and basic authentication, omit Step 2.

Controlling MD5 Authentication for a Specific Device Profile

To control MD5 authentication requests at the device profile level:

  1. Open a device profile file with a text editor. Device profile files are located in the $ORACLE_HOME/beehive/seed/oma directory.

  2. Locate the section of the file with the following text:

    <Capability>
         <Name>oma.support_md5</Name>
         <Type>boolean</Type>
         <Value>true</Value>
     </Capability>
    
  3. Modify the argument of the <Value> XML tag located in Step 2 to true or false, depending on the desired outcome.

    Note:

    When this tag is set to true, devices are forced to use MD5 authentication. They will only be forced to use MD5 authentication if the Mobile Data Sync service Md5Supported property is set to true.
  4. Save and exit the device profile file.

  5. Upload the device profile file to Oracle Beehive. For information about uploading the device profile, see Uploading a Device Profile.

Controlling Synchronization Ranges

You can control the maximum number of days, in the past or the future, that users are allowed to synchronize. By default the synchronization range depends on the type of device a user is using. Each device profile contains a default range appropriately adjusted to the capabilities of the device. You can change the default range for a particular device type by editing the range within the profile. Users can request a larger range by specifying a range within the Mobile Data Sync URI. By default the maximum range allowed is 365 days in the past, and 365 days in the future.

Note:

The synchronization range discussed in this section controls the range limits, and does not affect default values.

To modify the maximum date range allowed for data synchronization using beectl:

  1. Modify the synchronization range using the following command:

    beectl> modify_property --component _OmaService --name <PropertyName> --value <value>
    

    Where <PropertyName> represents a MaxSyncRangeBack (for the maximum number of days in the past) or MaxSyncRangeForward (for the maximum number of days in the future), and <value> represents a positive integer indicating the number of days.

  2. Activate the proposed property changes by executing the following command:

    beectl> activate_configuration
    

Example 7-2 displays how to enforce a data synchronization limit of four weeks in the past. The resulting output of the command is also displayed.

Example 7-2 Enforcing a Four Week Data Synchronization Limit

beectl> modify_property --component _OmaService --name MaxSyncRangeBack --value 28
Changes to configuration repository are not activated.
Successfully stored the property for component id 1e54ba56-7448-4849-b987-8dda59d26f4d.

Note:

You must run the beectl activate_configuration command after modifying a property, to apply your proposed configuration changes to the active configuration.

Configuring the Mobile Mail Service

Oracle Beehive allows you to configure certain Mobile Mail Service properties.

Note:

When changing Mobile Mail service properties, you will be modifying the absolute maximum values. Users will still have the option to change these values on their mobile devices, but will be limited by the Mobile Mail service absolute maximum.

This section explains how to modify Mobile Mail Service properties using beectl commands, and contains the following topics:

Controlling Maximum Number of E-mails Pushed to a Device

You can control the maximum number of e-mails that can be pushed to a device at one time. By default 200 e-mail messages can be pushed.

To modify number of e-mails that can be pushed to a device using beectl:

  1. Modify the number of e-mails that can be pushed to a device using the following command:

    beectl> modify_property --component _PushMailService --name MaxInboxMessages  --value <value>
    

    Where <value> represents an integer that is greater than 200.

  2. Activate the proposed property changes by executing the following command:

    beectl> activate_configuration
    

Example 7-3 displays how to change the maximum number of e-mails that can be pushed to a device to 500. The resulting output of the command is also displayed.

Example 7-3 Enforce a Maximum Number of E-Mails to Push to a Device

beectl> modify_property --component _PushMailService --name MaxInboxMessages  --value 500
Changes to configuration repository are not activated.
Successfully stored the property for component id ae373546-48e3-442d-8177-ae7e8f02e31e.

Note:

You must run the beectl activate_configuration command after modifying a property, to apply your proposed configuration changes to the active configuration.

Controlling the Maximum Message Size

You can restrict e-mail messages of a certain size from being pushed to a device at one time. By default the maximum e-mail message size that can be pushed to a device is 50 KB.

To the modify maximum e-mail message size that can be pushed to a device using beectl:

  1. Modify the maximum e-mail message size using the following command:

    beectl> modify_property --component _PushMailService --name MaxMessageSize  --value <value>
    

    Where <value> represents a positive integer.

  2. Activate the proposed property changes by executing the following command:

    beectl> activate_configuration
    

Example 7-4 displays how to modify the maximum e-mail message size to 100. The resulting output of the command is also displayed.

Example 7-4 Modify the Maximum Message Size

beectl> modify_property --component _PushMailService --name MaxMessageSize  --value 100
Changes to configuration repository are not activated.
Successfully stored the property for component id ae373546-48e3-442d-8177-ae7e8f02e31e.

Note:

You must run the beectl activate_configuration command after modifying a property, to apply your proposed configuration changes to the active configuration.

Controlling Past E-mail Push

You can control the maximum number of days in the past for which to push e-mail to a device at one time. By default the maximum number of days in the past is seven.

To modify the maximum number of days in the past for which to push e-mail to a device using beectl:

  1. Modify the maximum number of days in the past using the following command:

    beectl> modify_property --component _PushMailService --name NumberDaysPast  --value <value>
    

    Where <value> represents a positive integer, greater than 7.

  2. Activate the proposed property changes by executing the following command:

    beectl> activate_configuration
    

Example 7-5 displays how to modify the maximum number of days in the past of e-mail that can be pushed to a device to 14. The resulting output of the command is also displayed.

Example 7-5 Modify Past E-mail Push

beectl> modify_property --component _PushMailService --name NumberDaysPast --value 14
Changes to configuration repository are not activated.
Successfully stored the property for component id ae373546-48e3-442d-8177-ae7e8f02e31e.

Note:

You must run the beectl activate_configuration command after modifying a property, to apply your proposed configuration changes to the active configuration.

Deploying Oracle Beehive on iPhone and Blackberry

This section includes the following topics:

Deploying an iPhone Configuration File

Over-the-air access to an Apple iPhone XML Configuration file during device registration can be setup such that all necessary IMAP, SMTP, and CalDAV settings are provisioned automatically for the user. However, this file must be generated using the Apple iPhone Configuration Utility (iPCU) and then placed where Oracle Beehive can access it.

The iPhone Configuration Utility (iPCU) lets you easily create, maintain, encrypt, and install configuration profiles, track and install provisioning profiles and authorized applications, and capture device information including console logs.

Configuration profiles are XML files that contain device security policies, VPN configuration information, Wi-Fi settings, APN settings, mail and calendar settings, and certificates that permit iPhone and iPod touch to work with your enterprise systems.

In order for Oracle Beehive's device registration process to deliver an iPhone configuration file to user's iPhones it needs to first be generated using Apple's iPCU and then uploaded into Oracle Beehive.

  1. Generate a configuration file. Be sure to include settings for IMAP, SMTP, and CalDAV.

  2. In order to make the generated XML file generic such that it can be used for all Oracle Beehive users, you need to edit the XML and replace the hard coded values with tokens that Oracle Beehive can replace at runtime when a user requests to upload the file.

    Note:

    You must generate the profile with a security option of none. If you wish to sign your profile you can enter explicit values for each value but you will need to leave the user name blank and the user will be asked for it (as they are asked for their password) when they download the profile.

    The following sample samples shows the end result with the tokens highlighted in bold:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>PayloadContent</key>
        <array>
               <dict>
                    <key>EmailAccountDescription</key>
                    <string>Oracle Beehive Mail</string>
                    <key>EmailAccountName</key>
                    <string>$$DISPLAY_NAME$$</string>
                    <key>EmailAccountType</key>
                    <string>EmailTypeIMAP</string>
                    <string>EmailTypeIMAP</string>
                    <key>EmailAddress</key>
                    <string>$$EMAIL_ADDRESS$$</string>
                    <key>IncomingMailServerAuthentication</key>
                    <string>EmailAuthPassword</string>
                    <key>IncomingMailServerHostName</key>
                    <string>$$IMAP_ADDRESS$$</string>
                    <key>IncomingMailServerPortNumber</key>
                    <real>993</real>
                    <key>IncomingMailServerUseSSL</key>
                    <true/>
                    <key>IncomingMailServerUsername</key>
                    <string>$$EMAIL_ADDRESS$$</string>
                    <key>OutgoingMailServerAuthentication</key>
                    <string>EmailAuthPassword</string>
                    <key>OutgoingMailServerHostName</key>
                    <string>$$SMTP_ADDRESS$$</string>
                    <key>OutgoingMailServerPortNumber</key>
                    <real>465</real>
                    <key>OutgoingMailServerUseSSL</key>
                    <true/>
                    <key>OutgoingMailServerUsername</key>
                    <string>$$EMAIL_ADDRESS$$</string>
                    <key>OutgoingPasswordSameAsIncomingPassword</key>
                    <true/>
                    <key>PayloadDescription</key>
                    <string>Configures email account.</string>
                    <key>PayloadDisplayName</key>
                    <string>Oracle Beehive Mail</string>
                    <key>PayloadIdentifier</key>
                    <string>com.oracle.beehive.email</string>
                    <key>PayloadOrganization</key>
                    <string></string>
                    <key>PayloadType</key>
                    <string>com.apple.mail.managed</string>
                    <key>PayloadUUID</key>
                    <string>74753AFC-0702-4174-A3CA-621A603D2AF2</string>
                    <key>PayloadVersion</key>
                    <integer>1</integer>
               </dict>
               <dict>
                    <key>CalDAVAccountDescription</key>
                    <string>Oracle Beehive CalDAV</string>
                    <key>CalDAVHostName</key>
                    <string>$$BEEHIVE_SERVER_ADDRESS$$</string>
                    <key>CalDAVPort</key>
                    <integer>443</integer>
                    <key>CalDAVPrincipalURL</key>
    <string>$$BEEHIVE_URL$$caldav/$$ENPR_NAME_URLENC$$/principals/individuals/$$EMAIL_ADDRESS$$</string>
                    <key>CalDAVUseSSL</key>
                    <true/>
                    <key>CalDAVUsername</key>
                    <string>$$USERNAME$$</string>
                    <key>PayloadDescription</key>
                    <string>Configures CalDAV account.</string>
                    <key>PayloadDisplayName</key>
                    <string>CalDAV (Oracle Beehive CalDAV)</string>
                    <key>PayloadIdentifier</key>
                    <string>com.oracle.beehive.caldav</string>
                    <key>PayloadOrganization</key>
                  <string></string>
                  <key>PayloadType</key>
                  <string>com.apple.caldav.account</string>
                  <key>PayloadUUID</key>
                  <string>40A76E20-A6DE-4867-845C-549BBD287277</string>
                  <key>PayloadVersion</key>
                  <integer>1</integer>
           </dict>
       </array>
       <key>PayloadDescription</key>
       <string>Beehive Profile for IMAP/SMTP and CalDAV.</string>
       <key>PayloadDisplayName</key>
       <string>Oracle Beehive</string>
       <key>PayloadIdentifier</key>
       <string>com.oracle.beehive</string>
       <key>PayloadOrganization</key>
       <string></string>
       <key>PayloadRemovalDisallowed</key>
       <false/>
       <key>PayloadType</key>
       <string>Configuration</string>
       <key>PayloadUUID</key>
       <string>B24A2C42-277E-4D46-872E-33917300906C</string>
       <key>PayloadVersion</key>
       <integer>1</integer>
    </dict>
    </plist>
    

    Note:

    In addition to email and calendar settings, an Oracle Beehive administrator can include any other settings important for their deployment. When the user registers their device with Oracle Beehive and uploads the configuration file they will get the email and calendar settings as well as any additional settings. This can be done as part of one configuration profile or you can upload multiple profiles.
  3. To upload the configuration file to Oracle Beehive you need to create a ZIP file that contains the edited configuration file as well as a file called metadata.xml which should contain the following:

    <?xml version="1.0" encoding="UTF-8"?>
    <application>
        <property>
            <name> Beehive Mobile PIM Bootstrap </name>
            <display_name> Beehive Mail and Calendar Configuration Profile </display_name>
            <description> Oracle Beehive iPhone Configuration Profile for IMAP/SMTP and CalDAV. </description>
            <os> iphone </os>
            <processor>all </processor>
            <deviceclass> apple </deviceclass>
            <language> all </language>
            <version> 2.0.0.0.0 </version>
            <versionnumber> 20 </versionnumber>
            <patchsetnumber> 0 </patchsetnumber>
            <vendor> Oracle </vendor>
            <application_type>BOOTSTRAP</application_type>
        </property>
        <modules>
             <module>
                 <name>iphone_system.mobileconfig</name>
                 <src> . </src>
                 <dest> . </dest>
                 <contenttype>application/x-apple-aspen-config</contenttype>
             </module>
        </modules>
        <configuration>
            <param name="config_file" value="iphone_system.mobileconfig"/>
            <param name="download_mode" value="file" />
            <param name="replace_tokens" value="true" />
        </configuration>
    </application>
    

    Note:

    The display name in the sample above can be customized to the needs of the deployment. Also in this example the configuration file is referred to as iphone_system.mobileconfig, be sure to save the config file with this name or make sure to use your own name in the metadata.xml file.
  4. Upload the configuration file into Oracle Beehive:

    beectl upload_client_application –file iphoneconfig.zip

    With the configuration file now in place Oracle Beehive will automatically start offering it to users who register an iPhone.

Note:

In the sample configuration file shown above ports 993 (incoming email), 465 (outgoing email), and 443 (CalDAV over HTTPS), were used. In addition the Beehive Mobile Communicator uses the Beehive secure client port known as BTPS which is usually set to 5224. In order for iPhone users to have access to the Oracle Beehive functionality described above, these ports must be exposed outside the Enterprise firewall.

In cases where exposing such ports outside the firewall is not possible you may want to consider providing VPN access to your iPhone users. The iPhone Configuration Utility also includes support for Cisco AnyConnect and Juniper Networks SSL VPN clients.

Deploying Oracle Beehive on Blackberry

Before installing and configuring Oracle Beehive on their Blackberry device, users must activate their BlackBerry with BlackBerry® Enterprise Server for MDS Applications.

The BlackBerry device and BlackBerry® Enterprise Server for MDS Applications use symmetric encryption to maintain a secure communication channel between each other. To do that, both ends need to know a shared secret, the encryption key. The way that Research in Motion implements this is to use email to transfer the secret key from device to server.

To start, you need an IMAP account that the BlackBerry® Enterprise Server for MDS Applications can read. The Oracle Beehive administrator creates an account for the user, using their PIN (each BlackBerry has a unique PIN). They then give this to the user (usually verbally in person or over the phone).

The user then goes into their device, to the Enterprise activation screen, enters an email address (the IMAP account mentioned above) and the password supplied by the Oracle Beehive administrator.

The device then encrypts its local private key using the password entered, that then sends that payload to the email address supplied.

BlackBerry® Enterprise Server for MDS Applications monitors the IMAP account. When an email arrives it reads it and attempts to decrypt it with the password supplied. If it works, it then activates the account, and then starts pushing data to the device using the private key supplied by the device.

Follow these steps to deploy Oracle Beehive on Blackberry devices:

  1. Create a unique IMAP account within Oracle Beehive for each BlackBerry® Enterprise Server in your environment (For example, bes@yourorg.com). Configure each IMAP account to send and receive information in plain text. IMAP port 143 needs to be open from Blackberry® Enterprise Server to Oracle Beehive.

    Note:

    Do not use a personal IMAP account for BlackBerry Enterprise Server activations. The BlackBerry Messaging Agent searches the mailbox for unread activation messages; if an activation message is marked as read before the BlackBerry Messaging Agent processes the message, enterprise activation does not complete successfully.
  2. Once BlackBerry® Enterprise Server for MDS Applications is activated on their BlackBerry, users can proceed to the Mobile Center in Oracle Beehive Central and click on New to register their BlackBerry with Oracle Beehive.

    See the Oracle Beehive Registering and Configuring Mobile Devices end-user pages for more information on registering and configuring mobile devices and the Oracle Beehive Using Blackberry end-user pages for more information on how to access Oracle Beehive from your RIM BlackBerry device using Oracle Beehive Client and Oracle Beehive Communicator.