One solution I used when rolling out a 40mb module was use a 2 stage loader/installer with wpkg. Our reason was to cater for field operators who only connect for short periods then go away for weeks at a time. eg:- Package Loader - Copies the installer to the machine using something like Robocopy, stores it in %windir%\temp, tests for file on succeed Package Installer - Depends on Loader, runs installer from %temp%, tests for program installation, if space is an issue deletes zip file from temp and creates a 0 length package.zip so that loader doesnt repeat
One of the benefits of robocopy is you can control the download rate and retry on fail. -- Michael Chinn User Support Officer - Information Technology Great Barrier Reef Marine Park Authority PO Box 1379 TOWNSVILLE, QLD 4810 Ph 07 47500874 Fax 07 4772 6093 [EMAIL PROTECTED] ================================================================================ If you have received this transmission in error please notify us immediately by return email and delete all copies. Any unauthorised use, disclosure or distribution of this email is prohibited. ================================================================================ Urs Rau wrote, On 19/07/2007 18:45: > Friends, > > Wpkg is a great product, but it doesn't come without it's own dangers > and traps. > > One of the traps is that in order to make sure the wpkg installs get > pushed out inside a reasonable timeframe, I opted to setup a scheduled > task that restarts the wpkg service every two hours. Turns out that can > be more problematic than I was expecting. > > The other day I was adding "adobe reader 8.1" to our sites main profile. > > The result was that ~ 70 PCs were trying to download and install a >= > 90MB file from the server. This gave me an average uptime of around 30+ > for about 2 hours. Basically the install processes were slowing each > other down so much, that users couldn't work on the PCs. We had to go > running around and start switching about 50 - 70% of the PCs off. For > the remaining started installs to finnish. But this created 2 hours of > chaos and almost unuesable workstations. > > The server isn't really underspeced and has not ever shown signs of > slowing down any other time, under normal usage and loads. > > Does anybody have any clever or creative ideas on how to avoid this sort > of overload? Maybe having a central file that monitors requests that the > wpkg service want's to launch and a service that monitors sensible loads > and tells the wpkg service on the workstations to delay until it thinks > the server load allows for more processes? > > How have others worked around this? > > The thought of installing MS .Net frameworks or MS office pkgs using > wpkg now seems really frightening. > > Thanks for any suggestions or poiters. > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wpkg-users
