Good morning. Welcome to session 702 Managing Apple Devices.

Wow. I wasn't expecting that enthusiastic of welcome this early in the morning. I'm Todd Fernandez, and I am very happy to be here with you even at this ridiculously early hour for techies like me. Although for some of you, this may be the middle of your day if you work in schools our otherwise have to wear a tie to work. Many of us are far more likely to see this hour at the end of a long night of coding than at the beginning of our day.

Now, I open by recognizing our differences because this session's content is intended for a diverse audience. From Indian vendors, who need to learn how to take full advantage of the powerful device management capabilities that we've built into iOS 8 and OS X Yosemite, to app developers who want to understand how their apps may be used in schools and businesses, to administrators who need to know what changes are coming in the OS releases this year.

When I stood before you here last year, I was thrilled to announce 2 huge leaps forward in managing Apple devices. In the addition of managed distribution to our Volume Purchase Program and the introduction of the Device Enrollment Program which Craig highlighted in the enterprise section of yesterday's Keynote. It's hard to believe there was an enterprise section at the Keynote, but it was very exciting to see.

When we set out to create the device in Roman program, we did so after wondering, why does it have to be painful to do that initial configuration of your devices before handing them out to their users? And we started by asking a simple question. Why can't it be as easy as just un-boxing that device and handing that iPad or that iPhone or that Mac to its user? And it turns out many of you are asking the same question. And I'm very pleased to report that our customers are just as thrilled by the transformative nature of this new service as we had hoped.

One noteworthy example is Immaculata La Salle High School in Florida who believe that we, indeed, turned this dream into a reality. And they proved it by completely replacing their fleet of iPads with 600 new iPad Airs including restoring all the student apps and data from iCloud in 2.5 hours. They made a wonderful video showing just how they did it. And if you've never seen the Device Enrollment Program in action, I highly recommend checking it out.

So since we last met, we've been very busy launching managed distribution last fall. The Device Enrollment Program a few months ago. And we've also been busy adding all these features to fill in the gaps and smooth out the inconsistencies between iOS and OS X. So that vendors, like some of you creating device management tools, and the administrators, using those tools, have a much easier time managing all their Apple devices.

This session is going to cover the entire life cycle device management including both new tools existing tools and technologies and all the changes coming in iOS 8 and OS X Yosemite. And we'll show you how they all come together to provide a great experience for both the administrators and their end users.

From enrolling devices in your management solution of choice to distributing content to all those devices to the day to day ongoing management tasks that come up as time goes on and needs change. So let's dive right in and talk about enrolling devices. Of course, we're going to spend a fair amount of time on the device enrollment program, the best way to do this. I'll also talk about Apple Configurator as an alternative way to enroll your devices.

You also need to be aware of how to manage Activation Lock on supervised devices and be thinking about that at enrollment time. And then I'll conclude with what's coming in this year's OS releases. So before we go any further, I want to make sure that everyone understands what the Device Enrollment Program is and is not.

So it relates, you know, audience participation. Let's get going, although I appreciate all the responses already, the Device Enrollment Program is not a MDM server. Come on, say it with me, Device Enrollment Program is not an MDM server. Thank you. Though you'll note they're both 3 letter acronyms, those of you with eagle eyes with note they're not the same 3 letters.

In fact, the Device Enrollment Program is the best way to get your devices enrolled in whatever MDM solution you're going to use. It's an easy button to get your devices in your MDM server. It's really 2 parts: A way for administrators to specify which settings they want to use when their devices are enrolled in their management solution.

And the integration of the completion of that enrollment process right into the normal set of assistant process that the user will go through on both iOS and OS X. As I mentioned, we launched this in February with devices eligible that are purchased via direct sales in the U.S. And we've heard all of your feedback loud and clear that you'd like to see us expanded to additional countries and channels.

So I'm very pleased that, although we've only launched this a few months ago, we've already expanded access to our neighbors to the North. Any Canadians here? I'm so sorry about the Canadians, but, in fact, the Rangers knocked my Flyers out in the first round; so get them next year.

We've also made a number of other changes already since launch that I wanted to point out. Devices are now eligible up to 3 years in the past if you've purchased them up to 3 years ago. And there's some enhancements to the portal that allow you to set a default MDM server so that any new device purchases with automatically be assigned to that MDM server without you needing to take further action. You can also now see which administrators assigned which devices to which MDM servers.

And another, coming soon, expansion of eligibility is that when devices that are in the Device Enrollment Program are replaced by service, those devices will soon be remain in the Device Enrollment Program including, retroactively, devices that have been replaced over the past 3 years. We think customers will really appreciate that too.

So let's quickly recap exactly how this service works before I go into details, especially for the MDM vendors. Customer purchases devices, that information is fed into the Device Enrollment Program. When the customer provides their account information to their MDM solution, the MDM solution can download the device information from the program. The administrator can then specify their settings and upload those to the program.

Then, when users open the box and start walking through the setup assistant, the device receives its settings from the Device Enrollment Program which tell it to enroll with the MDM server. And I also, again, want to emphasize that once that happens, Device Enrollment Program has done its job. It's out of the picture, and your MDM solution is the only thing that's talking to the devices. So we're going to talk about 3 topics a few moments here related to the Device Enrollment Program and how best to integrate this into your MDM solutions.

So the first concept is, where should the ultimate repository of the truth relating to the program, the devices and the settings reside? The device information should really be in the Device Enrollment Program and treat that as the truth. You can always fetch that information from the service to your MDM server. But the settings that the administrator decides to apply to certain groups of devices, your server should really treat itself as the truth for that. It can always upload new settings to the program.

One caveat here to keep in mind, though, is what I explained on the previous slide: Even if the administrator changes the settings that are in the Device Enrollment Program for a particular device or devices, those devices will not see those settings until the next time that they go through activation after wiping and going back through the setup assistant.

So if the device is already enrolled and you happen to change the setting to say, Well, now I want it to be supervised, that won't take effect until the next time the device is set up. All right. So disowning devices, you may be thinking, what does that mean? Well, this removing a device from the Device Enrollment Program. And I'm here to scare you.

Our recommendation is to not implement this feature. Why is that? Well, and if you're going to break Rule No. 1, you need to really, really how many "reallys" did I put on there? really make sure they understand the consequences: That they will not be able to undo this action and get that device back into the program.

So, again, we recommend following Rule 1. All right. Our final topic is thinking about the combinations of two of the specific enrollment settings that you can configure for a device: Whether it's supervised or not, and whether that MDM enrollment can be removed or not by the user on the device.

And there our own Profile Manager has taken the approach of not separating these settings. That if you choose to supervise a device, it automatically, the MDM enrollment is not removable, that top right box. The bottom right box is forbidden. If you try to upload settings where the device is not supervised and the MDM enrollment is not removable by the user, the service will reject those settings.

The lower left box may be interesting, again Profile Manager doesn't well, that's what profile manger does if you don't check the supervised box that it's completely open. It's not supervised; end user can undo the MDM enrollment. Those 2 are really the interesting ones. The kind of half one in the upper left is allowed, but probably not super interesting to supervise a device but still allow the user to un enroll from MDM.

So that's a couple notes about the Device Enrollment Program. Let's talk a bit about Apple Configurator. So again Apple Configurator is also not an MDM server. I want to make sure everyone's clear about that. But it is an alternative way to install enrollment settings on a particular iOS device over USB. As an alternative to using Device Enrollment Program over the Air.

Once those settings have been loaded to the device, the actual requests that go to the MDM server to complete the enrollment are indistinguishable from whether they were done the settings got there over the Air or over USB. However, you can teach your server to distinguish between the 2 if you check to see if that particular device that's enrolling is in the list that you've gotten from the Device Enrollment Program.

Also, if a device has already gotten its settings from the Device Enrollment Program, Configurator will not overwrite those settings. One additional caveat is that delivering your enrollment settings via the Device Enrollment Program is the only way that you can make your MDM enrollment not removable by the user.

Another recommendation and one that we followed ourselves in Profile Manager is that it's probably a good idea to offer administrators the option to disallow installing settings over USB if you want to ensure that they only get your institution's devices only get the settings that you specify via DEP. That would present a user from using Configurator to install settings that allow enrollment in your MDM server without supervising for example.

Let's now talk a little bit about Activation Lock Management. So by default a supervised device does not allow the user to enroll in or to enable Activation Lock. But there is now a way that we introduced in the spring that MDM can request a bypass code that allows the MDM server to later or the administrator to later clear Activation Lock without needing the user's password.

At that time, there's also a MDM command that can tell the device, well, okay, now you can allow the user to enable Activation Lock. So you want to do all of this at enrollment time. If, in fact, your institution wants to use Activation Lock, which is a great feature. We also recommend that once you retrieve that Activation Lock bypass code that you provide access to the administrator to in the UI because it may be useful to maybe enter it manually on a device that for whatever reason is not currently reachable by the MDM server.

There are 3 new MDM commands to retrieve the code, to then delete it from the device so that no one can grab it off the device if they get physical access to it, and then, of course, to enable or allow the device to enable Activation Lock. And we strongly recommend that when you're completing the MDM enrollment, that, at that time, you always retrieve and then clear the bypass code from the device because it's only available for 15 days after the device was supervised.

You should also save that bypass code even if a particular device is un-enrolled from MDM because Activation Lock may still be enabled. And you may still need to clear it. And the device can later re enroll. And there won't be another opportunity to get a bypass code until the device is wiped and re supervised.

So those are the topics I wanted to cover on enrolling. But I'm also happy to tell you that there's important change in how the device responds when the enrollment is being completed in Setup Assistant. And I know your servers are all real excited. The administrators have no doubt specified lots of settings and apps and all sorts of things. They want to deliver to the device as soon as it's enrolled; however, the device isn't ready to respond to all those requests while the user is still completing Setup Assistant.

So now when any of these MDM commands are sent to the device while it is still in the Setup Assistant, it will return the "not now" status. So your server can know, hey, device isn't ready. I'm going to wait until it returns success for that enrollment. And then you can start completing your enrollment tasks or configuration tasks. So without further ado, I'd like to show you how this works, and I'm going to invite my colleagues Jussi Pekka and Mark up to show you a demo of enrolling devices.

All right, thank you, Todd. So here we have an out of box, freshly delivered, new iPad. Basically it was purchased by the institution and it didn't go through some boiler room. It was just handed straight to the user and our Profile Manager server this is our MDM server for this demo knows about this device because the time between Device Enrollment Program and Profile Manager and the device the purchase was made through the channels. So we know that this device is configured for our services. So I'm going to walk through the setup as usual. I'm going to pick my language. Go pick my country.

Connect to my network. So at this point, the device is now talking to the Apple Services and obtaining its activation information. And as part of that information is the notice that we are now in the DEP and we got prompted for enrolling in the MDM server. So just in a second we are still returning some information. And now we are talking to our server. So this is as far as DEP has talked to the device. Now we're talking to our MDM server.

And I can find more information about our instance. So if I need to know what to do next, I can call the ACME Help Desk. And now I go to the next. And you see that when I go forward, I'm now prompted for my user name and password.

And I cannot bypass this; so I do have to enroll this. So this device has been configured to be supervised, and the MDM profile is mandatory. So I have no way of bypassing this step. So I'll provide my log in information and move on. And now we're downloading the profiles from our MDM server.

So, again the DEP phase has been completed, and now we're talking to our management server. And Mark has set some screens to be bypassed here, so we're not seeing registration and other pieces. And while I complete my setup logging into my iCloud account, I'll have Mark show you the setup in the backside.

Yep. So Jussi is going to finish setting up his iPad. And I want to walk you through how in Profile Manager we've implemented this UI to support configuring Device Enrollment Program. So on the left side you see the devices that my server has retrieved from the Device Enrollment Program. My server is configured to download these devices, and then I have Jussi's iPad selected here. And you can see the enrollment settings that I've got selected here. Our first option is whether to turn on this configuration for this device or not.

You can also put these configurations on device groups as well. So you can get a whole collection of devices get the same settings. So we have this checked on because we wanted to send the settings down. The next option is whether or not the user is allowed to skip enrollment. And, as you saw in the case of Jussi's device, he's not allowed to skip enrollment; he's going to be prompted for credentials, credentials for his directory server.

Our next option is whether or not we want to do over the air supervision of the device. Now, in addition to being able to supervise the device, when you supervise the device, you also have the option of locking the MDM Profile so it can't be removed from the device. In our case, we've combined those into one option because we think our customers, whenever they supervise, they're going to want to have locked MDM. But if you're a third party MDM developer, you can always break that out and have it as a separate option.

The next thing is whether or not you want to allow pairing. So I have that turned on so the device can pair with another Mac if you want. Next is to request credentials for enrollment. You saw Jussi's device was prompted for credentials. And then there are various things that we can skip during the setup show or skip during the Setup Assistant. In our case, we have Apple ID enabled because we want to caption on, Jussi's device will get Activation Lock enabled.

So Jussi is finished actually setting up his device. So I am going to show you, our security settings for the device right now show that Activation Lock is not enabled. But I do have the Activation Lock bypass code. This what Profile Manager grabbed from the device when it was enrolled.

If I update my info now that he's done, we'll see in a moment here that Activation Lock is going to change to yes. And find my iPhone is enabled, is set to yes. So when this device comes back to me, I'll be able to run this clear Activation Lock if Activation Lock is still enabled. And I and clear that and hand this device out to the next user. So back to Todd.

All right. Thank you, guys.

So Jussi and Mark just showed you how you can enroll and supervise an iOS device using the Device Enrollment Program and how to configure the enrollment settings that were used using Profile Manager. But, of course, that can be done with any MDM solution that supports the Device Enrollment Program. And we hope all of them do.

Mark showed you how Profile Manager had retrieved the Activation Lock bypass code as it completed enrollment of that device. And then Profile Manager actually automatically allows or there's a setting, enrollment setting which I don't know that Mark showed that the administrator can choose to always automatically allow Activation Lock once it's retrieved, successfully retrieved the bypass code.

So let's move on to the next section of our talk and talk about distributing content to our devices. We're, of course, going to talk about the Volume Purchase Program and managed distribution. We'll talk a little bit about managed apps and then conclude with the significant enhancements in iOS 8 and OS X Yosemite to fill in some gaps here.

So, again, to recap, managed distribution allows the administrator to buy licenses instead of codes, which can be revoked and reallocated to a different user for both apps and books. And we provided API so that MDM solutions can integrate the service into their solutions. And it's currently available in 10 countries.

So, again a refresher of exactly how this works: The administrator can purchase apps and books in the VPP Portal, that information is stored in the iBookstore and the App Store. When they provide their account information to their management solution, it can download information about which apps and books have been purchased and are available for assignment. It can send assignments up to the iTunes Store and credit a particular app or book to a user account.

When the user configures their Apple ID on a particular Apple device, they'll see those assignments in their purchase list and can download the bits directly from the store just as if they had purchased them themselves. And, also, the administrator can send MDM commands from the server to the devices to say download this app to make sure that it is actually installed on that particular device.

So, again, dive into a number of topics related to the Volume Purchase Program to give you some advice on how to best integrate this program into your solutions. Starting off again with where should the different pieces of truth reside? And the VPP service itself should really be the truth for the status of user enrollment, whether a user has accepted an invitation and associate the their Apple ID with the VPP user, which licenses have been purchased, as I showed on the previous slide, as well as tracking in irrevocable book assignments that have been made.

You're MDM server should actually be the truth for everything else including revocable app assignments. And you might be wondering why shouldn't that be in the VPP service? Well if your MDM solution supports group assignments, you'll need to keep that information in your MDM server because there's no way to store group information in the VPP service. So if you're going to be able to reconstitute that, you're going to need to have all that within your database.

Let's talk a little bit about account management. When a particular administrator provides their credentials, their VPP account to your solution, and you want to establish that initial connection with the Volume Purchase Program you're going to need to check the client context attribute. And if it's empty that means that no other server has claimed this account or is using this account. And you should go ahead and claim it by providing the host name of your server and a unique a GUID so that you'll be able to tell whether your server is still the one managing.

If the client context has a value and it doesn't match the GUID that you have for that server, some other server is actually using that account. And you're going to want to alert the administrator that some other server is managing the licenses tied to this account and ask them to confirm that they, in fact, want this server to take over that account. That may, in fact, be the right thing if they're transitioning from one server to the next.

And then further, whenever you re establish the connection to the service, you need to check client context again to make sure that your server is still the one that's connected to this account. If it doesn't match any longer, you, again, need to stop making requests to the service and alert the administrator that this other host name has now claimed this account so they can take appropriate action.

If I've mentioned invitations already, that's part of bootstrapping this program is that the administrator needs it to invite each user to link their Apple ID to this particular VPP account so that licenses can be assigned. We strongly recommend that you do this invitation via MDM. You can easily send that invitation via an MDM command directly to an enrolled device. It's much more secure and reliable. Email is a fall back if you have a user you need to invite that doesn't currently have an enrolled device.

But there's a concern that you need to be aware of that because the invitation URL, there's an example on screen, is for the apple.com domain. Many mail servers will treat an email coming from your server's domain, including a URL from apple.com as a phishing attack and they filter them out.

There are a number of alternative ways to avoid this problem. You could create your invitation email URL that brings the user, first, back to your MDM server before redirected them to the VPP URL. Or you could integrate the invitation process right into your user portal if you have one.

Let's spend a few moments talking, again, about user IDs relating to Volume Purchase Program. I showed this slide last year. There are really 3 ideas of who the user is from the perspective of the MDM server, from the perspective of the VPP service, and the end user's Apple ID, which your MDM server will never see directly but will see a hash of it to protect the user's privacy.

Now, this is would be very simple if we lived in the ideal world where each user had one and only one Apple ID associated with your VPP account and would never change that Apple ID. In this case, there would be a simple one to one mapping between all 3 of these representations of the user.

Sadly, as many of you may be aware, we don't live in an ideal world. In the real world, multiple VPP users can accept their individual invitations with the same Apple ID. And you need to be aware of the implications of the sharing of Apple IDs. Specifically if you've assigned a license to a user that than is connected to that particular Apple ID. If you revoke that assignment, it's going to revoke it from every Apple every VPP user sharing that Apple ID.

Also, if you try to assign an app or a book to a VPP user that's associated with an Apple ID that already has that app or book assigned, that second assignment will fail. Another issue in the real world is that users can, after accepting an invitation with one Apple ID, can disassociate from that Apple ID and associate and accept that invitation with a different Apple ID. This becomes a problem if you've assigned any irrevocable book licenses to that Apple, that retired Apple ID. And you'll have to keep track and think about whether you want to allocate another irrevocable book license to the new Apple ID or not.

So the MDM server's representation of the user, the client user ID string, is something that's under your control. And we strongly recommend you pick a value that will never change, for example, the user ID from your directory services where you're getting your user and group information. You shouldn't choose something like an email address which can change.

And it's very simple. I had to have a slide with some SQL on, I'm sorry. It's very easy, then, to look up which VPP account that that particular MDM user is associated with. Whether it's just registered and you've sent the invitation or actually associated, whether the user has accepted it.

And, finally, the representation of the user's Apple ID who's accepted the invitation takes the form of an iTunes store ID hash. And you should track this as soon as a user has accepted an invitation. New in iOS 8, there's now a MDM query, not just in iOS 8, it's also in OS X Yosemite, a query to get that hash value so that you can know whether the Apple ID that's configured on a particular device changes.

You won't know exactly what the Apple ID is but you'll be able to tell if they've disassociated and re-associated with a different ID. As I mentioned already on the previous slide, you're going to want to track those retired values if the user switches to a different Apple ID, again, so you can keep track of any irrevocable book assignments.

There's another new change that will allow you MDM vendors to provide a better user experience in your tools for users outside the U.S. that we now report the country code that the account is tied to when you get your information down from the service so that you can fetch the proper app metadata, artwork, description, app name from the correct iTunes Store.

So managed apps is not a new concept. We've had it for a couple of iOS releases. It's a way for enterprises to keep better control over the data and documents tied to particular apps. It works with both App Store and enterprise apps. The managed apps must be installed via MDM with the install application command and with the management flag set on the app itself.

One limitation is that if the user has already installed an app, the MDM server cannot convert it to manage retroactively. However, the server can, of course, detect that an app is unmanaged and then alert the administrator so they could take action outside of MDM, if necessary, to have the user delete that app and the MDM server push it out again.

Managed apps work with Managed Open In a new feature in iOS 7 to help, again, prevent data leakage from managed apps to unmanaged apps. So that if you have a particular app that has sensitive documents, you can treat it as managed. Turn on Managed Open In, and then users will not be able to open those documents in other apps like well, I won't name any.

So you might imagine, I talked about filling gaps and eliminating inconsistencies. We have managed apps so what are we introducing in iOS 8? Well, of course, managed books. And just like managed apps, managed books works with both iBookstore books where you can, just like managed apps, tell the device to download a particular iBookstore book and treat it as managed. That that book must be published, purchased via VPP even if the user has it.

One difference between managed books and managed apps is that you can retroactively manage books in contrast to manage apps. Even if the user has it installed. This is very useful in schools to ensure that a particular title is installed, make sure the students have all their work and the dog didn't eat it.

Turning to enterprise books, you can, just like enterprise apps, can install the MDM and remove PDFs, ePubs, and iBooks Author books. These documents or these titles are stored in a different location than iBookstore books with Class C data protection. There are also a number of restrictions that we're introducing in iOS 8 to, again, give institutions more confidence that the sensitive data will be protected and not escape their control. They can disable iCloud backups of these enterprise books so that they just stay on the device where they're installed and also disable the user's highlights and notes on that title from being synced to other devices.

For you MDM vendors out there, it's going to be pretty straight forward to implement this. Just like there's an install application MDM command, there's now an Install Media MDM command where if it's a managed iBookstore book, you'll just specify the iTunes store ID. And if it's an enterprise book, you'll specify a URL back to your server to download the bits. You need to specify a persistent ID that's under your control so that you can uniquely identify each enterprise book that's being installed and its kind and then the matching remove media command.

There are a few limitations. Just like managed apps, is requires the app installation and the end enrollment, right, to be able to install managed books. And managing iBookstore books requires that you've, again, purchased it via VPP and that the App Store is enabled on the device that you're pushing an enterprise book to.

Another distinction between managed apps and managed books is that the MDM query to obtain the list of installed books will only show managed books and not every book that's installed by the user to preserve user privacy. And finally, again, to allow the institutions to keep control over these enterprise books and their sensitive data, enterprise books cannot be synced off a device using iTunes. So turning from what's new in iOS 8 to what's new in OS X Yosemite, we're going to fill another gap. And we are, have added the ability to install non App Store apps via MDM on OS X. Thank you.

You can thank you Jussi when he gets back up here. So you can specify a signed flat package containing an app via this MDM command, the install application MDM command which is now supported on OS X for non App Store books. And, in fact, your MDM solution can do the same thing that Profile Manager has done that you can support the administrator's providing you with just a .app bundle as long as you package it up as a signed flat package and send that over the MDM command. So without any further ado, instead of talking more about this, I'd like to ask Jussi and Mark to come back up and show you installing and removing enterprise apps and books.

All right. Thank you, Todd. And I'm just going to go into my iBooks library. So here we have some books that we already downloaded. I've been a keen reader of the Human Interface Guidelines, apparently. And we just downloaded the Swift book so we're going to learn some new things. And Mark's now going to push a PDF for the device.

So this is going to be an enterprise book. And this is will have the same open rules as any other managed assets on the device. So we'll have data protection between applications. And we won't be able to share the book anywhere else. So this our fancy new PDF that just got installed. And now, since this is a managed book controlled by our MDM solution, Mark can also remove the book. So Mark can now remove the book and it disappears from our bookshelf. So that's managing books on iOS 8. And we're.

Thank you. And on iOS we've had the Apple Teaching Store enterprise application so that we have our fancy new Swift application here, ACME Hub. But as Todd mentioned, we also have support for installing applications on OS X. So here we go into our Launchpad and Mark is now going to install our fancy ACME app onto the OS X client and no hands. This is all installed by the system. So sparkles fly and the ACME app landed on the system. So over here's OS X using the DEP app installation. So thank you, Mark. And now back to Todd.

We're going to complete the Activation Lock story to show you, to talk about how you use that bypass code you obtained at enrollment time. Talk a little bit about integrating you're MDM solutions with external data sources. Talk about something new called MDM service config. We'll come on to that in a few minutes. And, then again, conclude with what's coming in this year's OS releases.

So one thing to keep in mind with Activation Lock is, it's a little bit different from some other services. When you get the device information query, and Mark showed this in Profile Manager when he re fetched the device information and it reflected the change and Activation Lock status. There's a key that tells you whether the device thinks it's Activation Locked.

And there's a request that you send not to the device, but to our activation server to clear the Activation Lock and specify the bypass code that you have. Now, because that request doesn't go to the device, the device isn't checking with the activation server, it's not going to know that it's been cleared. So it's going to continue to report that it's Activation Locked to your MDM server.

Also, even after you have cleared on the activation server, the user, if they log out of or remove their Apple ID and log in again, that will re enable Activation Lock. So you want to definitely keep hold of that bypass code even if you've cleared it. This isn't going to, in the real world, going to usually be an issue because typically you're going to use this when you have the device in your hands. But you definitely want to keep that bypass codes because you might need to use it again.

All right. So one of the most important external data sources that your MDM server needs to integrate with is directory services. There are a number of different ones that your server probably supports. However, compared to the database that's back in your MDM solution, most directory services have some capabilities which make them limited in this context.

Usually you can't get a full enumeration of their contents. And there's not an easy way to discover the changes from the last time you fetched some subsection of those contents. They can be intermittently available and slow. So you're going to want to need to mirror some of the information into your server.

In contrast, we've designed both the Device Enrollment Program service and the Volume Purchase Program service to be simple and efficient to mirror that data into your MDM solution. You can fully enumerate the licenses for VPP or the device list for the Device Enrollment Program. And it's easy to get the changes from the last time that you got the enumeration. So you should definitely mirror this information down in your database and not use those services for live access.

Similarly, you're going to want to mirror in the directory services information to get better performance and reliability and all the benefits of your database. But definitely leave the authentication piece in directory services. It's less frequently used, and you need to have a single source of truth for that.

Also, you're not going to want to mirror your entire directory services into your database, of course. You want to just mirror in records that are related to MDM. Next, I want to talk about a new concept that those of you familiar with the StoreBag from iTunes, we could also call this the URL bag. It's something that would make it much easier for tools like Apple Configurator and other device management tools to just ask the MDM server what information they can obtain from it.

We specify this new URI MDM service config that any tool could then make an unauthenticated HTTPS request to your server and ask for it to provide a UTF8 JSON encoded hash for example, the URL for your MDM server's Device Enrollment Program enrollment. This would allow a tool like Apple Configurator to make it much easier for administrator to use it to configure settings because they wouldn't have to type the entire enrollment URL.

They'd only have to type the domain of your server. And it could then ask the server what's your URL and complete that for the user. So we're going to be implementing this in Profile Manager and we strong we would really like to see that in your MDM solutions as well.

So, again, let's turn to what's coming new in iOS 8 in terms of MDM commands and queries. We've seen some of these already. But it's now possible for supervised devices to tell them to set their device name via MDM. You can also clear the restrictions passcode in the user has themselves configured in the settings UI restrictions and set a passcode. That would have prevented, in the past the administrator from overriding those restrictions.

Now, you can send an MDM command that removes those settings and allows the MDM server to configure its own settings. We've already seen the new install and remove media commands as well as the query that allows you to ask which iTunes account is configured on the device via the iTunes Store ID hash. But it's also now possible to query the device to ask, when did it last back up to iCloud? There are a number of new payloads and additions to existing payloads in iOS 8. There's a new VPN connection type.

We've added new plug in content filters to expand on the built in content filters that we shipped in iOS 7. There's a new payload, called Managed Domains, which we're going to show you a little bit later that you can have managed email and web domains that work in conjunction with managed apps and books and managed open end and help institutions keep their data secure.

I think they actually mentioned, Craig actually mentioned the message S/MIME switch in mail yesterday. And it's possible to configure whether that's available to you user for both email and exchange. You can specify a certificate in the single sign-on payload that allows automatic refreshing of the Kerberos credentials without the user having to take any action.

And there are a number of new restrictions, both for unsupervised devices, the 5 at the top including disabling the it's a really cool feature Handoff, but that also may worry certain institutions about data that they consider sensitive transitioning from a managed device to another device outside of their control. We also already saw the restrictions on enterprise books.

And there are 2 new supervised restrictions that you can prevent the user from erasing all content and settings and wiping the device and undoing all that hard work you did to configure that device. As well as a pair for the MDM command that once you've cleared the restrictions, you can disable the user from actually configuring them using the device UI in settings.

Speaking of the device UI in settings, the iOS team has done a lot of work to dramatically improve the end user experience to see the effects of an MDM enrollment and any configuration profiles. An MDM relationship is now represented with a single item that coalesces all the profiles that are installed via that MDM channel showing all the settings, apps, and books that have come down via that MDM relationship with the most important things likes accounts and apps and books and restrictions at the top. What this also means is that users cannot no longer cherry pick and remove individual profiles that the MDM server has delivered to the device because they're just not shown that way.

Another improvement in the settings UI is that if there are particular features like the camera or in the restrictions UI in settings, it will indicate to the user that this particular feature has been disabled due to a profile being installed. So that they aren't confused and need to come to Genius Bar to ask them why their camera's disabled. It's also much easier to see all the certificate details that have been delivered via MDM. And finally provision profiles no longer appear at all in settings because it's handled completely automatically. The device will automatically prune expired provision profiles when they're no longer needed.

One less thing to worry about. Turning to OS X Yosemite, you'll see that we have support for a number of the new payloads. I already talked about on iOS 8 as well as the query to determine which iTunes account has been configured on that particular Mac. And we also have plugged another gap in adding the command that tells a Mac to initiate AirPlay Mirroring to a destination. So without further ado, I'm going to ask the guys to come back up and show you a few things that I just talked about and completing the device duty cycle.

So we go to the settings and we'll see what we have active as manage settings from our MDM server. So you'll notice that you don't have a profile setting under general anymore. This is called Device Management. If I just had regular configuration profiles installed, this tab would be called Profiles.

If I have both Device Management setting and Profiles installed it will be called Device Management and Profiles. So but since we only have the MDM enrollment profile here, I'm going to look into that. And, as you notice, this now a non-removable MDM profile. And you'll notice that every single profile that the server has pushed is now collated into some sensical category. So we have restrictions so you can tell which restrictions have been configured by the server.

And we have applications that have been installed here. And we have also accounts that have been configured. So we don't show the individual profiles that actually configured this. We just collate all this information so that's it's more readily accessible and discoverable. And in more details, as Todd mentioned, we have better information about certificates. We can now actually see the full signatures and how they keyed it up so it's not just like dot, dot, dot.

And you can also have information about other settings that come down. And here we have managed domains. So I'm going to show you managed domains. How those are working in mail. So we are in ACME, Inc. in acmeinc.private. And as I'm going to start composing an email, I'm going to pick [email protected]. And this is now Mark's address.

This is not something that I should probably be sending email to so it's marked as red. If I use a different address, use my acme in private mail that's marked as a valid email that meets our email rules. And this also applies to my sending account so since I have configured this device for iCloud, I also have my iCloud account. So my iCloud account is also marked as not something I should be sending mail with. So that's managed domains inside mail.

And then we are basically done with the device. So now we can return this device to service so the next user is going to grab this machine. And what Mark's going to do, he's going to issue an erase command onto the device. So basically the user has left the company or has graduated from the school and magic happens now.

So we're going to unplug this device and plug to a different device. So here we go. And now we have just received the same device and we're back in the home screen. I'm going to as a new user, I'm going to walk through the setup screens and configure this device. So.

That brings us to the end of our session. I'd like to sum up for, again, the different audiences for this session. If you're an administrator, you should use the Device Enrollment Program if you want to enroll your devices wirelessly or Apple Configurator if you want to do it wired.

You should use the Volume Purchase Program managed distribution and managed apps and books to distribute content to your devices. If you are a MDM solution provider, please support all these services: Device Enrollment Program, Volume Purchase Program, and Activation Lock management as well as all the new futures we talked about today in both iOS 8 and OS X Yosemite. If you're an app developer, for your enterprise we've got this great new page that talks about how you can use iOS to the best effect within your enterprise doing in-house development.

We have a number of resources, again, for developers both MDM and app developers. Our documentation of or MDM protocol, the configuration profile reference, the developer forums for MDM. And if there are any administrators out there, we've got documentation for the Device Enrollment Program and Apple Configurator and a number of discussion boards that are great places to ask your questions and get help, both from your fellow administrators and Apple representatives.

There are a number of additional sessions this week including 2 following this session right here in Pacific Heights. Some of our colleagues that help make that great new UI in iOS and implement a lot of these features. And with that, I will thank you for your attention and hope you have a great rest of the show. Thank you.