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.
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 groundctl.com.
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 groundctl.com, 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.
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 (https://sixcolors.com/post/2016/03/apples-lightning-to-usb-3-adapter-bri...).
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.
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!
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!
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 updates...no 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?
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, remove single app mode from mdm
- 2. exit the application (we have a way of doing that remotely)
- 3. use mdm to push a new version of the app
- 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?
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.
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.
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/GN-GoPro.app/_CodeSignature
Remove the existing provisioning profile and replace it with the one tied to the cert I'm signing with.
$ rm -rf ./Payload/GN-GoPro.app/embedded.mobileprovision
$ cp GoProAppDistnProvProfile.mobileprovision ./Payload/GN-GoPro.app/embedded.mobileprovision
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/GN-GoPro.app/Info.plist
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/GN-GoPro.app
Payload/GN-GoPro.app: 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?
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?
We regularly receive questions from our customers asking if it's possible to add the Apple devices they already own to their DEP account. We had a chance to speak with Apple Business Services recently to understand the specific situations where this is possible and want to share it with anyone who it might be of use to:
Hello again all! Sorry I haven't been posting up-to-the-minute updates from WWDC as I have in the past. The new company has me pretty busy. However I did attend yesterday's presentation on What's New in Apple Device Management. Apple has already posted a video of the presentation online.
The session was mostly a recap of what arrived in iOS 9.3. There's a good reason for that: iOS 9.3 delivered an uncommonly huge number of new features for enterprises. The way I see it, it's like we got to open our presents early.
There are a handful of new things in iOS 10, too. If you want a summary, I recommend Jack Madden's recap.
What are your thoughts?
iOS 9 was plagued with a bug that prevented customers from deploying VPP licenses of Custom B2B apps directly to devices using the new iOS 9 device-level assignment feature. This was a widespread bug that affected all MDM products.
Just today, Apple released iOS 9.3.2. In the release notes there's a fix that references this bug. Looks like Custom B2B apps should be device-assignable now.
More info here:
Here are the original Apple release notes:
iOS 9.3 supports a feature called Managed Lost Mode. This allows you to put a supervised device in lost mode via MDM without the need for an Apple ID. Also supported is location tracking while the device is in lost mode. This is a boon for companies trying to eliminate their dependency on individual Apple IDs.
Here's a writeup with more information about managed lost mode:
- Comparison of MDM Providers (773,783)
- Complete List of iOS User-Agent Strings (393,981)
- How to get remote viewing/control of the IPAD screen via internet or preferably 3G? (253,701)
- Apple Configurator vs. MDM (156,977)
- iOS Devices (134,775)
- Mobile Device Management (99,983)
- Apple Profile Manager (97,760)
- Batch Apple ID Creator (90,575)
- Gartner Magic Quadrant for MDM (2014, 2012, 2011) (87,933)
- SimpleMDM (84,519)
Mobile Management Provider changed by 7PMDM 2 days ago
Mobile Management Provider changed by taylor 1 week ago
Story added by Aaron Freimark 1 week ago
Mobile Management Provider changed by taylor 1 week ago
Mobile Management Provider changed by MDMforALL 1 week ago
Story added by Aaron Freimark 2 weeks ago
Story added by Aaron Freimark 3 weeks ago
Story added by brendan 3 weeks ago
Story added by Aaron Freimark 4 weeks ago
Story added by Aaron Freimark 4 weeks ago
Wiki Page changed by Aaron Freimark 4 weeks ago
Forum topic added by taylor 5 weeks ago
Forum topic added by Mahesh 6 weeks ago
Story comment by taylor 7 weeks ago
Wiki Page changed by Aaron Freimark 7 weeks ago
Story added by Aaron Freimark 7 weeks ago
Mobile Management Provider changed by Aaron Freimark 7 weeks ago
Forum topic comment by Elizabeth Hale 23 weeks ago
Mobile Management Provider changed by Simo Kari 24 weeks ago
Forum topic comment by jpref 24 weeks ago