I've posted a few times about issues relating to enterprise distribution of Silverlight, and I thought I'd mention one additional topic that came up during a customer tour that I've been on for the last ten days.

Computer Management If you're a systems administrator, one of the aspects of Silverlight that concerns you is probably controlling the distribution of updates. In general, enterprises like to control their desktop and laptop environments to ensure no sudden surprises are caused (for example, by a runtime update that breaks a commonly used application). So some people may wish to dial down the update settings that are optimized for end-users when Silverlight is running in a corporate environment.

Silverlight supports enterprise rollout via WSUS and we provide guidance on how to roll it out across an enterprise via other means such as Group Policy (using the EXE-based installer). Silverlight is installed via a normal MSI plus an MSP-based patch which can be chained through a variety of means. Updating Silverlight to the latest revision can be done automatically or manually (by pushing out the latest MSP).

There are two different knobs an enterprise administrator can turn to control how updates are applied to the runtime:

  • Firstly, if the enterprise sets the UpdateMode DWORD registry value under the HKLM\Software\Microsoft\Silverlight key to 2 then the Silverlight auto-updater will be disabled (i.e. it won't automatically check for updates or try to install them). This is the equivalent to an end-user choosing the Silverlight Configuration dialog and manually disabling auto-updates from the Updates tab.
  • Second, the feature that allows a non-admin to patch Silverlight on Windows Vista without requiring admin elevation is not a Silverlight feature: it's a feature of Windows Installer which can be disabled if the admin wants to do so (and is indeed off-by-default in Windows Server 2008). You can switch this off using Group Policy by setting the DisableLUAPatching property. More information on UAC Patching can be found on MSDN.

If an enterprise disables the LUA patching feature in MSI and does not give their users administrative access to machines then users will not be able to install, remove or patch Silverlight. Only the enterprise administrator could touch the files. Obviously, it's important that someone is actively monitoring and distributing patches; as with any runtime for any operating system, without any means to fix potential security vulnerabilities, users' machines are at risk.

Many thanks to Bob Pomeroy for providing the technical detail behind this post. Hopefully this is helpful to those of you who need to persuade your IT department that Silverlight is "safe" for corporate adoption.