Browse by Tags

• Silverlight

• Controlling the Distribution of Silverlight Updates in the Enterprise

  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. 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... Posted Apr 07 2008, 08:02 AM by Tim Sneath Filed under: Silverlight, enterprise

• Making Silverlight Easier for Systems Administrators to Install...

  If you're really astute, you may notice that we released a very minor update to the Silverlight 1.0 plug-in this week. There's no changes to the core itself, apart from a fix to improve logging of Windows Media audio-only streams; as a result, machines won't auto-update unless the site they visit explicitly requests the new version. (The new version is build 1.0.30109.0, incidentally.) The main reason why this release is interesting is that we've made a few changes to the installation process to enable systems administrators to deploy Silverlight into enterprise environments more easily. Starting from today, Silverlight is available as an optional update for Windows XP and Windows Server 2003 via the Windows Server Update Services tool (and, inevitably, Microsoft Update , since WSUS relies on Microsoft Update as its source for updates). Many customers have requested help with deploying Silverlight internally, and this change will hopefully be welcomed by enterprises who want to distribute Silverlight within their organizations using their established management tools. By adding it as an optional update, enterprises can control the roll-out of Silverlight within their organizations and schedule its installation as a background task so that the perceptible impact is minimal, and ensure that end-users can view Silverlight content without requiring administrative rights to install the plug-in. I'm really glad this is now available: the need for administrator rights to install a web plug-in is not unique to Silverlight, of course, but it's been raised a number of times as a potential blocker to enterprise adoption. Having this available will solve that problem and make it far easier for enterprise administrators to control deployment of Silverlight to their users. Posted Jan 22 2008, 12:09 PM by Tim Sneath Filed under: Silverlight, enterprise