Hi Simon, simplesi wrote: > Well the legitimate use is that I'd like to do it and I don't think anyone > or any computer dies as a result of doing this :) OK, I have to admit that the wording here was probably not perfectly chosen. Of course nobody dies and nobody prevents you from doing it. I intended to point out that I see no general requirement to support this way of (in my eyes mis-)using of WPKG. Mainly because I am sure it will lead to problems and neither me nor the people supporting WPKG would like to be flooded by problem-reports from people using this "feature" even without exactly knowing the constraints. > I only ever once had the need to remove a package (the original Giant > Antispyware before MS bought the company and turned it into Defender) Seems your environment is really "stable" and not touched for years. Still using Win 98 and the same software since years. Well, good to know in which environments WPKG is running... > I just removed the package from packages.xml and installed a new package > that did the removal. Again, that's not really a clean way to do it but yes, it might work. However if you use WPKG to do so then every WPKG query will show that "Antispyware" is supposed to be installed in parallel to "Defender" which is not true because "Antispyware" is not there any more. > I'm sorry if I'm the only one that gets their xml messed up sometimes :( You're for sure not the only one but WPKG is designed to handle such cases as clean as possible doing a clean removal if you remove a package and a clean re-install if you re-add it. > As I said, I get 3 hours a week in each school - not a lot of time for > package deployment testing in between changing printer cartridges/paper jams > :) I am also managing a school configuration using WPKG but I probably visit it once a month for about 2 hours. Usually to pick up the install CD for a new software (which I deploy remotely then by pushing the WPKG update to their server via RAS) or to fix some non-networked stand-alone machines. Paper jams can be fixed by instructed (teacher) personnel ;-) > This wasn't a big request - I just thought wpkg should be able to do it :) Valid request. However my personal opinion you read above. I see some constraints and possible problems with such a change. Probably you will run into such problems once too. > Its hard to see the endless reboot happening, from my view if no package is > ever removed, there is no harm in leaving an entry in wpkg.xml - wpkg will > just say the package is missing and just not do anything - its hard to see > that doing nothing can cause my machines to re-boot :) If the packages are still listed within wpkg.xml (which is exactly what your change will do) then WPKG will verify the package during synchronization. In your case WPKG will try to remove every package which is within the local wpkg.xml on each synchronization run (so the queue of tried removals will grow on each change). If you use the /noremove flag the removal process will be skipped, but WPKG will retry on each run to run the remove commands (which are skipped each time due to the /noremove flag). Actually I had a look at the code (well, it's late now here) but as far as I can see the /noremove flag would work for you in case you define appropriate checks for your packages. This way WPKG tries to remove the software packages which are not in your server-side package database but skips the execution of removal commands. As long as your checks yield true (package installed) it will stay within wpkg.xml (this also happens if you do not specify any checks). WPKG only removes the wpkg.xml entry if your checks defined return false (if there is really something missing). So you might try to use the /noremove flag with pakages which are either not speifying any check or even better specify checks which yield true (which is anyway required for successful installation). I will try to do some tests as well but actually that should leave you with a setup where WPKG only removes packages from wpkg.xml in case the software is (manually) removed. > I think for some reason, you've decided to attack a humble long time servant > and admirer of wpkg which is an ideal tool to use in small schools without > having to go down the domain controller/AD/GPO locked down client route. It was not my intention to attack. Sorry if I offended you. I am basically using WPKG in similar environment it looks. However there is one difference between our setups. I use WPKG to track installation & uninstallation - so I prefer to have a defined environment at every point in time while it seems you don't care too much about the exact system state. What offended me (personally) a bit was your statement that WPKG should handle a state where a clear misconfiguration (accidentally removed package) should not lead to WPKG action. This is somehow against the basic principle of such a tool from my (just my personal) point of view. I still think such a tool should exactly do what I tell it to. In case I remove a package it should remove it ;-) But you might try my suggestion about /noremove flag again. Just make sure to define appropriate checks. > The machines aren't mine - there is no network manager - software is > installed by myself and teachers - we have one logon (with no password). Same for me. But my teachers are the only ones having the local admin password. > My "users" are children up to age 11 and they think hacking is changing the > wallpaper to a picture of a football team :) (which I correct by having > wpkg change it back again the next day) Same for me here but kids today know how to access the control panel and click on the nice Add/Remove Software icon and yes, they will try to click on these nice buttons too. Some of them also just follow some instructions they found on the internet (like "you might increase your disk performance by using 'format c:'..."). OK, maybe your kids behave differently than the ones here in Switzerland but I am not willing to take the risk anyway. > I'm not running the computer section of the FBI :) I guess they won't use WPKG - if I am wrong please tell me :D > I hope, once your indignation that someone like me is allowed to set up > computers goes away :), that you might think that its not such a stupid idea > :) I already had countless discussions with so called "system administrators" which did not even have a clue about user permissions and things like that. Probably you're aware of most of the constraints but from your messages this was not clear to me (and still isn't). And yes, I still think using any sort of package deployment or policies in an environment with undefined targets (where all users have full access) leads to a very high risk of running into trouble. And as soon as people run into trouble they will show up in the mailing list again and complain about the tools they use. Would not be the first time I get complaints about WPKG not running on certain clients but on these clients the user switched off all non-Microsoft services (including WPKG client). Such support request mainly waste time of voluntary support people here in the list. And yes, it's annoying to trace down such non-bugs. That's why I intended to stress on the fact that you should probably re-think about the security concept you applied and if you keep the current concept then you should be aware of the (possible) consequences. So finally I hope you will continue to use WPKG - or let's say it will serve your needs too. br, Rainer |