Deep dive podcast on iOS 11 in the enterprise

No votes yet

A few days ago I joined Russ Mohr and Jack Madden, for a discussion of iOS 11 in the enterprise. That discussion is now a podcast, hosted by

Here's how Jack summarized the discussion:

  • First, we recapped some of the improvements in iOS 10.3 (and 9.3) and how customers have been using them—iOS really has a lot for kiosk and enterprise-owned use cases.
  • iOS 11 is coming out tomorrow. You can watch the WWDC session about MDM, the deployment guides should be updated soon, and now you can even read the full MDM protocol documentation without a developer login.
  • We gave an overview of the Device Enrollment Program, or DEP (as well as the merits of pronouncing it “Dep” versus “D - E - P”).
  • With iOS 11, any device can be brought into DEP. This could be big for refurbished devices.
  • Tethered management has a lot of advantages in many corporate-liable use cases; we also covered caching in macOS 10.13 High Sierra, as well as the future of potential caching hardware.
  • Blocking iOS updates is still an often-requested feature, and there’s no MDM control for it—and likely there won’t ever be. So for network admins that have to deal with a bunch of 2GB iOS 11 downloads on Tuesday, good luck!
  • Aaron talks a bit about Ground Control, a unique (and EMM-neutral) tool in our industry.
  • Is it time for Apple to make some improvements on the BYOD side? How about connecting devices to multiple MDM servers, with limited rights? Or making privacy more explicit? This is one of Jack’s soapbox topics (see here); we’ll see what comes up in a dot version or iOS 12 or 13.
  • We talk Face ID—many of the questions and answers that we had around Touch ID should apply here. MDM can prevent Touch ID from being used to unlock devices, we should find out soon if this will apply to Face ID.
  • The Apple Watch Series 3 has its own cellular connection, but for now, all signs point to it being dependent on a host iPhone. As such, it will inherit a few MDM controls: IT can enforce wrist detection mode, and on supervised phones, IT can block pairing. But it’s also easy to see that this device will evolve to be independent in another generation or two, and then probably have its own MDM support.

It was fun to record, and I hope this becomes a recurring feature.

iOS 11 & Provisional DEP: Questions and Answers

Your rating: None (1 vote)

What is Provisional DEP?
Apple Configurator 2.5 can add any iOS device to Apple’s Device Enrollment Program (DEP), so you can use this streamlined process for setup and enrollment.

Before this change, Apple required proof of ownership of a device in order to approve DEP enrollment. In practice, this usually meant that only new devices purchased from specific resellers were eligible. Now any iOS device can be enrolled into DEP. But there are some specific conditions to pay attention to.

What are the requirements?

  • Your devices must be updated to iOS 11.
  • The process will erase devices. It will not preserve data.
  • You need to plug in devices into a Mac (once) to start the process.
  • The technicians running the process will need credentials to the DEP portal.
  • You may need to manually assign devices in the Apple DEP portal and/or MDM server to complete the process.
  • For 30 days after enrollment, users may choose to leave DEP (and MDM). DEP is permanent only after the 30 day provisional period has elapsed.

What? Users may leave DEP within 30 days?
For a period of 30 days after provisional enrollment, users are able to remove MDM and opt out of DEP. The lock screen will display small text, instructing users that they can “leave remote management in Settings:”

And in Settings > General > Device Management, users have the ability to “Leave Device Management.”

These options appear even if you set MDM enrollment as mandatory. After 30 days, these notices disappear. At that point the device is permanently in DEP.

What happens when a user decides to leave remote management?
When a user ops out of DEP the device erases itself, removing any corporate (and personal) data. The device also removes itself from your MDM server. Finally, the device serial number no longer appears in the DEP portal.

After a user leaves remote management, you may use Apple Configurator 2 to add the device to DEP again. The device will begin a new 30-day provisional enrollment.

Is there a way to remove that button and notice, so users can’t opt out?
No. The notice and button are there for 30 days.

While provisional, if I erase the device does it remain in DEP?
Yes. The device remains in DEP after it is erased, just like standard DEP.

I have multiple MDM servers. Does Configurator allow me to assign an MDM server to the device?
No. MDM server assignment must be done in the DEP portal ( just like standard DEP. But if you have a default MDM server assigned, the choice is respected.

I have multiple DEP profiles in my MDM. Does Configurator allow me to assign a profile to the device?
No. Profiles must be assigned using your MDM server, just like standard DEP. But if you have a default profile assigned, the choice is respected.

If I “disown” a device using the DEP portal, can I use provisional DEP enrollment to return it to DEP?
Yes. This is good news, since previously “disown” was permanent.

Does this help with BYOD or personal devices?
No. DEP and supervision remain appropriate only for corporate-owned devices.

I have 1,000 devices that I want to put into DEP. What can I expect from the process?
Provisional DEP is intended to deal with exceptional devices, a small percentage of an otherwise all-DEP fleet. If you want to enroll a large number of devices, you may expect some challenges.

First, devices will need to tether devices to a Mac. Provisional DEP is not an over-the-air operation. You may, however, use a USB hub to work on several devices at once.

Second, be aware that Configurator will prompt for a DEP portal login. Most companies restrict employee access to the portal, for good reasons. You will need to provide credentials to your technicians. Note that Apple requires all DEP portal logins to use two-factor authentication, typically via SMS, so you may not be able have technicians share an account.

Third, the enrollment process will erase devices. So you must expect to re-provision devices as part of this process. If you already have a streamlined provisioning process for DEP devices, you’ll be in good shape. But if DEP is new to your organization, or to this particular use case of your devices, you may need to architect a new process. (A tool like GroundControl can dramatically speed device provisioning, especially for shared DEP devices.)

Finally, all devices will need to be updated to iOS 11 before the process begins. Configurator or GroundControl can update devices efficiently. You will want a high quality USB hub for this part, to make the process as robust as possible. Hubs from Datamation and Cambrionix are recommended.

Do these provisional devices work with GroundControl’s DEP workflows?
Yes. To GroundControl, these devices behave like every other DEP device, during and after the 30-day provisional period. Once you use Configurator to add these to DEP, you may use GroundControl to image the devices, restore a common backup, manage your MDM, etc. Add a supervision identity to your DEP profile to streamline GroundControl’s management.

Will GroundControl incorporate these new Configurator features?
Provisional DEP enrollment is a one-time operation. Today, we recommend you plan to use Configurator for this one-time addition of devices, then use GroundControl to provision the devices and for ongoing automated maintenance.

We are looking at options to support this without Configurator. The requirement for DEP portal login, with two factor authentication, makes this process difficult to incorporate at scale. But we continue to do research, because we understand our customers don’t always have Macs available.

Apple could easily improve the process with a spreadsheet upload to the DEP portal, or a public API. Perhaps you’ll help us make a feature request?

Tethered Caching is much better in macOS High Sierra

Your rating: None (1 vote)

Apple has posted an article detailing changes to tethered caching in macOS 10.13 "High Sierra." Caching used to require a Mac running their $20 Server app, but no longer.

  • Content Caching is now built into every Mac
  • Prior to macOS 10.13, Tethered Caching was launched from the command line. Now it's a simple checkbox in the "Sharing" preference pane
  • Caching recommends Ethernet, but Ethernet is no longer required
  • A number of advanced options are available if you hold down the Option key, including specifying parents to create a hierarchical caching system
  • Tethered continues to work great with GroundControl for mass-device provisioning

I'll post more info and screenshots when we get closer to release.

Alert: Apple requires action on September 19 for DEP to keep working

Your rating: None (2 votes)

Apple has posted a notice that new Terms and Confiditions for the Device Enrollment Program (DEP) will be posted on September 19. This is a big deal, because until the agreement is accepted, new DEP devices will not automatically enroll into MDM. (Existing DEP devices won't be affected.)

DEP administrators can't approve the new agreement; it must be approved by your DEP "agent." The agent is the person who originally set up DEP for your organization. There is only one agent per organization.

You may want to log into the DEP portal today, so you can be absolutely sure you know who your organization's agent is. And make sure that person isn't on holiday next Tuesday.

Apple says:

If you don’t accept the agreements

Devices that were assigned to a Mobile Device Management (MDM) server in Apple School Manager or the Device Enrollment Program won’t be affected. If you Erase all content and settings on a device, the device is still assigned to the same MDM server and the same settings are applied during setup.

However, these conditions apply until the new agreements are accepted:

  • Apple School Manager instructors and managers can reset user passwords and send or print login information, but other site functions will be disabled.
  • Device Enrollment Program admins (other than the Agent) won’t be able to log into the Device Enrollment Program portal until the Agent accepts the updated agreements.
  • In ASM and DEP, you can’t assign new devices to your MDM server, even if you have selected the option to * automatically assign new purchases to a specific MDM server.
  • Your MDM server might report an error message like "403 T_C_NOT_SIGNED” when communicating with Apple’s device management servers.

The third bullet is the one to pay attention to. Most organizations automatically assign new devices to an MDM server. This will stop working on September 19, until you accept the new agreement.

It seems impossible to accept or even review the new agreement prior to September 19. Hopefully your organization can be prepared to halt deployments during this period.

A curated list of enterprise mobility articles and resources

Your rating: None (13 votes)

Mobile Crusaders: bookmark this page right now. Jack Madden, my favorite observer of mobility in enterprise, has compiled his favorite resources into an indispensable guide. And I don't say that only because he mentions me! It's up to date (despite the URL) and almost perfect — if only GroundControl was included next to Configurator it would be. Smile

Apple’s new Tethered Caching is so good you may want to buy some Macs

Your rating: None (7 votes)

Tethered caching is a major new system from Apple to speed up device provisioning, app installs and app updates. It’s most helpful in places where many iPhones and iPads are clustered together, such as healthcare, retail, and hospitality. But it only works if you have updated iPhones and Macs (yes, Macs).

Tethered caching provides two separate but related features: tethered networking & app caching.

  • Tethered Networking: When active, all network traffic from the iOS device will be routed through the USB connection and out the Mac’s Ethernet connection. This includes web pages, MDM instructions, and push notifications.
  • App Caching: App Caching dramatically speeds up app installs if you are doing repetitive provisioning. As your tethered devices download apps, the Mac inserts itself as middleman, and will save copies of each installed app. Subsequent installs of the same apps (on the same or other tethered devices) are much quicker, since the apps load from the Mac’s hard drive instead of the Internet.

Continue reading our analysis at

Running tethered-caching at Startup

Your rating: None (5 votes)

Apple’s new tethered-caching service is an extremely powerful new addition to iOS management, at least if you are using Macs to aide your deployments. Once you get it running properly (see this article), you’ll probably want it running all the time. But it is not quite obvious how to get the service to launch at startup. The service actually requires an interactive Terminal, so normal launchd daemons can’t be used.

Over at, we're really excited because it complements our device provisioning software so well.

We figured out how to launch tethered-caching at startup, by using a Terminal command document and a little visudo magic. Check out our step-by-step instructions for launching tethered-caching at startup.

Push notifications to iOS require WiFi link when Ethernet used

Your rating: None (5 votes)

There appears to be a bug in iOS (10.3.1) with push notifications and Ethernet. We use the Apple Lightning to USB 3 Camera Adapter and a USB Ethernet adapter to provide network to devices in the field. During a troublesome deployment we discovered that the Apple Push Notification Service (APNS) does not establish a connection if the WiFi radio is off or not joined to a known network. That WiFi network does not need to have valid internet, or even DHCP available, the device will choose a self assigned IP and then the APNS connection will use the Ethernet adapter.

I imagine this has something to do with how APNS behaves when both Cellular and WiFi are available. I'm curious if Apple TV has a similar bug, I imagine not, given the fact the Ethernet is built in and likely a more common scenario. Although a seldom used feature, the Lightning to USB to Ethernet configuration was feature in a past keynote (

MDM commands are triggered by APNS messages which means MDM is not functional in an Ethernet only environment.

It was a tricky one to discover, requiring packet captures, and other network analysis to isolate, I hope this helps someone else in the future.


More about tethered caching

Your rating: None (6 votes)

Apple had posted a knowledge base article on the new tethered caching service in macOS 10.12.4:

Apple releases iOS 10.3 with some improvements for the enterprise

Your rating: None (4 votes)

Apple today release iOS 10.3 for iPhones, iPads, and iPods. The update includes a few features of interest for enterprise users:

  • Wi-Fi Restrictions prevents users from manually selecting Wi-Fi networks (that's a big one!) — supervised devices only
  • The ability to tether devices to a Mac to proxy network connections through the Mac
  • A caching server built into the Mac to support tethered app and iOS updates
  • Lots of new MDM features aimed at Apple TV
  • OAuth 2.0 support for Microsoft Exchange
  • More fine-grained settings for cellular configuration profiles
  • A few changes for education users
  • Configurator 2.4 — supporting iBooks, ePubs, and PDFs

Want to know more? I recorded a podcast with Russ Mohr from MobileIron. Have a listen below!

Listen to "The Impact of iOS 10.3 on the Enterprise" on Spreaker.

New host for Enterprise iOS, some content lost

Your rating: None (3 votes)

Hi all! We had some trouble with our old hosting provider, so I've moved the site to a new (and generous) host. Unfortunately about 2 months of content has been lost. That sounds like a lot, but since I've been so poor at moderation lately, it doesn't really amount to much. Still, my sincere apologies to the authors of this content.

I'm going to work on streamlining this site, making it once again relevant to the modern times. The MDM Comparison is so far out of date, it will be archived. There are other resources for this information now.

My primary work continues to be running GroundControl, an enterprise-class replacement for Apple Configurator. I haven't posted much about GroundControl here, but I'll start to. Besides the shameless promotion, I genuinely think the product could be a very useful addition to your mobile management toolset.

More to come!

Enterprise Development and Distribution Options

nosillok's picture
Your rating: None (8 votes)

In the past, our company developed applications for clients who wanted to put on them in the App Store.

We just finished up our first enterprise application (a total of about devices will have the application). We need some help on the best way to get our enterprise application to a number number of clients. The client does not need the application to be loaded on the 40-some devices until Jan.1 so we have some time to look at all of our options. Up to this point we have been testing with the customers using HockeyApp (ever since Apple bought TestFlight, we hate it). It should also be noted that we are currently working on scaling this application so that we can start selling our product to other customers with similar needs. A few other notes to narrow down our criteria:

  • We would rather not have this product go through the Apple App Store
  • Originally, we thought the enterprise program would be perfect to sell this product, but we found out that Apple says we cannot build apps under our own enterprise program and sell them to clients
  • The VPP program looks like it has its advantages, but Apple takes 30% of our revenue?? AND the app needs to go through the review process upon submission and thanks
  • Is anyone just selling apps to customers and using HockeyApp or something similar for distribution?

Honestly, so far I really don't like any of the options I have been researching. Can anyone please give some advice on how we should be moving forward?

reliable update of Single App Mode application

marcmeyer's picture
Your rating: None (7 votes)

We have an application that runs in "kiosk" mode: unattended, under MDM, and in Single App Mode.

To update the application with a newer version, we are forced to:

  1. 1, remove single app mode from mdm
  2. 2. exit the application (we have a way of doing that remotely)
  3. 3. use mdm to push a new version of the app
  4. 4. reapply the SAM profile from MDM

as a result the newly updated app starts up.

However, at times an IOS update is pending and when the SAM profile is removed, a dialog pops up asking whether to update the IOS version. This then backgrounds the application making it impossible to exit in step 2, and continue the process until someone manually intevenes.

Has anyone found a way to do this without falling afoul of this scenario?
Some have suggested blocking the updates with a proxy server. Anyone tried this? Does the proxy server have to be installed continuously or just when SAM mode is turned off?


Problems resigning complex iOS Apps for Enterprise Distribution

normangl's picture
Your rating: None (2 votes)

I'm working for a worldwide company that requires the apps we produce to be initially resigned for enterprise distribution for testing purposes before submitting to the App Store. This is so that testers who are based in branches all over the world can rigorously test and scrutinise the apps we produce before they are submitted onto the Apple App store.
I notice how the simpler apps we produce can be so easily resigned using iResign, where I just need to point to the enterprise distribution provisioning profile and the In-House distribution certificate and the apps then resign, install and work fine. Smile
However, some more complex apps we produce only install & work when I resign using Ad hoc distribution or developer cert & provisioning profile, but fail when I resign them for In-house enterprise distribution.
I find these more complex apps that deploy watch kit and have many entitlements in the AppID are the apps I cannot resign for enterprise distribution using simple iResign, because they just fail to install or crash upon launch. Sad
Are there any restrictions on what the apps signed for In-house enterprise distribution can contain? Compared to what apps signed for Ad hoc distribution can contain?
Also, all the Apple account certificates in my keychain have a certificate id in brackets after the certificate name other than the certificate for In-house enterprise distribution. See item 2 in the list below after the following terminal command, which may be the source of the problem:

$ security find-identity -v
  1) DF3E9EB66DDFD9464C9E9C8B7978C031DB5E7478 "iPhone Distribution: Smart Phone App Design Ltd (5T87Z3V53D)"
  2) 65AB5C69BF03D8DCB98B468BDB075A69CA06C6FA "iPhone Distribution: Smart Phone App Design Limited"
  3) E8768633790130B0262C7F1E6AE3BB67BAEE1A93 "iPhone Developer: Gavin Norman (XKD25VK538)"
  4) 24AD3C52FBA815EB890C0DC9423A8724780727D1 "iPhone Developer: Smart Phone App Design Limited (D4ECBYFEZX)"
  5) 64A424D387BEFCF8C10C08D8358994A21517564E "iPhone Distribution: Smart Phone App Design (H6**934YRM)"
  6) C9C0B4B054B23DC0EA52C37ABC9517C50CFEA3C2 "iPhone Developer: Smart Phone App Design (ZP36FJ4Y5Z)"
  7) 4F652CB23B920C831643D64B75A7184626F3F361 "iPhone Distribution: Gavin Norman (AJT88LS67C)"
I have even tried resigning from scratch using the following process:
$ unzip GN-GoPro.ipa
Remove the existing signature by going into the application folder
$ rm -rf ./Payload/
Remove the existing provisioning profile and replace it with the one tied to the cert I'm signing with.
$ rm -rf ./Payload/
$ cp GoProAppDistnProvProfile.mobileprovision ./Payload/

Change the bundle identifier (in the example below to com.smartdesign.app7.resigned.gntest)
$ /usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier com.smartdesign.app7.resigned.gntest" ./Payload/
I use an entitlements.plist file when code signing even if the app requests no additional entitlements.
I grab the appname.xcent from a build, copy it somewhere and then modify it to contain the bundle id I'm resigning to and my in-house enterprise distribution team identifier.
Now resign the app...
$ /usr/bin/codesign -f -s 65AB5C69BF03D8DCB98B468BDB075A69CA06C6FA --entitlements entitlements.plist Payload/

Payload/ replacing existing signature
$ zip -qr GN-GoPro_resigned.ipa ./Payload
Using the above approach, the in-house enterprise apps resign, but fail to install unfortunately.
Anyone experienced with In-house enterprise distribution resigning, I would really appreciate your help?

Prevent update to iOS 10

jammmet's picture
Your rating: None (9 votes)

We have around 1000 iPad Mini 2s that are about to be setup (reset, supervised, enrolled in Meraki MDM, VPP app install).
However, the app only works on iOS 9 and breaks on 10. Since we'll be doing to setup over the period when iOS 10 is released, we want to make sure that during the 'reset' phase, they get iOS 9.3.5 and not 10 (which will soon be the 'latest' iOS). Any way to prevent this from happening and make sure the devices only get iOS 9?

Recent Activity