Handheld devices such as PDAs and cellular phones are maturing into robust application platforms for enterprise business applications. Their connectivity, convenience and communications capabilities show great promise for new productivity gains. So what's holding them back? Managing and provisioning these devices is anything but easy.

Bringing notebook PCs into the enterprise wasn't as problematic. Notebooks could simply use the enterprise infrastructure already in place for desktop computers. Too different an animal, handheld devices aren't as fortunate. A Gartner study notes that fewer than 30 percent of the handheld computers--PDAs and smart phones--in enterprises are sanctioned or managed at any level.

Are we living dangerously? Consider how easy handhelds are misplaced. Ditto for the data on them. In the wrong hands, this data can compromise both organizations and individuals.

Then there's managing and provisioning. To be cost-effective and productive, handhelds need to be integrated with business processes and workflow, support the required business applications, and be regularly updated with the latest software. Too often they're off the grid.

Intel and Computer Associates recently teamed up to investigate ways to bring handhelds into the fold, reduce the total cost of ownership, and the security risk. The result was a prototype management and provisioning system and a proof-of-concept exercise with the University of Arkansas at Pine Bluff Technical Services Department. The good news? It worked.

Rethinking handhelds

To develop our prototype we had to rethink how handhelds are provisioned. Today's handheld devices come with a built-in operating system and prepackaged applications like WinCE, Palm, and Symbian. These devices can only be managed at or above the operating system level.

For our purposes, that was too limiting. We needed handhelds stripped down to just the hardware and firmware--no pre-loaded operating system or applications.

Handhelds like these would give IT departments the flexibility to load the appropriate operating system and preferred business applications, as well as the required corporate data, to make the device both usable and manageable in the enterprise.

The key would be having an easy way for IT to provision such a handheld remotely wherever it (and the user) happen to connect to the enterprise for the first time.

For our proof of concept, Intel developed a prototype (sans operating system) using its Universal Communicator design. This concept handheld supported voice and data over either a traditional GSM/GPRS cellular network or using 802.11 WLAN technologies.

Our prototype system used the Common Information Model (CIM), a data schema that provides a rich, extensible mechanism for representing and manipulating entities and information related to management tasks. Most computing vendors such as Intel, Microsoft, Sun, Cisco, IBM, Dell, and HP have adopted CIM. The enterprise management system we used was Computer Associates Unicenter.

The proof of concept

Four different scenarios were tried to evaluate the managing and provisioning benefits of the prototype device. The setup was a server, an access point, and two prototype handhelds containing only Extensible Firmware Interface (EFI) firmware with CIM and 802.11 capabilities.

-- Scenario 1: Provisioning bare Universal Communicator over a wireless network connection and downloading a generic OS image. This scenario demonstrated how handheld devices could be distributed to users, powered up to connect to the network, and then be automatically configured for the network. It also showed how, through using asset ID and rules configuration, the appropriate operating system for each user could be automatically uploaded to each device.

Aside from the coding of the rules configuration, no time or effort would be required from IT staff.

-- Scenario 2: Provisioning a second bare Universal Communicator over a wireless network connection and downloading a different operating system image. This procedure was exactly the same as the procedure for the first scenario, except testers first examined an XML file to see how it's configured to send a different operating system to Universal Communicator #2.

The device was then powered on and went through the same connection steps as outlined in Scenario 1. At the end of Scenario 2, the tester verified that a different operating system image had been loaded by viewing the user interface.

Scenario 2 demonstrated how different operating systems could be assigned to individual devices through rules configuration. It went on to show how these operating systems could be automatically uploaded to the appropriate device upon connection to the network with very little involvement from the IT staff.

-- Scenario 3: Reprovisioning a Universal Communicator over a wireless network connection with an updated operating system. This procedure started out like both Scenario 1 and 2. The Universal Communicator booted up, was configured with network settings, and was recognized by Unicenter. Then:

1. Unicenter requested characterization information from the device and, based on the rule configuration and asset ID, determined that the device required an updated operating system.

2. Unicenter sent the device the URL of the appropriate operating system.

3. The Universal Communicator downloaded the operating system from the http server.

4. The operating system loaded and the device rebooted.

5. The tester verified the operating system image was loaded by viewing the new user interface.

Scenario 3 showed how XML rules can be used to identify handhelds in the field that need operating system updates. It also demonstrated how these devices can receive updates automatically through the network with no involvement from the IT staff other than setting up the rules configuration.

-- Scenario 4: Identifying and decommissioning an unauthorized Universal Communicator over a wireless network connection. This procedure started out like the others--the Universal Communicator booting up, being configured with network settings, and then being recognized by Unicenter. Then:

1. Unicenter requested characterization information from the device and, based on the asset ID and rule configuration, determined that the device was not authorized.

2. Unicenter sent the device the URL of a specially programmed operating system for this situation.

3. The Universal Communicator downloaded the operating system from the http server.

4. The operating system was loaded and the device rebooted.

5. The operating system rendered the device inoperable.

Scenario 4 showed how asset ID and XML rules can be used to identify handhelds in the field that have been reported stolen or are otherwise unauthorized. It also demonstrated how these devices can receive a special operating system image automatically through the network that renders the device inoperable, preventing access to the network and to the data stored in the remote device.

Flying colors

Through this proof-of-concept study, we demonstrated the management and provisioning of handheld devices over a wireless network. We showed how:

-- A newly introduced handheld device could be automatically provisioned with the appropriate operating system and applications for a particular device for a particular user

-- An unauthorized handheld could be identified upon its first attempt at connection and then disabled through network management software

This proof of concept was part of ongoing research that Intel is doing to reduce handheld TCO, increase ROI, and enhance the user experience.

The authors wish to thank the University of Arkansas at Pine Bluff, for their participation in this research.