I was just helping someone internally with some deployment stuff and I came across these excellent videos by Richard Smith on MDT and doing Lite touch deployments. We obviously have an update of the tools but the basics still apply MDT Update 1 is available here and if you want to know more about Windows 7 deployment, check out Springboard.
What do you deploy to your people as part of your corporate standard desktop? Windows 7 – yep gota have that! Office 2010? Yep you know you need to moving to it if you want your people to work as efficiently as possible. MDOP – well obviously you’re going to be using parts of MDOP to get the job done, be it App-V to deploy your line of business app or Med-V to deploy the actual desktop. Over and above that what more are you packing in? Is Silverlight in there? In this post that’s exactly what I propose. You should be rolling Silverlight as part of your standard practice.
I can already hear the question screaming in over the ether…Why? Why? Why?!
And I can hear the reasons for not doing it too… “it’s another thing to maintain”, “it’ll encourage people to watch x-y-z instead of working”, “we don’t code for Silverlight, none of our own apps use Silverlight”, Actually that’s a good way to answer the why.
“it’s another thing to maintain”
That is a stance that you could take, given how hard other plugins are to manage. But we’ve thought about it well in advance and there are two very easy ways to do it. Firstly Windows Update is aware of Silverlight, so your WSUS, SCCM or SMS infrastructure that you’ve already deployed to manage your business is ready to keep your Silverlight clients on the latest version. Then there’s Windows Intune, when it’s released there’s yet another option for management.
Secondly Silverlight itself can check for updates and install them, something that’s controllable via group policy. What’s required for this “self update” option is for the user to have Administrator access to their PC and an Internet connection.
If you have a more tightly controlled environment then option one is probably for you but if you’ve chosen not to do too much in the way of management you’ve got yourself covered with option 2.
“it’ll encourage people to watch x-y-z instead of working”
Really? I’m not sure there’s a huge amount of merit in the argument for blocking peoples access to specific sites these days. It might be me, I might not be seeing it, but we don’t block access to iPlayer (or SkyPlayer which uses Silverlight) at Microsoft and I don’t see people watching TV shows all day. Surely as an IT Pro it’s better to provide the flexibility in case they do come across a business critical site that uses Silverlight – perhaps something using Pivot for really rich BI?
“we don’t code for Silverlight, none of our own apps use Silverlight”
Ahh the famous case of the chicken and the egg. I’m a firm believer that if you give people the ability to build something they’ll push the envelope and really build SOMETHING. How much of a difference would it make to your people if your line of business application actually looked the part and was so easy to maintain that the dev guys were able to keep it beating with the pulse of your business and users? IT Pros should be leading here, providing the tools and capabilities to make things better. It’s the same reason that I always think it’s best to deploy 64bit over 32bit where possible. Not because you need it right now, but you might.
I always remember being forced to deploy another browser plugin because a CBT (Computer Based Training) course was developed that would only run with version 9.55 or later and we were on version 7, in a regulated industry where you need everyone (that was about 10k people) to complete the training in 30 days time it was a painful lesson.
Do you deploy Office? Well if you do and if you intend to allow people to use Office 2010 Web Apps then you’ll get a much better experience with Silverlight installed as helps with even little things like synchronising files to the web. The Office deployment guide goes into far more detail:
Silverlight enables a better online experience with Office.com, powers the Office 2010 interactive guides (available with Office 2010), improves the user experience of Microsoft SharePoint Server 2010, improves the performance of Office Web Companion applications, and helps with the process of uploading Office documents to cloud services.
So all up, if you want the best Office 2010 experience you want to be installing Silverlight and if you don’t you’re going to miss out on some great features – the interactive guides significantly diminish the learning curve for your users!
From the why we move into the how:
How do I deploy Silverlight at work?
As I’ve mentioned a couple of times above, Silverlight is pretty easy to deploy and we’ve done all the heavy lifting for you with the trusty deployment guide. But to summarise it you can:
The last option isn’t mentioned in the deployment guide, however it’s as simple as installing before you sysprep your image and you can then mange Silverlight using WSUS and Group policy to keep it up to date. It’s probably best to use this option as a more tactical move if you’re a large organisation.
Resources:
For more information on Windows 7 deployment see Springboard, for more on Silverlight see Silverlight.net for more information on Optimized Desktop see
A couple of days ago I gave one of our customers a tour of Windows Intune and they were blown away with how simple it was to install and configure on clients. By blown away I mean they kept me talking about it for about 15 minutes…which considering there’s nothing to talk about (it just works) was a feat.
As this video I knocked up proves, there’s really nothing to the install. It’s zero configuration. Zero for the user to do wrong if they install it themselves. Zero for the sleep deprived IT Pro to error on.
Ok, nine minutes but in nice one minute bite sized chunks of video loveliness. Start here and my videos link together.
http://beautyoftheweb.com to download the IE9 Beta
Over the past week I’ve been asking people on twitter to talk to me about their experiences with BPOS and I had an interesting conversational thread with @IAmKat about multiple email accounts and how to send and receive. So I did some digging.
Firstly it’s really easy to receive email into one account from different addresses. For example, say I want to collect emails sent to admin@simon-may.com and have them go to my normal mail address. All I need to do (as the administrator of my BPOS account) is go to the Admin Center and edit my user account for the mail account where I want to receive the mail. If I then scroll down I can add any unused alias at any domain that I’ve got associated with my account. A great example of this would be to add the .co.uk domain if you normally use only the .com domain for your org.
Nothing here for your end user to do to receive this mail.
That’s only half the story though…what about sending?
That’s where things become more tricky. The BPOS team blog has the answer though in the form of distribution lists. Essentially what you do is create a dist list and allow one user to manage the list, then they can send and receive from it…it’s not super simple though which is a shame.