Take a peek inside a Google data center to see how the big boys do it (personal transport device included).

After several weeks of trial and error, Wright PC Consulting has finally made a transition to Google Apps for mail and other services.  This transition has no direct affect on current or future clients.

As a Google Market Place vendor, we have helped others smoothly migrate to the Google Apps platform before.  However, while the transition is typically a pretty straight forward process, the were several variables that made this one slightly more complicated, including billing scripts, BlackBerrys, server notifications via e-mail to name a few.

Why the change?  There were several reasons for our desire to utilize Google Apps:

1. Space.  I’d rather keep as much space available to customers as possible.
2. Spam.  Google, with their acquisition of Postini have a reputation for controlling spam.  As a forward facing company with many e-mail addresses floating around cyber-space, better spam control is always a welcome addition.
3. Uptime.  While Google, specifically, Gmail has has some recent well publicized outages, their overall uptime is excellent.  Additionally, in the unlikely event of an extended DimeNOC network outage, I want the ability to continue to communicate with customers in order to keep them updated.

Now to the challenges… There were only two, but those two consumed a significant amount of time.

The first was figuring out why, despite all MX records and the etc/remotedomains and etc/localdoamins files being updated correctly was my server refusing the send mail to my domain.  I was able to get the server via scripts to send to others and those outside of the domain could send mail that was received for my domain on the Google servers.  After much searching and testing I discovered that the issue was with Exim and hubbed hosts.  So, I added a file,  /etc/hubbed_hosts with one line of text:  wrightpcconsulting.com:  ASPMX.L.GOOGLE.COM.  I then added the following to the ROUTERS section of the Exim Advanced Configuration in WHM:

hubbed_hosts:
driver = manualroute
domains = “${if exists{/etc/hubbed_hosts}\
{partial-lsearch;/etc/hubbed_hosts}\
fail}”

route_data = ${lookup{$domain}partial-lsearch{/etc/hubbed_hosts}}
transport = remote_smtp

Once Exim was restarted by WHM I began getting mail from the server and all scripts that I run, including the billing scripts.

The second was much easier.  My BlackBerry was not getting e-mails via push.  Rather, they were delayed by about 15 minutes suggesting polling rather than push.  The new BIS 2.6 update solved that.  I deleted all accounts in BIS and re added them.  Suddenly instant push.

I hope that my experience helps someone…

Update:  Looks like BIS 2.6 is not yet ready for prime time.  I recently discovered that sending from two of my accounts using a desktop client (Thunderbird) caused my entire Sent box to be pushed to the my BlackBerry.  First time is was 58 messages, the second was over 183.  That is not acceptable!

Update 2:  The solution to the issue presented by the BIS 2.6 upgrade was to manually set the accounts as IMAP accounts rather than allowing BIS to do the setup.

I ran across this Storm vs iPhone comparison and thought that it was worth sharing:

Various media outlets have reported that details of the US Presidential helicopter(s) collectively known as Marine One when the Command and Chief is on board have possibly been leaked by a peer-to-peer application on a defense contractor’s computer.  According to the media reports, the receivig IP address resolved back to Iran.

In response to public criticism and concern about Google’s cloud solutions, known as Google Apps, Google has recently released a “status dashboard.”  Here, customers can check the status of Google’s cloud applications themselves online.

No more wondering if “it is just me?”