Skip to main content

Reflections on Google Apps

I just completed our first deployment to Google Apps Premier for a client and a had a great time with it. I've already moved my domain ( over to it and I highly recommend anyone who needs a mail system for their domain to consider it. Here are a couple thoughts on the overall process and results:

  • Carefully consider the clients technical prowess. Although Google has taken great strides to integrate the service with Outlook (And soon the rest of the office suite), there will be a learning curve involved. Our client was very tech-savvy and thoroughly enjoyed learning about all the new features, but that will not hold true for everyone.
  • Plan your deployment out ahead of time. Google makes it pretty painless for even complex configurations (dual-delivery, mixed environments, etc.), but read over the entire deployment guide before you get going. There are a lot of "gotchas" that popup. For instance, support for a GAL is not nearly as straightforward as Google insinuates on their website.
  • A smooth migration is the key to happy adoption. Lost emails or contacts will not be received well, obviously. Google makes moving IMAP and POP3 accounts easy, but be sure you understand how it works first. Two additional thoughts on POP3:
    • If the client plans to use the Gmail interface and currently uses Outlook, go with the Email Uploader utility and then install the desktop access points.
    • If the client plans to continue using Outlook, just install the Sync tool, import their data, and it will do the rest.
  • For staged deployments, get your account running on Google Apps first, create your users, and then use the mail flow rules to slowly move the stream of email for individual users to Google Apps. This way you can continue to operate on both the old and new messaging infrastructure, giving you plenty of time to migrate.
  • Google Apps is not Microsoft Exchange. It is still inferior in some areas, but far ahead in others. Carefully evaluate the clients needs and current usage, particularly if they are already on Exchange, before migrating to GA.
  • Support sucks. In comparison to Appriver and other hosting services, being required to wait several hours for an email response is atrocious. Be a Google Apps expert before you attempt to deploy, or you may end up with the short stick when it comes time to blame someone for poor service.
Additionally, you'll almost certainly want to set these features as soon as the domain is online:
  • Create CNAME records for all the major components (,, etc.)
  • Create SPF records to help prevent forged mail from your domain.
  • Enable contact sharing (Users And Groups > Settings > Enable contact sharing)
  • Change the user support contact information to your company (Domain settings > General > User support)
  • Enforce SSL on all Google Apps sites (Domain settings > General > SSL > Enable SSL)
  • Hide ads for all pages (Domain settings > General > Advertisement option > Hide all ads for this domain)
  • Change the default time zone (Domain settings > General > Time zone)
  • Upload a custom logo (Domain settings > Appearance > Header logos)
  • Get Google on your Desktop
    • Download the Google Apps desktop access points (Advanced tools > Google Apps desktop features)
    • Download Google Apps Sync for Microsoft Outlook (Service settings > Email > Outlook & BlackBerry Support)
  • Enable Email Migration API (Advanced tools > User email uploads)
  • Enabled Google Apps Sync, Offline Gmail, Gmail Labs, and Voice/Video Chat (Services Settings > Email)
  • Enable Postini mail filtering (Dashboard > Add Services)
There are a lot of other features you may or may not want, but the ones I just listed are nearly universal. Google Apps is not for everyone, and it still has some maturing to do, but the price point and feature set are excellent. If Google continues to add features as quickly as they have in the past and improve support, the Apps service will make a fine addition to your solutions arsenal. 


Popular posts from this blog

Outlook Credential Prompt When Opening Exchange 2013 Public Folder

After completing an Exchange 2007 > 2013 migration recently, I was left with one issue that was preventing us from stamping the project as a roaring success and moving on:

Outlook 2013 users were sometimes receiving a single pop-up prompt for credentials whenever they opened the Public Folder (we have only one). One. Single. Prompt.

Google was frustratingly unhelpful because searching for "outlook prompts for username and password when opening public folders" or something similar just resulted in a lot of folks who were always getting a pop-up that wouldn't go away. It was usually caused by an authentication failure of some sort.

However, we were in a different boat - Users got the prompt once when they first launchedOutlook and opened their public folders, but after entering it they could continue - authentication worked. Next time they logged in to their PC, it would happen again. Not a show stopper, but it definitely generated its share of support calls.

Repairing Mailbox Corruption in Exchange 2010

I recently got through recovering an SBS 2011 server after Active Directory face-planted in the middle of a workday. When I say recover, I mean I repeated the entire migration, using a cleaned up secondary DC - it was a fun weekend (expect another post about that experience). Although I thought we were in the clear, I got a call from the client about 24 hours after we had verified everything was working. He indicated that his iPhone had suddenly stopped receiving mail in the inbox (calendar, contacts, sent items were still fine) and throws up an error after spinning in circles for a few minutes that it "cannot connect to mail server".

SCEP Policy Update Troubleshooting

Because I'm a glutton for punishment, I recently started rolling out System Center Configuration Manager 2012 R2 SP1 and System Center Endpoint Protection across our VDI environment. There are always some considerations to be made in a pooled desktop / gold image type environment when loading software that uniquely identifies devices, but lucky for me SCCM/SCEP handled this just fine without any tweaking. However, there were some nuances to how SCEP policies are applied that caused some serious hair-pulling before I spotted the issues.