Deploy SilverLight 1.0 for the Enterprise

Since SilverLight 1.0 has been released I thought it best if I deployed this to all the machines I manage. Naturally it was quite early after the release that I tried to do this and Microsoft hadn’t exactly been helpful with how to do it. So I worked it out 🙂 Not that hard as usual.

Here’s what you do:
1. Get the .exe [link is for version 1.0.20816.0]
2. Unpack the .exe with the command: “Silverlight 1.0.exe” /x and put the files in an empty folder, eg. c:tempsilverlight
The files you’ve unpacked will include an .msi and an .msp – we need both of those as the .msi seems to do nothing much more than put the prog in Add/Remove Progs.
4. Now create your package in SMS, or modify your script, and use the following command from within a .cmd script file:
msiexec /qn /norestart /i “%~dp0silverlight.msi” /update “%~dp0silverlight.msp” ALLUSERS=2 (the %~dp0 command here is to put the path in to allow the update part of the command to work, as msiexec doesn’t seem to like /update usage when you don’t put the path to the file in)
5. Change the settings for the package so it runs from a drive letter and runs whether or not a user is logged in. You need a drive letter because you’re running a .cmd and these rarely work properly when run from a unc path.

That will install SilverLight 1.0 for all users of the computer silently and without rebooting the machines. It might need a reboot if IE is in use when the install starts so best to stop that too. It’ll shove its plug-in into Firefox if it’s installed as well which is handy.

One thing of note is that like Flash, SilverLight will try to install updates automatically. We probably don’t want that (I certainly don’t) and fortunately there’s a reg key to stop this happening… I made a group policy template for this one so it was set automatically.


Updated on 2007-12-06…

Since doing all this Microsoft did release a needlessly long document on how to do all this, all they really needed to say was: the quiet install option is… “/q” OK, whatever. Here’s their document:

Patching without Rebooting – HotPatching

I just stumbled upon the Microsoft articles explaining about HotPatching. A facility in Server 2003 SP1 and above that lets admins install updates without rebooting. Doesn’t work for all updates, but could be used for a lot.
Put simply you just add “/hotpatch:enable” as a switch at the end of a downloaded hotfix and it’ll try and HotPatch instead of ColdPatch. If the hotpatch fails it will do a normal coldpatch.

It’s a really cool idea really. They just append the modified code to the end of the binary and tell the app that running in memory to use the new code. After the next reboot the modified binary get’s replaced with the proper updated version.

Here’s a KB talking about what updates are compatible and how to use it: KB897341
And here’s a TechNet article about the technology: Whitepaper

New sysprep.exe ( for Server 2003 SP2

Here’s the file that you need for Server 2003 SP2 (kb926028): x86 / x64

Personally I couldn’t get the download to run properly on my Vista box (didn’t actually try very hard) so I ran it from an admin console with the /x switch.
It extracts some rubbish into a folder along with the that you want.

[Update 2011-06-15: Links refreshed]

Extend Vista’s Activation Dead-line by up to a Year!

It has been discovered that Microsoft have made it possible to delay the activation dead-line on Vista Business installs. Simple as changing a registry key, running a command and rebooting. Definitely script-worthy 😉
Found it on Bink first. Original article here.

Here’s my interpretation of what you have to do:
1. Running un-activated Vista, bring up regedit
2. Set the SkipRearm DWORD to 1 found at the following registry location: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL
3. Close reg-edit and run the following command as an admin: slmgr -rearm

After a reboot the registry key goes back to it’s default 0 value, and you have another 30 days of activation time. Sweet!

Apparently the act of setting the SkipRearm key prevents the activation information from getting wiped when the rearm command is run, so the rearm command just resets the expiry time. Supposedly you can repeat the process to give you a buffer of a maximum of a year.

The original article I’ve linked above starts babbling on about piracy and rubbish like that. Well who cares about that, that’s just home-user rubbish. This kind of thing will make admins very happy. Oh and don’t forget, an un-activated copy of windows can’t get on-demand updates from Microsoft Update can it! Something tells me the scare-tactics of “oh no, dodgy retailers might start selling un-activated Vista!” won’t quite hold any water.

Connection Failed when using a custom SMS 2003 console

Yet again, the usual annoyance with bloody Server 2003 SP1…argh!!! And now we have SP2 to play with too…what’s this one going to screw up I wonder…

If you’ve upgraded to 2003 SP1 on a server that has SMS2003, any delegated users that use the SMS console (e.g. for the remote control tools) will lose connectivity. See KB913000 article for assistance. It gets you to add a user or group to the ‘Distributed COM Users’ local group. God I should have known that one by now…
I found out a bit more about ‘why’ that makes it work and found the following article where you can give a security group remote launch and activation permissions.