Geek Out on the Best Practices of a Google Apps Deployment


Uploaded by GoogleApps on 02.06.2010

Transcript:

JAMES HILLIARD: Hello, everyone.
Welcome to today's webcast. This is Geek out on the best
practices of a Google Apps deployment.
Carl, we're getting started right now.
Appreciate you.
Phil.
We've got Lorca, Bobby, Brian, Dave, and many others already
dropping questions in to us.
What we do have a planned today is trying to address as
many of those questions as we can.
My name's James Hilliard.
Happy to be on board as the moderator for today's event.
This webcast obviously being brought to you by Google.
We've got a full table here with us to chat today.
Want to introduce our team.
Serena Satyasai's on board.
She's a product marketing manager with Google, and joins
us again on one of our webcasts.
And Serena, thanks for being here.
SERENA SATYASAI: Thanks.
It's always a pleasure.
JAMES HILLIARD: We have three of Google's Apps deployment
specialists listed.
Two of them have made it.
Jim Copeland couldn't be here today.
Traveling abroad.
But Dan Kennedy and Marcello Pederson are on board with us.
So to Dan and Marcello, I say, guys, thanks for taking the
time and joining us today.
DAN KENNEDY: Thanks, James.
Good to be here.
JAMES HILLIARD: A couple of the things we're going to
address, I'll go through that really quickly.
And then we'll actually get into our content, a couple of
poll questions, and then dive into what we've
got planned for today.
But really what we want to talk about, we had mentioned
in some of the promo material the idea of a Big Bang.
So we're going to tell you what's included, what's not
included, in a Big Bang.
We're going to talk about some of the migration tools and
services available to you all.
And then also talk about how you can customize your org's
deployment of Google Apps.
I've already seen a bunch of questions in the queue getting
to that point.
So we will be addressing those, and hopefully a lot
more, in today's presentation.
First piece of interactivity today is checking in with a
poll question.
And this gives us a little feedback here in terms of your
awareness level of Google Apps.
This time, we put right at the top that maybe you are already
a Google Apps customer.
Then, following in order, maybe you're not familiar,
you're somewhat familiar, you're currently doing some
type of evaluation for a near-term need that your org
has, or you might be considering Apps as part of a
longer-term strategy.
We see via our attendee list a good amount of customers that
we're familiar with that are looking at Google right now.
So welcome to you as well, being on board today.
Questions and comments, you can go ahead and drop those in
the lower portion of the player.
And just make sure you click the Submit button there so we
can get you queued up, and, again, answer as many
questions as we can.
Dan and Marcello are going to be keeping a drifting eye on
the questions as they come in.
So we'll try and mix some of those in during the
presentation as we go forward.
Also, we'll have, hopefully, a good 10, 15 minutes or so for
some Q&A at the tail end of the presentation.
With that, the results of the poll question.
Thank you all for voting on that.
28% of you, just by a slim margin, get the single highest
vote there, that you're already
a Google Apps customer.
Putting together those that are evaluating right now, I've
got close to 50% of you either for a near-term
or longer-term strategy.
Because we have so many people pretty familiar with what's
going on with Google Apps, as I turn it to Serena, we're
going to do just a brief overview, try and get you 11%
or so quickly up to speed on what the offerings are.
And then, for all the rest of you that are customers or are
familiar, again, most of the time here spent talking in a
little more detail talking about a Google Apps
deployment, what it can mean for you, et cetera.
So with that, submit those questions and comments.
Serena, I turn it over to you for that quick overview.
SERENA SATYASAI: Great.
Thanks, James.
Just for the folks who don't have a whole lot of
familiarity with Google Apps, couple things you should know
is that we're part of a enterprise division--
Dan, Marcello, and I--
that are committed to providing solutions for IT,
for enterprises, and schools, and organizations.
In addition to Google Apps, our division provides the
Google Search Appliance, for example, if you want to use
google.com's search algorithms behind your firewall to find
information, to help your employees find information
across multiple content repositories.
We also offer enterprise versions of our Google Maps
and Earth products.
And we find that a lot of government agencies, in
particular, use Google Earth to map out government
information services.
And if people are interested in that, you can take a look
online at a Google case study called Virtual Alabama, where
the state of Alabama basically mapped out a lot of really
great county-level and city-level information.
And many people use Google Maps to do things like fleet
tracking or other types of asset tracking.
Of course, if you're a real estate company, et cetera,
many people use Google Maps integrated to help them show
their listings to consumers.
And finally, Postini services are part of the Google Apps
suite of products, and are essentially Google Message
Security and an archiving and discovery solution, also
offered in the cloud, just like Google Apps.

Google Apps Premier Edition is really many different
applications.
It includes a suite of messaging applications and a
suite of collaboration applications.
I think one thing to note is that Gmail is essentially the
flagship application.
And it has built-in spam protection as well as a
25-gigabyte inbox for storage.
We also provide the ability to integrate shared calendars, if
you will, and integrated instant
messaging via your browser.
So if you want to do voice or video chat or plain text chat,
you can using your corporate domain identity.
Our second suite of applications really fall under
collaboration.
And they include Google Sites, and Google Docs, and Google
Video for business.
Most of our customers are really deploying Google Apps
in terms of messaging, first and foremost, and are building
their business cases off of messaging.
And then what they find is the collaboration apps are what
get their employees excited long-term.
And Dan and Marcello will talk a little bit more about that.
All of these applications are provided in the cloud.
And they are based upon our 24/7, 365 customer support,
99.9% uptime SLA, the ability for you to access the
information from anywhere.
Whether you have a smartphone, or your desktop, or your
computer from home, all you really need is an internet
connection and computer to access your Google Apps.
And for Google Apps Premiere Edition, of course, if people
are familiar with Gmail on a consumer basis, you can turn
off the ads.
This is just a summary, a quick summary, of what's in
Google Apps Premier Edition.
I encourage you to go visit the website for more
information.
That's listed below.
The price is a little over $4 per user, per month.
And that annualizes to $50 per user, per month.
And you can buy one seat, 1,000 seats, or 100,000 seats.
There's no minimum.
I did mention our Postini services.
I'm not going to talk a lot about them here.
But you can purchase these standalone.
Or, Google Message Security is included in Google Apps.
And that provides an additional layer of spam and
virus protection, as well
content-monitoring and filtering.
And with that, I'm going to hand it over to Marcello.
MARCELLO PEDERSON: Thanks, Serena.
Good morning, evening, and afternoon, for
everybody out there.
Our first slide that we're going to be talking about here
before we go into the technical details of the
presentation--
what we like to call the geek-out part, which is the
fun part for us--
we're going to give you a high-level overview of what a
Google Apps project plan usually looks like.
There are four phases to it, what we call plan, pilot,
plan, deploy.
What most companies go through is a planning phase where they
try to decide how long do they want to pilot Google Apps to
see if it's a fit for the organization?
They define some success criteria on what makes Google
Apps successful, to see if they want to go forward with
Google Apps.
And also they decide who is going to be in this pilot?
Usually, it's an IT group, with some key individuals from
your business folks.
So after that planning, we move into a pilot phase where
we have what we like to call at Google the
Alpha Wave of users.
They start using our products.
They start using Gmail, Google Talk, Google Calendar.

The IT team's goal during this phase is to track any problems
that you have during the pilot, see if there's any gaps
that you have to resolve before your deployment, and
also get some success stories.
This starts helping you build awareness of Google Apps, and
also help marketing this to some folks.
And I'm sure there'll be some talk in the halls of your
organization saying that we're trying Google Apps, and that's
a cool thing.
And this is the first time that IT goes out there and
talks about Google Apps.
Of course, here, very important for you to support
the users in the pilot.
You don't want to let them be out there by themselves with
no support.
But after this phase is done, and we move to the second
planning phase, you have some lessons learned from your
Alpha Wave. You try to understand, do you have to
change anything on your technical approach?
Do you have to create some more training material?
You should get some feedback from your users.
How difficult was them to get from whatever assistance they
have today to Google Apps?
How fast did they become productive on Google Apps?
Do they need more help?
Do they need less help?
This is where you try to identify those areas is doing
this planning phase.
And then, once you have this planning
phase done, it's showtime.
It's getting all your users on the system.
And it's start thinking about, how do we decommission the old
legacy system so we can start saving some money and we can
start enjoying Google Apps?
So for our presentation today, our focus is really on the
last two boxes here, the planning and the deployment,
because we think that a lot of you guys
out there are already--
you already think Google Apps is a fit for you.
So we're really talking about the last piece of planning and
deployment.
So for somebody like Carl out there in the audience who just
said that he's planning on deployment tomorrow evening,
this is very timely for you.
So with that, let's move on to the next slide, which is
actually called focus, because the most important thing that
we find is to determine what is your core focus for your
deployment?
What are you going to deploy to your users?
And what are you going to spend the majority of your
time with training, support, writing technical material,
deploying technical solutions.
And from the feedback that we hear a lot from our customers
here is that messaging, our messaging suite of products--
which is Gmail, Talk, and Calendar--
are usually the core focus of every deployment.
And the reasons are, it is probably the most disruptive
piece to your organization, because you are usually
changing your existing users from their legacy system to
this new system.
You require some training, because this is, again, your
users are so used to doing something already that they're
going into this new environment.
And this is true for every IT project where you spend more
time making sure that they're comfortable with the new
system, that they are given all the
training that they need.
Now, we also have our collaboration suite of
products, which is Docs, Sites, and Video.
We hear a lot from our customers that they do what's
called a soft launch, where they allow their users to
start using this, so there's some organic
growth of Google Apps.
Their users have access to it.
Usually, there's minimum support from the Help Desk.
But this is not actively marketed to your organization
as something that you're focusing on.
Once your users are up to speed, they can be productive
on email and Talk and Calendar.
Then we think it's good to introduce the other suite of
products, and start marketing around that.
And that keeps your users always interested in what's
coming next.
And I think that's always a win for IT.
So with that, we're going to move on to our next slide,
which is the timeline considerations.
So how fast do we deploy Google Apps?
You buy Google Apps.
You're paying $50 per user.
I'm sure you want to start getting your users using it as
soon as possible so you can start thinking about, when do
I decommission my old system?
And how fast can I get this moving?
We've heard that there are few drivers around this.
Some of them come from the business.
You're trying to save money.
Some of them are some technical drivers.
You may have some other projects
going at the same time.

You're trying to do a directory consolidation, for
example, that you may be dependent on Google Apps.
Or for example, there's a critical
system that's in place.
So you want to make sure that's well integrated before
you launch Google Apps.
And then the last piece here in the technical driver is the
coexistence investment.
Do you have to keep Google Apps and another system live
at the same time?
Do your users need to live on their legacy system doing
email, emailing each other from between Google Apps and
your legacy system?
Do they need to have counter-interop where they're
sending meetings to each other?
So there's a certain amount of investment that goes in here
to make sure that that's also working very well, so your
users have a good experience.
Now, from the business side, you may have some licensing
agreements that are coming due.
And you have a big bill coming that you want to try to avoid.

There's some other considerations here on how
fast you can go.
For example, a lot of companies we work with don't
do a lot of disruptive changes during their end-of-the-year
holidays, or maybe end of the fiscal year, for some of you
guys out there.
And the other part here is, perhaps the business has asked
IT for a new solution for collaboration, or a new
solution for mail, or your email system is dying, and you
need to get it replaced.
So you have some goals, as your IT organization, to get
Google Apps in place as soon as possible.
So that's another usual driver that we hear very often during
our deployments.
And with that in mind, I'm going to pass it on to Dan
Kennedy, who is going to be talking about one of the
approaches to deployment.
DAN KENNEDY: Hello.
Good morning, everyone.
Thanks for joining.
Glad to have everyone with us.
So one of the things that we talk about with all of the
customers that we're dealing with is, what's the best way?
Once you've decided, hey, you know what?
We are going to move to Google Apps in our infrastructure,
we're going to decommission our legacy infrastructure, or
at least pieces of it, and you're committed to that,
what's the best way?
And we've got several questions in the queue today
about what's the best way to roll this out.
And so here at Google, we've decided upon this term that we
call Big Bang and the Big Bang deployment.
And there's a little bit of confusion.
I think everybody out there in the IT world has done this
idea of a Big Bang migration.
And it probably conjures up a lot of different images of
what that really means.
So we've tried to narrow it down in terms of a definition.
And really, what we're getting across here is, in that plan,
pilot, plan, deploy concept, we're looking at it in the
last pieces.
And by no means are we advocating that, hey, you sign
your Google Apps contract, and in two weeks you're deploying
your last Google Apps user.
We know that's not really a relevant idea.
And that's certainly not something that we're going to
try to force on our users and our customers.
So really in those last two segments, that plan and deploy
segment, once you've made the commitment, and you've got
your IT resources all lined up, what we're telling people
is that, the faster we can start to take that general
office user case-- not your Google guides, not the
advocates, not the early Alpha Wave adopters--
once we start moving the generic, everyday users, we
try to do that as quickly as possible with a concentrated
effort around the long-term pieces, the things that are
going to really make our deployment successful:
training, support, communications.
And this gives us a lot of benefits.
And of course, we have a few watch points
inside of that as well.
And really, what this allows us to do from the IT
perspective is it gives our IT groups the ability to focus on
what they're going to be doing for the long haul, and all the
things that are really going to matter in the long-term:
having the best Sites collaboration, having all the
pieces of Gmail to focus on, the best possible training so
that the end-user--
which is really what's going to make or break your
migration, what's going to make everything look either
successful or look like there were too many challenges
through it-- how transparent the move is for the end-user.
And that's what this approach really allows us to do.
What our customers have told us throughout, with each
large-scale deployment that we've done, is that the best
thing that they decided to do was to really concentrate the
investment and the focus of all the groups involved,
especially IT, and really be concentrated on getting
everyone from the beginning point to the end point in a
relatively short period of time.
Some of the watch points that we've seen with this kind of
rollout when you're doing things so concentrated: change
management policies, and understanding everything
around those; requiring planning and good
communication strategy; having templates; knowing exactly
when I'm going to send out which communication, to who is
it going to go, and understanding all the pieces
around that; and then data migration.
And this is a piece I think everybody--
we've also seen some questions come in on this.
And having a very thought out and thoroughly explained
strategy to the users.
So they know when things are going to be available, how
much of it's going to be available, and if there's
going to be any times where, hey, I may need to go to an
older system to access some archives, or
something like that.
And we're going to be going through some data migration
pieces here and talking about what other customers have done
and some of the options.
One thing we like to do here at Google is, of course, give
our customers lots of options in terms of what they can do.
And this slide that's coming up in a few minutes on data
migration will show that you have a lot of different
choices when dealing with how much data, when to do the
data, and things like that.
All right.
So moving on, we're going to go in and we're going to get
down to some of the more technical pieces here.
And small, quick overview on some of the slides that are
coming up, just so everyone--
And I know people have been emailing on each of these
topics, lots of mobile questions, lots of user
provisioning questions that have come up.
So user provisioning and the way that we integrate with our
LDAP, we need to, of course, make sure that account
creation is as simple as possible.
We need to identify where our source of truth directory is
going to come from.
And how do we make it so that you're not maintaining just
another system, another application
inside the cloud now?
And how do we integrate with what you already have?
Your mail flow architecture.
One thing that we like to make sure that all of our customers
are aware of is that your mail flow architecture, when you do
something like this, is going to change.
No longer is your MX record going to point at your
gateway, which will then route in to your spam filtering
solution, which will then go to your document management
system, which will then go into your On-Prem mail system,
or something like that.
We're going to have some routing changes.
And we're going to talk about some of those and what we feel
the best strategies around those.
Mobile.
We definitely have support for the most popular mobile
platforms out there.
So we want to get into talking a little bit about those.
And then your single sign-on and password sync and
authentication strategies, of course.
How are users going to get into the system?
What makes it secure?
Things like that.
So we're going to talk a little bit about that.
Inside your existing environment, we're also going
to talk a little bit about coexistence
and what do we recommend.
What have we seen successful at other customers when it
comes to keeping the systems intact, having some people in
Gmail and others in your current system?
How does that work?
And what are the caveats around some of the setups?
Migration tools and how they're installed.
And really, anything from Google that needs to get
installed throughout the environment, of course.
It's a cloud computing platform.
We try to keep everything inside the cloud.
However, there may be times where, whether it's a
migration tool or another tool that you've decided to deploy
because it helps your end-users, circumstances
around your software delivery mechanism and the impact those
tools will have.
Then, of course, network consideration.
You're moving to the cloud.
We have some situations where your proxy, your firewall, and
these kind of things may need to have some small
modifications, or what we will need to have accessible via
your network at all times for all of your users.
All right.
So with that, first off, we're going to talk about Google
Apps Directory Sync and how it works.
And I saw a question from Colin that had come in earlier
talking about, how do we provision users?
Is this a system where now I'm just managing another
application with another set of maintenance and
administration for user provisioning, and group
provisioning, and contact provisioning?
And the answer to that is no.
And the reason for that is an application that Google
provides free of charge, called Google Apps Directory
Sync, aka GADS.
And what this does is it does a query of your LDAP server
for whatever type of objects.
And these are all very, very, very configurable in terms of,
I only want to provision users or groups or contacts or all
these different things.
Goes out to Google, identifies what Google has in its system,
does a comparative check against the two lists, and
then updates Google based on your LDAP system.
So a couple of things to think about here.
It is fully configurable for different and custom field
names, different OUs.
So if you only want to sync from one OU because only part
of your businesses is using Google Apps at some point,
maybe in a pilot or something like that, absolutely
configurable.
Your LDAP system is never altered.
We never write to your LDAP system.
We only read.
And we make updates on the Google side.
As you see here in our diagram, it is always done in
a secure manner, over a secure connection with HTTPS.
So we don't have the issue of a man-in-the-middle attack or
something like that.
So it's always done securely.
We have the ability to run multiple syncs.
So if you are unable to figure out a way, or you have
multiple apps instances, or something like that, we can
actually do multiple syncs with the application.
And this really works great when you have a termination
process or a new hire process and bringing people on board
or off-boarding people, and trying to figure out the best
way to automate the processes of a new hire or a
termination, which I think all of us have gone through at
some point with every system.
We have the ability to do exclusions and do very, very
complex rules based on different types of regex
expressions, LDAP filters.
So we have quite a few pieces of our Directory Sync
application that allow you to customize it.
So with that, we're going to move on.
But I do want to just specify that this Google Apps
Directory Sync is a very, very flexible, very log-oriented,
detailed application that can let you get pretty much
anything from your existing LDAP system into Google Apps
in a very, very quick manner.
It can be automated via Batch and via Cron and things like
that so that it really takes the stress out of having to do
user maintenance and user
administration on a daily basis.
JAMES HILLIARD: Just a reminder to our audience that
Dan Kennedy and Marcello Pederson are with us today.
Jim Copeland couldn't make it.
But we're talking with these guys.
We've had some more folks join us since the beginning of the
presentation.
We're about halfway through.
We have well over, I think it was over 150 questions or so
that have already come in.
So folks, just a reminder at this point, we're not going to
get to all of them today.
But what we will do is forward them on to the Google team, so
we can continue to not only address questions on the event
but follow up with you after this webcast as well.
So just wanted to throw that in there.
That should not keep you from submitting more
questions and comments.
We can keep these folks busy after this webcast is done.
So keep doing that.
And with that, I believe I'm probably throwing it back to
you, Marcello.
And we'll move forward.
DAN KENNEDY: Actually, I'm going to keep going.
JAMES HILLIARD: OK.
[UNINTELLIGIBLE]
DAN KENNEDY: I've got one or two more.
JAMES HILLIARD: Cool.
DAN KENNEDY: Thanks, James.
So moving on, guys.
We're moving on to another one of the technical topics that
we had discussed, and that is mail flow.
So inside the Google Apps Enterprise suite of products,
we also have the Postini system, which we call Google
Message Security.
So Google Message Security plays a vital role in all of
our recommended deployments.
And what we always recommend to customers, what our
customers have told us has always been successful with
that, is using this Google Message Security to help
facilitate mail flow.
One of the great ways that the Google Message Security helps
us is with this very, very simple diagram.
I think we all know, when it comes to MX records, we're
kind of at the mercy of we tell things where to go, and
that's what we get.
And that's really all we have. And then it becomes lots of
little trickery in forwarding and rules and things like that
to get mail to route to different places
if we need it to.
So what Google Message Security, formerly Postini,
can help us do is set up a very, very simple split
delivery setup where mail, inbound mail, flows into the
system, and then, based on simple routing rules-- which
are a one-time setup, and very, very easy to do--
they can flow mail to whatever system we need it to, whether
it be Google, whether it be to your mail
gateway, or anywhere else.
This is something that we recommend doing very, very
early in the migration process.
It helps facilitate the pilot, the alpha wave, moving users
over days instead of all in one fell swoop.
So that's something that we always try to get customers to
understand very early on in the process, and understand
how it can help the deployment.
Also in Google Message Security is where you'll
handle spam and virus settings for your domain.
There's tons and tons of granular settings, whether it
be on a per user, or per group, or any other type of
administrative gathering, grouping.

So one thing also that this helps us is that this allows
us, if there was an issue ever experienced with flowing mail
into Google and something was not working exactly as we need
it to, that, on a per-user basis, we can actually back
out single users at a time or multiple users at a time to
start routing their mail back to the legacy mail system,
which as, I think, everyone in IT understands, is a very,
very, very important role in any big deployment, being able
to take a user, or a group of users, for some unforeseen
circumstances, which we, of course, hope
will never come through.
Also in the Google Message Security product line is the
Google Message Discovery, which is
our e-discovery platform.
So if you decide to go with the e-discovery platform,
which is perfect for all those litigation circumstances and
the immutable storage of all of your messages, this is
where that would also happen.
So this system would be required in that scenario.
All right.
So moving on from mail flow, we're going to hit the next
slide which is talking about Mobile.
And of course, especially when it comes to executives and
your quote, unquote "VIP users," the Mobile platform is
very, very important.
And what we've done at Google is we've built in support
inside of Google Apps for all of the main messaging
platforms out there.
So the first one that we want to talk about is Google Sync
for BlackBerry Enterprise Server.
So what Google has done is created a plug-in that lives
on the standard BlackBerry Enterprise Server, and allows
you to get the native BlackBerry experience with a
Gmail backend.
So your users are not interrupted in what they're
used to from a user interface standpoint, from a
productivity standpoint.
And inside of the IT world, it gives us the flexibility of
all the things that BlackBerry Enterprise Server has
always given us.
So security policies, all the pieces that were there before
are still there.
We also support ActiveSync.
So things like iPhones and some of the other phones that
support ActiveSync, we have several security policies that
are now built into Google Apps around lockout of the device
and things like that, password complexity.
And those type of things are now supported natively inside
of Google Apps that an administrator can manage.
And of course, what Google always tell you is that the
wave of mobile computing in the future is going to be the
Android product.
So we have native support for Android.
And if anyone has used Android on Google Apps, you know that
it's a very, very simple two-step process that you put
in your user name and account, your password, and we
automatically sync all of your contacts, your calendar, your
email, and it is a very, very seamless setup.
So that's the Mobile piece of things.
And I know we have some questions that I'm going to
tackle later on Mobile.
But right now, I'm going to throw it back to Marcello,
who's going to take us through the next few slides.
MARCELLO PEDERSON: Yeah, thanks, Dan.
We have a lot of questions coming up.
So I'm going to try to move this along quickly so we can
get some of those questions and answers for you guys.
My next slide that I'll be talking about here is the
infrastructure integration of Google Apps.
Coming from the IT background before working on Google Apps,
I've dealt with a lot of proxy, firewalls, and imports,
and all that stuff that all of us have spent probably many
Friday nights trying to figure out why
something was not working.
I can guarantee to you that Google Apps is probably one of
the easiest things to configure in your environment,
from a proxy standpoint.
As long as your proxy allows the user's browser to connect
to the Google URLs over HTTPS, you don't have to configure
anything else.

In the Google control panel, you have the option to turn on
HTTPS or just leave it as HTTP.
Most of our customers use HTTPS.
So it's a secure connection.
And we support your proxy.
And most of our applications, like Dan talked before, our
Directory Sync tool also supports proxy configuration.
So from a proxy standpoint, it's fairly simple.
From a firewall standpoint, it's even easier, because you
only have to worry about one port.
And that's, again, port 443 for HTTPS traffic, if you're
doing HTTPS, which we strongly recommend.
Even for all of our suite of applications, including Gmail,
Calendar, Google Talk, all of our APIs, our Directory Sync
tool, they all use encrypted traffic on port 443.
And as long as your firewall allows that-- which we usually
don't have problems with companies that don't allow
that type of traffic--
you usually don't have a problem.
So if you worked on a Voice over IP project in the past,
or any project that required hundreds of ports and very
complex firewall configurations, Google Apps
will be very easy for you.
And the final piece is something that's actually very
important-- and I think it's very important for every
enterprise, regardless if they're using
Google Apps or not--
is SPF records.
SPF records, for you guys that don't know, is when you
actually specify which email hosts are allowed to email on
your behalf.
So for example, you only allow your own email servers in
Google Apps to email on your behalf.
So what this does, it actually helps reduce spam detection.
And it helps us insure that who's sending that message
from your domain is really on your domain, is really
approved by you, by IT, to send this.
This is configured with your DNS provider.
And just like everything that we have in this presentation,
we have a lot of documentation on our help site that we're
going to be talking a little about later.
But these are the usual infrastructure integration
points from a network security and network access standpoint.
So with that in mind, we're going to move to the next
slide, which is the other piece of infrastructure
integration, which is usually large customers that we're
working with, they use single sign-on.
Single sign-on is as a way of you controlling the sign-on on
experience for your users.
We had a few questions on this during, I can see in the Q&A.
For example, we had somebody ask, how can I make sure that
my users change passwords every 60 to 90 days?
Or how can I control who uses the system?
You can either use our native authentication mechanism,
where you have your users log in directly to Google.
Or you can use single sign-on.
What single sign-on does, it gives you a way to manage the
user identities in a single store.
So if we look at this diagram here, and we're going to
quickly go left to right, your users using their iPhones in
any Google plug-in or the browser, they're going to
Google Apps, and Google Apps is connecting to your single
sign-on system for authentication.
Your single sign-on system would then check against your
own password stored to see if that user's authenticated.
During that process, you can require the
user to reset passwords.
You can also implement password complexities.
Like one of the questions that we had in Q&A, this is where
you do this.
You have full control of your user access.
It requires you to have a single sign-on system.
We have several partners out there that do single sign-on.
A lot of companies are already investing in single sign-on
for their web-based applications, like some
internal URLs or internal domains that you may have.
And the other thing that you could also implement is a
password synchronization mechanism, so that your
company's password is also synchronized with Google, of
course, all over a secure connection.
So that for applications that do not support single sign-on,
which is a SAML protocol, your users can still access those
applications without having to remember
two different passwords.
So with that in mind, I'm going to be moving to the next
topic, which is a little bit of change here, but is data
migration, another interesting and important task on your
Google Apps deployment.
What we have found is that we want to first define a
strategy for migration.
One size doesn't fit all is what we believe in.
First, you have to understand what you want to migrate.
Some companies want to do archives, or they want to do
personal contacts.
Some companies want to [? do Calendar ?].
They wanted to do full-blown migration.
How you want to migrate it, we have tools available.
We have several partners as well that have tools available
for GroupWise, Lotus Notes, Exchange.
Do you do a server-side migration
or client-side migration?
A server-side migration is where IT
controls the entire migration.
They are the ones who go into the user's mailbox on the
servers and grab the information
and sends to Google.
Whereas a client-side migration, your users have
control to do that.
Your users installed something on their own computers, so
they have full control, when do they want to migrate, what
do they want to migrate.
And IT is not involved in that process, except for supporting
the users and usually pushing those applications.
And the last piece is who do you want to migrate?
And how do you want to migrate them?
For example, you may want to pay more special attention to
your VIP users, your executives, and migrate more
of their data or do a server-side
migration for them.
Your general office users may have a different requirement.
And your field users, maybe if they work in a factory, for
example, don't have the same amount of requirement.
The reason why we have this strategy here in place is
because migration.
Everybody out there, I'm sure, in this webinar, if you have
dealt with any sort of migration in IT, migration is
something that takes time and there is an
investment in migration.
So it's your decision how you want to migrate.
And usually that's something that you will probably spent
some time in.
So defining a good strategy going forward is very
important for the Big Bang go-live that we
like to talk about.
On the next slide here, what we have is an example of a
customer that decided to look at this, and they really said,
one size doesn't fit all.
I want to spend the majority of my time on
my executives, right?
We know the more costly and complex approach is where we
migrate everything, we do it for them, including their
archives, everything is server-side.
Whereas, for my general office users, I want to give them the
options to migrate their live mail.
I want to give them the options to
migrate their own calendars.
But they are responsible for it.
There's some costs here, but there's less complexity
because you're giving the users the option to do that.
And maybe for the deskless user, the factory worker,
you're just migrating their contacts.
A lot of them are perhaps just getting broadcast messages.
They don't check emails often.
So you don't want to invest too much of your time making
sure that they're working.
So I think the point that we have here is that one size
doesn't fit all.
And it's very good to lockdown that migration strategy early
on and stick to that migration strategy.
So I'm going to breeze through this slide right now so we
have time for questions.
This is the transition approach.
What we like to call coexistence.
What do you have in place during the pilot and during
the show time, the go-live?
There's a few considerations that you have to think about,
mail flow being one of them.
If you have to deliver your messages to Exchange first and
then to Google Apps, in case your users are still using
both systems, there are considerations that you have
to think about here.
You have to configure your existing system to do that.
We have a lot of this information on our website.
And we're going to be talking about that a little bit later.
And we also have a pilot guide that describes this
in detail as well.
We had a question about, how do we allow our uses to use
Google Apps and still work with users in Exchange?
From a Calendar perspective, we have Calendar interop tools
that you can install on your Exchange server to do
Free/Busy lookups, to look up conference room
information, et cetera.
Those tools are available, and they're free.
They're in our code website.
And again, our deployment guide talks about this.
And we also have some work necessary here for some
directory integration.
That's really, from our perspective, the way we see it
is GAL synchronization, is where you want all of your
Google Apps users to have access to all of the other
users in your organization, regardless if they're in
Google Apps or not.
And this is all usually done through our Google Apps
Directory Sync tool, where you can synchronize profiles,
which is users' rich information, like their phone
numbers and addresses.
You can synchronize other contacts, like
Help Desk and Groups.
And you can also synchronize contacts that are not a part
of your Google Apps instance yet.
So this is your transition approach.
A lot more information.
We have very good documentation on this.
But I'm going to be moving on to the next slide, that is
change management and training and communication.
We have here, we describe three phases, really, to
training and communications.
The planning aspect of training and communication,
what do you do during the deployment?
And what do you do after the deployment?
Because it's important to keep the users happy and making
sure that they're using the system and you did a good job.
So usually during the planning, we have a concept of
something called Google Guides and Early Adopter program.
And what the Google Guide and Early Adopter programs are
usually people in your organization that are
interested in Google Apps.
They are from, not only from IT, but from other areas of
the business that are interested in Google Apps, and
are willing to help you getting your users happy about
Google Apps, get them excited about Google Apps.
But also make them feel like there's somebody there for
them as well if there is an issue.
Of course, apart from this Early Adopter program, we
recommend developing a training strategy.
There are several training strategies out there.
We have documentation on our website.
We also have several partners that do things like training
the trainer, webinars to help your users get up to speed in
Google Apps as fast as they can.
And of course, there's some marketing and awareness that
you want to build.
You want some enthusiasm, and you want to make sure that
people are seeing that this is coming.
And you want to make this a positive message.
Every change in IT, it can be disruptive.
And you want to make sure that there's a positive
message around it.
During the deployment, it's communicating early, often, in
different ways.
If you don't want the users knowing that there will always
be an email coming at the exact same time every single
day, you want to keep changing a little bit so you still have
users' attention and awareness.
But at the same time, they're still engaged and you're still
giving them bite-sized chunks of tips and helping them
during a transition phase.
You want to make sure, of course, that you have support
ready for any users' questions that come in.
And of course, usually during show time, we have a command
center where not everybody from IT, but a good number of
IT and a good number of people from your project team are
involved in making sure that the questions get answered
right away, and your users are happy, and they feel that
they're in a supporting place.
And of course, after it's deployed, what I mentioned a
little bit earlier, feedback, getting
user feedback, surveys.
You can use even Google Spreadsheets and Google Forms
to do surveys with your users.
Help them with some refresher trainings.
Showcase some good examples of Google Apps.
And if there's any common questions that come up, give
them some guidance and guidance from your
organization.
How can you do this so you save some time?
So that's the training piece.
I think we are almost wrapping up.
I'm going to pass to Dan, here, who has a couple of
slides, I think, left.
So go, Dan.
DAN KENNEDY: Thanks, Marcello.
Hey, guys.
We want to get to the questions.
I wanted to put one slide in here.
We've got a very large number of questions from the user
audience today about, I run a financial company.
I'm in charge of a health care company.
I run IT for a school.
So I wanted to throw a slide in here that could speak to a
lot of those questions about--
and the question with those are, what's the best way for
me to do it?
I have 500 users.
I have 10,000 users.
So I wanted to throw a slide in here that talked a little
bit to how we did it at an actual customer.
So what I've done is I've got a high tech hardware
manufacturer.
So cutting edge technology, very, very high end, very
savvy users in some regards.
And then, in other regards, users that aren't part of the
technical community.
What their environment, they ran Exchange 2003 with
Exchange 2007.
They had begun a deployment of 2007, identified that cost was
a little bit prohibitive, identified that maybe they
weren't getting the same bang for the buck
that they were paying.
So they started evaluating Apps.
They had 15,000 users.
There were over 50 worldwide locations.
So the first thing they did was they went through a scope,
created a scope document, kind of like we talked about it.
And, if you remember the slide that Marcello displayed
earlier, it talked about, where is your core focus?
And what pieces of the applications are your core?
Gmail, Talk, Calendar.
And they had taken right from that slide and identified
those as the core pieces.
And then, what was going to also launch, but maybe they
weren't the priority for the early parts?
The Docs, Sites, Video, things like that.
So those were also, in their deployment, a soft launch part
of the deployment, where everything was available to
the users, but they weren't giving as much training.
They weren't putting as much communication around it.
So it was a softer launch that users had access to.
They could holistically start using, start getting
department-by-department velocity on
something like that.
They were going to roll out to all employees.
And they were going to deploy Postini.
And of course, this is being very
simplistic in some of this.
Because, of course, inside the scope document, there are tons
and tons of pieces of information that you want to
always be tracking.
But these were really the highlights.
These were the things we needed to accomplish
throughout the deployment process.
The pilot approach was that we had a user population of about
200 users from all over the business.
They used split delivery that I presented
earlier using Postini.
And they used a partner for
training and partner templates.
So what they had actually was they had a training partner
deployed to key locations around the globe, that they
were then able to get big batches of
users into the trainings.
They had people on site in each of their main locations
in geographic regions for a couple days, and told users,
hey, when you have your hour, you go in, and they're going
to be staggered throughout the days.
And that's how they
accomplished doing their training.
Their approach for deployment was what we talked about
earlier, was the Big Bang.
This particular company, it took about eight business days
to deploy all 15,000 users across the world in a kind of
follow-the-sun type of mentality, with conference
rooms set up for the quote, unquote "war room," where
anybody who had any issue could call into a centralized
war room that was staffed for several days, so that any of
the regional command centers, so the traditional IT staff
that would help, and who were already specially trained,
could help the users inside those regions.
But now, that local support staff had a group of Google
Apps experts waiting and available at all times to get
their questions answered.
So that was the global Big Bang.
Users were added using Google Apps Directory Sync.
And I'm going to be getting to a couple questions that have
come in on Google Apps Directory Sync that I've seen.
So if you had a question on that, hopefully I'll be
talking to some of those here coming up.
Users were allowed access to Gmail two weeks
prior to the rollout.
One of the things we've learned here is that, when
users are getting trained on an application like Gmail,
letting them have access to it early on, even before mail
starts flowing to it, especially to exercise some of
the techniques that they've learned in the training, is an
excellent idea.
So giving access to Gmail two weeks prior to the rollout was
a decision that this company made.
And it worked wonders.
Because now, when the users went into the system, it was
something they were already familiar with.
They were already playing around with some of the
settings, and looking at some of the lab features, and
things like that.
So that worked out very well.
As Marcello talked about, we have several different ways
that you can do data migration.
And what these guys decided to do was to use server-side
migration for their executives and VIPs, and client-side for
their general office users, which we've seen
over and over again.
It generally provides a very, very solid approach.
So for those of you guys who were asking questions about,
this is what my company is, this industry, with this many
users, this is a good template that you can see how a
customer has done it in the past.
And lastly, we've talk a little bit about the website
that we have. And I wanted to definitely give you guys this.
Hopefully, if we look at the analytics behind this website,
we'll be seeing a nice bump in traffic from all of you guys.
deployment.googleapps.com
I went through the site.
I've been through the site a million times.
And I went through it before this presentation, because I
wanted to have a couple things that I could just say, if
people went to this webinar and they listened to what we
have to say, and they're interested in Google Apps,
what are some of the topics that they could pull out if
they went to this website?
And I just wanted to give you guys a couple of the things
that are on this website that might help you, things like
the Enterprise Deployment Guide.
If you're looking at seriously deploying Google Apps into
your company, into your organization, I don't know if
there could be a better titled document that gives you all
the pieces of detail that you need in order to successfully
go from point A to point B and be able to turn off your
legacy mail servers, your existing infrastructure, and
fully move to Google Apps.
The Enterprise Deployment Guide is a one-stop shop.
It's an excellent document.
I highly recommend that.
We have checklists for the deployment so that you don't
overlook anything, so you don't miss anything because
you haven't done this before.
Let us help you give you, this is what
customers have done before.
All these pieces.
If you can check right down the list off on these pieces,
you're going to be successful.
Training seminars, already developed for you.
How to set up Google Guides programs. How to build
enthusiasm.
The marketing piece.
A lot of us are technical people.
We understand MX records.
We understand Directory Sync.
But we don't understand how to get people excited maybe.
So how to build a program around that.
Webcasts like this on how to do certain topics.
You want to learn more about GBES, you want to learn more
about Google Apps Sync for Microsoft Outlook.
Some of those topics already taken care for you.
Communication templates.
When to send and what to send to your end-users.
User guides.
So want to teach somebody how to give them a two-page
handout on Gmail or Calendar.
These kind of guides already developed to hand to your
end-users in very layman term.
So that, you're not talking to the most technical person?
Well, that's great.
We've already got some very simple, easy-to-follow,
picture-laden resources.
And then, of course, resources and training for your help
desk, which we're going to have questions come up, how to
specially train your help desk, how to get them going.
So please take a look at this.
I highly recommend this website.
There's a lot of different resources for you.
And with that, our pieces are done.
And I'm going to hand it back to Serena, who's just going to
take you through a few things.
And we're going to definitely jump in
to a bunch of questions.

SERENA SATYASAI: Thanks, Dan.
Just really quickly, in addition to the deployment
team specialists who have been speaking here, and obviously
who we also have working on customer deployments, we have
a large ecosystem of partners, some of whom are listed here,
that can help you with some of the activities that Dan and
Marcello just described, if you feel like you need to
augment your own internal resources.

Additionally, I've seen a lot of questions come about
customers, following up on what Dan was saying, we're a
customer of x, y, z size, we're in
such and such an industry.
One of the things that I would like to encourage everyone to
do is search out our customer webcast series.
Twice a month, we feature a customer speaker talk about
their decision to move to Google Apps as well as how
they went about the planning process and how they executed
their deployment.
So if you're a large company, 10,000 users, there are
several examples of companies who did the Big Bang migration
that Dan and Marcello just described.
For example, JohnsonDiversey had migrated, I think it was
12,000 thousand employees, from Lotus Notes Domino over a
two-day period in a follow-the-sun
mode, as Dan mentioned.
We've also had Sanmina-SCI, who migrated 15,000 employees
from Exchange 2003 talk about their deployment recently.
And Fairchild Semiconductor as well describing how they
actually used executives and admin assistants in the pilot
group, and how that helped achieve their success.
If you're an edu or a 501(c)(3) nonprofit user in
the United States, we do have Google Apps Education Edition
that is free, if you're an edu organization or a 501(c)(3) in
the United States.
And in those instances, we do have very large deployment,
because we're often talking about student bodies of
40,000, 80,000, 100,000 in size.
And there are some webcasts that describe the deployment
processes they went to.
I do see some K-12 customers online as well.
And it's a very similar process for students as well
as faculty.
One thing to note, again, just to clarify for folks out
there, what Dan and Marcello have been saying is we provide
the tools and services so that you can decide what the best
approach is for you, whether you're 5,000 users--
As James was asking about, how long should take?
It really depends.
And we hope that the information that we provide in
these webcasts help you determine what is best for
your company.

And James, I'll turn it back over to you so we can get to
some questions.
JAMES HILLIARD: Yeah.
We're going over the top of the hour by about five minutes
or so here to squeeze in some of these questions.
We do have some related resources on the right-hand
side of the player, which I encourage you to click on.
I'm putting out one last poll question, really just to have
some feedback as we follow up with you after the event.
We know some of the topic areas that you want some more
information.
Current levels of enterprise adoption, security, et cetera.
So we'll leave this up for a moment so you can do on that.
Dan, let me actually bring it right back to you.
Taking Aaron's question, but as you mentioned, a lot of
questions in here about Google Apps Directory Sync
and things like that.
Take a moment here and talk about Directory Sync, and go
into a little more detail like you wanted to.
DAN KENNEDY: Sure.
So we've had some questions around the protocols used.
And what if I want to just run a test pilot?
So let's talk.
First off, anytime we're coming through the cloud, we
are using a secure connection over SSL.
So some of the other questions were, what other ports would
come into play here, from a network
standpoint, things like that?
The only other ports we use are LDAP ports.
It can be standard 389, or it can be a secure LDAP port.
Another question that came in was about, can I just sync to
one specific little place to try and pull, like, one or two
users and do automation and things like that?
And the answer is absolutely yes, you can do that.
Very, very configurable tool.
So a couple of really good questions there.
JAMES HILLIARD: All right--
MARCELLO PEDERSON: And, I think, Dan-- sorry.
Just to augment Dan's point on Chrissy's question, the DSS
runs inside of your network.
So from a network perspective, you usually don't have to
open, from a firewall perspective, you don't have to
open any ports to your LDAP system, since the tool sits
inside of your network.
So when we use port 389 and 636, they're actually inside
of your network.
So there is usually not a firewall there.
But then, the tool communicates to
Google in the cloud.
JAMES HILLIARD: Marcello, we'll keep it with you.
Matthew wanted to know about the single sign-on products
that Google Apps works with.
Oblix, Novell, does it matter?
MARCELLO PEDERSON: What we do, we are SAML 2.0 compliant.
As long as you have a SAML 2.0 compliant tool, I'm not 100%
familiar on those exact ones.
We have a lot of partners out there that have SAML 2.0 with
their open source projects.
And there are a lot of companies out there, perhaps
like Novell, that already support SAML 2.0.
So we follow a standard protocol.
JAMES HILLIARD: All right.
I appreciate that.
Again, back on the screen, some URLs that you
can take a look at.
Folks have been asking if we recorded today's presentation.
And yes, we have. So if you missed anything, you joined us
late, you will all get reminder emails bringing you
back to the on-demand version starting tomorrow.
So look for that coming in here.
We talked a little bit about mobility and things like that.
Rich wanting to know, is there a separate charge for each
mobile device, BlackBerry, Android, et cetera, that will
be accessing the domain?
Dan, can you address that for us?
DAN KENNEDY: Sure.
Absolutely not.
One of the things that we try to strive for is to not have
any hidden costs in our product line.
So whether you have two Androids or 10,000 BlackBerrys
that are going to be accessing, from our
perspective, there is not, in terms of that.
If you run GBES, we do run off the base RIM product so that
we can support the base RIM product,
BlackBerry Enterprise Server.
So there is that piece of it.
But other than that, we do not have a charge fee for devices
on our domain.
JAMES HILLIARD: Dan, I don't believe we went over it,
although I've heard this on a lot of the Google customer
events that we've done.
And, again, I encourage, as Serena did, for folks to look
for those on TechRepublic.
Register for those.
They give you really good insights into folks that are
in your position as well.
What they've gone through.
Give you some insights on what you might do.
But a question that comes up a lot, Ron addressing it today,
is there a shared corporate address book?
If so, is that integrated with Active Directory?
DAN KENNEDY: So there is a corporate address book for the
different platforms. And it can be, based on how you put
your address book into Google, that will determine--
which, usually a company, if they have an Active Directory,
will incorporate that via Google Directory Sync.
And then that can be utilized on the
Mobile platform as well.
JAMES HILLIARD: Marcello, Lewis on board with us wants
to know, for the users out there, can you send users to a
Google site web page as a welcome page
when they log on in?
MARCELLO PEDERSON: You'd have full control of the user login
experience when you use single sign-on.
That is one option.
You can also customize some of the colors of
your sign-on page.
But if you want to display any sort of disclaimer or any
additional information, with single sign-on, you have full
control of that.
JAMES HILLIARD: Gotcha.
And, Dan, I saw a question in here.
I'm scrolling back up to it here.
You mentioned one of the deployments
Serena was talking about.
Some of the customers from large to small.
Jennifer and a few others were trying to really get into the
size company that you've seen benefiting
most from Google Apps.
Is there a difference between the large and the small
company that goes forward?
DAN KENNEDY: There's really not a big difference in terms
of the productivity benefits, the gains from a cost
perspective that you get when you go to Google Apps.
We've seen companies with two employees all the way up to
hundreds of thousands of employees deploy Google Apps.
And they all are very happy and, of course, get the same
kind of user experience and the same benefits that the
other ones did.
JAMES HILLIARD: I was looking today in the queue and some of
the questions, we had folks that have 15 or so folks that
want to move over all the way up to a minimum of some 5,000
and above that are looking.
So again, a broad range of interests.
For our audience, I do have one final interactive
component I want to push out to everybody, a
quick little survey.
Gives us some feedback about today's presentation.
So if you can have your pop-up blockers disabled, or hit the
Control C button right now, I'll go ahead and push that
survey out to everybody.
Just six questions or so on there.
Again, gives us a little feedback about today's
presentation.
And appreciate you all taking a moment to answer that.
One or two other questions that we'll get to.
Then we'll be wrapping things up.
The rest of these questions are going to have to be dealt
with offline, if you will.
Russell, interesting one here, Marcello, dealing with
executive assistants.
Often they are having to manage contacts, the email,
the calendar of their executives.
How is that handled when folks move to Google Apps?
MARCELLO PEDERSON: We have two options.
You can delegate Gmail through email delegation.
That's a feature that just launched not too long ago, and
something that we have a very good feedback on.
And we also have Calendar delegation, where the Calendar
can have full access to somebody else's Calendar for
managing their Calendar.
So we have support for that.
And we have good feedback on that, too.
JAMES HILLIARD: All right.
Cool.
Hey, we're going to cut it off at that point.
What we will do, folks, is we're going to take the
remainder of the questions that have come in.
And we will get those over to the Google team, and work on
getting some responses back out to you in some form,
whether it'll be through some postings, or whether it will
be through individual responses.
We're going to work to try to get some of those
answers out to you.
Back on the screen, some contact information.
If you want to download a copy of today's presentation, just
click the download slides.
You'll get a PDF of the presentation.
It will have these links in there as well.
And we've made these links available on the right-hand
side of the player.
I'm going to keep that player open for just a couple more
minutes here.
So you can click around there if you need to.
Again, if you have a final question or comment that you
want to submit to the team, feel free to
do so at this time.
We'll gather that in our report and
get it over to them.
My thanks, again, to Dan and Marcello for taking time,
being on board.
Serena as well.
We'll put good wishes out to Jim Copeland.
Hopefully, he'll be able to join us next time around.
And for all of you, our attendees, really do
appreciate you taking so much time to join us for the event,
go over a little bit on time, and ask
so many great questions.
We'll do our best to get some responses back out to you.
With that, we'll wrap things up.
Again, my name is James Hilliard.
And we do look forward to talking to you down the road.