This trick I learned few days ago from one my clients. While it's very simple to implement, I wasn't aware of this capability of Google Apps and I am sure it can help others as well.

Sometimes, you'd like to setup an auto-forward of incoming emails to some particular email address to be redirected to another external account. It can be an subcontractor which wants to present your company's email address but actually wants to read it from his own email account or any other similar use-case.

The "standard" way of setting it up is to create a Google Apps user account ($50/user/year) and configure Forwarding from the User's settings (Gear button). However, it requires license, knowing the end-user's password and some tedious process of sending confirmation email and approving it.

The much more convenient (each cheaper) option is to do this nice trick:

Step 1 - Create a Google Apps Group

Create a Google Apps group with email address you'd like, like ""

Step 2 - Add a member

Add a member with the real, external address to whom you'd like emails to be sent like to be delivered ( in my example).

Step 3 - Verify Group Settings

You'll need to verify that Group's Access Settings include "Anyone Can Post" and "Allow posting from the web" and proper Moderation settings to ensure correct delivery.

That's it. From this moment and on, all emails sent to will be automatically redirected to and you've just saved $50/user/year :)

AuthorVadim Solovey
2 CommentsPost a comment
For some reason, people often underestimate the value of Split Delivery feature in Postini. While it's a little more complicated to setup, it offers a really strong value for distributed organizations and Google Apps migrations.

In this post I will cover how Split Delivery helps with Google Apps migrations and makes them more flexible and easier to manage.

First of all, what is Split Delivery? This is basic Postini's feature which allows you to split delivery of inbound mail flow to several email configs (i.e. server mail servers). The mail server can be an Microsoft Exchange server or Google Apps.

Before we start the migration to Google Apps, your mail flow in being handled by some sort of mail security solution, often referenced as mail-relay. In rare cases, it's being routed directly to your mail server.  Given the fact that most of the migrations are phased (i.e. not all of your users are being migrated overnight), you'll need a flexibly way to route inbound mail.

By flexible way, I mean that inbound email flow for users who are already migrated to Google Apps will be delivered directly to Google Apps and for the rest of your users it will be delivered to your old mail server.

To start, you will need a Stand-Alone version of Postini. The Integrated version doesn't support multiple email configs, thus is inappropriate for Split Delivery. Your Google Apps for Business already includes a license for Google Message Security and you'll need to contact Google (if you purchased it directly) or to your reseller to ask to reestablish your Postini account as Stand Alone. This process can take few days, depending if your domain was registered with Postini prior to the change or not. See more details on two editions of Postini here.

When your Postini account is ready, you'll need to create two separate email configs. Usually, you'll already have one email config, named [Your Account Name] Email Config 1. You can rename it so something else to better reflect it's purpose under "General Settings" tab in your Postini Console.

The idea is to create two email configs, one for your existing mail server and another one for Google Apps.

Configuration of Email Config 1 (Inbound Servers -> Delivery Manager -> Edit) should contain your existing mail servers, i.e.

The 2nd Email Config (again, Inbound Servers -> Delivery Manager -> Edit) should point to Google Apps:

Before you begin your migration to Google Apps, you should place your users under Email Config 1 and as you go thru your migration, all you'll need to do is to move your migrated users between both Email Configs.

Personally, I like to create a group in Active Directory, - something like YetMigratedUsers and sync users using GADS based on group membership. This way, you'll assign all users to this group and remove their membership as soon as you migrate them to Google Apps. The GADS will do the account move between Email Configs automatically.

Note: You should be aware of "Differing mail hosts" issue when splitting email for a single email domain between several emails configs. See my post on this matter.
AuthorVadim Solovey
2 CommentsPost a comment
If you ever wondered how to check Postini's Operational Status, you can use the following links:

Don't know on what system you're?

Log in to your Administration Console and look at the URL of the page:
In the Administration Console, the URL will begin with ""

The number of the system you're on will appear in place of the X in the example URLs above. Available systems include 5, 6, 7, 8, 9, 10, 20, 200 and 201.
AuthorVadim Solovey
I never ran into this issue until few days ago. Migrating Microsoft Exchange servers to Google Apps often require definition of forwarding rules. Most often you'll want to auto-forward emails sent to Exchange accounts which were already migrated to Google Apps by people who wasn't migrated yet (co-existence mode).

It seems like Exchange 2007/2010 doesn't allow (by default) setting forwarding rules for external domains (and your Google Apps is considered external domain). I think I never ran into this before, because all of the Microsoft Exchange servers I migrated were upgraded from prior versions (like 2000/2003) rather than fresh/new installs.

Fortunately, there is an easy way to fix it. Go to PowerShell and type this command:

set-remotedomain -identity Default -AutoForwardEnabled $true
AuthorVadim Solovey
Sometimes, mailing list management goes out of control. Years after years people are tending to add more and more mailing lists (also known as Distribution Lists) and almost never delete the old ones. After a few years you will discover that you have more mailing lists than actual people in your organization, just as I did recently when helping a customer with some Postini troubleshooting.

The well-accepted approach for mailing list management in Postini is to add mailing list email address as an alias under some account in (i.e. This is correct for both manual management and mailing list syncing via Google Apps Directory Sync for Email Security.

This approach works well, until you want to know which mailing lists are in use and which aren't. Since all of the mailing lists are under the same account in Postini ( simple use of "Reporting" tab in Postini Console won't reveal the required information.

However, I was able to find a simple workaround which will give you a list of mailing list addresses which were actually and validly used during last 30 days (i.e. received valid email from external recipient).

This is the process:
  1. Select you Postini Account Organization (let's say "CompanyX Account")
  2. Select Log Search and fill it according to this:

Clicking "Export All" will generate a CSV file (it can be quite large, mine was 9MB).

Use your spreadsheet of choice to open the file (I used Google Spreadsheet, but you can do it with Microsoft Excel as well). The export file contains a lot of columns, but we'll need only some of them. Here is the list of the columns we are going to use:

'Direction' | 'To' | 'Disposition' | 'Disposition Filter' | 'Primary Address'

Now, we'll need to filter out some rows to get a list of only valid emails (i.e. not spam messages). Set your filters this way:

Direction = Inbound Only
Disposition Filter != "Blatant Spam Blocking" & Disposition Filter != "Virus Filtering"
Primary Address ==

The last action should be getting rid of duplicate rows (i.e. mailing lists which received an email more than once for last 30 days). Both Microsoft Excel and Google Spreadsheet provide an easy way to do it.

The resulting list is only externally used & valid mailing list addresses. All the rest isn't used anymore and you can act accordingly. 

The last thing - what to know how many aliases (i.e. mailing lists) you have under your Postini account?

Here is the simple batch command to use:

listusers ALL,, targetOrg=100046262, childorgs=1, aliases=1

The "TargetOrg" is the Postini Account Organization ID. The return values are a comma separated list of aliases for
AuthorVadim Solovey
Categoriespostini, tips

By default, the Gmail user interface (including Google Apps Business) contains rotating advertisement called “Web Clips”. Web Clips pulls the information from RSS feed and many end-users may consider it as advertisement.

This is how Web Clips looks like:

While it's possible to disable Web Clips, it being done on per user basis, meaning you (or the end-user himself) need to login as a user and disable Web Clips via Settings/Web Clips page. Off course, you can send email to all your users with instructions how to disable it, but I don't like it too much.

The other solution can be to utilize Email Settings API. It will require some basic programming skills, but at least it will automate the task and eliminate the need to login as a end-user.

However, there is a much simpler way to do the job. You will need to contact Google Support and request disabling Web Clips for your entire domain. You only have to do that before you actually creates any users, as it won't affect existing users in your Google Apps domain.

So, while it's probably won't help you with your existing domains, you can include this step in your domain provisioning flow (as I did to mine) and get rid of Web Clips once and for all.
AuthorVadim Solovey
4 CommentsPost a comment

Maybe, when reading Postini documentation you've come across something called "wide_account" flag. However, it's hidden so deep in the documentation hierarchy that most of the people never see it, unless they are specifically digging for it.

Or, maybe, you're syncing your LDAP with Postini and receiving "Differing mail hosts" and you're trying to solve the problem. The other error you're receiving might be "Error 451 Recipients not all at same mail host - psmtp". This way or the other, it might be a good time to learn what is "Wide_Account" flag, when (and how) it should be used?

Well, in some scenarios, you Postini account can (or should) look like this:
  • Email Config 1 (London)
    • London Users Org
  • Email Config 2 (New York)
    • New York Users Org
  • Email Config 3 (Singapore)
    • Singapore Users Org
What is special in this configuration is that users from the same email domain are distributed over multiple email configs. When this kind of configuration can be applicable? Well, in many scenarios, really. 

Imagine, that you are running Microsoft Exchange environment for multi-national company. You have several Microsoft Exchange servers running, let's say, in London, New-York and  Singapore. However, all email addresses are unified to the same email domain ( in our example).

So, you've setup the above structure in your Postini account. Now, you need to add users, right? You can do it either via Google Apps Sync for Email Security (look for my post on tips-and-tricks for GADS) or via simple Postini batch command from CSV file.

Either way, you're going to receive "Differing mail hosts" error when trying to add users with the same email domain to any additional email config to the first one (usually the default email config org). This is happening due to some nuances of how Postini's Delivery Manager works and it's beyond the scope of this article (I'll write a separate post on logic of Delivery Manager as it also hides many pitfalls and gems as well).

To get rid of the error (and to allow the distribution of users across multiple email configs), you'll need to contact Postini support and ask them to "enable Wide Account flag" for your organization. It almost sounds as a secret code, isn't it? ;)

It takes seconds after support will provision the flag for you and - 'voilà', - your configurations starts to work just as you expected. 

However, there is one thing you should be aware of: your backend configuration must allow internal routing between your email servers. 

This is because if a single email will be sent from outside to both and (while those users belong to different email configs) and the Email Config 1 (London) will be unable to deliver the email to you're going to experience another kind of error "Recipients not all at same mail host - psmtp", - but this is a good reason for another post ;)

Reference information for this post can be found here. Thanks to FrankM for pointing me out to this.
AuthorVadim Solovey
Categoriespostini, tips
2 CommentsPost a comment
Sometimes, it's not obvious that setting a filter can include a logical expression (or boolean operator, in other words) more than one value in each of the fields, like "From:", "To:", "Has the words:" or "Doesn't have:"

For example, if you want to check whether specific email is designated to either one of two email addresses (or nicknames) you own, you can put in "To:" field something like: OR

So, what if you'd like to create a filter which stars all emails sent to you directly (in to: field) but not when you're in cc: or bcc:?

In that case, your filter will look like this:

In "To:" field put "to:me" and set "doesn't have" field to "cc:me OR bcc:me". In addition to "OR" you can also use operator "AND" and operator "NOT" (which you can also reference to as "-", i.e. minus).

See Google's guide for Boolean operators in searches and filters here.

As a reminded what each boolean operator do, you can use the famous Venn diagram:

Do you know additional useful logical expressions which can be used in search and filters for Gmail? You're welcome to share it here..
AuthorVadim Solovey

If you ever tried to install Google Message Continuity (following as GMC) in Microsoft Exchange 2010 environment, you would notice that there are no clear instructions on how to configure permissions for GMC's account to access your user's mailboxes.

The Installation Guide tells something extremely general (as I think they mostly tested GMC with Exchange 2003/2007). This is what the installation guide tells:

Give Exchange administrative role permissions (including 'Receive As') to that Windows account ( This account must have both read and write privileges on all accounts to be synched.

Given the fact that permission module was completely redesigned with Exchange 2010, the above isn't enough at all to complete the GMC setup.

After investigating and many trial-and-errors I did earlier this week, I was able to successfully setup GMC in Exchange 2010 environment.

Here is the step-by-step instructions how to setup permissions on Exchange 2010 server:

Remark: All of my examples are referencing to user account for GMC Server as "GMCAdmin"

Configure Microsoft Exchange 2010 permissions for the Windows account

Open the Microsoft Exchange Management Shell.
  • Type: Get-MailboxDatabase | Add-ADPermission -User "GMCAdmin" -AccessRights ExtendedRight -ExtendedRights Receive-As, ms-Exch-Store-Admin
  • Type: Add-RoleGroupMember "View-Only Organization Management" -Member "GMCAdmin"
  • Type: Add-ADPermission -InheritedObjectType User -InheritanceType Descendents -ExtendedRights Send-As -User "GMCAdmin" -Identity "OU=<organizational_unit>,DC=<domain_1>"
Increase the maximum number of connections to the Address Book in Microsoft Exchange 2010
By default, Microsoft® Exchange 2010 limits the maximum number of connections from the to the Address Book service to 50. To permit the GMC Server to run, you must increase the number of permitted connections to a larger value

On the computer that hosts the Microsoft Exchange CAS server, in

 <drive>:\Program Files\Microsoft\Exchange Server\V14\Bin
  • Using a text editor, open file
  • Change the value of the MaxSessionsPerUser key to 10000
  • Save and close the file
  • Restart the Address Book service
Turn off client throttling in Microsoft Exchange 2010

By default, Microsoft Exchange 2010 uses client throttling policies to track the bandwidth that each Microsoft Exchange user consumes and enforce bandwidth limits as necessary. The policies affect the performance of the GMC Server, so you should turn off client throttling for the "GMCAdmin" account that has a Microsoft Exchange mailbox.

On a computer that hosts the Microsoft Exchange Management Shell, open the Microsoft Exchange Management Shell.
  • Type New-ThrottlingPolicy GMCPolicy
  • Type the following command: Set-ThrottlingPolicy GMCPolicy -RCAMaxConcurrency $null -RCAPercentTimeInAD $null -RCAPercentTimeInCAS $null -RCAPercentTimeInMailboxRPC $null -EWSMaxConcurrency $null -EWSPercentTimeInAD $null -EWSPercentTimeInCAS $null -EWSPercentTimeInMailboxRPC $null -EWSMaxSubscriptions $null -EWSFastSearchTimeoutInSeconds $null -EWSFindCountLimit $null
  • Type Set-Mailbox "GMCAdmin" -ThrottlingPolicy GMCPolicy
When you're done, make sure you have configured the GMC service to run with "GMCAdmin" account and being logged-in to the server which runs this service as "GMCAdmin" as well.
AuthorVadim Solovey

If you ever asked yourself how to setup Google Message Continuity (following as 'GMC') in a multi-domain environment, I am sure you were scratching your head (like I did) looking into installation guide and asking yourself - 'hmm, how do I do that?'.

Unfortunately, the documentation is silent on this matter and when I was trying to discuss this issue with the support, I was advised to setup 4 different GMC servers. Since this sounded as serious overhead for my needs, I decided to look into it and try to find more convenient path.

Let's suppose you have the following situation (like I did):

  • 4 email domains (,, and
  • User's accounts with multiple primary email addresses (i.e. some have their primary email set to and others as user@domain2 or user@domain3 etc)
  • Single Microsoft Exchange 2003-2010 organization with several mailbox servers 
  • Google Message Security (Postini) as your mail gateway (GMC's prerequisite)
  • Google Apps domain (another GMC's prerequisite)
First question you'll ask yourself, is what domain name you should use for Google Apps. From what I found, it doesn't really matters.. I chose the domain which had the most users set as primary email address but in reality it not that matters.

After your Google Apps domain will be provisioned by Google (the registration process for GMC require you to sign-up for Google Apps Standard domain and afterwords Google will 'upgrade' your account to have necessary features for GMC) you'll need to add additional domains to it.

Login to your Google Apps account via (replace to your real domain name which you have used to sign-up for Google Apps).

Go to 'Domain Settings', then 'Domain Names' and click on 'Add a domain or a domain alias'. Make sure you chose 'Add another domain' (and not 'Add a domain alias') and put your additional domains name (one-by-one).

You'll need to verify these domains using various methods Google offers. After successful verification you will be able to provision your users in Google Apps.

Usually, I am using GADS (Google Apps Directory Sync) which I did in this case as well. The result of this will be user accounts created in Google Apps according to their primary email address (such as,, etc). It's important not to forget to sync also user's aliases (proxyAddresses attribute in Active Directory) so you users will have all their aliases available in Google Apps as well.

Another catch is that GMC is only capable to work with a one Exchange Server. In my case, I had a single Microsoft Exchange 2010 organization with multiple mailbox servers within it. I found that if I configure GMC Server to work with one of them (doesn't really matter which one) it will be able successfully open mailboxes on other Exchange servers and retrieve the necessary data from there. 

If your Microsoft Exchange environment consists of more than one organization, I guess you're out of luck and then the only workaround is to really install several instances of GMC Server. One more option which you can research is to use Application Virtualization. While I never tried it myself with GMC, tools such as VMware ThinApp or Spoon Studio should be able to package GMC Server and allow several instances to run on the same physical (or virtual) machine.
AuthorVadim Solovey