2

What are the methods to install software (MSI) on a remote computers without active directory on windows platform?

The purpuse is to create universal application that installs software on all the workstations in diffrent locations and on various customers' networks.

  • 4
    What *do* you have? LanSweeper might be able to install software, but you don't mention the software you're deploying...proprietary installer, MSI, just unzip and run...can it be installed by a user via script or file share...does it need admin rights...what access do these users have, power user? Regular user? The question as worded is as vague as asking, "How can I get from New York to Vegas?" – Bart Silverstrim Oct 04 '10 at 13:06
  • +1 Bart. "How can I get from..." Classic – gWaldo Oct 04 '10 at 13:37
  • Let us know how you gen on with that "universal application". That's the Holy Grail that some of us have been chasing for 30 years or more. – John Gardeniers Oct 06 '10 at 04:40

3 Answers3

3

Use PSExec to copy and execute remote commands (such as .msi files) with the appropriate switches. You still have to provide admin credentials to each machine, however.

gWaldo
  • 11,887
  • 8
  • 41
  • 68
2

Your question can go one of two ways here. If the question is, "How can I manage software installation on Windows at an Enterprise level without using Active Directory and its related products" then there are a number of other products which would meet your needs -- the one I use is Novell Zenworks (which can optionally use AD but also Novell's eDirectory -- hence no AD) and I've been extremely pleased with it over the years.

However, if your question is (as I suspect) more along the lines of "How can I take a bunch of standalone workstations and remotely deploy software to them on the cheap," then we get into a bit more fun. The basic process of installing MSIs never changes -- you run the Windows installer from the command line, point it at the MSI file, and give it the appropriate flags for the kind of install you are trying to accomplish. It does get a little trickier if you are attempting to customize the installer or if the vendor has not provided a particularly msi-compliant file (some companies are notorious for wrapping their own .exe installers around plain-ol' MSI) and for that you might want an application like AdminStudio to modify MSI files or create your own. I would also recommend looking at a site like MSI Wisdom ( http://msiwisdom.com ) for tips on working with some of the more troublesome installers for popular applications.

The trouble starts when you need all those workstations to be able to run those installer commands without much intervention, and be able to run an ever-changing list of software.

My recommendation, very strongly, is that you get organizational buy-in to purchase and deploy a central directory service (like Active Directory or eDirectory) and workstation management software (like Microsoft's built-in offerings, Altiris, or the aforementioned Zenworks). This sort of software is not only more reliable than a homegrown solution, it will provide capabilities such as installation reporting (what installed where, what failed to install, etc.) that cuts down tremendously on your workstation maintenance workload.

That said, the "cheap" solution involves four things:

1) A file server with a read-only account specifically for software deployment

2) A local administrator account on every workstation with a standard username and password

3) A remote script on the file server written in a language capable of running the Windows installer (I would suggest VBScript or C#) and

4) A complementary script on the local workstation that is put into the scheduler.

So, what happens is this:

  1. Your local script in the scheduler runs at a set time every night (best to stagger it among the workstations) and does nothing but Map to the file server -> Run the remote script -> Remove the mapping after the remote script completes.

  2. The installer files are on the same file server share as the remote script. The remote script by default does nothing, but when you need to install software you change it (keeping the same name). When software needs to install, the script invokes the Windows installer running as the local administrator and installs whatever MSI package you currently have on the file server.

The cheap solution is going to be more costly in the long run. But if you don't want to do the installs via Sneakernet and are not going to deploy a centralized directory system with managed software, then this is the approach I would take.

Johnnie Odom
  • 1,199
  • 7
  • 10
2

We used to use the psexec with a batch script method gWaldo suggested. Recently we have started using PDQ Deploy to deploy our installers, both MSI and non-MSI such as Firefox. It is pretty straight forward and does multiple clients at once, which the batch file psexec method cannot do.

To help with these I look to WPKG.org for the correct switches to use for the silent installation

steve.lippert
  • 698
  • 6
  • 13