Google Apps Premier Edition Pilot Success Guide

 

Many of our Google Apps for Enterprise customers have asked us to help them define a plan for piloting Google Apps within their business.  This document represents our experience of best practices for running such a pilot. 

 

Contents:



Piloting Planning and Steps

This section summarizes what a successful Google Apps pilot life-cycle may look like.  We strongly suggest an IT professional assist your organization with your pilot and in some cases it may be beneficial to engage with your Google representative to directly help you or engage you with an appropriate Google partner.


In many instances, it may be useful to do a pilot as a small representation of your eventual deployment.  The following labels may help you identify and understand various likely successful pilot scenarios:


Pilots can be measured in many ways,  we'd like to propose a business and technical success description found below:
Business: We suggest that you first identify what the ultimate purpose of the pilot is; what "pain(s)" is the eventual deployment roll-out solving?  This then will better define a overall success measurement (we will expand more on this as we move along).
Technical: We also suggest you specify an architectural pilot outcome (probably guided by the ultimate vision).  Possible examples may include a Dual Delivery model of email, a Full Replacement/Migration and/or addressing the under-served knowledge workers.  Much of our documentation on a full email replacement can be found on our website once in the administrative console for Google Apps.  This document will focus on a dual delivery email model.

Identifying a Pilot Group with purpose will help you have a more productive pilot:


Tips around User Adoption:


Milestones:


Thinking long term:


Results:


We'd like to offer these percentage milestones as a guideline.  We recommend regular updates/meetings during this process:

* Tip: Tyinf the above percent milestones with a time-line will help keep you on track!

Piloting Setup Guidelines for Administrators

Choosing an appropriate pilot user set is crucial to its success.  After identifying both the Administrative and User groups we can begin setting up the domain. 

 

For piloting, we suggest a Dual-Delivery model.  Dual-delivery allows mail to be delivered to both the current email infrastructure as well as Gmail.  This will allow your organization to test out the Google Apps solution without having to interrupt current systems; making it a near risk-free pilot.  Mail can be split and dual-delivered at the gateway; we have found that using the current email system as the gateway will make this easier.  This can be accomplished by having the mail server forward a copy of the mail to Gmail.  We have included instructions on how to do this below in a Microsoft Exchange environment, which has been the most common scenario thus far.

Phase 1: Domain Setup and Admin Team Test

The first phase consists of setting up Google Apps to run in parallel with your existing systems.  Dual-delivery mode delivers a copy of a user's email to Google so users can experience the product on their own time without having to switch from their current setup.  This approach also allows for an easy side-by-side comparison of the two systems.

This phase can be completed in as few as two days and allows a very small team of admin and "friend-of-admin" users to verify configuration and basic features and functionality of the product.  Again, these steps will not result in any interruption of existing email service.

Who's involved:



Getting started:


  1. The first step is to register the domain and have it verified by Google.  We do this to make sure all requests are valid.  You can go through this process by going to http://www.google.com/a and register your domain (e.g. customer.com -- you will substitute your domain name) with Google. This process can sometimes be expedited by letting your Google representative know that you've done this and what domain name you've registered.

  2. You'll next have setup a way for mail to be delivered to Google.  You can do this by setting up the mail records (aka: 'MX Records') for the "shadow" domain to point to Google (example: galias.customer.com).  Even though you are using galias.customer.com, the sender and receiver will still be recognized by the email address: user@customer.com.  Here are the settings that you want to input into the domain registrant Administrator console:


HOST 

Record Type

Priority Server

galias

IN  MX   

1  aspmx.l.google.com.

galias

IN  MX   

5 alt1.aspmx.l.google.com.

galias

IN  MX   

5 alt2.aspmx.l.google.com.

galias

IN  MX   

10 aspmx2.googlemail.com.

galias

IN  MX   

10 aspmx4.googlemail.com.

galias

IN  MX   

10 aspmx5.googlemail.com.

       

Below are screenshots of the administrator console for Network Solutions, a provider where domain names are registered.

DNS Manager in Network Solutions: 

Network Solutions (after saving):




 
    3. Once the MX Records have been inputed you have to verify the MX records are up to date, you can do this by typing the following into the browser (substitute 'customer.com' with your domain name):
http://www.dnsstuff.com/tools/lookup.ch?name=galias.customer.com&type=MX
(Or in Unix, run "dig mx galias.customer.com" on a command line.)

    4. Once you've verified that the MX records are working, you have to make sure they are tied to your Google account.  You do this by adding the "galias.customer.com" alias to the domain in the Google Apps control panel (http://www.google.com/a/customer.com)
       * This step must be completed AFTER the MX records are added, or the alias will not be verified.

Google Apps Control Panel:




    5. Now we have to configure the MTA (Mail Transfer Agent) to deliver mail for pilot users to both internal system AND user@galias.customer.com.  The MTA is your mail gateway.  You can use your current email server as the gatway/MTA.  In Microsoft Exchange Server, the administrator must setup a separate Active Directory user object that 'ghosts or shadows' the account.  The reason for this is that any give user object can only have one email address assigned to it.  The primary account user@customer.com will have an Exchange mailbox, all mail to this account then gets forwarded to the shadow user account which has an external email address (user@galias.customer.com), which is the Gmail account.  Here are the steps for Microsoft Exchange:

a. First Create the Primary Email Account. E.g; user@customer.com on your Exchange Server.  Skip this step if you already have users setup with Exchange accounts.


b. Then create a second user (that will be the external address). This account is necessary since Exchange will not forward to another user object outside of it's Active Directory domain.  Do this by creating a user as normal, but at the last step, UNCHECK the option to create an exchange mailbox.  We suggest creating a naming convention so you don't get confused: e.g.: 'John Doe' being the primary and 'John Doe_Shadow' being its respective shadow account. 

 

* Note the unique user id (logon name)



* Do NOT select "Create an Exchange mailbox"

c. Now select the user you just created (shadow) and choose properties.  In the email field, type in the user sub-domain alias email (e.g.: customer@galias.customer.com).  This is how the mail is forwarded to Gmail.

 

 

 

d.  Now, go back to the properties on the original user account (user@customer.com) and select the Exchange General tab. Go into the Delivery Options menu and select another user to forward to. Select the user (user@galias.customer.com) you created that has the external email address.


* Be sure to select the checkbox “Deliver messages to both forwarding and mailbox”

 Your Exchange settings are now complete for piloting Dual-Delivery!

    6.   If you would like to also capture outgoing mail through your gateway, you will need to specify the SMTP server in the Google Apps dashboard.  The administrative accounts have access to this.  You can do this by logging in as administrator, then select the "Service Settings" tab then "Email."  You can then specify the SMTP server in the field by "Email gateway."

    7. In the Google Apps for Enterprise admin console, create one user account for each pilot participant.  To allow for true parallel email usage and to avoid confusion, the user alias should be exactly as the primary account: "user" in "user@customer.com"
    8. Test the setup by sending email to someuser@customer.com.  The email should be delivered normally and a copy should also be delivered to the user's Gmail inbox.

Here's some helpful information:

Support tip:


Estimated timing for this phase:


Helpful Tip: For continuity of service setup concurrent users before migrating.

Phase 2: Dual-delivery Roll out to Pilot Group

The second phase expands the admininstrator group test to include the full pilot group.  Google Apps continues to run in parallel with your existing systems.  This phase allows a larger group (25-200) to gain experience working with the product on a day to day basis, and is also an opportunity to integrate with existing systems such as single sign on.

How to do it:

  1. Create one user account for each phase 1 participant using the Google Apps for Enterprise admin console

    • You may want to create users by doing a bulk upload using a CSV file.  Detailed instructions are found in the Google Apps administrative console.

  2. Optional: explore mobile access options, integrate with existing SSO, integrate with existing user directories, Reporting/Provisioning API, archiving, etc.


Who's involved (suggested):


Training and documentation:

Support: