Hi Simon, simon.begin at institutsmq.qc.ca wrote: > I would'nt import AD user and group lists into XML files, this of course > could make WPKG rely on other subsystem. And I agree with you this is > not a good direction to take. In our AD we have > 2000 users and > computers, so this will quickly make huge and unmaintaneable XML files. I was not saying that WPKG should do this import - rather another subsystem could do it based on schedule. You don't have to "maintain" XML files in this case because they are discarded on each update and re-written by contents of ADS, so no maintenance of XML. > I was thinking of adding some kind of condition statement that could > check whether the user or computer is in a specified AD group, before > assign the package. This could be either in profiles.xml or in > packages.xml. > > And this could be as simple as we actually do in our KIX logon scripts: > > ---------- > IF INGROUP("AD Group") > do something > ENDIF You could even call wpkg here to either install packages one-by-one (using /install parameter) or assign profiles if user is in specific group (using parameter /profile). But this of course only works if run from the user context - which works only for administrator users or Windows 9x. But that "problem" you will have no matter which technology you use. In general assigning Software based on the user account who logs in is not a good in most cases because people can roam on any PC which would require to uninstall a lot of software and install the software which is assigned to the logging in user. So usually you assign software to hosts or groups of hosts. That's what WPKG does. And of course the WPKG hosts.xml and profiles.xml could be generated from ADS. As I said I will also (when I have some time) have a look at the ADS add-on in bugzilla. Highest priority for me would be not to affect existing WPKG users in any way. The drawback of integrating it is clearly a bloated WPKG with code (~+50% size) used by a small minority. In addition I don't know who will test each change if it works with ADS deployments too. So we might end up having a small minority of users continuously having problems with WPKG and complaining and taking up resources of WPKG developers asking for fixes while most users will not have any problem. A solution could be to structure WPKG in a way that ADS support can be maintained independently in a relative easy way. So ADS users can maintain their part of the code too - but again, this includes the risk of breaking something for all other users too. br, Rainer |