Software Deployment

For 200 machines, I'd consider a scripted approach, where you can pass in a filename which contains the machine names and the software which will be installed on those machines.

And no, I don't have such a thing. I'm happy to quote against a detailed specification, though. PM me if you want to pursue that route.

Other than that, what about ZenWorks? Wasn't that bundled with Netware?

Thanks VBScab, I have considered using AutoHotKey or something similar, but I wonder if MSI packaging would be better.

I have looked at purchasing something like Best Network Security (http://www.softstack.com/bestnetsec.html) which offers a low-cost administration solution: you only need to purchase licenses for the number of administration consoles. So regardless of the number of workstations the cost doesn't go up until you need another admin-console.

BNS lets you run batch files and deploy MSIs to PCs, which is kind of cool, but the thin is it doesn't seem to have the ability to easily group PCs into like a folder structure, then give you the ability to apply a task to *all PCs* in that folder - in fact it doesn't let you do folders.

I was wondering if anyone had experience with Best Network Security, or could recommend something with a bit more functionality - it doesn't need to be the same kind of licensing scheme, but low cost is easy to justify to management.

Thanks again!

-stu.

Can you clarify what is we're talking about here? Is it packaging or deployment?

- Packaging involves the creating of an installation. MSI is the de facto standard.
- Deployment is the distribution of applications to workstations.

BNS is a red herring for either, since - from my reading, anyway - it's concerned with workstation security.

Ok, my question probably needs proper clarification - from my understanding you need to create an MSI (or similar) package that will contain the program in a deployable state, only after you have the Package can you deploy the application/s to remote computers. Is this correct?

In answer to your question, I believe I am asking primarily about deployment, but would like to know a little about packaging as well:

1. Is MSI the best way?
2. Do I need Active Directory to be able to deploy MSIs to remote Windows workstations, or will it just be easier if I have an AD environment as opposed to needing to find a 3rd party stand alone package-management/deployment system?
   

RE: Best Network Security, yes it's a tool that will allow you to restrict a workstation, but it's not a red-herring, it actually does allow for package (MSI) deployment and running of scripts on the remote PCs:

From the official spiel on their site:
[blockquote]Best Network Security is the best solution for corporations, public libraries, internet cafes, schools, universities and other applications where administrator has to secure and maintain a lot of network PC workstations located in different places. Administrator does not need physically visit workstations to change security settings or install patches.
<SNIP>
You just connect your administrator's computer to the net from any place and remotely change security settings, upload and execute patches as well as schedule reboots, shutdowns, and Windows Explorer restarts just with a click of the mouse.
[/blockquote]BNSwill run DOS-style batch files, which kind of implies it will run other kinds of scripts too, (I've only tested .bat so far).

It seems like a good tool, I'm just wondering if there is another low-budget tool that has a better interface with similar or better capabilities I guess.

-stu.

Windows Installer (MSI) *is* your best option for creating packages, for too many reasons to enumerate here but you don't *have* to use it. I know of one very, VERY large investment bank which is still deploying apps using VBScript (Hi, Rizzage! Hi, Dobbage!).

Nor do you need AD to deploy MSIs although it does make it convenient, in that you can restrict a package's "audience" to members of a group or groups. You can execute MSIExec.EXE, passing it the MSI name (plus any transform file) from a command line, or you can use the WindowsInstaller.Installer object (recommended, if going the scripted route).

BNS: patches are NOT packages: they're patches to an existing package. I didn't see anywhere in the spiel which said BNS could deploy MSIs. It can run DOS batch files but who'd want to?!? Hideous...

In your shoes, if your scripting skills are reasonable, I'd seek some scripts to manipulate Netware groups (to fetch group memberships, for example), some to connect with remote machines using WMI, some to create log files and some which use the WindowsInstaller.Installer object. I'd then combine them. The beauty of this approach is that you can make your solution do whatever you want it to.

Alright, thanks very much for your advice, now I know at least the basic concepts, I can have a look over the rest of the site and hopefully not be overwhelmed

-stu.

This may be useful. (I haven't tried it personally.)

Purgos
http://www.softulz.net

It sounds like you're blurring the line between two highly distinct systems, allow me to try and separate the two for you:

Packaging: is taking any piece of software, and customizing and polishing (typically using an MSI editing tool like Wise or Installshield) it for deployment to an environment. In most cases where a company has a dedicated packager/packaging team, these deployments are for large (1000+ seat, at least) environments and are designed specifically to minimize user impact and provide rock-solid user experience across a huge number of users. The Packaging process is basically over before the software ever gets deployed to an end user.


Deployment: This is taking a finished package, and getting it to install on a target workstation(s). Deployment tools are things like SMS, SCCM, Altiris' Console, Zenworks, BigFix and others. These applications provide a mechanism for getting software to a workstation, but they don't really help out with preparing the package. With sufficient scripting experience, you could create your own deployment mechanism, but it would behoove you to expend significant time and effort making such a system as solid as possible.


The two concepts are absolutely related, but are still independent of each other as processes.

The bright side is that most programs nowadays have silent options built into their installers and, while they might not be exactly perfect for you environment, they will at least get the stuff installed. So your primary worry should be putting a system together using WMI calls that will allow you to remotely execute programs.

Or you could always pay VBScab (or me!) to do it for you.