Sept Edition – What’s New for Apps Admins
Articles Blog

Sept Edition – What’s New for Apps Admins

welcome to this month’s edition of “What’s New in Google Apps.” My name is Stephen Long, and I’m
a technical trainer and course developer at Google for Work
based in Dublin, Ireland. I’m working together
with Barry Schmell, my team member
based in California. We put this
presentation together for all you Google
Apps admins out there. The first thing I
want to mention here is our change of format. As you may have noticed, you’re
watching this on YouTube. Recently, we changed the
format of our popular “What’s New in Google Apps”
webinar series from scheduled live sessions
to these video recordings hosted on YouTube. So you can watch
whenever you want and share them with your
colleagues and users. Plus, the slides
used in the video will be linked below so
you can get more info or follow any of
the links mentioned. The “What’s New” videos
provide a recap of all the features we’ve released
in the past month that are of particular interest
to Google Apps admins. Please feel free to put
your comments and questions in the Comments section below. If you’re looking for a full
rundown of all the features released last month, then check
out the Google Apps Release Calendar, where you can see the
date and type for each release. Or alternatively,
you can check out the “What’s New in
Google Apps” newsletter for a full rundown of all
the features and more info on what they mean. You can find this newsletter
on the “What’s New” page above the Release Calendar. So let’s look at our
agenda for this video. We’ll start with
some headline news, talk about some
major marketplace updates, some changes
to the mobile features important for admins, look at
some general admin specific updates, and finish
on some API updates. Let’s start with
the headline news. As many of you may
have heard by now, as of September 2,
2014, what was called Google Enterprise is now
simply Google for Work. We believe that technology
should make it easier to get things done, no
matter where you work or what your job is. Millions of companies,
large and small, have turned to Google to
help them launch, build, and transform their businesses,
and help their employees work the way they live. Google never set out to create
a traditional enterprise business. We wanted to create a
new way of doing work. So the time has come for
our name, Google Enterprise, to catch up with our
ambition, Google for Work. But don’t worry, even
though the name is changing, the product experience
remains the same, as does our commitment to
bringing you the best tools to run your business. Now, speaking of
great tools for work, let’s look at some
marketplace updates. A major update for
admins last month was the opening up of
Google Apps Marketplace beyond Apps administrators. The Google Apps
Marketplace features hundreds of third
party apps that complement the suite of tools
in Google Apps for Work. Previously, only admins
could install these apps within an organization. Starting in September,
employees can install these apps without involving their admin. So if you work at
an organization that uses Google Apps for Work,
Google Apps for Education, or Google Apps for
Government, your users now have greater access
to apps that help you work faster,
more efficiently, and collaboratively. Let’s take a look
at the Admin console to see how this is done. Under Marketplace Apps, if
you click the settings icon in the top right hand
corner, click Manage Apps, and finally, if you click Manage
Access to apps, what you’re going to see here
are the settings that you can adjust
to manage and filter which third party apps are
available to your organization. First, you can
choose Allow users to install any application
from Google Apps Marketplace. Some important
things to note here. These settings
allow you to choose which Google Apps
Marketplace apps are available for users to install. However, they don’t
block your users’ ability to grant data access on
third party vendor websites. Also, these settings
are forward-looking, which means that changing
your selection to options two or three does not affect
apps previously installed by an end user. By default, option
one is selected, with the exception
of K-12 EDU domains, where it’s set to option two. At launch, this means for
rapid release domains, this feature will be defaulted
to allow users to install any Marketplace apps. Admins from schedule
release domains will see the Admin
console controls for this feature with
the rapid rollout, and can disable it if so desired
prior to the scheduled launch. Users from schedule
release domains who try to install an app
prior to the schedule rollout will receive an error message. So that’s the default option. Next, you can
choose Do not allow users to install any
application from the Google Apps Marketplace. And again, noting any
previously installed apps won’t be uninstalled. Finally, you can
choose Allow users to install only whitelisted
applications from the Google Apps Marketplace. Let’s whitelist some apps and
see how this affects my users. First, I’m going
to save my changes, and when you click Save
Changes, now you’re going to see a Manage
whitelist link. After I click the
link, it shows me that I don’t have any
whitelisted apps yet, so I’m going to add some. As you can see, there’s a
list of apps to whitelist. For simplicity’s sake, I’m just
going to choose the first two, and confirm that. Now, you can see here
Confirm two whitelisted apps for this domain. Now that I’ve
whitelisted these apps, let’s jump over to a user
account in this domain and see how this setting change
affects what the user sees when they go to the Marketplace. As a user, to find and add third
party apps for Google Apps, you click the app launcher icon. At the bottom, you click More. And then more Marketplace apps. Here we can see that the
only apps visible are now the ones that I have
whitelisted by my admin. If I wish to install them, I
can just click Install App. Next, let’s go back to the
Admin console as the admin and turn off the ability to
install apps all together. So if I go to option
two here, Do not allow users to install
any Marketplace apps, and save changes– now,
if I go back to my user and I try and install some
Marketplace apps again by going to Launcher, More,
and More for Marketplace, I’ll be able to see
plenty of different apps. But if I try and
install one, I’m going to get an error message
saying that my domain admin has disallowed the installation
of these Marketplace apps. As we are talking about
Google Apps Marketplace, let’s look at another
announcement this month that involves Marketplace apps. These days,
technology moves fast and we want to keep our
developer products moving and innovating fast, too. Google API has used the OAuth
2.0 protocol for authentication and authorization. We’ve been working
with developers to migrate their Google Apps
Marketplace apps from OAuth 1.0 to OAuth 2.0, as OAuth 1.0
has been officially deprecated since April 20, 2012. It continues to work as
per our deprecation policy, but we’re moving towards
the end of this deprecation timeline for the Google
Apps Marketplace. Any developers out
there, we encourage you to migrate to OAuth
2.0 as soon as possible. In most cases, apps
developers have already worked with their customers
to migrate to OAuth 2.0. However, for those apps
that have not been migrated, the following September
announcements apply. On September 30, 2014,
Google will no longer enable any new installs
of OAuth 1.0 apps, and these apps will be
removed from the Google Apps Marketplace. However, previously
installed OAuth 1.0 apps will continue to work. On April 20, 2015, if your
application provider has not completed your migration
to their OAuth 2.0 app, then the single sign
on functionality will stop working, and the
app icon will no longer appear in the app launcher. These changes improve
integration, security, and management of
third party apps. Now, let’s look at some of
the mobile specific updates for all you admins
out there managing mobile devices in your domain. In September, we introduced
a new iOS mobile device management solution known
as iOS Sync for Google Apps, offering administrators
an additional way to manage iPhones and
iPads connected to Google Apps for work accounts. iOS Sync is integrated right
into the Google iOS apps. Today, these include Gmail,
Google Drive, Docs, Sheets, and Slides, so your
users don’t have to download any additional
app for device management. But your organization
maintains its security needs. iOS Sync will support
iOS 7, 8, and of course, the new iPhone 6 and 6+, and is
now available for Google Apps for Work, Google
Apps for Education, and Google Apps for Government. The main advantages of iOS Sync
for users and administrators include admins can
enforce security policies when users sign into a Google
App, and enroll their device. This is especially useful
if your domain has a bring your own device or BYOD policy. They can preconfigure
Wi-Fi networks. And also, their support for
existing policies like managing password requirements,
encryption, and camera policies,
as well as actions like remotely wiping a device,
and activation approvals, and blocking devices. Let’s check out
the Admin console to see where we can set this up. Under Device Management, in
the Mobile Management settings and under Device Management
settings, you’ll find iOS Sync. iOS Sync is enabled
for all users by default, meaning
anyone within your domain can use the Google
for Work iOS apps, such as Gmail and Google Drive. You can also enforce
additional mobile settings and enable iOS device management
with just a few simple steps. But as you can see, the Enforce
is actually grayed out here at the moment. First off, you’ll need to
establish an Apple Push Notification Certificate. To do this, your Google Apps
account and Apple servers need to exchange
certificate files. If we go back to
the mobile section, you’ll see that there’s
an area to set up Apple Push Certificate. I’m going to go through
these steps right now just to show you how to set this up. First, download the certificate
to your local machine. I’m going to hit Download here. And then it’s going to go
into my local download folder. You can check the
box to say I’ve downloaded the certificate
for that particular step. Next, you need to sign
in with an Apple ID. Apple requires a valid Apple
ID to log into the Apple Push Certificate portal. If you don’t currently
have an Apple ID associated with
a work account, you’ll need to create one. We wouldn’t recommend
using a personal Apple ID, unless you’re setting this up
for your personal Google Apps for Work domain. Let’s run through the set
up in the cert portal. First of all, I’ll just
click Create Certificate. Make a note of the domain
you’re doing this for. Finally, hit Choose File to
upload the certificate that you just downloaded from Google–
google_ios_push_certificate.csr. Once you’ve done
this, click Upload. You can see now that I’ve
successfully created a push certificate with the following
information– Mobile Device Management, Google Inc. If you then download
that certificate again to your local
machine, back in the Admin console once I’ve downloaded
the push certificate, I can say I’ve got
that step done. And finally, now I’ll
select the certificate to upload again into Google. Once all those steps are
completed, I’ll hit Verify, and the push certificate
will be uploaded. Now that I’ve got an up-to-date
Apple Push Certificate, that means I can use
iOS Sync to manage iOS devices in my domain. This certificate will last
for a year, and after a year you will need to renew it again. So this is really
something you’re only going to have to do
once a year to make sure that your domain is up to date
with an Apple Push Certificate. At this point, if I back
to my device settings, and again, find my
iOS Sync section, you’ll see now that Enforce
is no longer grayed out. So if I click in the Enforce
policies on iOS devices and save changes,
now I’m going to be able to configure some device
management policies for my iOS users. For example, I could
go down to the bottom and set some network
settings for my users, such as adding a
wireless network and even a wireless password. So this is preconfigured
for my users. So a major benefit
of this update is simpler configuration,
such as providing passwords for preconfigured
Wi-Fi networks, and set up of
CalDAV and CardDAV. Once you’ve installed the
Apple Push Certificate and enabled iOS
Sync enforcement, your configured
settings will not take effect until
users in your domain have installed the
Google Apps device policy profile on their devices. So let’s take a look now
at the user experience now that we’ve enforced
policies for iOS Sync. By enforcing policies, what
we’re really saying here is that yes, we want our
users to be able to connect with an iOS device. However, we want to ensure that
the security on that device meets with all of
the security policies before allowing the sync. In order to do that, we’re
going to have a device policy installed on the actual device. So let’s say our
user goes and tries to connect with
their Google Apps account using Gmail or Drive
apps on the iOS device. So let’s say they’re trying
to sign into Gmail here. They add in their
account details. They’ve created an
Account Profile. And when they try and
enable this account, what they’re going to see
is a Device Policy Error. What this error says
is that in order to use this device with this
particular Google Apps for Work account, then you’re going to
have to install the security profile to keep the data safe. So this is the enforcement
as the user sees it. If they click Next, what
they’re going to see is a Google Apps
Device Policy Profile, and they get some
information about what installing this profile does. It highlights to them that their
admin is enforcing policies, configuring settings,
and has the capability to remotely erase this device. When they click Install,
and then Install Now, they’re going to get a
warning that just highlights to them that the
administrator may be able to collect
personal data, add and remove accounts,
and install and manage apps. And of course, then remotely
erase this particular device as well. So it’s really just
outlining to the user the kind of security policies
that are being put in place, and then they have
to agree to these. If they click Install, what
they’re going to see then is the Google Apps Device
Policy Payload Profile has now been installed and related
to that particular account. So then when they go back
into their accounts page and turn their
account on, they’re just going to be able
to sign in as normal and get into their Gmail
through the app in this case. One thing to be aware of
here is that you can only install one profile per device. So you couldn’t set this up
for multiple user accounts on a single device
towards different domains. Next we’re going to take a look
at some admin general updates. Continuing the theme
of updates for iOS, a new version of the
Google Admin app for iOS is now available
in the App Store. This is for all
those super admins who want to have the
ability to still manage their Google for Work products
on the go with their iPads and iPhones. This allows you to manage users
and groups, review audit logs, and contact support,
all while on the move. This latest release, v1.1.0,
contains some great new features, like improvements
to searching users, the ability to switch between
multiple accounts quickly, and a new settings page
with settings like remember password. Be sure to check it out
in the Google App Store. For all you admins out there
using Google Apps Directory Sync or GADS, to provision and
sync your user information from an LDAP directory, the latest
release of GADS v4.0.1 has several new features
and bug fixes. The biggest change here
is that GADS now requires using OAuth for authorization. Where previously you could also
use the admin credentials, also known as client login, this
is no longer supported, as it’s been deprecated. Customers using client login
must now authorize using OAuth. For more information, see the
Authorize using OAuth section of the admin guide. Any customer already
using OAuth will also need to authorize again, with
existing or new credentials, because this version of
GADS uses different APIs. And the scopes for which
tokens are generated will also have changed. Another big back end
change is that GADS now uses the Directory API instead
of the deprecated Provisioning and Profiles Data APIs. We strongly recommend switching
to the latest version of GADS. All GADS versions will stop
working once the Provisioning and Profiles Data APIs are
discontinued on April 20, 2015. The great news is that
GADS will run faster using these new APIs. Some other updates will
improve GADS’ usability on the front end, such as GADS
now allowing several profile and shared contact fields, like
department, job title, office location, and notes
to be comprised of multiple concatenated
LDAP fields, meaning it’ll be easier to
take information from your LDAP and make it clear and
usable in Google Apps. For more information on
this release of GADS, make sure to check the release
notes, and don’t forget to download the new version. Also, we’ve introduced
a date picker on the top right of the report
section in the Admin console to provide additional
transparency to any reporting delays and unblock partial data
feeds in the event some data is unavailable. In the Admin console,
if we go to Reports, we can see a little bit
more about this new update. As you can see, the reports
show historical data generated for the last
seven days, the last month, the last three months,
or the last six months. The date in the upper right
indicates the most recent day for which report
data is available. The pull down arrow
next to the date opens a calendar page–
we can select another date to use for reports. The latest date for which all
data or points are present has a green background. This is usually two days
prior to the current day. You can select another date
beyond the full data date, but any later date you
choose may have partial data or may only show a subset
of the expected reports. The API will also
return a warning if some data is missing. OK, now we’re going to take a
look at some Chrome updates. Tying in with some of
the other mobile updates that we mentioned earlier, let’s
talk about Chrome policies. Since April, 2013, admins
have had the capability to set 100 plus Chrome
policies for users on Chrome devices,
Windows, Mac, and Linux when they sign into Chrome
with their Google Apps account. On September 23, we started
providing an early preview of applying some of
these same policies to Chrome on Android
and iOS as well. This means in the
Google Admin console, you can select if supported
policies should apply to Chrome on mobile devices. So you can do things
like set bookmarks, define proxies, or manage
password policies once, and it will apply on Chrome
on all six platforms, including mobile. Let’s check out where we
can enable this setting in the Admin console. Under Device Management, when
you click Chrome and then check User settings, you
should be able to see this Chrome mobile
BETA at the top. Note that Chrome
management needs to be turned on first before
enabling this setting. Once enabled, users who are
signed into Chrome on Android or iOS with your
organization’s account will begin receiving the
user settings you set. To see if a policy is
supported on Android or iOS, check the light bulb next
to each policy in the Admin console. Please take note that this
is an experimental feature, so make sure to read the
Help Center carefully before enabling this. Another update
for Chrome devices is related to managing
client certificates. In many organizations, users
must authenticate themselves using a digital certificate
to access certain networks and internal web resources. Client certificates allow
users on Chrome devices to access these types of
networks and resources securely. On September 4, we launched
an easy way to provision and manage certificates
across a fleet of devices. We’ve provided an API
so that extensions can support a variety
of enrollment protocols and workflows. There are several steps in
putting a client certificate on a device, depending
on your workflow. For more information, see
Manage client certificates on Chrome devices
in the Help Center. Another bit of news related to
Chrome is a new 64-bit version. In late August,
we released Chrome 64-bit for Windows, which
brought benefits in speed, security, and stability. Now, we’re bringing
these benefits to OS X with Chrome
64-bit for Mac, version 39, due to be
released in November, 2014. While doubling the
numbers of bits doesn’t make it
twice as good, it does allow us to make a
number of speed and security improvements. You can check to see
what version of Chrome you’re running by checking
the Chrome’s About page. The final bit of news for
Chrome is related to the Legacy Browser Support Extension. If your organization wants to
take advantage of the Chrome browser but your
users still need to access older websites and
apps that require Internet Explorer, you can use Legacy
Browser Support Extension to easily switch
between browsers. We’ve launched a Legacy
Browser Support test channel so that you can test the next
versions of the LBS Chrome Extension and MSI before
they’re promoted to stable. There is one very
important action needed for admins using
Legacy Browser Support today, so listen up. The next stable release of LBS
is slated for early November. Starting with this
upcoming version and all subsequent
stable and test versions, the MSI will be required in
order for apps and websites to open in the
appropriate browser. Therefore, it’s
critical to make sure that you have deployed the
stable MSI to your users before November so that Legacy
Browser Support continues to function when it updates. You can find the
download links for the 32-bit and 64-bit
versions of the stable MSI at the links provided
in the slides. The last section
we’re going to cover is some API updates for all
you coders and developers out there. The Google Admin SDK
allows developers to write applications to
manage Google apps domains, allowing you to manage
users, groups, devices, and apps all from one place. In September, there were
some important updates to this Admin SDK. First off, now available
is a new feature in the Directory API, which
allows you to add custom attributes for your users. For instance, you could
store the projects your users work on, their desk
number, job level, hiring date, or whatever makes sense
for your business. Once you define the custom
attributes for your domain, all you have to do
is get or set them just like any other
attribute field. You also have control over
the attribute’s data type and visibility. Another new feature is the Read
access to all the main users. Historically, only admins
were able to access the data in the Admin SDK. Beginning in September,
any user, not just admins, will be able to call
the Directory API and read the profile of any
other user in the domain. Of course, only if allowed to
do so by your access and profile sharing settings. This new feature allows you to
build business applications, such as corporate yellow
pages or vacation management, that can be accessed and
used by all your users. Check out the documentation to
learn more about the Admin SDK. And specifically,
the Directory API. Finally, as we are
discussing the Admin SDK, let’s look at an important
update on API deprecation. In May, 2013, we
introduced the Admin SDK. And later, in July,
2013, we followed with the release of the new
improved Email Migration API v2. With each of these
introductions, we also announced
the deprecation of a set of corresponding APIs,
such as the provisioning API and Email Migration
API v1 that would be replaced by the new APIs. As of April 20, 2015,
we will discontinue these deprecated APIs. This means that
the service calls to these APIs are
no longer supported and Google Apps features
implemented using these APIs will not function. For all you
developers out there, you can find comparable
functionality in the Admin SDK and the
Email Migration API v2 to transition to. In the coming weeks, we’ll be
contacting the domain admins whose applications currently
use these deprecated APIs with an email
reminder and guidance on the appropriate
migration path. So that’s it from us this month. Please don’t forget to
subscribe to the channel and leave your comments
and questions below. This has been “What’s
New in Google Apps” recap of September, 2014. And I’ll catch you
all next month. [MUSIC PLAYING]

One thought on “Sept Edition – What’s New for Apps Admins

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top