WWDC2013 Session 300

Transcript

X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[ Silence ]
>> Todd Fernandez: Good morning,
and welcome Session 300,
Managing Apple Devices.
I'm Todd Fernandez and
I'm very happy to be here
with you this morning
representing not only my own
engineering teams, but
a number of other teams
from across the company
who had been hard
at work making some
exciting changes
in how Apple devices
can be managed
in education and enterprise.
Look out, I just
said the E word.
In days of yore, device
management was based
on the desktop PC model.
IT departments would receive
a shipment of computers,
they'd erase them, install
a corporate custom image
containing whatever software
and policies and settings
that they felt were appropriate.
They distribute those computers
out to their end users.
Periodically, IT
may update them.
This model worked reasonably
well for a long time,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
but times have changed
and we here
at Apple will modestly
take most of the credit.
Customers now have much
higher expectations.
They're no longer
satisfied with the static
and monolithic system imaging
methodologies of the past.
They now expect from their
device management tools
that they are dynamic
and on demand
and provide over-the-air
device management capabilities.
In short, devices
are now mobile.
iOS and the App Store introduced
the new model for deployment
and management and we want
to complete that transition
for all Apple devices.
People are now buying their
own devices and wanting
to bring them and use
them at school and work.
They're very comfortable
installing their own apps
and configuring those
devices to access resources
and information whether
they're on the road,
in the office, at
school or at home.
This has presented IT
departments with the challenge
of supporting this multitude
of deployment models while
still providing easy setup,
enforcing security policies
and distributing apps
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and other content out
to their end users.
Our goal is to enable those
organizations to manage all
of their Apple devices in the
same ways with the same tools.
We've been working towards
this goal for some time
and we're taking
a big step forward
with some powerful new device
management capabilities
that we've built in to both
iOS 7 and OS X Mavericks.
People love how easy it is to
set up their new Mac, or iPad
or iPhone or iPod Touch.
Within minutes, they are
connected to the internet,
installing apps and
communicating
with their friends and family.
And now, the same experience
is available to businesses
and schools to simplify
setup and management
of large numbers
of Apple devices.
We've greatly enhanced
app and book management,
dramatically simplified
device enrollment interval,
remote device management systems
and made a ton of enhancements
and added new capabilities
that enable organizations
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to get more control over their
devices while still preserving
the great experience that users
have come to expect from Apple.
So our agenda today, we'll begin
by covering the large number
of small to medium size
changes that we've made
to the MDM protocol and
configuration profiles
in both iOS and OS
X and I'll point
out the remaining OS
specific differences as we go.
Now that work taken together
alone would be a huge advance,
but we didn't stop there.
We've also made big changes
to the App Store
Volume Purchase Program
and we're introducing
a new service
that makes it much easier
to get devices enrolled
in the MDM server solution that
the organization is deploying.
Now, this session is primarily
targeted at developers
that are creating MDM and other
device management solutions.
Because we've done a lot of
work already, but we really rely
on you just as with the 1500
and more APIs we've
introduced this week
to fully take advantage of these
new capabilities we're offering
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to you to make the experience
of our joint customers
much greater.
But of course it will
also be of interest
to anyone who's managing large
numbers of Apple devices as well
as app developers who want
to make their app attractive
to education and enterprise
customers who are buying
and deploying large
numbers of Apple devices
and may very well be interested
in buying large numbers
of copies of your apps.
Now, I'm no marketing executive,
but I think that might be
of interest to some of you.
So let's get started.
Before we get into what's new,
I wanted to just
give a brief recap
about the foundational tools
that Apple provides to those
of you who are building
device management tools
for the Apple ecosystem.
The first of which is our MDM
protocol which you can implement
to be able to over the air
communicate with Apple devices
and get information about that
device, be able to remotely lock
or wipe the device if it's
lost, to be able to install apps
over the air, as well
as installing configuration
profiles.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, configuration profiles were
the second foundational tool.
And they are collections
of settings
that can configure things on a
device such as accounts, mail,
context, calendars and so
on, in post restrictions
such as disabling the camera
if this device will be used
in a particularly sensitive
location, to provide access
to services like
networking and printers,
as well as to actually complete
MDM enrollment and establish
that connection back
to the MDM server.
Now, for those of you who
may not have actually solved
that problem of getting devices
enrolled in your MDM solution,
you may be thinking, "Well,
Todd isn't that a
chicken and egg problem?
You've got the MDM protocol
that you need to be established
to deliver the configuration
profile
which establishes
the MDM protocol?"
But in fact, we'll
leave that egg
to hatch later in the session.
So, just to give
you a quick scope
of what change we've introduced
in these new OS releases,
I'm only going to
highlight a few of these
and talk about them in detail.
But this is a huge amount of
work and we're looking forward
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to you integrating
these new capabilities
into your device
management solutions.
And I'm going to talk in some
detail about five of them.
The first four are
primarily of interest
to enterprise deployments.
But I think the fifth one will
be compelling for both education
and enterprise customers
that are installing Apple TVs
in their conference
and classrooms.
But before I get
into the details,
I want to spend the moment
talking about a problem
that the mobile device
industry is facing.
And that is how to keep separate
the user's personal private data
and the company's secure data.
Now, some in the industry
seemed to have concluded
that the answer is
dual personas.
That the user should have
to decide whether
they're using their device
as their personal device with
access to their own private data
or they're using it as their
company's device with access
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to the corporate secure data.
We don't think this
is the right approach.
We think that place is the
burden on the employee to make
that decision and
that's not how you--
people are using their devices.
We think the solution
needs to separate the data
without creating
separate workspaces.
And so, the features I'm going
to talk about now are part
of that solution and are focused
on keeping the user's personal
data protected and private
and the corporate data
protected and secure.
So the first feature I want to
talk about is very much in part
of that solution and
it's Manage Apps on iOS.
Now, this is not a
new feature in iOS 7.
What you can do previously
is install apps via MDM
on an iOS device and because the
organization has installed those
apps on that device, they
have additional rights
over those devices--
over those apps
and can therefore have
more control over the data
to prevent their secure
data leaking out in ways
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that they don't want including
being able to delete that app
and its data and
prevent that apps data
from being backed up to iCloud.
In iOS 7, writing a number
of new capabilities including
on supervise devices, and
that little guy there is going
to indicate that
particular setting
or capability is only available
on supervised iOS devices
through out this session,
that apps can be installed
without user interaction on
supervised devices [applause].
I'm glad you like that
but there's way more.
And it's also possible
to configure device--
configure apps over the
air to provide the defaults
to change their behavior
once they're installed
on the device [applause].
I agree, it's really cool.
But we also have
the opposite of that
where using the MDM protocol,
you can then pull data back
from the app that has been
stored in the App Sandbox back
to the MDM server to provide
to the organization [applause].
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And then finally, this one
again is a big part of how--
of keeping that data separate
is Managed Open In [applause].
Apparently, you all
know what that means.
What that means is that the
organization can have greater
control over how their
users open documents
in Managed Apps and Accounts.
They can restrict the
list of apps that appear
in the Share Sheet thereby
keeping better control
over that data and again,
preventing it from leaking
out in ways that
they don't want.
The next feature I want to talk
about is called Single Sign On,
and this is really
building on some
of the concepts we introduced
in iOS 6 with the integration
of the Twitter and Facebook
credentials that are--
can be used in multiple apps.
We've now generalized
that to be able to be used
across the system where a set
of credentials can be stored
in one place provided
by configuration profile
and then used by multiple
apps for authentication.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
This, we think, will be
great for app developers
to help them solve the
authentication problem
and help get their apps
adopted more wildly.
It takes the form
of a new payload
that provides the credentials,
as well as optionally a set
of URL prefixes where, if a
user goes to one of those URLs,
those credentials can be
used for authentication,
or in addition, they
can also provide a list
of app identifiers that are
for apps that are allowed
to use these credentials
for authentication.
Next, we move on to
one of the features
that Craig briefly
mentioned yesterday
and there's one brief shoutout
of excitement about that,
hopefully more of you are
excited about Per-App VPN
because this is another big
piece of the puzzle of how
to solve that data
separation problem.
Per-App VPN allows organizations
to more narrowly focus
which apps are going to use the
secure and private network back
to their remote services
at their company.
What this means is that instead
of having the VPN
cover the entire system
and have all data go
through that private network,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
only the corporate
secure data will go
through the secure network, the
users private data does not.
So, this is better for both the
organization and the end user.
And there's one additional
detail for those of you
who are going to be implementing
this is that on iOS,
the Managed App needs
to be configured
to use Per-App VPN
when it's installed.
If you didn't notice one
more detail about that,
since it didn't have the iOS
badge up there when they cleared
that Per-App VPN, is
available on both OS X and iOS.
Now, moving on to an
OS X specific feature,
FileVault of course is not new
and even managing
FileVault is not new,
but we've added a great
number of new capabilities
that you can now manage
remotely for OS X systems
that are using FileVault,
including querying the status
of whether FileVault is enabled,
as well as preventing users
from disabling FileVault
once it's been enabled.
During the process of
enabling FileVault,
an individual recovery
key is generated
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and provided to the user.
Instead of that being
sent to Apple for help--
the AppleCare, organizations
can now configure the device
so that key is sent back to the
company instead of to Apple.
They can also add
whatever period of--
periodicity they
feel is appropriate
for their security policies,
they can rotate the
institutional recovery key via
MDM [applause].
Thank you.
All right, we appreciate
your enthusiasm.
All right, moving on
to AirPlay Mirroring.
This is the feature that
I mentioned earlier.
I think it will be
great for both education
and enterprise deployments.
We are adding a new MDM command
that allows the MDM server
to tell a specific device
to begin AirPlay Mirroring
to a specific AirPlay
destination.
We're also providing
a new payload
that allows configuring
a whitelist
of allowed destinations on
supervised devices as well
as pre-configuring passwords
for AirPlay destinations
in the payload so that users
don't have to answer them.
And you can have the Apple TVs
locked down but still not have
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to have each end user
know what the password is.
I'm also very pleased
to announce
that Apple TVs can now be
enrolled and managed via MDM.
[applause] We agree.
This is very exciting
including querying
and setting the language
in locale
and configuring our
network access including
to protect the 802.1X networks.
But that's just the first couple
that I wanted to highlight,
there's so much more including
the ability to install fonts
on both iOS and OS X via
configuration profile.
We've enhanced the Wi-Fi
payload to add support
for the new Wi-Fi Hotspot 2.0.
On iOS, we're allowing you to
configure AirPrint destinations.
All right, somebody's
using AirPrint?
Single App Mode is not new
but you can now configure a
lot more accessibility options
which we think will
be great in schools
for doing testing
on iOS devices.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We're also providing
a new payload
that provides web
content filtering
on supervised iOS devices.
And a few OS 10 specific
changes,
the exchange web services
payload is not new
but it now supports all
five account types; Context,
Calendars, Email,
Notes and Reminders.
[applause] The passcode policy
of course is not new either,
it's been supported all
along on both iOS and OS X,
but there were a small number
of settings that did not--
were not supported
on OS X and we now
in OS X Mavericks have
complete parody with iOS,
so you're being confident
that your passcode policies
are applied the same way
across both OS's.
There are also, as you can
see, many new restrictions,
the first six there
available only
on supervised devices including
preventing users from creating
or modifying accounts.
Again, another way to
help separate the data
between the users personal data
and the corporate secure data.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
There's also a new restriction
controlling whether a supervised
devices can pair to other
Macs but I'm going to talk
about that more a bit
later in the session.
Finally, there are a number
of additional enhancements
to the MDM protocol.
I already mentioned one new
command, but there are a number
of new queries where you can
ask the device whether certain
features are enabled
or not; Mobile HotSpot,
Do Not Disturb, Find My iPhone.
And you can also ask the device
if it has an iTunes
account signed in.
In addition to the new command
to begin AirPlay Mirroring
to a destination, you can also
now set a custom lock screen
via MDM.
You can put the device
in lost mode
which adds contact
information to the lock screen,
so that if somebody
finds your lost device,
they can get it back to you.
And you can also disable
the Personal Hotspot.
So, that's a lot of work and
lot of talking by me and I now
like to ask Jussi
and Chris to come up
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and show off those new managed
app enhancements that you were
so excited about and
they are really cool.
So, guys take it away.
[ Applause ]
>> Jussi: All right,
thank you Todd.
So, first I'm going
to show you some
of the new management
features for Managed Apps.
So, Todd mentioned
managed configuration
and managed feedback for
managed applications.
So, here I have a sample
application that seems
to be stuck in time
back in 1993.
If anybody remember or
saw San Jose Conferences,
can you raise your hand?
[applause] Oh, thank
you for coming back
and sticking with the platform.
So, this used to be Newton
App, if you remember,
and we can update it to some
modern conference location.
So, if Chris is now
sending an app update,
so you notice right now
we're in San Francisco,
we just came back to the future.
And what just happened is
that there was an application
configuration payload
that was sent over MDM, so this
app got an instantaneous update
of a Push Notification and
as an application developer,
you want to think of what
kind of settings would you
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
like to implement
as live updates?
This is effectively
life preferences
for some app settings.
And as an MDM vendor, you'd
want to implement the method
for sending these
application-specific payloads--
configuration payloads
that they're not--
the developer has
taken advantage of.
So, that's all fine and great
but then we also have
a support for feedback.
So, gathering feedback
from the application
and this is an awesome
conference if I could type that,
[inaudible] conference.
No, let's try that again.
[ Pause ]
Also in conference again.
And now, Chris is going
to send an MDM command.
Again, another command that MDM
vendors will want to implement
and let's see how that
output looks on the Console.
So, here we have a feedback
dictionary that's returned
over the MDM protocol
to the MDM server.
So, as an MDM vendor, given
that there's probably
several thousand applications
that will have managed
configuration preferences,
you will not necessarily
have able--
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you will not be able
to implement a [inaudible]
mechanism or--
and reporting mechanism
for each every app.
So, what you want to do
is provide mechanisms
for this feedback data
that we gathered and stored
and then further process
by a site-specific
application or Backend.
So, you act as a conduit
for gathering feedback
from the application
and then delivering it
to some other application that
will then process it further.
So, that's a quick
overview of the App Feedback
and App Managed Preferences.
If you want to know more
about these specific features,
there's a session today at
3:15 regarding Extending Your
Applications for
Education and Enterprise use
and there'll be more information
about these specific
things there.
So, the next thing is Managed
Open In back to default.
So, enterprises.
So, we have apparently some
mail here and this seems
to be the new iOS
Enterprise Deployment Guide,
and that's great.
So, let's see if we can
send this over to somebody
that has a Dropbox
account or whatnot.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But that's not necessarily
ideal.
This is a draft document,
not to be shared.
So, I need to be able to
lock this account down
and restrict the ability of
this document to be shared.
So, with Managed Open In,
this mail account is managed.
So, my MDM payload
configured this account.
I also installed
some applications
as Managed Applications.
So, Chris is now going to
send a configuration profile
that restricts my ability
to open the document
in any other application
besides the ones
that the administrator
has chosen
for this app to be opened.
And you'll notice that
I just lost Dropbox,
I lost Google Drive, I only
have GoodReader as an option
to open this document in.
So, this is basically a way
of compartmentalizing
your application data
and your user data without
compromising the iOS
user experience.
So--
[ Applause ]
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, that's Managed Open
In, and now back to Todd.
>> Todd Fernandez: All right,
thank you very much guys.
All right, so that's
already a lot of change
but we're just getting started.
Now, I'd like to talk to you
about the App Store
Volume Purchase Program.
Many of you may be aware
of this already, but today,
education enterprise
organizations can purchase app
and education books
codes in bulk.
The App Store or B2B
Store and MDM vendors many
of which have integrated code
management and distribution
into their MDM solutions
to enable organizations
to install those apps on
their end user systems.
But of course, this involves
managing spreadsheets
of redemption codes and
nobody really likes that,
for two reasons,
one, it's very clumsy
but more importantly it
involves a permanent transfer
of ownership of that
asset to the end user.
So, I'm very pleased to announce
that we are allowing
organizations
to purchase licenses
that are revocable
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
for apps instead of codes.
[applause] But that's not all.
We're adding Mac Apps
as well [applause].
We're adding books
for enterprise and--
all right fine, nobody wants
to read technical
manuals, I get it.
But even better for those of you
who are working on MDM products,
we're going to provide a
rich set of Web Services APIs
to allow you to fully
integrate this new system
into your products and
give a great experience
to our customers.
[applause] So, let's talk
about how this system is going
to work starting of course
with what the end
user will experience.
Once an assignment of one
of these revocable
licenses has been made,
the assigned app appears in
the user's purchase list just
as if they purchased
it themselves.
And that's great
for self-service,
they can then tap
it to download it.
But we are also providing
an MDM command
that allows the organization
to tell the device to install
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that app, which will
then be a managed app
on iOS allowing enterprises
to get the right apps
on their employees' devices,
allowing schools to make sure
that the students have the
apps that they need to learn
and not be taking up class time.
So that's great.
That's how to get the
apps on the devices.
What about revoking a license
when an employee leaves their
job or student graduates?
Well, when the command
to revoke that license
from that particular user
is sent to the store,
that app will just
no longer appear
in that user's Purchased list.
That of course means that
it can no longer be updated
or redownloaded on
additional devices that has
that same iTunes
account logged in.
This will be notified that that
app has been revoked and prompt
to buy, which I'm
sure will make those
of you app developers happy
to buy their own copy.
Now, because the security model
is different on iOS from OS X,
there are some differences
in exactly how the Apple
behaves once it's been revoked.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
On iOS, because apps are not
allowed to exit themselves,
the OS itself will enforce
that if the app will not launch
after a 30-day grace period
allowing the user time
to purchase their own copy.
On OS X, the app will
need to check the receipt
and once the receipt has
expired after that grace period,
the app can then quit on launch.
And for those of you
OS X app developers not
yet checking receipts, there's
a session later this week
that will teach you how to do it
and I will give you
all the details
at the end of this session.
All right, so that's
the end user experience.
Now, let's talk about what the
MDM product developers will need
to do to support
this new system.
And it really breaks down to
three areas of functionality.
First, authenticating this
organization's account
with the Volume Purchase
Program,
sending a user an invitation
to link their Apple ID
to your organization
and I'll talk much more
about that in a moment.
And then of course the
heart of the matter,
being able to assign licenses,
to be able to revoke them
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and then assign into
some other user.
So let's talk about
each one in turn.
The organization will
obtain a secure token
from the VPP website
where they're going
to purchase their
content in bulk.
This works great because
then you don't have
to store their credentials
for them, you just need
to provide URI for them
to enter their token.
It's relatively long-lived
but will currently plan
to expire after a year.
So, it is something
that they will have
to do periodically
but not frequently.
Now, user invitations.
This is a really
important part of the system
that preserves user privacy.
We don't want to force users to
reveal their private Apple ID
to the organization or
the school that's going
to provide them with
this content.
So there's a one-time
process to link their Apple ID
with the organization providing
content in the iTunes Store.
The MDM server will request
an individual URL for the user
that they are tracking in their
system and then be able to use
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that URL to construct
an invitation
and they can send it via
email, construct a web portal,
or send it over MDM, which
we think is the best approach
if the user has a
device enrolled
that the MDM server knows about
and we'll show that later on.
Finally, the process
of the assigning license
couldn't be easier.
The MDM server can--
once it's authenticated,
the account with the iTunes
Store can request the list
of app and book purchases
that organization has made.
They can send request to
say assign this list of apps
and books to these
lists of users.
And then, if desired,
that's already sufficient
to get the content out to
those users, but if they want
to tell the device to
install the app on the device,
they can send the
MDM command out.
Revocations are the opposite.
They can send a list of
revoked licenses for this app
from these lists of users.
However, book assignments
just like code based model,
it's still permanent, a
transfer of ownership.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We decide to add that
to the new system
because that will enable
MDM providers as well
as organizations to use the
same system to manage both types
of content, but for
now at least,
book assignments are permanent.
All right, let me
give you a short--
walk you through a short
architecture diagram
to give you another
way of thinking
about the way the system works.
Each organization will go
to the [inaudible] website
and purchase whatever
app and book licenses
that they wish to have.
That information flows
into the iTunes Store.
The MDM server can query the
iTunes Store for those licenses
and then send up requests
to make assignments.
Once that's been done, the
device can check in with the--
the device will be notified
to pull its Purchased
list and update its UI.
At that time, again, the user
can freely download those
assigned apps and books or the
MDM server can send the command
down to the device to tell it
to download particular book
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
or books-- sorry,
particular app or apps.
All right, so let's get down
another level into details
of how these APIs will work
and how you'll use them.
There's a common URL prefix
that then you'll append
the specific service
that you want to use.
Now, the various tips and
advice that I will pass along
through the remainder of
this section of the session.
One-- Important one is not the
hard code, those service URLs.
They may change over
time but the ser--
the VPPServiceConfigSrv
will always be able
to provide you the
latest service URLs.
You'll provide the parameters to
these services as JSON strings
and the secure token
that I mentioned
earlier will be provided
with all service requests
to authenticate the call.
What you'll get back
is also in JSON format.
If there are any fields
that don't have a value,
those will not be included.
And, if for some strange
reason there's an error,
you'll get both an ErrorNumber
and user readable ErrorMessage
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that you can provide
in your UI to the user.
I want to clarify that.
An ErrorMessage will map
back to a single ErrorNumber,
unique ErrorNumber but each
ErrorNumber may represent a
number of different user
visible ErrorMessages.
And just to give you an
idea of the kinds of errors
that may happen, of course,
they'll never be any errors
but you probably should
handle them anyway.
All right, now let me walk
you through a specific example
of how you would use
one of the services
and this service is the one
where you actually
associate a particular license
with a particular user
effectively assigning it
to them.
Provide some information
including the secure token,
call the service, and then the
response might look something
like this where you get
some additional details
about the license that's been
assigned including its ID,
whether it's revocable or not.
Some other details
about what that app was.
You also get all the
details about the user.
And there are several different
ways to reference the user
and I'm going to cover
that in a moment.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So breaking this down
into their various tasks,
you need to perform and the
services that you'll use
to perform those tasks.
I already mentioned
the VPPServiceConfigSrv
that you'll use to
fetch the current names
for all of these services.
The registered VPPUserSrv is
what you will use to obtain
that individualized invitation
URL to construct the invitation
to invite users to
link to the program.
There's a service that will
allow you to get all the details
about a specific user including
any licenses currently assigned
to that user.
You can of course get
a list of all the users
in your organization including
fetching only the users
that have been modified
since the last time you
downloaded the list.
You can also request a
list of every license
that that organization
has purchased including
if there is a user
assigned to any of them.
And then finally, the pair-- the
one that I showed you an example
of that actually
assigns a license
to a user and then revokes it.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
There are a few additional
services
that performs an important
housekeeping tasks including
if you want to update
any of the user metadata,
if you want to store
some additional metadata
for the organization, and if
a user leaves the organization
for whatever reason or no longer
needs to be provided assets,
you can retire that user
and disassociate
their iTunes account
which will also revoke any
revocable licenses currently
assigned to that user.
You can of course later reinvite
that retired user if desired
by passing along their
previous user string
to the registered service.
Now, I mentioned earlier
there are a number
of different user
concepts within the system.
So let's talk about that now.
The first is your MDM
solutions idea of the user.
That's represented in the system
by the client user ID string,
which is typically
going to be a UUID
and this may be the
representation coming
out of the directory
that's feeding users
in groups into your solution.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
The second is the VPP--
the Volume Purchase
Programs ID of the user.
And that's represented
by the user ID.
Finally, there's
the user's Apple ID,
which again we don't want to
reveal to the MDM solution
and the organization,
so you will receive
Hash of that Apple ID.
So there's three kinds
of users can be combined
at the two different key forms
or the ways that represent--
or referring to a
particular user.
The user ID is just
a single long
and then the other form is tuple
of the client user ID string,
again typically UUID and
the Hash of the Apple ID.
Now, these two key forms
have a one-to-one association
at any one given time,
but that's not immutable,
that link can change if a
user is retired and reinvited.
So, let's talk a little
about the user ID key form.
This one is very easy
to track as it's just
that one single long
integer, and as I mentioned,
it's always tied to exactly
one client user ID string
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
but that reference can
change, and in fact can change
when the user accepts
the invitation.
So, I'm going to illustrate that
again with a little diagram.
So, at this point, the
MDM solution has its idea
of what this user's UUID
is from their directory
and has called the
register service
to obtain an individualized
URL for that user,
which now is identified
with user ID2 .
That invitation sent
out to the user
and when the user accepts it,
the MDM server will be provided
with the Hash of that Apple ID.
Now, let's imagine that
for whatever reason
that user is retired, and in
fact this is not the first time
that this has happened,
there was a former user ID1,
but now retired that link,
generate a new invitation
for user ID3 which could be
sent out to the user again
which could accept-- who could
accept it with the same Apple ID
or different Apple ID.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, let's talk about
the other key form based
on the MDM's servers
idea of the user.
Now, this more directly
maps between the MDM user
and the Apple ID be it Hash.
What you'll see is that
that hash will be null
until the end user has
accepted the invitation.
Once the user has accepted the
invitation that hash uniquely
and of course opaquely refers
to that end user's Apple ID,
however, there is a potential
problem here when you send
out an invitation
for a particular
client user ID string.
If that invitation,
for whatever reason
and let's say a student
forwards their invitation to one
of their classmates,
two different Apple IDs
can accept that invitation.
There's no way to prevent that
but this is almost certainly
something the admin is going
to want to know about.
Primarily because in that case,
there will be two MDM users
and two VPP users and they
will allocate two licenses
for an app perhaps
but they will not get
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
to two different Apple IDs,
two different actual
users on devices.
So again, let me illustrate
this with a simple diagram.
Imagine two different MDM users.
The MDM server generates
or requests two different
invitation URLs and sends
out those invitations.
One of them is accepted
with a particular Apple ID
and the other one is
accepted by the same Apple ID.
And this is the state
that you want to detect
and alert the user of
your admin console of.
So again, emphasize that there--
there's only one
active VPP user account
for any given client user
ID string at one time.
You're going to use that
string to identify this
if you're using this
key form as opposed
to the user ID VPP key form.
If you want to get a retired
user back, you'll also have
to provide the Hash that
you had for that user.
So now I want to pass
along some advice from some
of the engineers on my team who
are the first to adopt this API
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and they have some
things that they'd
like me to share with you.
So one important decision is
which key form you want to use
and they strongly recommend
that you choose one of them
and always use that consistently
because if you want--
if you try to mix them,
you're going to have
to very carefully keep
them strictly in sync.
Next, I want to talk about
a few individual areas
of the system, first, users.
When choo-- I've already
mentioned this several times
that when you're choosing
what to represent each user
in your MDM Solution, you
want to pick a Primary Key
that won't change so you
don't want to use a username
or an email address
'cause you won't be able
to change this once they have
been invited and enrolled.
We strongly recommend a UUID.
You can make your server
the truth for user accounts
but you're going to have to
handle retired accounts then
which you can always fetch using
to get VPP user service
'cause users may unenroll
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
from the service,
you may retire them.
You can always reregister that
user and send a new invitation
but of course that may be
linked from a new Apple ID.
One important reason to keep
track of retired users is
that if you have actually
transferred any irrevocable
licenses for books because you
won't want to assign another--
if the user was retired by
accident or for whatever reason,
the student came back to
school, you don't want to end
up transferring a second
irrevocable book license to them
when they already have one.
Next, let's talk a little
bit more about licenses.
So similar to not relying on
the names of the service URLs,
you don't want to assume
that you know forever
which license types are
revocable and which are not.
You want to always use-- is
that irrevocable attribute
to determine whether a
particular license can
be revoked.
Another important consideration
is how to handle the difference
between assigning a
license to the user
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and actually sending
the MDM Command
to tell the device
to install that app.
You can assign licenses before
inviting the user has accepted
the invitation and associate
their Apple ID but you may want
to wait until they've actually
accepted the invitation
and that you have a
hash for their Apple ID
because you don't want to end
up assigning licenses to users
that never actually used them.
And you want to incur-- make
it easy for organizations
to prevent that from happening.
Now similarly, you can make
the MDM Server the truth
for revocable license
assignments but you don't have
to worry about tracking
unassigned license IDs
because when you call that
service to assign a license
to a user, it will pick one
of the unassigned
licenses from the pool.
However, once you've assigned
a revocable license you do want
to track those because
you'll need the license ID
in order to revoke them.
Finally, when thinking about
installing apps in the command,
you've probably in the UI want
to separate the assignment
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
from the installation.
It may seem at first like a
great idea to be able to do both
at once but because of
the hugely scalable nature
of the iTunes Store,
there may be some delay
in the notification of--
to the device that
assignment has been made
and if the command comes
in before the assignment,
before the device
knows it's entitled
to that app, it will fail.
There's also the
possibility that a student
for whatever reason may
have signed out with
that iTunes account and if the--
that account is not signed in,
the device won't know that
it's authorized for that app
and again, the command
will fail.
So in summarizing, we
have made some big changes
to the App Store
Volume Purchase Program.
We've added revocable
app assignments.
We've allowed new systems
that also support
permanent book assignments.
There's a new MDM
Command to tell the device
to install whatever apps
are assigned to them.
All of these is fully
integrated with iOS Managed apps
so that organizations
can be confident
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in using this new system while
still protecting their secured
data being used by those apps,
whatever those apps may be
and all of this works really
great with OS X caching server
so that even if a
school for example needs
to assign a thousand copies of
20 apps to all their devices
on campus, they can only--
they only have to download
each app once to their site
to the caching server.
And with that, I'd like to turn
to our final section
of the session today.
And I know some of you might
be wondering what I mean
by Streamlined Device
Enrollment.
Well, those of you
who have worked
on MDM products have already
had to solve this problem
of how do I establish
that initial connection
from each device back
to my MDM server.
Some of you have created
apps for the App Store.
Some of you created web
portals but those require
that the organization using your
product then train their users
how to use those apps,
where to find them,
how to complete the enrollment.
Some of you have documented
how to use our own tools
like Apple Configurator to
complete that initial step.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But wouldn't it be easier
if we gave you this.
[laughter] An easy button
for device enrollment.
We think so.
We think this will be great
both for the organization
and for the end users and
that's what we're doing.
We're adding a new
enrollment method solely
for devices purchased
by an organization.
This is not for BYOD but for
organization-owned devices,
there's two steps.
One for the organization, they
need to provide a small number
of settings for how they want
this enrollment to be performed
to this new Apple service
and we have integrated the
enrollment process right
into the Setup Assistant in
both iOS 7 and OS X Mavericks
to give the user the
standard out-of-box device
experience [applause].
So let's talk about
how this will look
from both the organization
and the end user perspective.
So what's the workflow
for an organization now
using this new service?
Well, they hopefully
order lots and lots
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of Apple devices from us.
They assign those devices
to this new service.
They decide which settings
that they want to use
for those devices to be enrolled
and they can use different
settings for different groups
of devices, for example
different schools.
They receive their shipment of
the devices and they hand them
out in the box to
their end user.
That's all they have to do.
[applause] So what does the
user do when they get this box?
Well, they open it just
as if they purchased it
from the Apple store.
They begin walking through
the Standard Setup Assistant.
They choose their network
then they're prompted
by your MDM Solution for
credentials to authenticate
who they are to make sure
that only authorized
users are enrolling
in the Device Management
System deployed
by that organization, that's it.
So let's start talking
about a little bit of--
few of the details.
There are a couple
of critical settings,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
the most important one
is the URL for enrolling
in your Device Management
Solutions.
There's also an option the
organization can decide whether
or not they want to allow
the user to skip enrollment
or whether they want to make it
mandatory and prevent the user
from preceding through
setup and using the device
without accepting enrollment
in Remote Device Management.
There are a few additional
options specific to iOS devices,
first of which is that you--
the organization could decide
that they want to
supervise these devices.
You may not realize
what that means,
you'll no longer be required
to use Apple Configurators
Supervised devices.
It can now be done
over-the-air using this new
enrollment service.
[applause] I alluded to
this earlier but in addition
to that change to supervision,
we're also separating
the concept
of supervision giving you access
to additional restrictions
in settings from the
pairing restrictions
and the organization can now
choose whether or not they want
to prevent the supervised device
from pairing from--
with any Mac.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[applause] We think this
will be great in schools
where students-- where
schools really want
to have the additional
restrictions
but also want their students
to be able to connect a Mac--
or sorry connect an iOS device
to a Mac to get their photo
or video content off to
edit in iPhoto or iMovie.
And then finally, I think
you'll like this as well,
for devices that have been
enrolled using this new service,
the organization can also
choose to prevent their users
from removing MDM enrollment
so that they can be confident
the device will continue
to be enrolled and
manageable over-the-air.
Now that's all great, that's
all about device enrollment,
but we didn't stop there either.
We also wanted to streamline
the entire setup experience
so that part of the Settings
of this new service also allow
an organization to decide
to skip certain panes
in the setup assistant.
For example, if a school doesn't
want to ask their 10-year-olds
to decide whether or not they
want a location service is
enabled or whether they're going
to send diagnostics
back to Apple.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So again, let's turn from
the way the feature--
the system works to
what work you need to do
and it again breaks
down to three areas.
Similar account authentication
to the new App Store VPP.
You'll need to create a settings
editor for that small handful
of settings for the--
your customers to be able
to specify how they want
their devices enrolled.
And you'll need to be able to
communicate with the new service
to tell it which groups
the device you should get
which settings.
So walk you through an
architecture diagram
to show you how this will work.
The organization
purchases devices.
They add those devices
into this new service.
Your MDM Solution talks to
the enrollment service to find
out the list of devices that
are eligible for this service,
pushes up the settings for
groups of those devices.
Once that's been done,
as devices start to go
through the setup assistant,
they contact the enrollment
service to get their Settings
and enroll in your MDM Server
which can then manage them
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in all of the ways we've talked
about earlier via
the MDM Protocol
and Configuration Profiles.
So again there are a
couple of these tasks
and there are services
that you'll use
to perform those tasks to
get started with the service,
to get the account details
for that organization,
to fetch the device list,
handling the settings
whether you're defining them
and pushing them up to the
service and then assigning them
to groups of devices and
fetching the settings back.
And then some more
housekeeping services
that fetch specific
details about devices.
If you have to remove
devices from the services
if an organization sells them.
Or to remove settings that
they're no longer using.
And so just to further encourage
you to integrate this service
as quickly as possible,
I just want to quickly
illustrate what the OS X setup
experience looks like today.
You have to go through these 14
screens to get to where you want
to be which is that user-- using
their Mac to work or learn.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now I know you want
to see what it looks
like using the service fully.
But I don't want to show
it to you in slides.
I'm going to ask you to Jussi
and Chris to come back up
and show you the-- both of
these systems working together
so that all of you are really
excited about going off
and integrating both
of these services
so that together we can
provide our customers
with an outstanding
setup experience
in education and enterprise.
So we're going to show
you from taking the device
out of the box, enrolling it in
MDM and assigning it content.
So guys, take it away.
>> Jussi: All right,
thank you Todd.
So I'm not going to have
my Mac Book in a box.
So this is basically
imagine if this came in a box
on a container of like
thousands of Mac Books
and this is the setup that
I'm going to go through.
So power it up and I get
to see some of the panes
that I usually see, and it's not
that this setup experiences
is really slow today, I mean,
we have pretty fast going
through the setup today.
This is just faster than
what we have right now.
So I set my country,
set my keyboard
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and the first thing that's--
or it still needs
to pick a network.
So let's go to ACME Wi-Fi, I
you have to Wi-Fi, go ACME.
And what Todd is--
Todd is explaining is
that we have MDM sever that has
implemented this streamlined
device enrollment protocol.
So now, my setup assistant
has just contacted Apple.
So what happened is
that the configuration
for this machine was found
in the Apple services
and it basically said
you are called ACME, Inc.
Here's the number to call if
you don't know what this is
and would you like to
apply these settings.
So-- and in this case, I have
an option of skipping this
or accepting the configuration.
So I will accept
this configuration.
And now what happened is
that the configuration
contains a call home URL.
So the MDM server
has a new feature
for authenticating users.
So this system is no longer
talking to Apple services.
This now talking to an MDM
server that will be hosted
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
by the organization would
be in the company or in--
at school and the username
password is what I would use
to log in to that company's,
that school's systems.
So I will be-- in this
case, I will be Jack.
And Jack is going to
have a password hopefully
that I can remember.
And now we are done
with the configuration.
So I still have to
create a local pass--
local user for this machine.
And there it goes,
Jack and that's it.
So if you saw the-- saw the
screens that we have before,
we didn't get to see a do I
want to register this machine
because this was
organization purchased.
It doesn't really make sense
to have the individuals
still register it again.
I didn't get to see an Apple ID
because the organization decided
that that may not be applicable
for this system or this user.
And here we are.
We are ready to set
the system or ready
to put the system in use.
And I land finder with a
wonderful and new background.
Here we go.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Let's go surfing.
And when I go to my
preferences I noticed
that I already have a
enrollment profile here.
So I have a system-- I have
a profile that was installed
on the system as part of
enrolling into the MDM service.
So here I have remote
management already enabled
and now the organization
can send me any profiles
that are applicable
for this user
on this system and
I'm good to go.
So that's the setup
experience on the Mac.
[ Applause ]
So an iOS device, so I
have an iPhone in the box
that I did cut open, sorry,
so we get to have the
nice woosh effect.
Here we go.
And I did power it
on, sorry, I cheated.
So it's already on.
So if and go to the
phone please.
There we go.
I could learn lots
of languages here.
I think that means caller.
Let's go set this up.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Here we go.
So again, I get to
choose my language.
I'm still in the US.
I get to choose my
ACME Wi-Fi again.
So here, the configuration
profile that was downloaded
from the streamlined device
enrollment service now got the
record from Apple again.
And we know that
this device needs
to be configured for the system.
And you'll notice that I
don't have an option to skip.
So I have to go through this
setup assistant or the iOS setup
with this configuration
from my organization.
So there's no option to opt out.
So again, I'll configure
this device.
And again I'll log
into my company account
and again this device
is now talking
to the MDM server
authentication part that's going
to be implemented by all the
new MDM servers out there.
So I'll log in here, and I
get configurations set down.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And here we are installing
the configuration
from a company and
I'm good to go.
So here I am in my home screen.
I have a basically a clean
system but now if I go
to my settings and
look at some details.
So notice that this
device is supervised.
So this device was not
connected to Apple Configurator.
It was never plugged
into any system
but it's already supervised.
So I can now take
advantage of some
of the new supervised features
like installing [inaudible]
apps, doing other restrictions
that wouldn't apply to
non-supervised devices.
So this is supervision without
tethering using the streamlined
device configuration service.
And other part is
that you'll notice
that I have configuration
profiles installed.
And if I'm looking
at my MDM profile,
there is no remove button.
So the only way-- [applause]
thank you, yes, yes please.
There's no way for the user
to exit the management state
and if they restore the phone,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
basically erase/install
the phone,
it will still have the
streamlined device on its record
in the cloud-- in
the Apple Cloud
and because this device is
required to have this setup,
you can't bypass the setup
assistant and you'll always end
up this management
state [applause].
OK, so that's fine and good.
We seem to have lack
of application.
I could spend days just looking
at stocks and playing videos.
But let's see what
apps this user has.
Well, it's an out-of-box system
so I don't have an
Apple ID signed in.
So let me go and sign
up with my ID here.
Oops. Oops.
OK, this is the demo
typing that's happening.
And you would spell that right.
There we go.
And then hopefully,
password is right.
And now log out.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So we have an Apple ID and
now we have some updates.
Oh sorry, not updates,
applications.
So this user has already
purchased some applications.
So here's my application list.
And these are effective
with the free apps by Apple.
So this user has a free Apple ID
with no credit card
associated with that.
That's kind of an anomaly.
Usually people do
buy apps for cash.
But in this case, this
has no CC on file.
So Chris is now going to assign
applications to this device.
So Chris is going to send
a list of applications
that the organization
has licenses for, OK.
Oh I'm sorry.
I'm skipping ahead of myself.
So how do we get this
user into this program?
Yes. We need to invite
that person.
And there are many ways
of getting the user
invited into program.
We can direct the user into a
portal or we can send an email
and we can send a
push notification.
So first I'm going
to show you an email
that the MDM console
is going to send.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And that'll show up in
the device momentarily.
So here we have an
invitation email
that is basically asking the
user to enroll their Apple ID
with the corporate email.
So Apple does not know
what this email address is.
This is only for
the user to know
and then the user can
bind their Apple ID
and this corporate email account
and then they can
assign licenses.
But-- and this email is a URL
and that URL can be on a webpage
so depending on how the
MDM vendor would want
to implement this.
As long as they find a way to
display that URL to the user
and have the user click
that, then we're good to go.
So another way to
invite this user is
by sending a push command.
And now we get to log in to
the App Store or we get--
we are brought back
to the App Store.
And we know that OK,
this organization would
like to assign applications
for this ID.
And yes, now we got
three pushes.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So yes, I will allow apps
to be assigned to this.
And now, we have the user ID
that the email was sent to
and the account that
was associated
with this ID, now
they are linked.
And I've been just sitting here
and what Chris has been doing
as the survey admin, he is
assigned applications to me.
So they just show up
in my purchase list.
So I guess I have
a checklist thing.
I need to know what to do.
I have a things app
I need to learn math.
So these are the licensees
that the company has licensed
and assigned to this user.
And they show up in
my purchase list.
But even better way instead
of just having me pull
this application stone,
the administrator
can actually request
that these apps be
installed on this device.
So because this device is
supervised, Chris can now send
and request app install command
and these applications just
start showing up on the device
without me doing anything.
[ Applause ]
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So-- and that is the demo.
Back to Todd.
Thank you.
>> Todd Fernandez: Thank
you very much guys.
All right, well before I sum up,
I just wanted to point something
around what Jussi said
about the ability of the--
even if the user wipes
the device, it's enrolled
in this new service, but
you're still going to have
to go through it each time.
You can't get around it.
This actually makes for a
great experience in schools
if a student graduates and
returns the device in school,
all they need to do to prevent--
prepare it for the next student
for the next year is wipe it
and hand it to the new student.
All right, so what have we--
what have we talked about today?
Well, we've added a huge
number of new capabilities
to configuration profiles and
MDM protocol for all of you
to adopt in your MDM solutions.
We've made big changes
to the App Store
Volume Purchased Program
to add revocable app assignments
as well as book assignments.
We've created a brand new
service that you just saw
to make it really easy for both
organizations and end users
to get their devices enrolled,
remote device management.
And I'm really looking forward
to working together with all
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of you to get these
systems integrated
into your MDM products so that
we can make managing large
numbers of Apple
devices a pleasure
for both the organization
and each of their end users.
Now I hope the next question
in your mind is, Todd,
when can we get started?
Well, I have some good
news, the documentation
which includes details on how
to obtain your VPP Test
Accounts is available today.
And the device enrollment
accounts will be ready
next month.
So with that, I will leave
you with the pointers
to that documentation for
both the updated MDM protocol
that covers both the new App
Store Volume Purchase Program
as well as device
enrollment service,
an updated configuration
profile reference
that contains all
the new payloads
and changes we've talked in the
first section and the new forum
that you will hopefully
join to begin discussing how
to integrate these best
into your products.
As we've alluded during the
session, there are a number
of sessions that will be
interest to app developers
in particular who want to learn
more about how to take advantage
of these new management
features in their apps including
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that receipt session I
promised on Thursday afternoon.
And with that, I will thank you
very much for your attention
and look forward to
seeing you in the lab.
[Applause]
[ Silence ]