Table of Contents

Policy Summary

When a group is created, its expiry date will be 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—will be 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 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. 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 in 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

Transitioning Groups Created Before this Policy was Implemented

Rather than have all 180,000 existing groups expire on February 19, 2008, the expiry dates were staggered over a period of 18 weeks. Some pre-existing groups, for example, had initial expiry dates set to be as long as one year plus 18 weeks from February 19, 2007.

E-mail notices were sent to all group owners informing them about the new expiry policy and letting them know that within the next year they would need to renew any groups they wanted to keep.

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.

     ITCS 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 ISPs because of the quantity of spam going to members of obsolete groups.

   • The U-M Online Directory will be replaced by MCommunity in 2008. Those who have participated in major data conversion efforts report that moving existing data from the old to the new system is often the most time-consuming task in implementing a new system. If at all possible, 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. Work has begun on a new directory, identity management, and provisioning system called MCommunity that will replace the current directory. 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 will cease 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 the group will be 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 will remain in the directory for one year. If it is not renewed during that year, it will be 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.

   It is not practical for ITCS to notify all group members about expiry when group owners neglect their ownership responsibilities for several reasons:

   • Many groups have a large number of members, internal and external to the University, as well as groups as members. In many cases, the number of e-mail messages these notifications would generate would be perceived as spam by the recipients—and we run the risk of getting the University blacklisted as a mail sender by major ISPs.

     We also run the risk of overwhelming 4-HELP, and thus frustrating users who must wait to get help, if we send out too many notification messages in one day. Based on past user notifications, we have learned that we should not send more than 3,000 notices per day. Even if there are no questions about the content of a notification (and there are always questions), many people will call 4-HELP for reassurance that the message is legitimate. Even if we were to send notices only to the members of groups whose owners have no mail forwarding address listed, that would mean sending out about 600,000 messages. This is unworkable.

   • We cannot identify all the group owners who are unreachable.
     • These can be identified: We know there are about 1,000 groups whose owners no longer have directory entries. There are also about 17,800 groups whose owners have no mail forwarding address listed in the directory at all.
     • These cannot: We will not know which group owner addresses are valid or not unless we send messages to them and see which ones bounce.

   The MCommunity Governance Board agreed at its January 25, 2007, meeting that we should not contact group members through e-mail. Instead, we will rely on general communication to the U-M community.

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. Spam. 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?
   We considered this, but the Academic Computing Support Forum (ACSF) decided against it—for now—after a discussion at one of their Fall Term 2006 meetings.

   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 we are trying to avoid:

   • 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.

   For now, it would be simplest and easiest for group owners to have renewal be an explicit, consistent procedure across all groups. MCommunity will use technology that will track complete information about each change as it occurs. When MCommunity is implemented, we can revisit this issue and consider automatic renewals for certain types of changes.

8. Could you archive disabled groups instead of deleting them, just in case?
   We are concerned about archiving group information outside the directory for several reasons:
   • Data would not be maintained. As individual entries change, these changes would not be made to the archive. Over time, the data in the archive would become obsolete.
   • Data conversion issues. In 2008, the way directory data is stored will change. Data archived in the old LDAP format will not work in the new format to be used for MCommunity.
   • Manual retrievals. Retrieval would have to be done by someone with administrative access to to the archive on a case-by-case basis. The data retrieved would likely be in the form of a list that the user could then use to re-create the group manually; in other words, it would not be possible to re-enable groups from the archive.

   If a just-in-case copy of expired groups is needed, it is best to provide that by leaving the expired—and therefore disabled—groups in the directory for some reasonable period of time. During this time, the group owner(s), as well as ITCS user support staff, can re-enable the groups if need be. At its January 25, 2007, meeting, the MCommunity Governance Board settled on one year as a reasonable length of time to keep a disabled group available for renewal.

9. 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, ITCS 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 ITCS staff make the final decisions on the policy details, ITCS referred these decisions to the EDS 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.

ITCS'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 ITCS 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 ITCS 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 Technology Central Services at the University of Michigan

ITCS Home  |  University of Michigan