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, 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 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 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 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.

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 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 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 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]. 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.

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, 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 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 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. 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. 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 and show off those new managed app enhancements that you were so excited about and they are really cool. So, guys take it away.

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 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.

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-- 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.

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--

So, that's Managed Open In, and now back to Todd.

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 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 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. 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 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 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. 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 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 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.

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.

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. 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 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. 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 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 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 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 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 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 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. 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 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, 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.

[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.

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 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.

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 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 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. 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.

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.

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. 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, 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. 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. 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. 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.

So-- and that is the demo. Back to Todd. Thank you.

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 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 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]