Table of Contents

Policy Summary

When a group is created, its expiry date is set for one year from the date of creation. If the group is still needed at that point, the group owner must renew it.

Groups that are not renewed before the expiry date will expire. An expired group is "disabled," which means that the group no longer works. An expired group remains in the directory in a disabled state for one year. During that time, the group owner(s) can renew it. Expired groups will be deleted from the directory one year after they expire, unless they are renewed.

Table of Contents

Group Expiration Steps

1. When a group is created, its expiry date will be set for one year from the date of creation.

   Group owners can renew the group at any time. See the Renewing Groups section of Managing Groups that You Own in the U-M Online Directory (S4277) for renewal instructions.

   The person creating the group—the group owner—is notified during the group creation process that the group must be renewed yearly.

2. Ninety days before a group is to expire, an e-mail renewal notice is sent to the owner(s) through e-mail. Group owners must have a valid mail forwarding address in their directory entry in order to receive renewal notices. A group owner can then choose any of these options:
   • Renew the group (see renewal instructions in group ownership documentation).
   • Let the group expire.
   • Delete the group if it is no longer needed (see deletion instructions in group ownership documentation).

   The text of the 90-day notice is provided at the end of this document (Appendix: Text of the 90-Day and 30-Day Renewal Reminder Notices).

3. Thirty days before a group is to expire, a final renewal reminder notice will be sent to the owner(s) through e-mail. Group owners must have a valid mail forwarding address in their directory entry in order to receive renewal notices.
4. On the expiry date, the group will be disabled. Disabled groups no longer work. Mail sent to a disabled group will be returned to the sender. If a disabled group is used to control authorization (such as for access to a web site or wiki), that authorization will fail. If you search the directory for the group, however, you will find it. The group entry will indicate that the group is disabled.

   The text of the 30-day notice is provided in Appendix: Text of the 90-Day and 30-Day Renewal Reminder Notices.

5. The group will remain in the directory in a disabled state for one year. The owner(s) can renew it during this time. After one year, if it is not renewed, it will be deleted from the directory. Once it is deleted, it cannot be retrieved or renewed.

ABOUT ABANDONED GROUPS: If a group owner is no longer maintaining a group that is still needed by its members, the members of that group can ask that one or more of them be designated as the new owner of that group so that it can be renewed and maintained. Group members who wish to become owners of otherwise abandoned groups can contact Directory Administration (dir.admin@umich.edu).

Table of Contents

Frequently Asked Questions (FAQ)

1. Why can't we just leave groups in the directory forever?
   There are several reasons why we want to remove obsolete groups from the directory:
   • Spam. Many people are annoyed at the amount of spam they receive as members of obsolete groups. By setting expiry dates, we provide group owners with reminders to check their groups and renew those that are still needed. We provide a mechanism whereby forgotten, unwanted groups can be removed.

     ITS staff who provide support to users (4-HELP, the Accounts Office, Postmaster, User Advocate, Directory Administration) report that the spam sent to obsolete groups is a significant problem for the U-M community. Users are unhappy with unmaintained groups.

     U-M is periodically blacklisted by major Internet Service Providers (ISPs) because of the quantity of spam going to members of obsolete groups. When this happens, the ISP stops accepting mail from @umich.edu addresses that is sent to its members.

   • The U-M Online Directory will be replaced by MCommunity, which is currently under development. Those who have participated in major data conversion efforts report that moving existing data from an old system to a new one is often the most time-consuming task in implementing the new system. We would like to remove obsolete group data from the directory rather than transferring it to the new system.
   • To free up group names that people want to use. A number of obsolete groups use names that members of the University community would like to use for new groups.
2. Why can't you let people designate certain groups to never expire?
   This is not feasible yet given the current data in, and structure of, the U-M Online Directory. MCommunity will replace the current directory at some point in the future. The new system will allow for different kinds of groups that behave differently from one another. Once we have the ability to provide this feature, we will do so.
3. What happens when a group expires?
   When a group expires, it is disabled. It ceases to function in all ways except one—if you search the directory for it by name, you will find it. The entry will indicate that the group is disabled.

   Mail sent to a disabled group is returned to the sender as undeliverable. If the group is being used for authorization (such as for access to web sites or account provisioning), the authorization will fail.

   The group owner(s) can renew a disabled group. If a group has been abandoned by the owner but is still needed, the group members can contact Directory Administration (dir.admin@umich.edu) and ask to have ownership of the group transferred to them. Then they can renew it.

   A disabled group remains in the directory for one year. If it is not renewed during that year, it is deleted from the directory.

4. Will I be notified before my group expires?
   Yes. The group owner(s) will be notified through e-mail twice when the group gets near the expiry date:
   • e-mail reminder notification 90 days before expiry
   • final e-mail reminder notification 30 days before expiry

   The notifications are sent to the e-mail forwarding address(es) listed in the group owner's directory entry. The text of the notices is provided in Appendix: Text of the 90-Day and 30-Day Renewal Reminder Notices.

   During the group creation process, a notice that the new group will need to be renewed in one year or it will expire is displayed on the group creation confirmation page.

5. If the owners are unreachable, could you notify the members instead?
   It is the responsibility of group owners to manage their groups and to provide a valid mail forwarding address. If a group owner neglects this responsibility and becomes unreachable, a group member can contact Directory Administration (diradmin@umich.edu) and ask to take on ownership of the group.
6. Can you set groups not to expire until one year after their last use?
   No. Unfortunately, this is not possible for two reasons.
   1. Information about when e-mail is sent to a group (basically a look-up of the members' mail forwarding addresses at the time of mail delivery) is not logged. There is no way to know when mail was last sent to a directory group.
   2. Even if this information were logged, there would be no way to know whether the message last sent to the group was spam or legitimate mail.
7. If changes are made to a group, could the group be automatically renewed for another year?
   Given the way the current directory works (that is, given the version of Open LDAP we are using), automatic renewals would be inconsistent. The process that evaluates groups for renewal and expiry runs once a day. When a change is made to a group, the change is made, and the entity that made the change, as well as a timestamp, is recorded. If another change is made before the batch process runs, the change is made, and the information about the entity that made the change and the time the change was made is overwritten with the new information. Therefore, the batch process only knows who made the last change and at what time.

   Consider these examples of the inconsistent results that would occur:

   • Various programs make changes to groups that would, but should not, trigger renewal. These include such changes as a uniqname change for a member and removal of a member from the directory.
   • A large group of students (most of whom are now alumni) has become obsolete. Periodically, spam is sent to the group. In annoyance, a group member contacts Directory Administration and asks to be removed from the group. This removal would show up as a change to the group, and the group would then be renewed automatically—even though the group is obsolete.
   • Some have suggested that automatic renewals only happen if an owner makes a change, but it is not always possible to determine that a change was made by an owner. For example, if an owner makes a change to a group, and, later in the day before the batch process is run, the uniqname program makes a change to a member entry in that group because that person has changed his or her uniqname, the batch process will only see information about the most recent entity (the uniqname program) that made a change. The batch process would not "know" that the owner had made a change.
   • A person owns two groups, one joinable and one not. A member joins the joinable group; the group is changed and is therefore renewed automatically. The owner will likely wonder why the expiry date changes on one group but not the other.

8. Did you consider the needs of U-M schools, colleges, and departments in setting this policy? Did you get their input?
   Yes. The initial idea for the policy was a response to many requests from the members of the U-M community to do something about the spam being sent to obsolete groups.

   In the summer of 2006, when the policy was little more than an idea, ITS staff went to the Academic Computing Support Forum (ACSF) and to the MCommunity Governance Board to get their general approval and input before proceeding. Both these groups are made up of representatives from across the University. ACSF members are mostly information technology staff. They meet regularly to share information about University information technology. The Governance Board includes representatives from schools and colleges as well as business units such as the Registrar's Offices of all three campuses (Flint, Dearborn, and Ann Arbor) and HRAA. It is charged with interpreting and communicating policies and guidelines for a new Enterprise Directory that is expected to replace the current U-M Online Directory in 2008.

   A draft policy was presented to both groups in fall 2006. Considerable discussion ensued regarding some of the policy details, such as whether expired groups could be deleted from the directory. Rather than have ITS staff make the final decisions on the policy details, ITCS referred these decisions to the MCommunity Governance Board. The board reached agreement on the policy details in January 2007, and the policy was implemented in February.

Table of Contents

Additional Resources

Managing Groups that You Own in the U-M Online Directory (S4277)

Managing Your Membership in U-M Online Directory Groups (S4345)

We welcome your comments; please send e-mail.

ITS's Online Help Desk provides a variety of computing help resources.

For further help with directory groups, send e-mail or phone (734) 764-HELP.

Table of Contents

Appendix: Text of the 90-Day and 30-Day Renewal Reminder Notices

90-Day Renewal Reminder

You own one or more groups in the U-M Online Directory <http://directory.umich.edu> that will expire in 90 days. If not renewed, the group(s) listed below will expire on <expiry date will appear here>.

Instructions for renewing groups, as well as more information about group expiry, can be found in 'Managing Groups that You Own in the U-M Online Directory' (S4277) at:
<http://www.itcs.umich.edu/itcsdocs/s4277>

If you have questions or need help with this, please contact the ITS consultants at 764-HELP, Option 1, or online.consulting@umich.edu.

- U-M Online Directory Administration

List of group(s) expiring -

Groupname 1
Groupname 2 (and so on)

30-Day Renewal Reminder

You own one or more groups in the U-M Online Directory <http://directory.umich.edu> that will expire in 30 days. If not renewed, the group(s) listed below will expire on <expiry date will appear here>.

Instructions for renewing groups, as well as more information about group expiry, can be found in 'Managing Groups that You Own in the U-M Online Directory' (S4277) at:
<http://www.itcs.umich.edu/itcsdocs/s4277>

If you have questions or need help with this, please contact the ITS consultants at 764-HELP, Option 1, or online.consulting@umich.edu.

- U-M Online Directory Administration

List of group(s) expiring -

Groupname 1
Groupname 2 (and so on)

Table of Contents

Information and Technology Services