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:
So in our environment we have an MDM platform which deliveries a exchange payload. All the information is completed apart from the password field as this expires every 90 days as per our corporate policy.
We also have account changes locked down as we don't allow personal email or apple IDs.
What I am experiencing so far is that when an exchange password expires, the user never gets prompted to input the password again, and doesn't have access to the account (due to the lock down) so they can't update the password!
Does anyone have a clever way of managing this other than moving users into a permissive policy group periodically?!
I have iOS 9.3.1 on an iPad which I am supervising via Apple configurator. It is not DEP enrolled.
I am looking into the what the optimal enrollment flow might be when we need to deploy several hundreds. (If they are not DEP enrolled).
When executing the supervision proces via Apple Configurator 2 then it is activating the iOS devices with the apple ID I am currently logged on with in Configurator. Everything progresses as expected and I end up with a device supervised by my organisation.
However, I am forced to log in with my apple ID AFTER the actual activation. Am I doing something wrong or is the some way of skipping this step?
The purpose of supervising is to avoid no entering the organisation Apple ID several times, which works for activation but iOS still requires me to log in with an apple ID to access iCloud, iTunes, App Store etc.
Hoping someone here has an idea for me. I work with an IOS reseller and we provide technical support to end users. At the moment we use a caching server in each store, and mix that with manually updating customers iOS devices via iTunes. This is a huge part of the business, and we are inundated with customers requiring updates. This means our techs spend all their time updating devices rather than helping customers with tech queries.
I have looked into bring Apple Configurator 2 to streamline and improve the process, but does anyone have any better ideas on how to build a dedicated updates station? Apple Config 2 workflow works really nicely, but management don't want customers data to backup to our devices so I'm a bit stuck.
All we need it to do is: Plug device in, updates device. Preferably by itself. We can do it manually, but anyone have any better ideas?
Thanks in advance!
We have an always-on IKEv2 VPN with a Global HTTP Proxy profile pointing to our internal proxy server.
We are using AirWatch in the cloud to manage the devices.
When the VPN is on APNs doesn't seem to be connecting the devices.
We have opened up the full 188.8.131.52/8 address block into our environment for TCP ports 5523, 2195, 2196 and 443 as described in this apple document - https://support.apple.com/en-gb/HT203609
Do we also need to apply the rule the other way so that the devices can connect back to APNs?
AirWatch seem to suggest that the devices don'e connect back to APNs and instead connect straight back to the console.
Can someone help with this please?
- Comparison of MDM Providers (766,898)
- Complete List of iOS User-Agent Strings (388,866)
- How to get remote viewing/control of the IPAD screen via internet or preferably 3G? (250,102)
- Apple Configurator vs. MDM (155,627)
- iOS Devices (132,107)
- Mobile Device Management (99,119)
- Apple Profile Manager (96,588)
- Batch Apple ID Creator (89,732)
- Gartner Magic Quadrant for MDM (2014, 2012, 2011) (87,053)
- AirWatch (80,745)
Story added by Aaron Freimark 20 hours ago
Story added by Aaron Freimark 23 hours ago
Wiki Page changed by Aaron Freimark 1 day ago
Forum topic added by taylor 5 days ago
Forum topic added by Mahesh 2 weeks ago
Story comment by taylor 2 weeks ago
Mobile Management Provider changed by Aaron Freimark 3 weeks ago
Wiki Page changed by Aaron Freimark 3 weeks ago
Story added by Aaron Freimark 3 weeks ago
Mobile Management Provider changed by Aaron Freimark 3 weeks ago
Forum topic comment by Elizabeth Hale 18 weeks ago
Mobile Management Provider changed by Simo Kari 19 weeks ago
Forum topic comment by jpref 20 weeks ago
Forum topic comment by bugfrisch 21 weeks ago
Mobile Management Provider changed by krypted 21 weeks ago
Mobile Management Provider changed by JAMFSoftware 21 weeks ago
Forum topic comment by spurtipreetham 22 weeks ago
Forum topic added by okta 22 weeks ago
Forum topic added by am.imran.ahmed 22 weeks ago
Forum topic comment by Samuelbrown 22 weeks ago