Hi Johannes, Johannes.Brix at evidian.com wrote: > Hello Rainer, > > let me explain my scenario: > I have a bunch of different user groups: students, secretaries, > consultants, managers, developers, support people. > I created a hierachy in the profiles: > 1st level: I grouped packages > 2nd level: I grouped the packages for my different usergroups. > > This works fine, but now, one user got a new notebook with Vista and there > are two applications, which do not work > or which are no longer neccessary. > > My idea was to check in the application package if the OS is Vista and then > not to install the package. Well, so you want to have a hack just for this one computer. To be honest I think this is quite a bad approach and makes the package structure difficult to maintain if there are lots of exceptions and pre-checks and the likely. As I wrote you could use a cmd script in the install command definition which executes the actual installer only if the package should be applied to the host (by executing any number of script-internal checks). Just make sure that you pretend to WPKG that the package is actually installed. For example the script could write a text file (e.g. %SystemRoot%\softXinstalled.txt) and you add a new check to the package like: - uninstall entry: softX installed OR - file exists: %SystemRoot%\softXinstalled.txt So the software will not be actually installed by WPKG but WPKG thinks it is. Thus not repeating the installation at each run. However I think it's not the best solution. I would rather prefer to create a new profile for vista clients. Of course this could easily double the amount of profiles you have (one for XP, one for Vista). However in my eyes this is a good idea anyway as you do not have to double the maintenance effort. In most cases you just update the package definitions and the same packages are refered within XP profiles as within Vista profiles. So no update required later on. Of course for some packages I also did similar things - I do some detection for "special" systems within the install script and I pass different parameters to the installer. However if a package is assigned to a node I generally want that this package is actually installed on that node - else I do not apply it to the node. > An other case is that all applications we use can be installed on a PC with > XP german on it. > But from time to time, our support needs to setup PCs in english or french, > and there are some applications > which cannot be installed in them. > Everythime the update is running, it tries again to install this package, > but fails. Also here - these machines need a profile which contains packages which are working for the machine. WPKG is designed to install software and make sure it is deployed. It is not designed to make decisions whether a software should probably be skipped or not depending on some rules. The same as I wrote above applies here as well. You might write some packages which "skip themselves" when executing on an inappropriate node while keeping exit status 0 (successfully installed) - making WPKG think it is installed properly. WPKG offers a lot of extension points and possibilities (like the ones described above) in order to do such "hacks". However I do not really recommend them as it makes it difficult to keep track of the actual software which is installed. Imagine you're doing some "inventory" or copying the local wpkg.xml to a server. Then the package is actually listed there, indicating it is installed. However you are not sure if it is really installed or if the install script somehow skipped the installation (probably wrongly). So I really suggest to assign only packages to hosts which should be installed. If you're not able to reduce the number of "machine classes" with different software base, this means that you have to maintain a profile for each of them (in worst case a list of packages for each node independently). This is not a problem of WPKG, it's a problem of planning. Operating an extremely heterogeneous environment also includes additional maintenance effort. It also includes additional testing effort as each package in theory would have to be tested on each machine independently to make sure it runs smoothly (if each environment looks slightly different). So I strongly advise administrators to operate as less "machine classes" (pools of machines with identical configuration) as possible. > So, if I can state not to install a package if the language is not german, > would be extremely helpfull. WPKG does not have such a functionality. As I wrote above if you operate machines with different languages and a different package set I suggest creating different profiles: - profile-langA - profile-langB If both profiles contain some packages in common you might use dependencies to minimize effort. For example I assume that the profiles differ only in a very limited number of applications (lots of applications are multi-language capable). So the profile structure could look as follows: - profile-global All applications applying to all profiles - profile-langA depends on "profile-global" above. adds langA specific packages. - profile-langB depends on "profile-global" above. adds langB specific packages. Unfortunately you did not name which applications you're talking about. Up to now I managed to write one single installer for all OS languages for every software I used. Most of the time it is simply about different "c:\Programme" or "c:\Program Files" paths or the likely. By using %ProgramFiles% variable or a small script detecting the path it is usually possible to use the same application on various Windows-language-versions. An install script might also determine which language the OS runs on and then run a language-specific installer. > And creating additional profiles for each exception would result in an > unmanagable number of profiles, > which we had before you added the "dependency" feature. > > I hope, this makes my question more clear. Yes, it does. I see your hints, however there is no easy way to solve it. By definition packages you add to a profile should be applied to the system (and not to be excluded due to some additional ruleset). I gave some hints above how you could solve it. However if you really have that many "special" installations you are in any case creating a huge effort in terms of managing the "software package" for each machine independently. If the effort to support that many different environments is too high, then a company should think about reducing the number of independent platforms in order to reduce effort and cost. Again, if each machine in a company would have its own list of software which should be managed by WPKG and each set is different, then this company would need a profile for each host for sure. Even that is not really a problem - an administrator could easily draw a tree to get an immediate overview which package is applied to which profile. Updating/changing a package is not a problem - it will apply to all nodes/profiles which include the package. Of course when a new package is introduced, then it needs to be decided to which profiles it should be added. In most companies there are some IT-guidelines which clearly state which software is installed in which departments. So it is common to have a profile for each department. While in lots of companies most departments use the same software profile while there might be a couple of departments having custom requirements and custom profiles. Applying special "rules" to packages where it is decided on each node if the software is applied or not creates some basic problems: - System administrators says software X is installed on all nodes within finance department. - Finance says software X does not exist on node a, b and c while it is installed on node d and e This creates some hard to trace problems for system administrators. Here it might be easy to have a profile for node a, b and c and another profile for node d and e. So it's very easy to see if a software X should be installed on node a, b, c, d or e and WPKG will write such messages directly to the server if installation fails. br, Rainer |