Apple released the first beta of iOS 10.3 yesterday. Perusing through the notes for Configurator 2.4 beta and macOS Server, it's possible to find several new enterprise management features. While the majority of new features are focused on tvOS (i.e. the Apple TV), there's a nice little gem for those of you with share devices.
iOS 10.3 adds a new restriction: forceWiFiWhitelisting. When set to True, the device will connect only to the wifi networks that have been installed by profiles (config profiles or MDM). As you can see from the before-and-after screenshot above, the UI changes. "Other..." is gone, and discovered SSIDs are no longer listed.
This feature seems aimed at retail and healthcare, where devices are supposed to be locked to a specific SSID.
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 18.104.22.168/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?
Apple's released iOS 9.3 about a week ago, then pulled it for many devices, then re-released it yesterday, hopefully for good. There's a LOT of new features for enterprise in here, and we'll try to break it down for you.
Some of these features require MDM support, so you will need to wait for your MDM to support them. Others only need a configuration profile which you can create with Apple Configurator 2 or by hand (if you are adept at manipulating XML), and then distribute using your MDM. Apple's configuration profile reference is now a public document.
ALL of the new commands require Supervision on your devices to prove that they are corporate-owned. Supervision is available by the Device Enrollment Program, or by the Mac software Apple Configurator, or by using the cross-platform GroundControl (disclaimer: that's my company).
Requires MDM Support
Allows MDM to retrieve the longitude and latitude of a device marked “Lost”, and displays custom text (such as a phone number) on the lock screen. Seems to be the enterprise version of “Find My iPhone” without the hassles of Apple IDs and activation lock.
Home Screen Layout
Configuration Profile: Example
Enforce home screen icon positions, locking apps in place and making them undeletable.
App Whitelist and Blacklist
Configuration Profile: Example
Prevents apps listed (including all built-in Apple apps except Settings and Phone) from being shown or launchable, or specifies a whitelist of apps that are the ONLY ones that can launch. If you try to include Settings in the payload the device will reject the configuration profile. This is a long-awaited feature and we're happy to have it (although we wish it could hide Settings too).
Shared iPads & Education Features
Configuration Profile & MDM support required
Supervised Only with new shared device mode
Now labeled a “Preview”, Shared iPads are initially being promoted by Apple for education use only. Setup involves multiple steps, and requires several tools. There's a new Apple School Manager system that's a bit like DEP and a bit like our Apple ID Batch Creator. We’ll explore this more in the future. Allows a school to specify users & classes & groups, assign these to specific devices, and log out users from devices.
Specify which apps should get which notification types (none, banner, modal alert, etc.)
Lock Screen Text
Configuration Profile: Example
iOS 9.3 now prints (very) small text at the bottom of the lock screen. Two configuration profile keys allow administrators to specify additional information: an Asset Tag and and an "If Lost..." message.
New restrictions to block the Apple Music service, block iTunes Radio, prevent changes to Notifications settings, and to restrict Safari password saving to specified domains only.
- Comparison of MDM Providers (774,429)
- Complete List of iOS User-Agent Strings (397,725)
- How to get remote viewing/control of the IPAD screen via internet or preferably 3G? (255,314)
- Apple Configurator vs. MDM (156,926)
- iOS Devices (134,490)
- Mobile Device Management (100,025)
- Apple Profile Manager (97,948)
- Batch Apple ID Creator (90,924)
- Gartner Magic Quadrant for MDM (2014, 2012, 2011) (87,968)
- AirWatch (81,513)
Forum topic added by taylor 2 weeks ago
Story added by Aaron Freimark 3 weeks ago
Mobile Management Provider changed by FrankGraziani 5 weeks ago
Mobile Management Provider changed by rachana 6 weeks ago
Forum topic added by taylor 6 weeks ago
Mobile Management Provider changed by taylor 11 weeks ago
Forum topic comment by Elizabeth Hale 13 weeks ago
Mobile Management Provider changed by Simo Kari 14 weeks ago
Forum topic comment by jpref 14 weeks ago
Forum topic comment by bugfrisch 16 weeks ago
Mobile Management Provider changed by krypted 16 weeks ago
Mobile Management Provider changed by JAMFSoftware 16 weeks ago
Forum topic comment by spurtipreetham 16 weeks ago
Forum topic added by okta 16 weeks ago
Forum topic added by am.imran.ahmed 16 weeks ago
Forum topic comment by Samuelbrown 17 weeks ago
Forum topic comment by Elizabeth Hale 18 weeks ago
Forum topic comment by taylor 18 weeks ago
Forum topic comment by bhaveshagrawal1014 18 weeks ago
Forum topic comment by Sabi 18 weeks ago