Aracılığıyla paylaş

Silverlight Enterprise Deployment Guide

  • Makale

This guide is intended for any organization who would like to deploy, manage, and troubleshoot Silverlight in their environment.  Some of the things you can find in this guide are installation switches, update behavior, value proposition on why to deploy, group policy adm / admx / adml files, and instructions on how to deploy Silverlight via group policy & SMS.

Back in May of this year I was presented with a side project to work on by Tim Sneath for this guide.  I accepted and it's great to have it finally released.  I had help from our SMS team doing a test deployment to 60k machines using the document, documentation reviewed by a number of people, and of course help from the Silverlight product team.

As an FYI - Efforts were made to create an MSI of Silverlight which could be deployed via group policy in addition to the script method, but there were challenges with this based on the way Silverlight inherently installs.  The Silverlight EXE extracts into an MSI and MSP file - both of which are required to install in order for Silverlight to function.  So if we gave you this version of the MSI, you'd have to go back and install the MSP separately after the MSI install (yuck).  In trying to package the exe into an MSI, you can't have two MSI files trying to install at the same time - so this doesn't work either. 

At any rate, the guide still shows you how to install Silverlight via group policy using the provided script.  Each group policy method (MSI and script) have advantages and disadvantages; the script method should be sufficient for most organizations.  In the future, there will be more installation/upgrade options and updated versions of the guide.  Future availability of a MSI package for group policy deployment is uknown at this time.

So please, download here and feel free to provide feedback.

Important Updates:
1) Many people seem to overlook the "important" notice on page 20 to answer the concerns about the HKCU registry settings for UpdateMode.  We intentionally did not create an ADM(X) template for this reason.  You should not be using this to control the setting because users can manually override this.  In the guide it states:
"The Silverlight control’s Automatic Update policy can be set per-user or per-machine. If an administrator sets a per-machine setting, then this overrides the per-user setting. We recommend that you manage Silverlight by using the Administrative Template settings in Group Policy whenever possible because these settings are always written to a secure per-machine key in the registry. This means that users cannot change settings by using the Silverlight user interface or by modifying the per-user update mode registry key."

2) As for the problems with importing the ADM(X) templates, errors will occur if the ADMX file is saved with any other name than SL_PARAMS.admx.  You will get the error as follows:
"Expected one of the following possible element(s), <target>,but found <using> instead.
File C:\Windows\PolicyDefinitions\name.admx line3. column 69"

To fix this, save the file as SL_PARAMS.admx (matches to <target prefix> syntax under %systemroot%\PolicyDefinition).

Technorati tags: Silverlight, Microsoft, Deployment Guide

Comments

  • Anonymous
    January 01, 2003
    Microsoft has release t he Silverlight Enterprise Deployment Guide This only includes 1.0 right now, but the deployment instructions and specifics should be pretty similar between versions. Microsoft wants to make sure Silverlight is taken seriously in

  • Anonymous
    January 01, 2003
    Microsoft has release t he Silverlight Enterprise Deployment Guide This only includes 1.0 right now,

  • Anonymous
    January 01, 2003
    So you want to deploy Silverlight ?&#160; Well, David Tesar wrote in his blog a few months ago about

  • Anonymous
    January 01, 2003
    Woke up to a funny email this morning. David Tesar in my team has been working on a Silverlight deployment

  • Anonymous
    January 01, 2003
    PingBack from http://www.wpfdev.com/2007/09/30/silverlight-deployment-guide/

  • Anonymous
    January 01, 2003
    I am testing deployment in my lab using SMS 2003.  Users are not admins of their boxes.  Therefore, I must disable automatic update check.  When disabled manually via the player,the following reg keys are written: Windows Registry Editor Version 5.00 [HKEY_CURRENT_USERSoftwareMicrosoftSilverlight] "UpdateMode"=dword:00000002 [HKEY_USERSS-1-5-21-1273229941-2172069033-1641802145-500SoftwareMicrosoftSilverlight] "UpdateMode"=dword:00000002 I'm not a GPO Pro (yet) but the ADM sample referred to in my previous post appears to not achieve the desired outcome.   Any help from anyone would be terrific. Regards.

  • Anonymous
    January 01, 2003
    I followed the steps contained in the 'Silverlight Enterprise Deployment Guide'; however I receive a parsing error in the ADMX file (waiting for "<target>" but found "<using>" tag). Are you sure that the ADMX definition contained in the guide is correct?

  • Anonymous
    January 01, 2003
    If you are looking to deploy Silverlight broadly throughout your organization, my colleague Dave Tesar

  • Anonymous
    January 01, 2003
    はじめて Silverlight のコンテンツにアクセスすると、アイコンが表示されて、そこから Silverlight をインストールすることができますが、企業内では各ユーザーが手動でインストールするのではなく、計画的に展開したいと思われるかもしれません。そのような時に役立つ、企業内での

  • Anonymous
    January 01, 2003
    Page 21, "ADM and ADMX file template settings" I imported the ADM sample "as-is" and am not able to get it to populate the registry "HKLMSoftwareMicrosoftSilverlight".  Is there a paritular forum for dialog on this? Thanks, dolson

  • Anonymous
    October 01, 2007
    Why would the RTM release be packaged across both an MSI and MSP?  Using login scripts for deployment is a throw back to the early 1990s and Novell Netware.

  • Anonymous
    May 28, 2008
    Quick question about automatic updates for Silverlight...  We'd like to use WSUS and never have the clients check themselves. In your documentation, you state that this key needs to be set: HKEY_LOCAL_MACHINESoftwareMicrosoftSilverlight Value Name: UpdateMode Value Type: DWORD Valid Values: Auto Updates 0x00000000 Prompted Updates   0x00000001 No Updates              0x00000002 However, if we actually change the setting manually by right-clicking and choosing Silverlight configuration, it updates HKEY_CURRENT_USER, not HKEY_LOCAL_MACHINE.  What gives? Is that a typo in the documentation, or does the HKLM setting override what the user does? Just wondering if we need to implement the adm for HKLM or HKCU .. I don't want 1000 users all calling up the next time an update is released.