Rutgers, The State University of New Jersey
OFFICE OF INFORMATION TECHNOLOGY | RULINK HOME

For Departmental Administrators

WARNING: This page has not been checked after the software upgrade on January 13, 2006. Portions of it are likely slightly out of date.

NOTE: These instructions refer to web pages. Unless otherwise specified they are part of the "Mail/Calendar Configuration Tool", available at rulink.rutgers.edu.

This document begins with a review of the major functions of the system, from the point of view of a departmental administrator. At the end are checklists for a couple of common tasks.

To request a domain, please contact rulink_support@email.rutgers.edu.

Domains in this system represent departments or other collections of people supported by a single set of system administrators.

Mail Domains

For the mail system, a domain represents a completely separate set of email addresses. E.g. smith@rucsnb.rutgers.edu is a completely separate address from smith@rutgers.edu, and may be a different person. Mail addresses in a domain are created by a departmental administrator for that domain.

In the mail system, domains can contain the following five types of entity:

In addition to sections on each type of entry, there will be a section description setup options that the departmental administrator can choose. These are permanent setting that affect the way the the departmental directory works.

Rutgers NetID

The most common entity in the mail system is a user who has a valid Rutgers NetID. A departmental administrator can add any valid Rutgers user to their domain. You do this in the "Manage Users" page, using Give Users Mail Addresses in the Domain. By default, their mail address will be netid@domain.rutgers.edu. E.g. if you add a user whose netid is smith to the domain rucsnb.rutgers.edu, by default that person will end up with an email address of smith@rucsnb.rutgers.edu.

It is possible for the administrator to specify a different mail address. We have lots of cases where a new faculty member wants the name smith, but ends up with rms297, because all NetID's with smith in them have been taken. Thus it is possible to add the NetID rms297, but specify that their email address in your domain should be smith. It is possible to add the same NetID more than one time, thus giving them several different mail addresses in your domain. In general I'd recommend adding them first with their NetID, and then adding any additional names that they may want.

Note that all of these mail addresses are associated with the same mailbox. So if you add the NetID rms297 in your domain as smith@rucsnb.rutgers.edu, they have one mailbox, with two different addresses:

To read mail, they will login with their NetID and password. But they'll see mail that was sent to them with both addresses.

When someone sends mail, the address that the mail comes from is set as follows:

If you have chosen the option "Add/Remove addr book entries when we add our email address to other users", when you give a user an email address in your domain, the system will also add an addressbook entry for them. That way they will show up within your departmental addressbook. That addressbook entry starts with information taken from the University directory. However you can edit the information with the "edit" function, in case you want to add additional information for the person that will be visible to people using your departmental addressbook.

Shared Mailbox

Administrators can create a "shared mailbox". This looks almost exactly like a user, except that it doesn't have its own password. Use this where you want mail to go to a common location, and be picked up by one or more other people. E.g. a department might have an address for email from prospective grad students. One way to do this is to set up a mail alias that forwards from that address to the chair of the graduate admissions committee. But chairs may not want this mail mixed in with their regular email. There may also be several people who look at the mail. So you can create a separate mailbox for it.

To create a shared mailbox, use "Create shared mailbox in this domain" in the "Manage Users" page.

Now we have an obvious question: how do people read this mailbox? Most IMAP mail readers let you subscribe to mailboxes other than your own. Once you've done this, you'll see a list of all the mailboxes available to you somewhere, often in a region at the left of the window. Just click on the shared mailbox to open it.

In order to subscribe to a mailbox, you need to know its name. Normally, names refer to your own folders. E.g. if you tell a mail reader to open "INBOX", you get your own inbox. To open someone else's mailbox, you need to specify a bit more. For example, if you have a shared mailbox called gradadmissions@rucsnb.rutgers.edu, you would subscribe to "Shared Folders/User/gradadmissions@rucsnb.rutgers.edu/INBOX". "Shared Folders/User" points you to a list of other users, rather than your own mailboxes. The reason it's "gradadmissions@rucsnb.rutgers.edu/INBOX" rather than just "gradadmissions@rucsnb.rutgers.edu" is that each shared mailbox is like a user. It has not just an INBOX (which is the primary mailbox), but you can create a whole set of folders, in case you want to save mail in different folders, which you share with your colleagues.

In order for this to work, the administrator has to define who can read the shared mailbox. In the "Manage Users" screen, you'll see a list of all mailboxes in your domain. Next to them there is a link "Mail ACL". This lets you edit the "access control list", which specifies who can do what to the mail box. You should add all the users that need to be able to open the shared mailbox. For each one, specify a set of rights that lets them either just see mail, or see it and delete it.

Mailing List or Alias

There is a separate "Manage Lists" screen for creating and maintaining mailing lists and aliases in your domain. There's really no difference between a mailing list and an alias. Both simply forward mail. We normally call it a mailing list if mail is forwarded to more than one person, and an alias if mail is forwarded to just one other address.

We recommend using Listserv or RAMS for large mailing lists. However those create addresses at email.rutgers.edu or rams.rutgers.edu. In some cases you may want to create an alias or a list whose address is in your domain. This "Manage Lists" page lets you do that.

Note that lists can have two different kinds of members:

You should use internal members where possible. An internal member points to the database entry for a person. It uses whatever their current email address is. If the person changes their email address, their entry will still work (assuming that they keep their information up to date in the People Database).

Internal members will also have other functions later in 2003. For example, if you keep a list of your faculty members, you will be able to use this list

(The last 2 features depend upon the next release of the software, which is why they aren't available now.) These features will not be available for external members of a list, because we have no way to verify who they are.

Use an external member for someone who doesn't have a Rutgers NetID or some other entry in our database. An external member is simply an email address.

In addition to members of the list, you can define

The departmental administrator can always manage the list. By adding additional owners, you can delegate control of the list to someone else, who isn't an administrator. E.g. you could have clerical or administrative staff in your department manage the list of faculty.

The "file directory" feature is currently experimental. It lets you create a directory where members of the list can put documents for other members to look at. The list is accessed via the web (both for adding documents to it and looking at them). If you create a file directory, all members of the group will see that directory on the main page of the "Mail/Calendar Configuration Tool."

New users

It is possible to create a real user in your domain. Use this if you need to create a personal mailbox or calendar for someone who doesn't have a NetID. If you have guests in your department, it is normallly best to go through the OIT guest process to create a NetID for them. However there may be times when this doesn't make sense, or when you need something that looks like a user but isn't an actual person.

I should note that there's a possible policy issue here. If you use this facility to create an account for a person, you'll need to make sure that the person has enough affiliation with Rutgers that it is legitimate to use Rutgers resources. We understand that departments have a variety of arrangements with collaborators at other institutions and research groups. It's often useful to give them accounts on Rutgers systems to facilitate shared work. We also understand that there are various special programs that are associated with Rutgers departments, which departments authorize to use departmental resources. However non-Rutgers users of this system should be be using it for something connected with Rutgers. We aren't in the business of providing email and calendaring service for a whole organization just because some of its people are involved in a Rutgers-related activity (though those who are can use our facilities to support the Rutgers-related activity), Nor should this system be used to host services for friends or relatives with no connection with Rutgers.

To create a user in our domain, use "Create new user in this domain" on the "Manage Users" page. Note that you'll need to assign a password for this user, so they can login. They will login using user@domain and that password. This will work both with web mail and IMAP or POP. They must use the full domain name with rutgers.edu. E.g. if you create a user "smith" in the domain "rucsnb.rutgers.edu", they will need to type "smith@rucsnb.rutgers.edu" when they login. Only these users need to type their domain name when they login. Normal users, who have NetID's, login using their NetID alone, even if their primary mail address is in your domain.

There is no need to create addressbook entries for people of this kind. Because their primary directory entry is in your domain, it will automatically be picked up as part of the addressbook. You can specify the same information for these entries as for separate addressbook entries.

About using RULink as a departmental addressbook

It is possible to use RULink as a departmental addressbook. This will work from any mail program that understands LDAP directories. Most modern mail programs do. When configuring your mail program, it will typically want the following information:

The search base uses the domain name assigned to your department in RULink. E.g. my area uses rucsnb.rutgers.edu. So we would use a search base of "o=rucsnb.rutgers.edu,o=rulink-top". If you use a search base of "o=rulink-top" you will see all departmental addressbooks that have permitted you access.

Note that one of the options the departmental administrator can set is who is able to see their addressbook. If they set "anonymous access" then the information above is all you need. If they set an option that requires authentication, then you will need to make the following settings:

Setting up SSL is sufficiently arcane that you may prefer to make your addressbook visible without authentication. However make sure that none of your users have privacy issues with making their data available. If they do, you can edit the addressbook entry for that user to omit the data that they consider a problem.

Addessbook entries

If you are using RULink as a departmental addressbook, you may want to make additional addressbook entries. You will automatically get entries for users in your domain, and if you set the option "Add/Remove addr book entries when we add our email address to other users", you will get entries for users to whom you give email addresses in your domain.

But you may have people outside the University that you want to appear in your addressbook, e.g. consultants or vendors with whom you work a lot. For this reason, there is a function "Add Addresbook Entry." Adding this entry doesn't have any effect on the way the system behaves. People in addressbook entries can't send or receive mail or use calendars. They're just entries in your addressbook.

Accessing the web mail personal addressbook from Outlook

The previous section tells you how to access a departmental addressbook you manage. Your users may also want to create personal addressbooks, using the web mail application.

If they want to access that addressbook from Outlook (or other clients that support LDAP), here's how to do that.

WARNING: This only works with the old-style addressbooks, created from the old web mail application. The new addressbook in UWC uses a different format which Outlook can't access in this way.

Use tools/accounts to create a new LDAP addressbook. Here are the parameters:

Main page:

More settings, Connection

More settings, Search

Caveats:

Department Options

As mentioned above, there are 3 options that the departmental administrator can choose. These are permanent settings, which will persist until you change them.

1) Who can see entries in this directory.

Each department has its own private directory. While it's part of the overall RULink directory, normally people look only at specific portions of the directory, such as the normal Rutgers directory, or the portion for a specific department.

This option controls who is able to see the section of the directory for your department. As mentioned above, some choices make it visible to people without login. Others require them to configure their application to login.

2) Add/Remove addressbook entries when we add our email address to other users.

If you are using the system as an addressbook, normally you want to turn this on. It causes the system to create an addressbook entry for any users that you give an email address to.

3) Give all users mail filter that rejects attachments that are Microsoft executables.

All email to and from this system goes through McAfee antivirus processing. However some people are concerned that viruses may get into their system before McAfee has updated their virus definitions.

Therefore we provide a filter that will remove all Microsoft executables. It is based on the filename, since that is what most Microsoft software uses to decide what a file is. Currently, we conside a file to be a Microsoft executable if it ends with one of the following:

bat ceo chm cmd com exe js jse mdb mtx pif reg scr shs vb vbe vbs vbx wsf wsh

If you choose this option, even user in your domain, and every user with an email address in your domain, will have this filter applied to all incoming mail. Any attachments matching the names above will be removed from their email, and replaced by a message explaining what has happened.

When you change the option, it affects any new users added after the change. It does not affect existing users. You also have the option to enable or disable the filter for specific users.

Calendar Domains

For the calendar system, a domain represents a set of resource calendars. These are normally used for conference rooms, projects, or other resources that you may want to schedule.

Users calendars are not part of your domain. Everyone with a Rutgers NetID can create a personal calendar. We don't see any advantage to putting them in domains, and the software wouldn't really handle them well.

There is actually an exception to this. If you create a user using "Create new user in this domain", that person doesn't have a NetID, and thus wouldn't normally have a calendar. On the "manage users" page, next to each user you have added, you'll see "create calendar". This can be used to create a calendar for a guest user or even a shared mailbox. That will create a calendar with your domain name on the end of the name. We are concerned that this feature may create unexpected results. Please consult with hedrick@nbcs.rutgers.edu before using it. If a guest needs a calendar, please consider going through the guest process to allocate them a NetID.

Resource calendars begin with a "prefix" assigned to your domain. This is often the same as the domain name, though at times it makes sense for the prefix to be shorter.

For example, for the domain "rucsnb.rutgers.edu" we might have the prefix "rnb". All calendar names would have to begin with the prefix. Thus for room 120 in Hill Center, we might use a calendar ID of "rnb-hill-120".

The calendar ID is the name used inside the system. It's much like a username. Like usernames, it can't contain spaces, and it's typically brief.

There is a second name, called the "calendar name". This is like a person's real name. It can include spaces. It is typically more explanatory. So the calendar rnb-hill-120 might have a calendar name of "RNB Hill Center 120". Both the calendir ID and the calendar name must begin with a prefix assigned to your department. It can be in uppercase, lowercase, or a mixture.

You can have more than one prefix. E.g. you might want to use a longer prefix for the name. Thus rucsnb.rutgers.edu might have prefixes "rnb" and "rucsnb", and use rnb for calendar ID's and rucsnb for calendar names.

You create and delete calendars using the "Manage Calendars" page. Once you've created a calendar, you'll want to control who can put events on it and who can see it.

To do this, we recommend clicking on "Open Iplanet on this domain", in "Manage Calendars". This opens the regular Sun ONE calendar program, logged in as a special privileged user. This user is called "calmaster@domain", e.g. "calmaster@rucsnb.rutgers.edu". This user owns all calendars in the domain. We use a special user for this, rather than someone's NetID, so that no problems occur when staff in a department change.

From the calendar program, choose the "calendars" tab. We automatically subscribe calmaster to all calendars in the domain. So that tab will list all your calendars. You can then choose "edit" to change who can access the calendar, just as you would for a personal calendar.

There are other functions on the "manage calendars" page. These let you look at various information in internal format. These are intended primarily for debugging. You'll generally find it easier to use the Sun ONE calendar program to administer the calendars.

In addition to setting up who can access a calendar, there are three other features you may be interested in:

1. The "dir props" entry next to a calendar opens a web page that will let you specify email addresses for the calendar. These will send email when someone schedules (or attempts to schedule) an event on this calendar. You could use this if you want a single staff member to manage the schedule for a room. However in most case we recommend setting things up so that everyone who regularly uses a resource can schedule it themselves.

2. The "cal data" entry next to a calendar opens a web page that lets you do several operations on the contents of the calendar. You can save all the events and to-do's to a file in ical format, load information from such a file, and clear all entries in a calendar. You can also restore data from daily backups from the last week.

Unfortunately there is no way to rename a calendar. Thus the best approach is to save all the data into an ical file, create a new calendar, load data from the saved file into it, and then delete the original calendar.

3. The "save" entry next to a calendar lets you cut and paste the owner and access permissions. Let me explain why you might want to do this: The Sun ONE calendar program lets you set up a list of people who can read and write a calendar. But this can become a pain. Suppose you have 10 rooms, and you have a list of 20 faculty who should be able to schedule each one. Whenever a faculty member comes or goes, you would have to go to each of the 10 rooms and update the access control list.

The "save" function saves you from this. You can maintain the access list for one room. Once you get the access control list right for one room, click "save" next to that calendar. This will save the ACL and owners to a special save area. It will also change the web page so there's a box next to each calendar. Click on that box next to all the other calendars and select "copy saved permissions to all checked calendars" to copy the saved ACL and owners to all the other calendars at once.

Common Procedures

Create a new domain

This section probably doesn't belong in this document. It's documentation for OIT staff who create domains. That's the one function that isn't currently delegated to departmental staff, largely because the tools are so clunky. However you may find it useful to look at, because it will give you an idea of the information you need to give to the OIT staff. Again, to request a domain, please contact rulink_support@email.rutgers.edu.

The next section, on creating users, is appropriate for departmental administrators.

To create a new domain, we need the following information from the department:

If you already are using a domain name for your department, think very carefully about whether you want to use that domain name. If you already have a mail system that is using the domain name, you may want to choose a different one. That would allow you to experiment with mail on this system. If you choose the same domain name, you'll have problems, because you can't have two different mail systems with the same name.

For OIT staff: here's how you set up the domain:

To add a user

It's easy to add a user to the mail system: Go into Mail/Calendar configuration tool, the "Manage Users" screen, and add the NetID.

However there are some additional things you should think about:

Initially you may want to experiment with the system without making it your permanent mail system. To do that, once you have added the user to your domain, ask them to

NOTE: If you forward mail to the new system but also keep copies on the old one, this can result in filling up your disk quota on the old system. Make sure that people review mail on both systems and keep within quota.

When you want to change to the new mail system, tell your users

BACK TO TOP

For more information, contact rulink-support@rutgers.edu
© 2007 Rutgers, The State University of New Jersey. All rights reserved.

 

Search Rutgers