 |
| |
About groups and organizational units
About user groups
User groups give administrators a way to assign privileges, layouts and Desktop views to groups of users at once instead of having to configure each user uniquely. This allows greater control over your FirstClass system and makes global changes easy.
When you install your FirstClass server, there are three sets of groups defined in your network store (four if you have OTSW installed):
• Standard Groups
• Configuration Groups
• Department Groups
• Domain Name Groups.
These sets of groups already have groups created to help you get started in setting up your FirstClass environment. The Groups folder may look a little overwhelming at first glance, but is very easy to work in and customize once you are familiar with its structure and how individual groups fit into this structure.
User groups make your job easier, as you can set privileges, create model Desktops, or make changes for a group of users rather than individually for each user.
Standard user groups
When you install your FirstClass server, it automatically creates several standard user groups. FirstClass automatically adds users to these groups as required. While not all of these groups are displayed in the User Groups section of the User Information form, users still belong to them based on eligibility. The following are the standard user groups and a list of users belonging to them.
 WarningDo not delete or rename any of the standard user groups. Deleting these groups can lead to unpredictable system behavior and system damage. If you delete one by mistake, recreate it immediately with exactly the same name and restart your server.
The values set on the Group Privileges form for these groups override the values that are currently set for the user’s other groups and the System Profile. The privileges set for these groups can be overridden on users’ User Information forms.
For example, if you set a connection limit of Unlimited on the All Users Group Privileges form, but you want all autoregistered users to be limited to 30 minutes, set this value for the Autoregistered Users group on the User Limits tab of the Group Privileges form.
Keep in mind that anything you enter on a individual’s User Information form overrides all other settings.
Configuration Groups
Configuration groups are simply groups that define the use some users make of your FirstClass system, but it does not define their roles within the organization. The pre-configured groups in this area are:
• High Disk Usage
• Help Desk
• Subadmin Users
• Suspended
• Webmasters
• Time zone groups
• RAD Developers
• DS Deleted
• DS Admin
• Voice users
• No Outbound Internet Mail
• Administration Resources
• Online Help Administration
• Online Help End Users
Membership in these groups is not based on organizational identification. Group members may have additional configurations based on membership in one of these groups, but these privileges do not define users’ overall roles in the organization. For example, you may have five members in your IT department (organizational), but only two of these users are also subadministrators (additional configuration). The organizational classification of these five users is IT, and the extra duties of two of these users include subadministrator duties, which require additional configurations. Therefore, they are added to the Sub Admin configuration group.
You can delete or rename any group in this area, however, we suggest you do not delete the Sub Admin or Webmasters groups since they have been configured to contain all the tools and security required to perform these roles. If you do not use a subadministrator to help with FirstClass administration, or you do not use FirstClass Internet Services to connect to the Internet, leave these groups intact but do not add users to them.
Department Groups
Department groups are used to organize people on your system into their functional areas. You may want to designate organizational unit levels for these groups.
You can delete or rename any group in this area. You can have as many as 600 user groups on your FirstClass system (more for MP sites).
When you install FirstClass for the first time, you can run a one-time script to change the preconfigured department group names. See the Start Here folder on the administrator's Desktop for information and instructions.
Domain Name groups
You can create groups based on a specific domain name, such as huskyplanes.com. Whenever an Open Text Social Workplace (OTSW) user is invited and they are a member of that domain, they will automatically be added to that group and receive the associated model Desktop, privileges, and so on.
Organizational units
An organizational unit (OU) is, quite simply, just another way to use user groups to organize your system for easier identification of users and/or to allow duplicate Directory entries (applies to user names and conferences). OUs are not required in setting up your FirstClass system, but can play an important role in organization and security, especially in complex FirstClass systems with many users, locations, or branches.
 CautionDo not assign OUs to Standard groups.
 FCDSIf you plan to use FirstClass Directory Services (FCDS) in LDAP mode, remember that you must make sure the user groups that are part of your organization's hierarchy are assigned to organizational units in a way that reflects your hierarchy.
If you are using FirstClass scripting to configure your system and users, the SETOU command can be used to define the OU.
When configuring your system from the administrator’s Desktop, OUs are defined on the Group Privileges form:
 OUs are used to define a set of levels into which people on your system fit, but the OU does not determine the hierarchical role of the members. A user can be a member of several organizational units at any level.
The most user-specific organizational unit is the user’s Primary organizational unit. For instance, a user is an employee, a member of the management team and a member of the accounts payable department, all of which are defined as OUs in the company. The most user-specific OU for this individual is the department group (accounts payable). Therefore, this is the individual's primary OU.
The Primary OU can be (but does not need to be) a member of a larger OU, like an umbrella structure. OUs classify groups of users according to their role in the organization, not according to their levels.
NoteA user’s privileges and permissions are not inherited from one organizational unit to another. You must specifically assign the user to each group in the proper order on the User Information form.
NoteIf you use OUs for your system structure, all users must belong to at least one OU or permissions and privileges may not work as intended.
Business example of creating OUs
Husky Planes has the following divisions within its organization:
• employees
• management
• IT
• finance
• customers.
Management, IT, and finance are distinct departments within the company and each user belongs to one of them. Therefore, these groups will all be given the OU level of Department.
The customers group also fits this model since its members use Husky Planes’s FirstClass system and communicate with some Husky Planes employees. Therefore we will also give the customers group the OU level of Department.
Even though we decided that employees was a logical division in the company, we still haven’t given the employees group an OU level. Since this group contains most, but not all, of Husky Planes’s users and it contains members of other OUs (some, but not all the departments — customers are not employees, but they are a department on our system), we will choose the OU level of Company.
Education example of creating OUs
Avalon Academy school has the following divisions:
• employees
• faculty
• school admin
• IT
• students
• teachers.
The faculty, school admin, IT, students, and teachers groups are distinct divisions within our school structure and each user on our system belongs to one of them. Therefore, these groups will all be given the OU level of Department.
Even though we decided that employees was a logical division in our school, we still haven’t given the employees group an OU level. Since this group contains most, but not all, of Husky Planes ’s users and it contains members of other OUs (some, but not all the departments — students and parents are not employees), we will choose the OU level of School.
Directory listings for organizational units
On the Group Privileges form, you can choose what information to list in the Directory. Choose Organization to display users' primary OU only, and choose Organizations to display all the OUs to which users belong.
 In this example, Joe Employee is not a member of any specific department so his Primary OU is Employee. Although Joe Manager and Joe IT are both employees (and members of the Employees OU), their Primary OUs are listed.
If a user belongs to two Primary OUs (management and finance for instance), the one listed closer to the top of the user groups list on the user’s User Information form will be the one that is displayed. In the following example, Joe IT is also a manager and is a member of the Management OU:
 In the Directory, Joe IT will be listed as IT, not Management.
 Conferences in organizational units
Conferences and conference groups created by the administrator on the administrator’s Desktop do not belong to an OU. However, administrators can set the conference or conference group OU using the FirstClass scripting SETOU command.
A user's objects inherit the OU of his Primary OU. If you have given your users permission to share conferences or calendars, any conference or calendar a user creates will inherit his Primary organizational unit.
Organizational units and duplicate Directory entries
OUs allow you to have multiple Directory entries. If you select "Require unique names within this organizational unit" on the Group Privileges form, you can have two people with the exact same name in the Directory as long as they have different primary OUs. For instance, if you have a Lisa J. Smith on faculty, you can also have a Lisa J. Smith who is a student teacher. When you list the search for Lisa J. Smith in the Directory, you will see the following:
 You cannot have duplicate names within the same organizational unit. If Lisa J. Smith is hired on full time, you will have to change her name in the Directory (Lisa Julie Smith, for instance).
NoteYou can never have duplicate userids.
Using Designer to edit organizational unit levels
If you want to edit the names of the organizational units, or add more levels to better fit your organization, use FirstClass Designer. For basic information about editing forms using designer, see FirstClass Designer, or our online help.
The server reads the organizational unit as a number only. If you open the Group Privileges form using Designer and look at the organizational unit dropdown list, you will see that each level has a number beside it. You can edit the wording beside the number, or you can even edit the numbers. As well, you can add additional choices to this list. The numbers are merely a way for the server to read the written information. Valid numbers are between 0 and 800.
Creating a multi-tenant environment
The flexibility organizational units adds to your system is best seen when used in a multi-tenant environment. This is a configuration in which there is more than one independent system running on a single FirstClass server. These systems are entirely independent of one another, and users on one system can never see users on any other system in the Directory.
Creating a multi-tenant business environment
Husky Planes is starting a subsidiary company, Malamute Transport. Malamute Transport will use Husky Planes’s FirstClass system, however, management wants Malamute Transport to be its own independent entity. They do not want to share information, communication, or Directory listings between the two companies. While they will share a FirstClass system, they will be entirely separated from each other. The FirstClass administrator will use organizational units and Directory filtering to accomplish this as follows:
1 Make required changes to the groups folder.
• Do not change any of the Standard, Configuration, or Directory Filtering groups. Any settings or overrides set for these groups will apply to all applicable users on your system.
• In the Department groups section, create a new group called HP Users. This will be the master group to which you will add every Husky Planes user.
• Create a new conference group called HP Conferences and a new calendar group called HP Calendars. These will be the master groups to which you will add every conference and calendar respectively for Husky Planes.
• Rename all Department groups, Conference groups and Calendar groups to be specific to Husky Planes. For instance, rename Employee to HP Employee, and Finance to HP Finance. You may want to group all Husky Planes groups on one side of the Groups folder to make organization easier as your system grows.
At this point, the Groups folder will look something like this:
 2 Set the organizational unit levels of the HP groups.
• Set the HP Users organizational unit level to Company.
• Set all other HP groups organizational unit levels to Division, Department, Group, or Team, as appropriate.
3 Set the unique domain names.
Husky Planes will have a different domain name than Malamute Transport. On the Services tab of the HP Users Group Privileges form, enter "huskyplanes.com" at "Domain name" (this is Husky Planes’s registered domain name). All the Internet aliases for members of this group will default to this domain name.
If you will not have separate domain names for your multiple tenants, do not enter the domain name here.
NotesIf a user is a member of multiple organizational units and more than one of them has a domain name, the domain name for the user’s Primary organizational unit will be used.
If you have multiple domain names, remember to include them on the Multiple Sites and Languages form.
4 Set up Directory filtering.
Do not set up Directory filtering for HP Users, HP Conferences and HP Calendars.
Set up Directory filtering using the Group Privileges form Directory tab for all other HP groups by selecting "Allow this group to view these groups" and entering HP Users, HP Conferences, and HP Calendars.
NoteYou can filter the Directory more if you like, but ensure these are listed first.
Some things to remember:
Ensure that any user added to the Husky Planes system is made a member of the HP Users group. List this directly after the class of user group on the User Groups/Directory tab of the User Information form.
Ensure that every conference on the Husky Planes system (and any conferences you add to the Husky Planes system later) is made a member of the HP Conferences conference group.
Ensure that every calendar on the Husky Planes system (and every calendar you add to the Husky Planes system later) is a member of the HP Calendars groups.
When a user creates a new conference, the user’s organizational unit is inherited to the conference, so the Directory filtering rules will be applied automatically.
5 Create a Department group structure for Malamute Transport using the same principles used for Husky Planes.
NotesPreceed all user, conference, and calendar groups, as well as all conferences and calendars with MT to distinguish them as being solely for Malamute Transport.
Set the MT Users organizational unit level to Company (like HP Users).
Set all other MT groups to logical organizational unit levels.
Remember to make all Malamute Transport users members MT Users, all Malamute Transport conferences members of MT Conferences, and all Malamute Transport calendars members of MT calendars.
The Husky Planes/Malamute Transport multi-tenant environment Groups folder looks like this when complete:
 No user configured as a member of HP Users can see any user in the MT Users group. All Husky Planes conferences and calendars are hidden from all Malamute Transport users, and vice versa. With the Directory partitioned in this way, they can function as two completely independent systems, apart from the server administration. Any tracking and billing can be done at the company level (or group, or user level), instead of at the All Users level, making this a true multi-tenant environment.
Creating a multi-tenant education environment
Avalon Academy is a school in Separate School District 21. Separate School District 21 wants to run its office, Avalon Academy, and other schools on one FirstClass server, but it still wants to maintain each school and the district office as separate entities. They do not want to share information, communication, or Directory listings between the schools or the district office. While they will share a FirstClass system, they will be entirely separate from each other. The FirstClass administrator will use organizational units and Directory filtering to accomplish this as follows:
1 Make required changes to the groups folder.
• Do not change any of the Standard, Configuration, or Directory Filtering groups. Any settings or overrides set for these groups will apply to all applicable users on your system.
• In the Department groups section, rename the School group to AA School. This will be the master group to which you will add every Avalon Academy user.
• Create a new conference group called AA Conferences and a new calendar group called AA Calendars. These will be the master groups to which you will add every conference and calendar respectively for Avalon Academy.
• Rename all Department groups, Conference groups and Calendar groups to be specific to Avalon Academy . For instance, rename Faculty to AA Faculty, and Students to AA Students.
• You may want to group all Avalon Academy groups in one area of the Groups folder to make organization easier as your system grows.
At this point, the Groups folder will look something like this:
 2 Set the organizational unit levels of the AA groups.
• Set the AA School organizational unit level to School.
• Set all other AA groups organizational unit levels to Grade, Class, Group, or Team, as appropriate.
3 Set the unique domain names.
Avalon Academy will have a different domain name than the school district office and all other schools in the district. On the Services tab of the AA School Group Privileges form, enter Avalon Academy ’s unique registered domain name at Domain name. All the Internet aliases for members of this group will default to this domain name.
If you will not have separate domain names for your multiple tenants, do not enter the domain name here.
NotesIf a user is a member of multiple organizational units and more than one of them has a domain name, the domain name for the user’s Primary organizational unit will be used.
If you have multiple domain names, remember to include them on the Multiple Sites and Languages form.
4 Set up Directory filtering.
Do not set up Directory filtering for AA School, AA Conferences and AA Calendars.
Set up Directory filtering using the Group Privileges form Directory tab for all other AA groups by selecting "Allow this group to view these groups" and entering AA Users, AA Conferences, AA Calendars.
NoteYou can filter the Directory more if you like, but ensure these are listed first.
Some things to remember:
Ensure that any user added to the Avalon Academy system is made a member of the AA School group. List this directly after the class of user group on the User Groups/Directory tab of the User Information form.
Ensure that every conference on the Avalon Academy system (and any conferences you add to the Avalon Academy system later) is made a member of the AA Conferences conference group.
Ensure that every calendar on the Avalon Academy system (and every calendar you add to the Avalon Academy system later) is a member of the AA Calendars groups.
When a user creates a new conference, the user’s organizational unit is inherited to the conference, so the Directory filtering rules will be applied automatically.
5 Create a Department group structure for Separate School District 21 using the same principles used for Avalon Academy.
NotesPreceed all user, conference, and calendar groups, as well as all conferences and calendars with D (for District) to distinguish them as being solely for the school district office.
Instead of having a group called School, name the group something like D Office. Give this group an organizational unit level of District.
Set all other D groups to logical organizational unit levels.
Remember to make all school district users members D Office, all school district conferences members of D Conferences, and all school district calendars members of D calendars.
The Separate School District 21/Avalon Academy multi-tenant environment Groups folder will look like this when complete:
 No user configured as a member of AA School can see any user in the D Office group. All Avalon Academy conferences and calendars are hidden from all school district users, and vice versa. With the Directory partitioned in this way, they can function as two completely independent systems, apart from the server administration. Any tracking and billing can be done at the school level (or district, group, or user level) instead of at the All Users level, making this a true multi-tenant environment.
If you want some collaboration between the school district and the schools, you can set up conferences and user groups that span the separate environments you have created.
For more information
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||