 Related topics
About user groups
When you install your FirstClass server, there are five sets of groups already defined in your network store:
• Standard Groups
• Configuration Groups
• Directory Filtering Groups
• Department Groups
• Conference 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 the structure of the Groups folder and how the individual user 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. The server automatically adds users to these groups as required.
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.
All Users
Everyone who logs into your system is a member of the All Users group. It is a good idea to set base system defaults at the All Users level and then give or remove permissions and privileges from that starting point. This results in a system which is much easier to track and administer. The All users group will never be listed on the Groups tab of a user’s User Information form since all users belong to this group.
Regular Users
This group is made up of all users defined as Regular in the Class field of the User Information form. By default, all regular users will have Regular Users listed first in the list of groups to which they belong on the Groups tab of the User Information form. Never delete this entry. Enter all other groups below this entry.
Remote Users
This group is made up of all users defined as Remote in the Class field of the User Information formBy default, all regular users will have Regular Users listed first in the list of groups to which they belong on the Groups tab of the User Information form. Never delete this entry. Enter all other groups below this entry.
Offline Users
This group is made up of all users using FirstClass Personal. This is a temporary group and users will only belong to this group for the time they are using the FirstClass Personal application.
Unauthenticated Users
This group is made up of users accessing your system via unauthenticated HTTP, Finger, or LDAP protocols, or users accessing your system using a web browser to visit a user’s website. This is a temporary group and users will only be a member of this group until they log into FirstClass.
Note
If this group is missing from your network store when you start your server, you will receive a warning. If this group does not exist in your Groups folder, create a new group and name it Unauthenticated Users.
Other Sites
This group is made up of gateways and users on remote servers only.
All Conferences
This group contains all conferences configured on your system. It is a good idea to set default conference permissions at the All Conferences level and then give or remove permissions for conferences and conference groups from that starting point. This results in a system which is much easier to track and administer. The All conferences group does not apply to any Mailboxes on your system.
All Calendars
This group contains all calendars configured on your system. It is a good idea to set default conference permissions at the All Calendars level and then give or remove permissions for conferences and conference groups from that starting point. This results in a system which is much easier to track and administer.
All Mailboxes
This group contains all user Mailboxes configured on your system. It is a good idea to set default Mailbox permissions at the All Mailboxes level and then give or remove permissions for Mailboxes from that starting point. This results in a system which is much easier to track and administer.
Note
All folders on user’s Desktops inherit the user’s Mailbox permissions. If the user has no personal Mailbox permissions defined then the folder’s contents will inherit the expiry period set at Conference item expiry in the System Profile.
Legacy systems’ groups
Several more standard user groups were installed by default in FirstClass systems prior to FirstClass 7. If you want to recreate these standard groups, simply create a group and give it the name of the legacy standard group. The group will function the same way it did prior to FirstClass 7.
Override groups
Some standard user groups are specified as override groups. These are temporary groups to which users are assigned based on access method.
The override groups are:
• Unauthenticated Users
• Autoregistered Users
• Offline Users.
The Autoregistered Users group can have a Model Desktop, Offline Users and Unauthenticated Users cannot.
The values set on the Group Privileges form for those 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:
• Sub Admin
• High Disk Usage
• Help Desk
• Webmasters
• Suspended
• Time zone groups
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 the users’ overall place 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.
Directory Filtering Groups
You can delete or change the names of any group in this area, but we suggest you don’t. These groups have been created to help you build a secure environment, protected from outside users trying to access your Directory from the Internet.
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 up to 300 groups (unlimited for MP sites) in the Groups folder.
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.
 CautionDo not assign OUs to Standard groups.
FCDS
If you plan to use FirstClass Directory Services (FCDS), 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.
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. If these were all defined as OUs in the company, the most user-specific 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.
Note
A 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.
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
When you list the Directory, the user’s Primary OU is displayed in the Organization column. A user viewing the Directory, or Who’s Online, can easily determine what department another user is in.
 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.
The user's objects inherit the OU of his Primary OU. If you have given your users permission to create conferences or calendars, any conference or calendar a user creates will inherit the user’s Primary organizational unit.
Organizational units and duplicate Directory entries
As stated earlier, 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 are in different OUs. For instance, if you have a Lisa J. Smith in Management, you can also have a Lisa J. Smith in Finance. 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 promoted from Finance to Management, you will have to change her name in the Directory (Lisa Julie Smith, for instance).
Note
You 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 multitenant 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.
Notes
If 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.
Note
You 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.
Notes
Preceed all user, conference, and calendar groups, as well as all conferences and calendars with MT to distinguish them as being solely for Malamute Transport.
The MT Users organizational unit level should be set to Company (like HP Users).
All other MT groups should have logical organizational unit levels set.
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.
Notes
If 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.
Note
You 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 .
Notes
Preceed 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.
All other D groups should have logical organizational unit levels set.
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.
|