Nothing special, right? Not really. Just like any other migration this project has its share of technical challenges but we have grown used to that. More importantly, as part of “Going Google” we also planned training sessions for the employees.

In the past I have explained some useful things for users moving to Apps from other mail systems in this blog post.
However something that users really struggle with is searching instead of sorting emails.

So how can you show the power of search in Google Mail in a playful manner? Probably if you are willing to wager for a bottle of champagne.

It has become almost a classic during our training sessions: betting with attendees that they cannot find their PUK code, their PIN Unlock Key of their SIM card, in less than 5 seconds.

This probably has happened to you also. You enter an incorrect PIN code three times and your mobile phone is blocked. You can only unblock it with your PUK code. But… where is it?

Traditional answers are “in my office”, “it is on my mobile as a note” or “I don’t have a clue where”.

Mostly everyone tends to admit that they cannot find the code in less than 5 seconds. But would they be willing to bet that I can?
Nobody dares to accept the wager.

And probably for the better because I would win every time!
How?

When I received my unlock code I sent a mail to myself that contained my PUK code –not only for my mobile phone but also for my iPad– with PUK as a keyword.
In less than 5 seconds I get all the emails with my PUK codes if I enter ‘PUK’ as a search phrase in Google Mail.
By the way, the same trick works like a charm for finding serial and license numbers of hard and software.

People are often amazed by the extra dimension that search commands add for retrieving information in Gmail. Search phrases such as ‘after:2011-01-11′ (after January 1, 2011), or ‘paswoord -password’ (paswoord not password) greatly increase your efficiency.

So may be this overview of the advanced search terms in Google Mail can be an addition to your holiday reading list?
Or even better, the coming summer months get your employees to become real GMail Ninjas during a personalized Google Mail training session.

Interested? Contact us to learn more about our arrangements.

However for organizations with multi functionals or scanners there is a problem!

It is common in different types of organizations these days: documents are scanned with a multi functional or scanner and are sent via email internally. The recipient receives an email with the scan, often as PDF attachment. However, that is not the problem.

The problem starts with the layout of the email messages. Depending on the type of multi functional, the subject line is in many cases always identical.
Despite the different attached files, Google Mail ‘groups’ them into one conversation. You can see an example below. Now, if you don’t pay real close attention, you miss the last received scan. More than irritating.

True, you can disable the conversation mode, but then it applies to all your messages. And often that is not what you want!

A great solution could be a filter that ‘breaks’ the conversation based on a conditional text string, i.e. by adding a time stamp to the subject line. Unfortunately today this is not possible.

I can hardly imagine our customers being the only ones that are thrilled by conversations but annoyed by the scan problem. That is why I am publicly asking Google to come up with a creative solution. May be a new Lab?

Or may be even better, support us and our tormented customers by entering ’support multifunctionals, break conversation mode’ here as a Gmail feature request.

Just do it!

Most of the times they have a problem understanding the differences between using folders and labels. During training courses I like to refer to labels as being post-its. Instead of duplicating mails to organize them in different folders, labels are comparable to post-its. You can add one or more of them to the same document. Just like you would with a physical document.

Only question that remains is, how? A small overview of the many different views can be viewed below. With thanks to Rick van Vliet for the tip of dragging an email from the overview to a label.

Has your organization ‘gone Google’, but do your users experience difficulties changing work habits? Talk to us about our training options.

An example? A Dutch company has used mycompany.nl as their primary Google Apps domain, but they also have employees in a Belgian subsidiary. All employees log into Google Apps with the email address associated with the primary domain. Really easy because resources such as meeting rooms or calendars and documents can easily be shared between employees in both locations.

This makes Google Apps a great fit for organizations active in multiple countries. So, let us stop the sales pitch here.

As a user and with some configuration work, I can determine which email address I am going to use as outbound address. In our small example above, it might make sense that Belgian employees prefer to email Belgian clients with mycompany.be instead of mycompany.nl, their default outbound email address. In your mail settings you can easily select which address you want to become the default one if you have multiple.

But how about support for this on a mobile device? A short overview.

Android always uses the default email address of your Google Mail account. If you have marked mycompany.be as default in the web interface despite the Google Apps domain being configured as mycompany.nl, then all your mail will be sent as mycompany.be. Unfortunately Android does not allow you to explicitly select an email address when composing a message.

iPhone and iPad users will have the same Android like experience if they opted to use the Gmail client.
If you have configured your iPhone or iPad via ActiveSync then the result is below par: you always send email with the address of your primary Google Apps domain. In our example and despite changing the default email address in your account, you will always send always from mycompany.nl.

So this blog post is a feature request to Google to modify their implementation of ActiveSync. ActiveSync does support using a default email address different from the user name. Proof? In BPOS / Office 365 it is perfectly possible to obtain the Android-like behavior on your iPhone / iPad.

So do we need to wait for Google to fix it? Nope.

One of our clients has three business units, each with their alias domain that are on the same Google Apps instance. What they did not want, was their iPhones to use the ‘wrong’ email addresses. Some creativity was needed to make this possible.

The solution?

All iPhones were configured by activating ActiveSync but enabling only the synchronization of calendars and contacts with Google Apps. The iPhone’s account settings allow you specify what to sync. As a first step simply do NOT enable mail sync.

Then a second account was created on the iPhones but with IMAP. As Address the email address of the business unit was entered. As user name and password the Google Apps account data were used. And… presto. iPhone (and iPad) users were able to send email with another email address as send as address.

May be not the most elegant solution… but it works!

After the ability to configure ‘organizational units’, a concept from the LDAP/Active Directory world that enable you to create groups that can you allow or disallow access to certain services, Google takes a next step forward with the introduction of the superadmin and the (normal) admin.

Why is this so important?

In larger organizations typically system administration is done by several people and they do not necessarily have the same administration rights. For example, help desk engineers are allowed to reset passwords but do not have the admin rights to delete a user.

As you can see on the screenshot below, Google Apps now has two different types of administrators: the superadmin and the admin.

The superadmin is the almighty of the Google Apps domain. He can grant a wide range of specific rights to ‘normal’ admins. It is now possible to grant certain collaborators admin rights for an ‘organizational unit’ such as a branch office. Or the superadmin can grant very limited admin rights across the entire organization.

When used with careful consideration a most welcomed extension of the Google Apps Dashboard.

If you previously had a complex folder structure with many levels in Outlook, then the result in Gmail after migration is very long labels… with only the first 26 characters visible.

So what if you really want to keep a hierarchical structure of your mail archives? A few suggestions.

I could write a number of pages why not to invest time and effort in keeping folders to organize mails and why ’search’ is more efficient. But I also know from experience that there is a ‘right’ time for everything.

Mile long labels with only the initial 26 characters visible are going to annoy you big time.

A first step to prevent increasing frustration is to enable the ‘Nested Labels’ Lab functionality. You will now be able to manage your email by sorting it into a hierarchy of labels. Simply add slashes (/) to label names to express inheritance. For ‘ex-Outlookers’ suddenly a number of things become ‘like they used to be’.

Also, Google recently solved another problem: manually created labels were limited to 40 characters while migrated labels could be up to 255 characters long. Manually shorten migrated long labels to values longer than 40 characters was not allowed because of an input validation rule. An update in the visualization and edit functions now has solved this.

So you have bought an iPad and want to use it for Google Apps? What are the tricks of the trade? A small summary…

Close to everything you find about using Google Apps with an iPad refers to the configuration of your Google Apps account as an Exchange account on your iPad.

Because Google has a license of Microsoft’s ActiveSync technology you only need to enter your full user name, password and m.google.com as server. Apple’s Mail.app, Calendar and Contacts neatly performs two-way syncs with Google Apps and allows you to performs updates on while you are offline.

You are also going to find out pretty soon that when you delete a mail in Mail.app, in Google Apps it is not in the Trash can, but the mail will have been archived. Annoying behavior…

As Google Apps user you have probably grown used to access your mail and calendar via your internet browser, so why not do exactly the same with the mobile version of Safari on your iPad? And have all the functionalities of Gmail, e.g. labels, correct deletions instead of archiving, search, etc.

Instead of messing with bookmarks in mobile Safari it is a lot easier to install the Google Search-app from the Apple App Store. If you place the application icon for Google Search in the task bar you can easily open all the different Google applications.

Google Buzz is supposed be to their answer. After what happened with Google Wave, maybe I  will need to rephrase this soon to was.

Google Buzz is now available for more than a year (an eternity in web technology) and is hardly used by anyone. True to Metcalfe’s Law people seem to flock to those networks where others are present: Facebook and Twitter.

Chances that Buzz can convince huge numbers of users to use it as their main tool to publish their status info are close to nil.

Nevertheless especially in larger organizations, there is a clear need to share status updates with others in the organization. Similar to what consumers do. A need that Yammer, with a recent funding of $25 mio, and Salesforce with Chatter seem to be able to address very well. Yammer claims that 80% of Fortune 500 companies use their software.

So it is very hard to understand that Google does not change its strategy and make Google Buzz part of Google Apps. Their intentions expressed more than year ago to do so.. again remain without results.

With the proper configuration settings of Google Buzz in Google Apps comparable to the settings of Google Chat, open it up or restrict to the domain, the support of Buzz could be greatly enhanced. Just like with shared documents in Google Docs where external users experience new possibilities of collaboration when working together with Google Apps users, a similar ripple effect in favor of Google Buzz could start.

How do you feel about Google Buzz? Dump it or change it?

Their three separate businesses currently have their own Google Apps instance. Regularly they run into problems related to this: searching in Google Docs is to a high degree domain specific, using a Google Group with users from an external domain for authentication in Google Docs (STILL) leads to issues related to the link of the shared document, setting a ‘global address book” of the three domains is next to impossible, etc. …

Having everyone on the same domain, albeit with an appropriate default email address that refers to an alias domain, seems to be the best solution. For end users of the consolidated domains the only difference is that they now will login with a user name that is different from their email address.

So let us get the ball rolling.

The first problem and the solution
First problem you run into: it is not possible to add an alias domain to an Google Apps domain if that domain is in use in another Google Apps domain. E.g. you have two Google Apps instances –let’s call them company1.com and company2.com– and you want to consolidate them both into company1.com.

Removing the alias from the domain or deleting the entire Google Apps domain is not the solution. There is a 5-day grace period before you can add the domain to another primary Google Apps domain.
The solution here is to call Google Support asap and set a date and time when they can delete the domain and add it immediately without domain validation. At the same time you will probably also need to change MX records in order for mail to be delivered to the proper Postini system.

The second problem and the solution
Deleting a Google Apps domain also has a consequence that all information is removed. Last thing I heard users don’t really like that. So we need to come up with a solution to migrate calendar items, contacts and mails from the domain that will be deleted later and make sure that the users keep receiving mail while we migrate everything!

Via the IMAP migration option in the Dashboard of the domain that we will consolidate to, we are able to migrate the user’s mails to their new account. (I don’t understand why Google will no longer be supporting this migration feature from the end of April)

The end user can provide you with a manual export of their contacts and calendar. Automating the export via the Contacts and Calendar API is often a better solution.

In the domain that we will consolidate to, we will need to add an extra mail address of the migrated domain for all the migrated users. In other words, their user name will become @company1.com, but their default email address will be @company2.com. Again, scripting this is the best solution.

Configuring forwarding via the Dashboard in the domain that will be deleted later, enables all mails to be forwarded to the appropriate accounts in the consolidated domain. In this way you avoid that new mails are skipped during the migration.

Tip 1: change the passwords of all the users on the domain that will be deleted just to avoid that users create new calendar items, contacts or send mails by mistake in or from the wrong Google Apps environment.

Tip 2: If you use custom URLs such as http://mail.company2.com, check if you can enable forwarding in your DNS to http://mail.company1.com in order to avoid user frustration and calls to your Support Helpdesk.

‘The proof of the pudding is in the eating’
If all is well, you probably now only need to remove all accounts, except the admin account, close to the time you have scheduled with Google and let Google Support do their thing.

Tip 3: Don’t forget the user’s documents. Downloading and uploading their own Docs prior to the deletion of the domain is something the users should be able to handle themselves. Adding their ‘new’ user name to every shared document they have, is a bigger problem. Doing so by using a script with OAuth across both domains is probably the best and safest solution.

Tip 4: (and the most important one) Communicate to the concerned collaborators in due time all the different steps. Explain to them why and when things will change.

Does it seem like a puzzle to you and pretty complex? Maybe it is, but that is why Google recently started certifying Google Apps Certified Deployment Specialists.

And guess what, Romneya is certified by Google!

Google App Engine appears to be the ideal platform to host your website. Especially if you are already using Google Apps. True? Or not?

One of the reasons why GAE is hardly used for hosting sites is the limited number of supported development languages. Only Java and Python are supported. Add to this the lack of support for SQL databases and you will start to understand why developers of content management systems (CMS) stay away from GAE.

Most of the popular open source CMS software, such as Wordpress, Drupal or Joomla, have been built in PHP with MySQL as underlying database.
Converting everything for the Google platform, and despite obvious advantages by doing so, does not appeal to open source developers. The hundreds of plug-in developers that add value to any CMS, also prefer to stick to a popular CMS with lots of users.

Our search for a decent possible solution on GAE did not bring much to the table. The only ones we found were Vosao (in Java) and Micolog (Python). Both leave a lot to be desired for.

So hopefully Google, or Accenture that made the royal site, will soon provide more details on how they built the site. Or even better, release the CMS software under an open source license for others to improve and extend.

In this way using Google App Engine for website hosting might become a little bit more attractive.