A typical device management operation involves the following steps:

1. The target device polls the server.
   
   The Device Management engine sends an HTTP POST to the server that contains its identification information.
   
   For more information about the client database, see Device Management Client Database.
   
   For more information about polling the server, see Poll Request to the Server.
   
   
2. The server responds to the target device poll.
   
   The server sends back a poll response with information about all packages that the target device is supposed to have, including optional packages. The response also contains changes, if any, to client configuration settings.
   
   For more information, see Server Response to the Device Poll.
   
   
3. The target device schedules an instruction request session with the server.
   
   The target device receives and parses the server response. The package list from the server is compared to the internal database of packages, and the target device computes all the packages that it needs to have to conform to the list received. It also removes those packages that it already has that do not conform to the list. The target device then sends an instruction request for every package that is needed.
   
   For more information, see Instruction Request to the Server.
   
   The server sends back a download instruction response for every download instruction request it receives from the target device. The download instruction response contains the download instructions for the package.
   
   For more information, see Instruction Response from the Server.
   
   
4. When the target device receives the download instruction response, it schedules a download event. The download event can be triggered immediately or it can wait for specific conditions, such as when the target device is docked. The scheduling criteria, including time schedule and bandwidth restrictions, are part of the download instruction response.
   
   A download event can be recurring or non-recurring. In either case, the download event consists of four phases:
   
   
   • The target device sends a package location request message to the server to get the current download URL. The server responds with a package location response.
     
     
   • The target device sends a status report that indicates the beginning of the download event.
     
     
   • The target device sends a status report that indicates the end of the download event. When the download is successful, it triggers the execution of the post install command. This is the command the target device should execute after the package is downloaded.
     
     
   • The target device sends a status report that indicates the end of execution of the post install command.
     
     
   A recurring download event is of two types:
   
   
   • Download package on every recurrence.
     
     
   • Download package only on first execution and only execute the post install command on recurrence.
     
     
   For more information about downloading a package, see Target Device Download Event.
   
   
5. If requested by the server, the target device also sends reports such as software inventory reports, machine inventory reports, and file collection reports to the server. The server controls these reports and the frequency at which they are posted by enabling the necessary report type in the server response to target device poll message.
   
   For more information about sending reports to the server, see Reports to the Server.
   
   

At any point in the preceding process, if a network connection is not available when a task or event has to execute, the task is queued by the device management scheduler until the network connection is available. Once the network connection is available, the task will execute at a time that is defined by the task frequency.

In addition, when a package download is interrupted because of a network connection failure, the device management engine keeps track of where the download was interrupted, and when the connection is restored, resumes download from the interrupted byte. For more information, see Checkpoint Restart.

See Also