Push it. Push it real good.

April 3, 2009 8:01 AM

Is there a way to push the installation of browser plug-ins on a network where users don't have workstation admin rights (windows network)?

We are running windows server 2003, and have a network of maybe 19 Windows XP workstations. We have our network policy set up so that domain users are not workstation admins, so they can't install malware.

Problem is, they also can't install things like java updates or flash player updates. Group Policy allows us to send them Windows updates automatically, but I was wondering if it was possible to push updates for these browser plug-ins to all machines using an admin command of some kind? It would certainly be a pain in the ass to have to walk around and install this individually on each machine for the client.

posted by orville sash to Computers & Internet (7 answers total)

We're using Systems Management Server for this, but it's a fairly big product and system itself. But this is exactly the kind of thing it's good at because the agent that runs on the workstation does have admin rights, and can install things that the user could not.

If we didn't have that, then I suppose we'd probably look at doing something sneaky with the runas command inside a batch file to run the installation program under an admin account, and then have a logon script automatically run that batch file. That seems a tad messy though (especially as it would involve putting a password inside the batch file in plain text, yuck!)
posted by FishBike at 8:31 AM on April 3, 2009

Response by poster: Thx Fishbike. We've never actually used SMS before. Can you manage several different domains using SMS, or does it have to be purchased for each indivifual domain? It definitely looks interesting, and if we can purchase only one license and use it to administer all of our clients, that's definitely worthwhile.
posted by orville sash at 9:09 AM on April 3, 2009

We're using it to manage several domains within the same AD forest, using one server plus a "distribution point" in each of our offices so that the actual software to be installed doesn't have to be sent across the WAN multiple times to every office. You have to purchase licenses for the server(s) as well as client licenses for it, but as far as I can tell from our installation it doesn't really care about which domain the clients are in as long as they're all in the same forest. Microsoft themselves are generally pretty helpful in figuring out what you need to buy for your environment.

It strikes me as perhaps overkill if you're only managing 19 computers with it though. You may spend longer setting it up and setting up each distribution package of things you want to install than you would have just manually installing on each computer. That is right around our "sucks to do it either way" threshold too.

Basically it just involves figuring out how to do an unattended install of the product, that doesn't pop up any messages or prompt the user for anything. Then you put together a package in SMS that includes all the installation files and what command line it should run to launch the installation. You specific which machines to run this on and it reports back later on the status. I'm simplifying greatly of course.

For us the hardest part has been getting unattended installs to work on 100% of our computers, since various weird differences between machines have caused problems with failed installations. For us it's still better to deploy to 490 machines successfully and then go back and fix 10 machines, than to have to manually install on 500 machines. It's also generally easier to deploy an update when we've already done it before--if the vendor hasn't changed the process we can usually just update our distribution package and re-deploy it.
posted by FishBike at 9:25 AM on April 3, 2009

You can use Group Policies to install software for them (relevant Google).
posted by rhizome at 10:20 AM on April 3, 2009

In an active directory domain all your clients have two types of start up scripts. One is a user logon script and another is a machine logon script. You should see these in group policy. You can write a machine script that will install these apps at boot up using the SYSTEM account. The app's installer will need to have the option to run silent and without any intervention from the userts, thus the preference for .msi installers. You can work around this by using something like AutoIT to press buttons, do input, etc.

Your script should also check to see if the program is already installed so it doesnt run over and over again.

That said, this might be overkill for 19 machines. By the time you test it out you might as well have just done it per workstation. I think 19 machines is somewhere on the fence. If its a simple msi file you can save time by doing it but if youre going to spend three hours writing and testing install scripts, its probably not worth it.
posted by damn dirty ape at 10:23 AM on April 3, 2009

AppDeploy is a great resource for doing exactly this.

SMS would be a little overkill but following some of the info on appdeploy you should be able to easily push your browser updates out
posted by moochoo at 10:50 AM on April 3, 2009

Response by poster: Thanks, Damn Dirty Ape.

I actually do outsourced IT, so we have about 500 networks that we support in some way or another, but only very few are using Group Policy at this time. As spyware and spam gets more aggressive, we're looking to employ this in other networks, so we are hoping to find a solution that works for several networks. In that case, even though it might be overkill for one 19 machine network, it makes sense for 150.

I'll follow up on this thread with any R&D we end up doing.
posted by orville sash at 3:35 PM on April 4, 2009