San Jose State University : Site Name


Thursday, October 28, 2010

By: Bill Nance

This message is a comprehensive update regarding the university’s on-going migration to a single-platform email system using Google’s Gmail. I have shared much of the information in this message with many of you through various distribution channels, including forums, committees, and individual emails and conversations over the past couple of months. However, I have waited until now to send this broadcast message in order to have a fuller understanding of the many issues that have arisen, answers to questions that arise most frequently, and clearer updates as to the status and deadlines for the campus migration.

To date, campus techs have migrated nearly 2,500 users to their Gmail accounts – including users from essentially every college or department across campus, and from every legacy email platform in operation. On behalf of the university and the University Technology Services (UTS) Gmail team, I want to personally thank the technical support staff for their continuing efforts in this area. I held an open forum about the Gmail migration with the campus techs very early on following my appointment as Interim CIO, because a successful campus migration depends significantly on their personal involvement and commitment to this massive effort. “Thank you” doesn’t begin to express our appreciation for their contributions, but it’s certainly deserved.


Our migration timeframe and goals for the next few months have been clarified in the past month and were recently reaffirmed by the President’s Cabinet. As noted with the techs in August, the strong encouragement and expectation is to have most user accounts migrated by the end of the Fall 2010 semester. Realistically, the goal is to complete at least 4,000 – and hopefully closer to 5,000 – by the end of December, out of roughly 6,500 total accounts. A number of faculty and staff have indicated that it would be problematic to migrate their email during the semester, especially towards the end of the semester, so it is reasonable to defer those migrations until after Finals Week or, more likely, into January. The downside in these instances is that the migration will need to occur during the Winter Break, perhaps in the faculty member’s absence. There is no easy solution to that dilemma, but at least there is flexibility if needed.


Specific deadlines for migrating accounts have been somewhat fluid over the past few months as the migration has ramped up, techs and users have been trained, and questions and issues have been sorted out. Deadlines have now been clarified for the particular systems from which user accounts are migrated. The general target for all migrations is the end of January 2011, with some systems able to extend slightly into the Spring 2011 semester. All migrations are to be completed by March 31, 2011.

  • Users who are migrating from the university’s central Lotus Notes system have a firm deadline of January 31, 2011 due to server licensing constraints. We simply must be off of the Notes servers promptly. Users who are migrating from the university’s UNIX system (i.e., “”) have a January 31 target, but may extend until February 28, 2011 if necessary.
  • Users who are migrating from other local email servers such as college or departmental systems should similarly be targeting the January 31 timeline. If they need to roll over into the early Spring semester for reasons such as migrating new hires or returning faculty, February 28, 2011 can be considered the official deadline. Meeting this February 28 deadline for distributed systems provides the university and the campus techs the month of March to do final exception migrations and various clean-up activities prior to the overall project deadline of March 31, 2011.

While the above deadlines focus on various email systems, we recognize and encourage the practice of migrating accounts by departments or user groups rather than by particular types of other email systems. Automated tools are available that can help your group’s tech support person expedite the migration of user groups.


Not surprisingly, many issues and questions about the university’s Gmail migration have arisen over the past year or so, ranging from philosophical to operational to highly technical. UTS staff have developed volumes of documentation for this process, much of it targeted originally at supporting the campus techs for the technical migration process and at early adopter users who have been willing to share their experiences and feedback to pave the way for the majority of the campus. Based on this feedback and shared learning on the part of all involved, UTS has developed several user-support websites such as “Getting Started” and “Frequently Asked Questions” (FAQs) for Gmail and other Google Apps. They can be found at the following links:

But in addition to simply directing everyone to the website to read the materials, I also wanted to address here a few of the most common and, to many, most significant questions that have been asked of me personally and of others in UTS more generally.

Legacy Addresses

The question that has come up most often, by far, is “After I convert to the email address, will I still be able to receive messages that are sent to my previous email address?” The answer is YES, absolutely. A system that handles legacy addresses for the next two years is already in operation. In addition, the university is nearing completion of a follow-on system that will provide an enduring solution for legacy addresses that will allow users to maintain up to two other inbound email addresses essentially for perpetuity as long as they remain authorized users in the university’s Gmail account system.

Auto-Forwarding to External Email System

Much discussion has occurred regarding the practice of enabling or disabling an “auto-forward” mechanism in the university’s Gmail implementation. While auto-forwarding is available technically within Gmail, the university’s position is that it is not going to be enabled due to a combination of legal and university identity rationales. Without going into legal complexities, the essential point is that when messages are auto-forwarded to external (i.e., non-SJSU) personal or business email accounts, the university’s confirmation that an item can be considered an official university message is compromised. Auto-forwarding represents a fundamental difference from a user who accesses their SJSU account and hits the “Forward” button to send the message to that same external account, because the latter approach can be confirmed that the intended recipient did indeed access the message. Furthermore, it retains the original message in the user’s university account. Closely related, the SJSU identity is retained in the message addressing trail, regardless of where or how often it is forwarded and/or replied to.

Department Accounts Using Groups

A third common question involves the creation of Gmail accounts for organizational units such as colleges or departments using the Gmail “Groups” feature. The way the Gmail system implementation at SJSU works for user logins (aka “authentication”) maps specific Gmail accounts to individual users through their TowerID. Since departments are not individuals and therefore do not have TowerIDs, the only practical solution to create department mailboxes is through the use of Google Groups. Though some operational/technical differences do exist in the use of groups compared to a true mailbox, for the most part the user experience does not have to be significantly different. One characteristic that many users find useful is that the group setup allows the department mail to be routed to their individual mailbox, alleviating the need to monitor multiple inboxes.

The groups feature in general is designed for “true” groups such as clubs or organizations who wish to establish tools for communicating with their membership. That feature is available in SJSU’s Gmail system in a self-service mode, where group accounts can be created and have a “-groups” suffix appended to the requested group name. Department accounts for official organizational units, however, can be created without the use of the “-groups” suffix. To be established, these accounts require manual support by UTS staff and require a degree of review relative to campus naming guidelines and user authorization before approval and creation. But to be clear, the university policy does enable the creation of department groups, without the “-group” suffix, for organizational units that are formally part of the university’s organizational structure.


On behalf of UTS and the university, I want to thank all of you for your understanding and contributions to this extraordinary migration effort. It is long and arduous, but long overdue as well. Please visit the UTS blog site where this message and subsequent updates will be posted about Gmail, calendaring, Google Apps, and other related topics as we move forward. The blog can be found at:

To all who made it this far, thank you for your time.

Friday, October 22, 2010

It’s the end of another week, and time for a Google Apps project update. We’re going to start with a few reminders and then move on to some task completions:
  • Quick URLs for Google Apps
  • Google Groups Reminder
  • Google Calendar Resources Update
  • New project: Legacy Address Support enhancement

Monday, October 18, 2010

It may not seem like a big deal, but we've re-done the Google Apps planning board over in UTS. This should help us stay on top of the strategic goals we're working on and the operational, development and content-generation tasks we need to do to meet them.

Migration is the biggest task, but the board has several communications-related goals that we're close to completion on:
We hope that these efforts will make it easy for you to learn more about Google Apps features and take better advantage of Google Apps services as the university's migration progresses.