One of the most useful features for a Teamsite administrator could very well be the flexible Teamsite groups.

These teamsite groups, which are equivalent to groups at the os-level, have two major advantages over these os-groups:

• they are controlled by the teamsite administrator
• they have to option to add a group to a group, empowering a hierarchical set up

The first is important because the os-groups are normally managed by a far away department that is usually slow to react. Adding or removing a user from a group could easily take days, leaving the end-user without proper access to Teamsite.

The second is maybe even more important because this, once set up right, enables the teamsite admin to easily add new users the proper rights by adding the user to 1 group only. Example: a basic group division would be 1 group of global adminstrators, 1 group of developers per 'teamsite-project' and a group of content-editors per 'teamsite-project'. Normally the developers have the same rights as the editors and some more and the admin's have all rights of the developers but IN EVERY PROJECT. This can be done by creating these groups:

• a group for the editors which contains all editors and the developers-group (per project or branch)
• a group for the developers which contains all developers and the admin-group (per project or branch)
• a group for the admins

Does using these ts-groups also have disadvantages? Sure:

• The iwchgrp clt does not work recursive where as chmod -R does
• In the os-level privileges all you see is the iwglobal group