Google Apps | Edoceo's Blog

Done with Google – Part 2

We had (and still have some) a bunch of Google Service for our company/domain. For migrating away from Google Apps (now know as GSuite) we’ve had to take loads of steps manually, I’ve not been able to find tools to sort all the things together properly. There are 60 Google services that are part of this GSuite and it’s fair to say that Google is a “first class” citizen on the Internet. We cannot get completely away.

Phase Two

For phase two of our extraction from the Google Suite we proceeded to turn down all the service in the Google Admin panel that we could. Since there are 50+ services, and we’re turning them off slowly – to prevent any large-scale shock, we were doing about one a week. There were some service we could completely drop without issue.

  • Blogger
  • DoubleClick/DART Stuff
  • FeedBurner
  • GoogleCode (we’ve moved to Github and Gitlab ages ago) and Google is killing this product anyway
  • Google News
  • Google Shopping
  • Panoramio

We progressed for a few months, taking down one (maybe two) services per week and waiting to make sure nothing broke. All went well but, we’re only disabling services around the edges.

Once those services were disabled, we were able to start reviewing how Google actually touches our business — it’s mostly Email and Calendar, which are nice – but we still need to scale down our existing Google dependence before moving on.

Google Play Store Forces TOS Agreement

If you have multiple accounts on one table or device using the Google Play Store forces users to accept the TOS or it will become completely blocked.

We have one tablet, with multiple accounts configured and one accidental click has left the Play Store unusable, none of the apps can update.

Steps to Reproduce

  1. Use an Android 4.0 or newer device
  2. Add multiple accounts to the device, including one that has not agreed to Play Store yet.
  3. Open the Play Store, it will presently select an existing account.
  4. Select the New Account, you will be prompted to Accept
  5. Decline – Play Store Exits
  6. You are now Stuck – Google is forcing you to Accept due to this bug

The reason that one account should not accept the TOS for the Play Store is that those applications are not "Kid Safe".

The only option now is to remove the account from the device entirely and start over. The average user wouldn’t do that, they’d simply enter into this binding contract with Google – even if they didn’t want too.

Seems like there is nobody at Google working in QA, bugs like this – and the terrible password issues in Chrome – keep appearing in their products.


Google Checkout/Wallet Migration Nightmare

Some time ago Google began this forced migration process of regular Google Accounts into Google Apps accounts – for those that had overlap. For these users data from multiple services had to be migrated or merged. We wrote about it twice: accounts transition and blogger migration. The migration for Checkout has been terrible!

Checkout Migration Issues

Even after months of being told that migration would soon be possible it still has not become so. Our checkout data is now scattered across three accounts. It’s a terrible inconvenience to the business. The resolution is drop the other two, of course but for us that is kind of an issue.

Our merchant id and the codes used for integrating our infrastructure into Google Checkout/Seller/Wallet/Whatever-next was in production across multiple servers and multiple applications, some more tied into the management systems than others. Basically, we have to ack/grep a bundle of code/configs for the two IDs that were created in the interim to try and solve the migration/transition issue – and re-test all of it.

We had these three accounts, accountA, B and C; A was the original Google Account that became conflicted with a Google Apps Account (C); B is the interim account that was a temporary holding while migrating. Each had to be bank verified while migrating and then cleaned-up. Checking code on multiple applications across multiple servers takes time – more than you want to spend and of course interrupts existing work-flow.

  1. Sign-In to AccountA
  2. Check Google Dashboard – false positives for subscribed services
  3. Confirm Checkout Settings (9 pages – Preferences, Tax and Integration are important!)
  4. Archive Orders and Financial Data
  5. Search Apps/Servers, Replace IDs
  6. Test – Google lets the same account buy from themselves?
  7. Wait to Process to re-verify for Badge Status

Questions for Google

  1. Why did you force migration before all services could be migrated?
  2. Why has there been no progress on the Checkout/Seller/Wallet migration since?
  3. Do you know it’s not cool to mess around wildly with financial systems that many businesses depend on?
  4. Why can’t we simply re-assign the Owner role? It’s stuck to the ‘@gtempaccount.com’ still (even after creating the migration account like you directed)!

Alternative Solution Path

So, that was quite an inconvenience for us and a few of our clients as well – other payment processors haven’t done anything that stupid to date (that I’m aware of). Evaluating a few we’ve decided that stripe is the way forward. Their system is elegant, secure and very easy to integrate. Since they’re dedicated to just one thing it’s less likely they’ll force you into a lot of work when they mis-manage an infrastructure "integration" project.

See Also


Moving Mail via IMAP from Account to Another

Most of the hosting providers these days provide for IMAP access to your mailbox.
This is great, but what if you want to move messages from one IMAP account to another?
We wrote this little tool for it: imap-move.

The IMAP Move tool was written with a few, very specific, intended purposes but there could be others.

  1. Archive messages from IMAP into a local directory
  2. Move message from one Mailbox to another Mail Account

The tool keeps track of the moved message (by mail message ID) so it can be run over and over on the same source mailbox w/o having to repeat it’s work – this can save time when you have 40k+ messages.

List the Source Folders/Labels

imap-move.php -s imap-ssl://user@domain:password@imap.gmail.com:993/ --list

Source: user@domain
01 Follow up; 0 messages 0 bytes
02 INBOX; 1080 messages 108104263 bytes
03 Misc; 0 messages 0 bytes
04 Priority; 0 messages 0 bytes
05 [Gmail]; skip [container only]
06 [Gmail]/All Mail; skip [skip list]
07 [Gmail]/Drafts; skip [skip list]
08 [Gmail]/Sent Mail; skip [skip list]
09 [Gmail]/Spam; skip [skip list]
10 [Gmail]/Starred; skip [skip list]
11 [Gmail]/Trash; skip [skip list]
11 Folders, 1080 messages, 108104263 bytes

Copy to Local Directory

Please note, this is not a MAILDIR (or, at least I don’t think it is)

  -s imap-ssl://user@domain:password@imap.gmail.com:993/ 
  --copy /path/to/storage

Copy one IMAP Account to Another

This can take a long time, the application has a lot of spew, maybe use |tee or something.

  -s imap-ssl://user@domain:password@imap.gmail.com:993/ 
  -t imap-ssl://noob@domain:password@imap.gmail.com:993/ 


Google Apps Transition – Google Analytics

In similar fashion to the issues with the Blogger Service, Google Analytics require similar steps to remove the gtempaccount.com association – and re-join into the proper/original account in your Domain.

  1. Sign-in to Analytics as the user% account
  2. Select User Manager at the bottom of the dashboard
  3. Select Add User in the upper-right of the user table
  4. Enter the email address of user@, set Access Type to Account Administrator and enable all Website Profiles.
  5. The new user won’t get any email notification
  6. Sign-out and flush cookies, Sign-in as user@ account
  7. Use the User Manager to remove the user% gtempaccount.com user

A little easier than the Blogger process and all history and identifiers will be preserved.

See Also

  • Soem
  • G Page


Google Apps Accounts Migration for Blogger & Checkout

Google has updated their Apps and is forcing all users to Migrate.
Unfortunately not all of their services are ready for this and will not fully migrate automatically.

At the time of this writing the following services fail to transition properly: Analytics / Website Optimizer, Blogger, Google Alerts, Google Base, Google Calendar, Google Checkout, Google Custom Search, Google Docs, Google Maps, Google Moderator, Google News, Google Reader, Google Subscribed Links, Google Talk, Groups, iGoogle, Places and Webmaster Tools.

Yea, that’s quite a lot, these 18 products (of roughly 70) are not ready.
Google has mentioned that eventually this will be fixed but has not announced any ETA.

That makes it difficult for anyone, including us and our clients, to plan.
We’ve been forced to figure out work-arounds and here is one for what to do on Blogger.

Migrating Blogger or Checkout with Google Apps

This is a tedious process, where your Blogger or Checkout account is going to have the existing authors switched around.
You will need two Google Apps accounts, in the same domain, to perform these steps.

Is is critical that you do not delete your blog or you will lose the custom domain (like blog.edoceo.com)

  • user% represents the old account with the conflicting name that was migrated to gtempaccount.com
  • user@ represents the new account in the Google Apps domain
  • temp@ represents the account in the Google Apps domain which will be used for an interim Author

There were some transitioning issues when attempting to go from the user% account directly to the user@ account – so we had to use an interim transitioning account – which temp%

E.G. For us user@ would be our old blog@domain.com (user@) account, which got migrated to blog%domain.com@gtempaccount.com (user%).
We had to use the interim account shit@domain.com (temp@) during this migration.

Here are the steps to follow, may the force be with you.

  1. Sign into Blogger using the user% account
  2. Visit Settings » Permissions and select to add a new author
  3. Enter the account for temp@ to become an Author
  4. Sign out of Google as user%, flush cookies and sign-in now as temp@
  5. Follow the link in the invitaion email, connect to Blogger and create your Profile
  6. Sign out of Google as temp@ account and sign-in again as user%
  7. Grant Admin Privileges to this the temp@ user account
  8. Sign out of Google as user% and then sign-in as temp@
  9. Go to Blogger Settings » Permissions again and remove the Author user%
  10. Sign out of all Google stuff and flush cookies
  11. Wait about 20 to 30 minutes for the Google Infrastructure to update, going too fast can make the next step fail.
  12. Did you really wait 30 minutes? Do yourself a favour and execute this step properly
  13. Sign-in as temp@ then add user@ account to your Blogger (Settings » Permissions), this will bring in the Apps account.
  14. Sign-out as temp@ then sign-in as user@ and follow the link in this email.
  15. Sign-out again as temp@ and promote user@ to an administrative level account
  16. Sign-in now as user@ and visit Blogger, you should have full control.
  17. None of the Profile settings from the user% account will be migrated to the user@ account so you will be required to re-create all that.

There is some data migration issue that Google has not resolved yet.
When you start promoting your Google Apps domain to function more like a Google Account (or when Google forces your migration) these steps will be necessary to clean data out of your @gtempaccount.com domain and into your desired domain.

See Also


Google Apps, Talk / XMPP, Andriod Failures

We recently decided to disable the Google Talk feature for our Google Apps for Business and use our own Jabber/XMPP server to improve monitoring and audit-ability of these communications. Turns out Google does not like it when you dis-connect their services and it will fully break email services on your phone.

Disabling Google Talk / XMPP

This process is simple enough.

  1. Create your own XMPP Server (ejabberd works well)
  2. Update the DNS Service Records
  3. Disable the Google Talk service in the control panel for Google Apps

At this point you’ll notice that your Android phone starts throwing authentication errors for Google Talk, even if the Talk service is not running, disabled and such. This error about Talk authentication is actually coming from the Google Mail service on the phone. It appears every time the phone tries to sync the mail or calendar.

We had hoped this issues would be resolved after all systems were updated but even after 24 hours these errors/issues were still affecting all users.

The actual error is this:

Authentication Error
Google Talk failed to login. If
this is a Google Apps account,
confirm that Chat service is
enabled for this account.
  [ Retry ] [ Cancel ]

If you press Retry it will of course retry and fail, if you press Cancel then your phone will no longer receive mail on that account, leaving you bricked. Don’t worry, it will throw the error again in a few minutes – and still not deliver email to your phone. This error still appears even when Sync is fully disabled for the affected account.

Attempts a Resolution

We attempted multiple ways to try to fix this. The easiest fix was to simply remove that Google Apps account from the phone and re-add it – all was well.

However, that does not work on the primary Google Account on the phone as that one cannot be removed! Now you have a broken account that cannot be removed, re-created and updated to function properly.

So we opened a trouble ticket with Google, via email, and waited 36 hours without a response. As we have Google Apps for Business we also get telephone support for “down” emergencies, such as when our phones cannot receive any email messages.

Three times we called Google (877.355.5787) and were disconnected by their system after entering our support PIN, that sucked. We finally got a hold of them to explain the issue, went like this:

  • Me: My phone no longer receives messages. I disabled Talk services and now phones cannot receive email.
  • Google: I’ll have to dispatch this to our technical team
  • Me: [ waits 10 minutes ]
  • Google: What network connection are you using wee-fee?
  • Me: You mean why-fi?
  • Google: Here is your ticket number, we’ll call you back within 24 hours. Anything else we can help you with?
  • Me: It would help to get support now, not some mythical time in the future, but we have no choice, I guess I’ll wait with broken email.

They sent an email to follow up with my email down issue, awesome. Of particular note was that our domain name was listed as "Edoceo, Inc.", affected accounts were mis-identified, and the carrier was noted as "Striant" – not "Sprint" like I explained and spelled for the CSR who took the call (their command of the English language was not good).

Hard to have confidence in Google when the service is so fragile and the "support" team is so very sub-par.

How to Fix (what Google should do)

  1. Google Mail should not be attempting to sign-in to Chat when Chat is disabled for this domain. Perhaps it could update settings on the account when service options change.
  2. An option to disable this would be handy. There are no settings for the Chat service in the Google Mail account setup on the phone, only for Contacts, Mail and Calendar.
  3. Not forcing users to tie their phones to an un-removable Google Account would be handy.
  4. Calling the product by a single name would help, Chat and Talk are the same, but confused the CSR.

Update from Google #1

Google advised to just add the account (yes, the one that was already added and that could not be removed because it was the primary). So their first attempt at "support" was #fail. Clearly their support reps did not even read the report we submitted. Also of note here is that follow-up to our support telephone call was an email from a support rep that only contained canned instructions. Google clearly has a lot to learn about customer service.

Update from Google #2

Supposedly can simply ‘Resync Account’ by visiting Settings » Accounts & Sync » [ your account ] » Sync Now. We tried that, waited but the error still appeared.

Update from Edoceo #1

That clue from Google may have started the right process. We noticed still at issue was the Google hosted servers still (even after 24h) think they are responsible for XMPP services for edoceo.com (details below). While that is not true, their updates appear to just be taking a while to publish to all their systems. A typical problem for large scale service providers.

Fixed: Clearly caching is an issue, which led us to the following solution.

  1. Settings » Accounts & Sync », for each affected account
  2. Uncheck All Sync Options (Contacts, Gmail, Calendar)
  3. Wait for two hours (could be less, but that’s how long we waited)
  4. Revist account options, re-enable Sync for desired services

This will even work to fix issues on the primary account, which cannot be removed. Once it came back on-line the errors from Google Talk Authentication were no longer present.

On another device, which had the affected account not the primary, we were able to remove and re-add the account to fix. Duh, right?

Here is the details about the issue from our eJabberd verbose logs.

  <undefined-condition xmlns="urn:ietf:params:xml:ns:xmpp-streams" />
    <str:text xmlns:str="urn:ietf:params:xml:ns:xmpp-streams">edoceo.com is a Google Apps Domain with Talk service enabled.</str:text>

<iq from="$buddy@gmail.com" to="me@edoceo.com/Office" type="error" id="purplef88a9f67">
  <vCard xmlns='vcard-temp'/>
  <error code='404' type='cancel'>
    <remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' />