Topic Last Modified: 2010-07-14
 Note: |
|---|
| This topic applies only to IP phones. |
Microsoft Communications Server 2010 includes the Device Update service, which is automatically installed with Web Services. This service allows you to download updates from Microsoft, test them, and then deploy the updates to all the IP phones in your organization. You can also use Device Update service to roll back devices to previous software versions. We recommend that you check for updates every three months.
 Important: |
|---|
| Before you can use the Device Update service, you must fulfill the topology, component, and other requirements described in Planning to Deploy Devices. |
This topic helps prepare you to use the Device Update service by providing an overview of the components and update process.
Components of the Device Update
Service
The Device Update service is made up of the following components:
Device Request Handler
The device request handler performs the following tasks:
- Receives requests for software updates from IP phones.
- Receives device logs and stores them on the server.
- Generates audit logs for device update activity.
Device Updates Cabinet Files
Microsoft makes updates available in cabinet (.cab files) that you can download from the Microsoft Help and Support Web site. An update .cab file contains updates for one or more unified communications (UC) devices. After obtaining the .cab file, you upload it to Device Update service by using the Communications Server Management Shell.
The following file types are contained in an update:
- .cat: Security catalog
- .nbt: Software image
- .xml: Description file
Communications Server Control Panel
Use the following tabs, in the Clients category of the Communications Server Control Panel, to manage the Device Update service:
- Device Update. Provides the ability to view updates in
the device update store, create device update rules in Central
Management database and approve or reject device updates for
deployment, approve or reject updates for test devices, and roll
back updates to a previous version.
- Test Device. Provides the ability to specify the devices
that are to receive pending updates for testing purposes.
Device Updates Filestore
The Device Updates filestore serves as the central repository for the update information, logs, and audit information. It provides the installation point for devices that require updates.
In Communications Server 2010 Standard Edition, this folder is automatically created by the installer and located in the Web Services folder, under the installation folder. The default path is as follows:%ProgramFiles%\Microsoft Communications Server\Web Services\DeviceUpdateFiles.
In Communications Server 2010 Enterprise Edition, prior to installation, the administrator creates a shared folder to contain both client and device update files. The administrator then specifies the location of this folder when running the Create Enterprise Pool wizard during deployment.
| Important: |
|---|
| It is highly recommended that you create a quota on the Device
Update service log filestore at %ProgramFiles%\Microsoft
Communications Server\Web Services\DeviceUpdateFiles, using the
File Server Resource Manager. A quota will help to ensure that the
number of log files does not increase greater than the size of the
filestore, which could cause problems on the Web Services role. The
Device Update Service log filestore is installed as part of the Web
Services role, and it is recommended that the quota be set up
whether or not you are using the Device Update service. For more information on setting up a quota using the File Server Resource manager, see File Server Resource Manager Step-by-Step Guide for Windows Server 2008. |
The Device Update Process
The Device Update process begins with you downloading an update from Microsoft.com, and then using the Communications Server Control Panel to test, approve, or reject the update. Approved updates become pending updates that devices retrieve via the following process.
The first time a user starts an IP phone and signs in, the device gets information via in-band provisioning from the server. The information contains the internal URL of the server running the Device Update service.
If the device is turned on, but no user signs in, and no user has ever signed in on the device, then the device sends a DNS lookup request to ucupdates-r2.<the DNS domain name that was provided by DHCP>, and obtains the internal URL of the server running the Device Update service.
The device checks for updates every time it is turned on, every time the user signs in, and every 24 hours, by default. It checks by sending an HTTP request over port 443 to the Web Services server that hosts the Device Update service. The request includes the current version of software that the phone is running, and the response is determined by the device is and whether there is a new update on the server to download.
Internal Devices
If device is inside of the organization’s firewall, and the user is signed in, the Device Update service returns a response that contains one of the following:
- If no approved updates exist for the current version of the
firmware, or if the current version of the firmware matches the
version of the approved update, the response contains NumOfFiles =
0. For test devices, pending updates are also considered.
- If an approved update is available for the current firmware
version, the response contains the path to the location from where
the update can be downloaded.
External Devices
If the device is outside of the organization’s firewall, and the user is signed in, the Device Update service returns a response indicating that anonymous access is not supported. The device then sends an HTTPS update request over port 443 to the Device Update service. The Device Update service returns one of the responses listed in the internal case, above.
If the device is outside the organization’s firewall, and the user is not signed in, the Device Update service denies the request.
When the update is complete, the device will use the update as its current version, and the previous version will be stored in the firmware as a backup.