Background

These are resurrected notes on the design of the Over The Air upgrade mechanism that was introduced in XenClient and continues to be used in OpenXT.

The XenClient software installed on a machine has the following constituent components:

...

• An update must be distributable as a single file with a declared three-letter filetype suffix.
• It must be possible to securely verify whether an update originates from Citrix or a proper source or not.

Phase 2

General

• For phase 2, it must be possible to apply an update using the Client UI by entering the URL of the update data.
  • [PB: This was a nice to have, so either allow upgrade via Client UI or just continue to support the CD based upgrade.]
  • For phase 2, it is not acceptable to require the use of the dom0 CLI to apply an update.
• Update from the Client UI must be possible regardless of whether the Client is registered to a Synchroniser.
• The Client UI must indicate which release is installed.
• The Client UI must report the download progress of the update data during transfer.
• The Client UI must prompt the user to reboot the host once application of the update has completed.

...

• It must be possible to apply an update via the Synchroniser to registered clients.
  • The Synchroniser must be able to function with clients with differing releases and different sets of hotfixes applied.
    • [Restrict combinations of Synchroniser and client release?]
      • [PB: The requirement I put in was starting with Brian we need to go one back. So Brian needs to support Dylan clients but not Lois clients. In the future we will likely need to do more but for now one back is fine.]
  • The Synchroniser must be aware of which release is installed on each client and which hotfixes have been applied.
  • It must be possible to upload client upgrades and hotfixes to the Synchroniser.
    • [PB: Would be good to define this a bit more. If we can do it I’d like to have the admin be able to use the Sync web UI and browse for a local file on their system to upload. Hit the upload button and get some basic progress and a message that the hotfix, upgrade is valid and who it comes from.]
  • It must be possible through the Synchroniser UI to target upgrades and hotfixes to specific clients.
    • The Synchroniser must be aware of which upgrades and hotfixes can be applied to each client.
    • [Ways to select clients?]
      • [PB: I spoke with you guys last time about doing device based selection but allowing the admin to derive a list of devices by entering a username or group name from a local user db or from AD.]
    • [Automatically applying upgrades/hotfixes to new clients?]
      • [PB: After the current environment gets upgraded then the admin will want to flip a switch and have it automatically upgrade any new clients added to the environment that are on an older version of the software. This is from XCP-562:]
      • [PB: The Synchronizer will need the ability to report on the version of XenClient software that is running on each endpoint and provide a mechanism to target the over the air upgrades to a subset or the total population of XenClient endpoints. The administrator should have the ability to phase the upgrades of endpoints over a period of time and target specific systems, users, or groups of users for upgrades. The user and group targeting should include both local and Active Directory linked objects. The system should also have a mechanism to report on upgrade failures.]
  • The Synchroniser must be aware when a client update fails.
    • [PB: Needs to allow an admin to run a report and see which systems failed.]
    • [PB: In some future release we would want to send e-mail alerts, etc, But running a report is fine for now.]
  • The update mechanism must obtain the consent of the user on the client before the update proceeds.
  • The update mechanism must not require the device admin password to be entered on the client.
  • [PB: The update mechanism should allow the user to postpone an update for some reasonable period of time. We should map to the Windows update process. I think the options are 10 minutes, 30 minutes, 1 hour, 4 hours.]

...