- How to add holidays to the Exchange calendar with PowerShell - Wed, Apr 23 2014
- How to change the domain name in Exchange Server 2010 - Tue, Apr 8 2014
- How to enable Unsolicited Remote Assistance in Windows 7 / 8 - Tue, Oct 1 2013
The great thing about WPKG is that it doesn’t require any infrastructure other than an SMB network share, oh, and it’s free! To follow this introductory tutorial to WPKG, head over to the download page to get the latest version of WPKG, unzip the file and copy hosts.xml, packages.xml, profiles.xml and wpkg.js to C:\WPKG or a location of your choice. You should also share this folder, as you will need to access it over the network.
WPKG configuration files
The wpkg.js file is the main engine of WPKG. It first looks through the various XML configuration files, and then runs any required commands to install, upgrade or remove software from your client systems.
So-called profiles are defined in profiles.xml. A profile basically contains a list of software packages that will be installed on the remote system.
In hosts.xml you can assign computers to a WPKG profile. For example, you could assign all hosts that belong to accounting to the finance profile.
Finally, packages.xml contains information about all the available software packages that you can manage with WPKG. Each package definition should include a "check" to determine if the software is installed or not, a set of installation commands, a set of upgrade commands, and finally commands to remove the software.
If you take a look at the files you have copied to your WPKG folder, it should be relatively easy to gain an understanding of the way the WPKG configuration works: A host is allocated to a profile, and a profile then refers to packages which contain information about the way how the software has to be installed.
To keep this example easy, we will just deploy a single application( 7-Zip) to our clients. Download the 32-bit MSI and then save it to C:\WPKG\Software\7-zip\7z920.msi.
WPKG sample configuration
First, open profiles.xml. Take note of how the example profiles define dependencies. The "other" profile section includes the openoffice package and refers to the software packages in the "default section". The definition of default packages is useful for deploying a base set of applications to all workstations.
<?xml version="1.0" encoding="UTF-8"?> <profiles> <profile id="default"> <package package-id="firefox" /> <package package-id="thunderbird" /> </profile> <profile id="custom"> <depends profile-id="default" /> <package package-id="openoffice" /> </profile> <profile id="administration"> <depends profile-id="default" /> <package package-id="openoffice" /> <package package-id="acrobat7" /> </profile> <profile id="other"> <depends profile-id="default" /> <package package-id="openoffice" /> </profile> </profiles>
Remove the example configuration from profiles.xml, and insert this very basic profile, containing just one package:
<?xml version="1.0" encoding="UTF-8"?> <profiles> <profile id="default"> <package package-id="7-zip" /> </profile> </profiles>
The example hosts.xml file adds any unknown/unmatched clients to the "other profile", so we don’t need to edit this file for now, although you probably will want to do that later when you’re getting more adventurous with WPKG.
Packages.xml also contains examples, which you should remove and replace with a simple configuration containing just one package. In a common WPKG setup, you would have multiple packages listed here. Replace packages.xml with the following configuration:
<?xml version="1.0" encoding="UTF-8"?> <packages> <package id="7-zip" name="7-Zip" revision="9.20" reboot="false" priority="1"> <check type='uninstall' condition='exists' path='7-Zip 9.20' /> <install cmd='msiexec /qn /norestart /i "\\SERVER\WPKG\Software\7-Zip\7z920.msi" REBOOT=ReallySupress' /> <upgrade cmd='msiexec /qn /norestart /i "\\SERVER\WPKG\Software\7-Zip\7z920.msi" REBOOT=ReallySupress' /> <remove cmd='msiexec /qn /norestart /x "\\SERVER\WPKG\Software\7-Zip\7z920.msi"' /> </package> </packages>
I will quickly outline what’s going on in this file, as the packages.xml is certainly the most complex configuration aspect of WPKG. You can find the full documentation for packages.xml at WPKG.org.
Package id - The ID of the package, must be unique and match the package-id that you used in profiles.xml so that WPKG can create the link between the two.
Package name – This is just a friendly name that is displayed while the software is being installed.
Package revision - I usually use the software version, although you can just use an incrementing number – if you increase the revision number, WPKG will run the upgrade commands for the package.
Package reboot - Some packages might require an immediate reboot, in this case you should set reboot to "true". In our example the package won’t require a reboot, so I’ve left it at "false".
Package priority – Defines the order in which packages will be installed by WPKG. The higher this number is, the higher the priority of the package is (5 will be installed before 1).
Check – This section defines how WPKG will verify whether the package is installed on the client. There are a number of different checks that can be performed. In my example, I am just checking for a certain entry in the "Add/Remove programs" control panel applet. You can combine multiple checks if required.
Install – This is the command used to install the software for the first time. For automated software deployment, it is important that this command runs without any user intervention (unattended installation). It can sometimes take a bit of time to find out the required command line arguments for unattended installation. WPKG wiki and appdeploy.com are great resources if you are searching for command line parameters of well-known installers. Luckily the 7-Zip installer comes as a Microsoft Installer package (MSI) . You can use "/qn2" for quite (unattended installs). As you probably already guessed, "/i stands for "install". You can see the full list of command line arguments for MSI installers by running "msiexec /?" If you add multiple install commands, WPKG will run them sequentially.
Upgrade – Upgrades work the same way as installations, however this command is only executed when the revision number of the package is increased.
Remove – If a package has been removed from a profile, but is still present on the system, WPKG will run the remove command(s) to uninstall application from the system. This takes the same options and format as the install and upgrade commands.
If there are any syntax errors in your XML files, WPKG will not process the configuration. It is often helpful open the files in Internet Explorer as this will highlight syntax errors.
In my next article, I will show you how to set up the WPKG client WPKG-GP.
You should mention that there are serious obstacles with using WPKG in a Win7/Vista environment due to the new secure desktop model. They even had to create a whole new way of running it: http://code.google.com/p/wpkg-gp/
As of today WPKG only supports Win9x – XP clients… 🙁
Here is the notes on WPKG and Vista/Win7
http://wpkg.org/Screenshots#Windows_Vista
David
Wait for part 2 of the article, where we go and configure the client side! We will get it all working 🙂 Group policy extensions (WPKG-GP) certainly is the way to go with Win7!
Nice article! Just waiting for part 2 🙂
I’ve tried WPKG-GP and it definitely is the right way to go for Win7-Pro clients. But it does not work on Win7 Home Premium which unfortunately renders it useless for myself in most cases. Usually I just use WPKG client and schedule the service startup to delayed start so it runs a couple of minutes after start. The user might already have logged in at this point of time which leads to a small risk that the user just runs some application to be upgraded.
Most installers will handle this situation properly. For others I’ve just included a taskkill command to close the application when in use. Usually such installers also just fail if the application is still running. So WPKG will just try again on next boot. Sooner or later it will succeed. Not the most clean solution but works in a couple of productive installations for me.
I stay well clear of all home SKU’s of Windows – even in my home!!
When did you last try WPKG-GP? More recent versions allow it to operate via the local policy on Windows systems – so maybe this will work on Windows Home systems? Maybe somone could give it a try and let us all know?
I’ve done my tests using WPKG-GP 0.14 (actually startet with 0.13, reported a bunch of bugs and got them fixed). During my testing we’ve discovered that local GPO do not seem to work on Windows 7 Home editions while on Windows Vista Home it still worked. I was not yet able to find any registry switch or hack which is easy to implement and gets local group policy to work on Windows 7 Home.
Actually my issues with home edition are documented here:
WPKG-GP appears to be the right way for modern OS like Vista and Windows 7 but unfortunately it’s not working at the most widespread editions.
So in general I would still recommend to give WPKG-GP a try in professional environments. But personally I am back to WPKG-client executed as a delayed-start service, running just in the background after boot.
Some questions I wish could be explored/covered:
We have multiple AD domains (spread out globally) connected via 10Mbps Internet & VPN connections) with a total of 500 PCs.
We have roaming users (non domain users with their own laptops AND domain members with laptops who take them with them when they travel)
WPKG-GP sounds great, how do we accomplish load balancing based on nearest UNC path with roaming users?
What happens on slower PCs when the suggested 30 minute GPO load timeout is reached? Is the install package interrupted?
How does it handle roaming users? A UNC path does not always resolve (nor would we want to without a secure VPN connection which is not always guaranteed to be up!)
WSUS (not that I want to compare the two) uses BITS to deliver the packages with whatever speed it’s possible (streams it a a byte level until the package is done vs. a “File copy” operation which is interrupted as soon as the UNC source is lost)
Does it have reporting features (X number of PCs were installed, Y number failed etc…)
I’ve been eying WPKG for a while, but in an enterprise setting where these things need to be counted on, how does it work? (or did I just need to read the FAQ?)
Does it handle dependencies? X application needs Y, Y application needs W etc…
Some answers:
> We have multiple AD domains (spread out globally)
> connected via 10Mbps Internet & VPN connections)
> with a total of 500 PCs.
OK.
> We have roaming users (non domain users with their
> own laptops AND domain members with laptops who
> take them with them when they travel)
OK.
> WPKG-GP sounds great, how do we accomplish load
> balancing based on nearest UNC path with roaming users?
WPKG is working on application level. Load balancing on software share servers is handled exactly the same way as you handle load balancing on your data shares (SMB/CIFS). Windows already provides balancing and load-sharing mechanisms. DFS can distribute the share contents to multiple local servers in order to reduce load on network connections and remote servers.
> What happens on slower PCs when the suggested 30
> minute GPO load timeout is reached? Is the install
> package interrupted?
That’s a specific question to WPKG-GP. I suggest asking on the WPKG-GP mailing list. Perhaps it will just terminate the WPKG-GP script execution and therefore the WPKG run. However if you have local servers I’ve never had any WPKG run which took longer than say 15 minutes. Often the software updated is pretty limited and installation is done within a couple of seconds (like upgrading Firefox or similar). Even deploying MS Office 2010 from local shares usually is done within 5-10 minutes.
If WPKG (the core wpkg.js script) is terminated before it finishes its job it will just start over next time it’s run and continue where it stopped (unless some installer is terminated in some unexpected state and then refuses to do its job when re-launched).
> How does it handle roaming users?
> A UNC path does not always resolve (nor would we want
> to without a secure VPN connection which is not
> always guaranteed to be up!)
In this case invocation of wpkg.js from the UNC share is unsuccessful. WPKG-client as well as WPKG-GP will report an event to event log about being unable to launch wpkg.js and terminate without any side effects (except the expected skip of updates).
> WSUS (not that I want to compare the two) uses BITS
> to deliver the packages with whatever speed it’s
> possible (streams it a a byte level until the
> package is done vs. a “File copy” operation which
> is interrupted as soon as the UNC source is lost)
WPKG is able to run any sort of script or application. It does not inherently support BITS but you can also call some BITS-enabled downloader to download local files before you run the installation. WPKG will just make sure your installer is called and waits for it to be finished.
WPKG comes with a “downloader” script which is able to use wget for HTTP/FTP downloads and robocopy to synchronize files to local HDD before running the installer. Wget also supports traffic shaping and bandwith limitation. However in most cases it’s simply sufficient to run the installers directly from a share. As said if it terminates before the installation is done WPKG will detect this by so-called “checks”. If checks are false (e.g. you can check for a specific software uninstall entry in the control panel) then WPKG will just report an error and re-try on next run.
> Does it have reporting features (X number of PCs were
> installed, Y number failed etc…)
The core WPKG script does not feature reporting. However there are a couple of Perl scripts included which prepare detailed reports of each client to you.
WPKG writes detailed installation logs to a server share if you want. So you can trace the logs for execution errors. Moreover WPKG writes the current machine state to a local database (wpkg.xml, located in %SystemRoot%\system32 by default). Many users use an “execute-always” package which simply copies this DB to the server so you can analyze it off-line (the Perl scripts included are doing this).
The next release of WPKG will also include additional command line parameters to query such wpkg.xml files. So you can query the state of each client of which you have a copy of wpkg.xml. You can also query which actions WPKG will perform on next run (like installations, uninstallations, upgrades or downgrades).
You might want to have a look at WPKG-Express which features a web-based interface to package management and also reporting:
I list this as the last option since I’ve never tried it personally – but the project looks pretty promising.
> I’ve been eying WPKG for a while, but in an enterprise
> setting where these things need to be counted on, how
> does it work? (or did I just need to read the FAQ?)
Many of the things have been discussed on the mailing list:
Feel free to ask your questions there as well.
Some Questions are answered on the WPKG wiki like Active-Directory integration:
But honestly WPKG is a small tool mainly targeting small (and potentially medium) sized enterprises. Large enterprises likely will use some (expensive?) professional service and would rather not rely on an open-source project.
I’ve also rejected a couple of change requests which were about enterprise integration only. The reason is that almost none of the supporters have a test environment of that scale and I can’t buy all the licenses and hardware required to simulate these environments (not even talking about time resources to support such features). So the answer is honestly and truly that WPKG scales quite well also in some larger enterprise environment but of course has some limitations like most FOSS projects in corporate environment.
> Does it handle dependencies? X application needs Y, Y
> application needs W etc…
Yes, fully supported package dependencies, chaining and include. The same for profiles.