Setting Up Google Apps For Your Domain, Part Three

In our final installment of the Google Apps series, we will walk you through the last steps of setup, testing, and finally launch! But don’t get excited just yet. Launch is only the beginning!

As a quick recap, in part one we went through prerequisites and initial setup, up to setting up E-Mail. In part two, we dived into the larger parts of Calendar, Groups, and Contact Sharing.

In Part three we’ll be looking at setting up Mobile Clients, Steps for Launch, User Support, and then what to do to customize and further improve your service.

Mobile Clients

Mobile is one of those words that used to make administrators shudder. Allowing mobile phones access into your network was a recipe for disaster, mostly because the management was non-existent, and phones were so easily stolen. While the stealing part hasn’t changed, the management tools these days are excellent.

If you’re a BlackBerry shop, you have a few options. One is to use Google Apps for Business and install the Blackberry Enterprise Services (BES) Connector from Google. This will link up your BES server so that it will send push email from Google to handsets and still allow you full control.

Another option is to install Google Sync on all the devices and let that handle contact and calendar sync. This approach works well for small shops, but once you hit more than 10 devices, you should really look into BES. Also in this approach, you have to use IMAP to access mail, which is slow and drains batteries on mobile devices.

For everyone else, you can hook in using the standard IMAP or POP3 access, or use ActiveSync. For my personal deployment, we are all iPhone users, and so ActiveSync works quite well. I am sure that once we grow a bit beyond that, we’re going to need centralize management, especially if they are company phones floating around. Android users have it really easy because Google Apps integrates pretty deeply into the OS.

Steps for Launch

Hopefully after you read through part one, it was clear just how much Google Apps relies on DNS, and that having complete access to your DNS is important. Aliases rely on it, as does email to even work at all.

At this point in the process, you hopefully have already created all the necessary aliases, created users, set up the accounts, and basically gone through everything we’ve covered up until this point. Once you start down the DNS switch road, it’s not exactly easy to come back.

First, before going anywhere, you have to lay down a plan for your users. Communication is key for critical service migrations like this, because your userbase is going to be very upset if not. Once a plan document has been finalized, post it to as many places as you can. Email, websites, cork boards, etc. can all be used to communicate your plan. I would even go so far as to have preliminary training demonstrations for larger userbases so people know what to expect.

Once this planning step is done, double check all your work. Test your aliases to make sure the redirects work. Make sure all your users have been imported. Send out usernames and passwords to accounts if you haven’t done so already.

Larger enterprises have the fun time of making sure all their Outlook installations are set up correctly. Google provides several way to deploy their connector for Outlook, and you should look into them if you have Active Directory as it makes the process easier.

Launch finally comes preferably on a Friday evening. Why Friday evening? Because it gives you the entire weekend to roll back the DNS changes if everything goes down the drain. Budget a good portion of Friday and Saturday once you’ve started the final DNS changes. At this point, that should mostly just be the MX records for email, allow with DNS TXT records for spam mitigation. You already activated Gmail during step one, right?

User Support

So how’d launch go? If you got to sleep Friday and Saturday nights, things must be going pretty smoothly. Now your users are beginning to use the system, and ultimately questions arise. Who forgot their password, or who doesn’t remember the URL, etc. Thankfully Google’s Deployment Center can assist with that. The site is user friendly, but most of the documentation is meant to be customized by you, so take a look before sending users there.

The Administrator Guide is where you, the admin, will go to find the support docs you might need. If you’re paying for Google Apps, you have the additional nicety of tech support. Never be afraid to use it! Google has some really solid engineers working for them, and asking questions early means quicker solutions later.

What’s Next?

There are a few more items you can look into once you’ve come this far. Google’s Postini service, for example, is usually recommend to be configured post-launch as Postini, if incorrectly configured, can really trash a launch. I did not bother setting up Postini, as Google’s default spam catcher is actually really good. If you want to configure Postini, please read the documentation here.

Also a great place to checkout is the Google Apps Marketplace. There are hundreds of applications available, ranging from free to rather expensive CRMs, Expensive reporting tools, trip managers, and so on. Google also provides a rating system for these addons, so it’s a good idea to do your research, because you have to support these addons once they are installed and visible for users.

Conclusion

As we reach the end of this “two then three” part series of articles, let’s take a look back at what we’ve accomplished. We have successfully set up, tested, integrated, and launched a complex system that aims to replace (and does so for many) the traditional groupware suite. Not only that, but for many companies, Google Docs has also begun replacing Microsoft Office as the primary office suite.

So in closing, we hope you all have enjoyed the article series as much as we enjoyed writing it. We are planning on writing more of these and would like to hear from you what you might like to see!