Some administrators choose the easy way and just give local admin privileges to the user on the machine. It is then left up to the user to update and patch their system at their convenience. This is not only poor administration practice from a security standpoint, but it is also a nightmare to keep track of rogue software installs and licensing.
As a supporter of open-source solutions, WPKG is a great solution for managing software deployment on a small or large network with Windows based machines. It is easy to deploy, manage and saves administrators from hours of headache and frustration.
WPKG [www.wpkg.org] only requires a small service to be installed on the workstation. The server side of the package is just a SMB share which contains XML configurations and available applications for deployment. This means your file server can run Microsoft Windows, Linux or any other operating system that has the capability to provide network shares.
I recommend using the beta client which stable in all my testing. The beta client has better support for what WPKG calls "Laptop Mode" or "Off-line Mode". This prevents the software from trying to do things when working off-line. All software is installed at boot time prior to letting the user log into the system.
As with all open-source software, it is recommended that the manual and all documentation be completely read before asking questions. If you don't and the answer is in the manual or other documentation, you will probably be directed to read more. However, the community is active and quite helpful with problems.
The software can be broken down into four main parts. Three of them is server configuration and the other is the client configuration. The first part is the hosts configuration.
All settings for hosts is contained in a file called hosts.xml. This file is easily editable and maintained from any machine with write access to the share. WPKG has a basic reg-ex engine built in to help apply profiles to a group of similarly named machines. This is ideal if machines are named and numbered based on department. Below is an example of some hosts and specific profiles associated with those hosts.
The first is a static host name and it gets any software in the custom profile. The second entry is for any machine that begins with sales will get software from the sales profile. The third is the same but for another department.
<host name="sales.+" profile-id="sales" />
<host name="cs.+" profile-id="cs" />
The second part is for configuring the various software profiles. Each profile has a set of software applied to it, and only those machines associated with that profile will get that software deploy, upgraded and removed.
<profile id="standard">
<package package-id="firefox" />
</profile>
<profile id="sales">
<depends profile-id="standard" />
<package package-id="acrobat" />
</profile>
<profile id="cs">
<depends profile-id="standard" />
<package package-id="photoshop" />
</profile>
<profile id="custom">
<depends profile-id="standard" />
<package package-id="vmware" />
</profile>
</profiles>
The third part of the configuration is the packages. This is where all information for each application or script that is to be deployed out to the machine is stored. With WPKG, not only applications but console commands and scripts can be used. This makes it useful for doing other general maintenance. WPKG uses various types of check and conditional checks to make sure software is only deployed when it meets certain guidelines.
id="firefox3"
name="Mozilla Firefox 3"
revision="302"
reboot="false"
priority="10">
<check type="uninstall" condition="exists" path="Mozilla Firefox (3.0.2)" />
<install cmd="taskkill /F /IM Firefox.exe">
<exit code="0" />
<exit code="128" />
</install>
<install cmd="%SOFTWARE%InternetfirefoxFirefox Setup 3.0.2.exe -ms" />
<upgrade cmd="taskkill /F /IM Firefox.exe">
<exit code="0" />
<exit code="128" />
</upgrade>
<upgrade cmd="%SOFTWARE%InternetfirefoxFirefox Setup 3.0.2.exe -ms" />
<remove cmd="taskkill /F /IM Firefox.exe">
<exit code="0" />
<exit code="128" />
</remove>
<remove cmd="%PROGRAMFILES%Mozilla Firefoxuninstallhelper.exe /s" />
</package>
The client settings can be configured with the GUI client and then exported for importing into the rest of the clients. In my setup, I keep the settings on the share. I then use a script to copy the settings to the local machine at log-on and import into the client. This is so I can change the settings on the server and have it auto update the clients when they log on if required.
In conclusion, using WPKG as an open-source solution for software management is both cost effective and is easily managed in a network environment for any size of company. You have also saved your company money that can be used for something more useful.


" When the character of a man is not clear to you, look at his friends"
This past Friday, I traveled to Washington D.C. to take part in BlogPotomac, a casual conference (it took place at the State Theater, host to mostly concerts).



This question just came up during a webinar that Chris Baggott hosted today (5 Compelling Reasons SMB's Should Blog. Slides coming soon), and I couldn't resist responding to it myself.
