Integrating Google Apps: Provisioning and Management of Email

Preamble

The Open Campus uses Google Apps to provide email service for all students. There are over 4500 active email accounts. For the month of November 2008, an average of 1200 accounts are accessed per day.

History: The DEC MIS Implementation

The DEC course delivery model shifted to more online interaction and the need to provide an email solution for students grew. The Google Apps for Hosted Domains was one of the solutions considered. It is free for educational institutions and at the time offered 2GB mailboxes. The hardware and software of service would be handled by Google. The DEC had to handle the user management.

Creating Accounts

In the testing phase accounts were created individually using the Google Apps admin web interface. The admin interface also provided a bulk account creation tool. Account information would be uploaded in a csv file and the user accounts would be created. Any issues with the data caused the account creation to stop. The successfully created account removed from the file, the error was corrected and the file was re-uploaded.

The required information was extracted from the MIS database and saved as an spreadsheet. This was then broken up into csv files to make the error management easier.

This was a tedious task that required fortitude and patience. Clearly a better way was required.

First Steps in Provisioning

Sada Systems released an open source bulk provisioning toolkit. We first tested it with the Excel file generated for our original method. The toolkit used python to create accounts at a rate of almost 10 per second. It was amazingly fast. The actual magic was in the error detection before it connected to google. The toolkit highlighted all errors allowing correction to be made and account creation to be a much nicer affair.

Eventually we dropped the need for the spreadsheet and connected the toolkit to the MIS, using a mySQL view to provide the data. All errors would then be corrected at the source and thus the potential for data disparity issues removed.

Creating many accounts now required a single click in most instances. Individual accounts was still done manually using the admin interface. All management tasks, including password resets, checking if accounts were created and active, etc were also done in the admin interface.

Current: The Open Campus OCMS Implementation

Bulk Account Creation

We still required the provisioning toolkit to do the original bulk account creation as the gdata zend library could never match it in terms of speed. The OCMS was connected much like the MIS to the toolkit and one click later 8000 accounts were created.

The No Click Way

In the OCMS we aimed for a (almost) zero management solution leveraging the Zend Framework and Google provisioning API. The one click method was still one click too much. And so the student email model was written.

When a student logs in for the first time the student email model goes to work. It looks in the database and generates an email address for the student based on the first and last name. It also checks for and avoids duplicates. The account is then provisioned and the student advised that they should activate the new account. When the account is activated the email model notes the activation.

Individual accounts are now handled by the OCMS. All new students will get email accounts in this way. Separate password resets are also a thing of the past as the students access their email using SSO from the OCMS.

The experience of doing things the hard way helped to mold effective design choices that integrated the provisioning into the OCMS.

One Comment