I posted about Google Apps in the Enterprise a year ago. Google constantly evolves, I decided it would be a good time to update the post with more current information. Updates in red font.

Pluses

• Email and calendar syncs with multiple devices – Native apps for Android and Blackberry, and IMAP support for the iFolks. No need for Blackberry Enterprise Server. Coming from an environment where only upper level management got Blackberries, having my calendar and e-mail on my phone was a huge plus.
• Multiple editors – Google Docs lets you have multiple users in the same document editing simultaneously. This proved highly useful for many collaborative efforts.
• Education – Provides a low cost, easy way to provide email accounts and collaboration tools for a constantly changing set of users.
• This is a benefit of all cloud-based email, but you relieve your admins of the need to run a mail server. Google manages antivirus, antispam, storage, and updates. You can buy Google Vault for email compliance, no need to continue buying trays of disk as your archive storage demands grow.

Minuses

• User Deletion – When you delete a user, it’s 5 days before you can put that user back in. It was an accident? Too bad. That user is without their e-mail account for 5 days. This extremely annoying problem seems to have been resolved.
• Document Deletion – When a user is deleted, so are all their documents. Seriously. Every document they own is *poof* – gone. If you’re running Sharepoint, deleting the owner of a document does nothing. The rest of the team is able to access the documents authored by the deleted user. This is not the case with Google Apps. Forcing a specific user to own documents is a major flaw in Google Apps. There is now a document transfer utility, but you have to run it before the user gets deleted. It’s a manual process to assign the user’s documents to another user. If you’re running the Google directory sync tool (GADS), it gets even more difficult to manage. You can’t let the users automatically delete, so instead you have to suspend the users. You then need to go back in and manually clean up the suspended users, saving whatever documents need saving. Doing this on an enterprise level is EXTREMELY difficult and time consuming.
• Management Delegation – There are no degrees of admin rights – you’re either an admin or you’re not. Although you can do some interesting thing with delegation using Google Organizations, many corporations have a centralized helpdesk. If you want any helpdesk worker to be able to help any employee, the helpdesk worker has to be a full blown administrator over the entire Google Apps domain. This is not a particularly palatable choice when you’re talking about hundreds of outsourced workers. Fortunately, Google updated this system to include a wide array of permission delegation.
• Bandwidth – Your bandwidth costs are going up. WAY up. Using Lotus Notes, a file attachment sent within the company never left the WAN. With GMail, the sender has to upload the attachment to the Internet, and then each user who receives it has to download it over the Internet. Every time people check their email, it’s Internet bandwidth and not WAN bandwidth. That’s thousands of users generating Internet traffic that didn’t exist with Notes. No change here, but that’s the deal when you go a cloud service.
• Constant Development – Google Apps is continuously changing, and changes are pushed to Production with no warning. Things break overnight and it irritates the hell out of your users, and drives up support costs for IT. The business has to get used to the fact that IT no longer has any control over changes to the email system.
• No Logs – Logging is nonexistent. There’s no event viewer, no activity log, nothing. You have no idea who is doing what and no way to look it up
• Extracting Information – You can’t even get a simple list of who your domain’s administrators within the Google GUI. If you want to extract the information, you’ll be writing a script. They have libraries in Java, JavaScript, .NET, PHP, Python, and Objective-C. If you’re a system admin, you’re probably not a programmer, so you’d better brush up on your Python. You’re not likely to make it past the learning curve to be able to use anything else.
• Emergency support – You can’t get support without your support PIN, and you can’t get that without administrative access to your Google domain. The PIN changes periodically, so you can’t rely on having written it down. If you’re locked out of the domain, you’re stuck with filling out a form and waiting for e-mail support to get back to you.
• The apps – Using the apps feels a lot like using Office 1.0. They’re rough, good enough for the very basics but not really ready for primetime. Your accounting department would stage a revolt if you forced them to use Google Spreadsheets instead of Excel
• Enterprise Integration
  • Passwords – You can use the Google Apps Directory Sync (GADS) tool to automate user provisioning up to Google Apps by syncing your existing LDAP infrastructure with Google. However, passwords are quite a challenge. If you have a way to extract the user’s password out of your LDAP directory, you can push that up to Google – but who wants Google to have a copy of the user’s corporate password? So you’re left with maintaining a separate Google password. Even if you implement Single Sign-On and authenticate users against your own LDAP server, that only applies to access via web browser. The separate Google password is still used for mobile device access. The GADS tool will allow you to sync passwords, but only if your directory stores them with easily broken SHA-1 encryption, or plaintext. I am not in favor of reducing the security posture of your internal network just to be able to sync email passwords out to the Google cloud.There is a new tool called GAPS, the Google Apps Password Sync utility. You have to install it on all of the domain controllers in your domain. When a user changes their Windows password, the change is synced up to their Google Apps account.  The tool works well but I am also not an advocate of installing a utility on all domain controllers, particularly one that reads all password changes in plaintext.
  • Single Sign-On– If you decide to go the SSO route, you have to have a secure way to store a user’s e-mail address within your directory structure. With SSO, no user credentials are sent to Google – instead, Google uses a certificate to ask your company’s SSO server to authenticate you. Your SSO server must send the user’s e-mail address back to Google. This directory attribute must be created and secured, otherwise anybody with access to that attribute can impersonate any user. Let me repeat that – *ANY* user in the organization with access to the “email” property in your directory system can use SSO to read *ANY* user’s e-mail. For many enterprises, this means an unacceptable number of non-privileged IT workers have the ability to read anybody’s e-mails. Google does not offer any kind of AD schema update like an Exchange installation would to create a properly secured set of properties for e-mail address, so you are forced to create the properties manually and come up with a set of ACLs to achieve the proper security. This can be extraordinarily tricky in a large enterprise.Despite the difficulty, I prefer the SSO route. You don’t have to install anything on your domain controllers and user passwords never leave your network. Some of the SSO software vendors such as PING Identity have a Google Account password change plugin for their SSO software, so your users can authenticate with their AD credentials and can change their Google account password without a helpdesk call. I find this to be the most secure of the choices.

Google Apps seems has matured sufficiently that I believe you can successfully deploy it in most use cases. I would still question it for a large enterprise, but for SMB or Education purposes, Google Apps is a solid choice.