[wpkg-users] RE Deploying software using AD group membership

[Rainer Meier]

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