Sense 10.3.1 seems to have disabled sending MDM commands to IOS 10.3.1 for devices with a lock code using a Wired connection to clear Passcode's for Student device's
However using the Tethered Caching you can send MDM commands to a IOS device with no wifi connection.
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.
Worked for me.... eventually :) Fully updated Mac, tethered-caching enabled on Mac ( sudo tethered-caching )
iPad Air at 10.3.1.
Passcode set (known, for my test)
When I turned wifi OFF, it did not work.
With Wifi Enabled, but all known networks forgotten, so offline, it worked right away.
Interesting that this is working for both of you. I am seeing the exact behavior I mentioned above. My test iPad will not talk to my Mac unless I've previously told it to trust the computer. If I set a passcode on the iPad and give it a restart, the iPad will not talk to my tethered-caching Mac. This seems like the way Apple would've designed it. If an iOS device hasn't agreed to trust a computer, it shouldn't be able to talk to the caching service either.
To be clear, once I let my iPad trust my Mac everything with tethered-cache works as advertised. I'm using a supervised iPad 4 running 10.3.1.
I've done this without the mac tethered caching piece. I just have a powered USB hub which has a USB out. So I have a ethernet connected to the hub via an adapter, then the USB out has an adapter for the iPad and plugs in. That way I send the command over a wired connection and it works. You don't need apple specific products to do this.
@CairoJXP Is this still working for you after one of your devices have been upgraded to the latest iOS (10.3.1 as of this posting). I'm finding that the old USB hub/adapter methods are failing me after that update and apparently that's due to Apple closing that loophole somehow. Would love to hear if it's working for you. As for tethered-caching...not off to a great start...so apparently I can't seem to get the thing to work unless
I'm hoping that's not the case, but around here its the only way I can get tethered caching to work. I'm hoping, I'm doing something wrong.
I did get it to work but that trust does have to be there. That's the key. There is a way to get that trust upon deployment of a new device but it involves using a configurator 2 supervision identity on your dep instance and reenrollment. Very lame I agree! I am trying to study this problem in more depth but before I post more, I want to try a new version of the lightning USB camera kit apparently that may hold the key to fixing this and hardware without having to mess with tethered caching!
So, at this point, there is no workaround for passcode reset once a device has been restarted? If the device needs to be trusted for tethered caching to work and the USB ethernet option does not work, are we looking at having to DFU and restore devices where the user forgets the passcode?
C'mon, Apple! Please. How can we even administer devices when you keep building walls? Stuff like this frustrates both admins and end users.
My Experience: iPads at 10.3.1 or 10.3.2 work using Internet Sharing>USB iPad found in the Sharing panel on Sierra 10.12.5
iPads 10.3 or below still work with the McGyver setup (Camera adapter>USB Ethernet>CHarger)
Tethered-caching works great when activating iPads using Apple Configurator
Thanks everyone - It works! A few things...
The Mac(book) and iPad must be in the same DEP. Log in as an admin. Must do sudo command in Terminal to see the "iPad USB" choice.
Per the Apple link in kuypers post, https://support.apple.com/en-us/HT207523
= = =
Set up tethered caching
Sign into your Mac as an admin user.
Plug in your ethernet cable and make sure you’re using the ethernet connection to access the Internet.
Open Terminal and enter this command to start the tethered caching service:
sudo tethered-caching [ supply admin pw; accept terms; wait for the service to be ON ]
Connect your iOS device to your Mac over USB.
= = =
Now, in Sys Prefs > Sharing you can choose "share your connection from" = Thunderbolt Ethernet
and "to computers using" displays the choice for "iPad USB"
Check the box "internet sharing"
That's it! Sandy is right - both devices must be in the DEP which gets around the trust issue.
Got iPad stuck in lost mode. The person that put it in lost mode forgot to clear the passcode before hand so it's now stuck in lost mode. Connected to AC2 to try get round it but still doesn't work. I guess the passcode is preventing it from getting an internet connection.
Trying to clear passcode from AC2 but says I need to enter the passcode before hand. Can't enter the passcode because it's in lost mode. Can't get it out of lost mode because passcode is blocking connection.
This has been round for a few years. I don't get why Apple don't have an easier method of getting round this. iPads seems to be so inconsistent with getting internet connection when locked/in lost mode/cable connected. Sometimes works sometimes doens't.
To my understanding this doesnt work, and the reason for it is, once in disabled or lost mode, if the device is rebooted, the peripherals are also locked. I've reported the bug, ticket number: 33886664
But feel free to report your own, so it is dealt with more seriously:
feel free to cut and paste the following:
If a DEP or Apple Configurator SUPERVISED iPad is disabled, due to failed passcode attempts or lost mode enabled, & then powered off and back on, the iPad looses the ability to communicate back to an MDM or apple configurator 2 or itunes.
There is 2 parts to this issue, when the iPad is in disabled mode and turned off and back on... it causes the iPad not to automatically attempt to connect itself to wifi, preventing the MDM from reaching the iPad.
It also prevents the ability to directly network the iPad, using a lightning to usb3 camera adapter, a usb ethernet adapter and lightening cable and 10W charger, to directly network attach the iPad. Or in conjunction with a USB hub for that matter.
From my investigation, this appears to mostly affect IOS 10.3.1 and above... but could affect earlier versions. it also shows the device can be pinged - although it is believed the ping response is from the adapter and not the ipad. Initially I was under the belief that the bug was disabling the MDM from communicating to the iPad, but further investigations suggests that the usb ethernet adapter can be pinged, but the actual bug is that the lightening port gets disabled from data sending to and from it.
This belief is reinforced as the bug affects the ability to attach iPad to apple configurator 2, or itunes, indicating the underlying problem isn't network communication, but rather the lightning port being disabled.
if the iPad is never rebooted after it is passcode disabled, it continues to allow the passcode to be removed.
I have attempted this on an iPad air and an iPad 4 model.
Steps to Reproduce:
If an ipad is disabled, due to failed passcode attempts, & then powered off and back on, the ipad looses the ability to communicate back to an MDM or apple configurator 2.
There is 2 parts to this issue, when the ipad is in disabled mode and turned off and back on... it causes the iPad not to automatically attempt to connect itself to wifi, preventing the MDM from reaching the iPad.
It also prevents the ability to directly network the ipad, using a lightning to usb3 camera adapter, a usb ethernet adapter and lightening cable and 10W charger, to directly network attach the iPad. Or in conjunction with a USB hub for that matter.
From my investigation, this appears to mostly affect IOS 10.3.1 and above... but could affect lesser versions. it also shows the device can be pinged. Initially I was under the belief that the bug was disabling the MDM from communicating to the iPad, but further investigations suggests to me that the usb ethernet adapter can be pinged, but the actual bug is that the lightening port gets disabled from data sending to and from it.
This belief is reinforced as the bug affects the ability to attach ipad to apple configurator 2, indicating the underlying problem isn't network communication, but rather a disabled lightning port.
if the ipad is never rebooted after it is passcode disabled, it continues to allow the passcode to be removed.
I have attempted this on an ipad air and an ipad 4 model.
The iPad, should continue to allow itself to be connected to apple configurator 2 or to wifi or direct network connection via a lightning to usb3 camera adapter / usb ethernet adapter. To allow apple configurator 2 or to allow a MDM to remove the passcode.
The iPad remains disabled and cannot be unlocked. Resulting in the iPad needing to be erased, resulting in data loss.
10.3.3 10.3.2 - although have observed on older versions.
This does not appear to occur if the iPad is not reset after it is disabled. It must go through all failed attempts, 1 , 5 , 15 minute and 1 hour, until the iPad indicates that it is disabled and needs to be connected to iTunes. Then it must be Hard reset (home button and power button).
In the attached screen shot, you can see an iPad in question that has been through the process, it is technically supervised by the same computer in which the screenshot is taken. Suggesting that the bug actually disables the ability for the lightning adapter port on the iPad to send and receive data of any sort.
Apple config 2 supervised device, with mdm enrolment or DEP supervised with mdm enrolment.
We had an iPad stuck today in Lost Mode running iOS 11.1.1.
Apple USB Ethernet adapter through camera connection wouldn't work and neither would tethered caching.
Turns out, I cleared the pending commands for the device in Jamf (the one pending was UpdateOS) and then it unlocked the ipad while on ethernet.
@murph you cleared everything except for which commands? i've tried this too and it doesn't always work - it's so hit or miss.
lately we've had a bunch of kids reporting lost iPads; i was getting clear passcode commands to go through before putting them into lost mode and we had no issue getting the majority of them out. i kept track and out of 18 instances we had ONE device that got stuck. the clear passcode command did successfully complete, lost mode enabled, then it randomly lost WiFi and i could not get the disable lost mode command to go through over ethernet (Apple USB camera adapter dongle with firmware update, verified it had an IP address in DHCP). call to jamf support said we'd need to DFU restore (shocker). we decided to randomly try a hard reset (because hey, why not?) and when it came back up it was on. effing. WiFi. we've never seen that happen - generally the hard reset is what makes it loose WiFi, but because the clear passcode command had gone through it of course didn't require the passcode to re-connect. that iPad was running 10.3.2.
then yesterday a student that had lost her iPad at home before thanksgiving all of a sudden returned it to school. we'd issued the enable lost mode command at the beginning of the month but it was just stuck in pending with a few other commands, when suddenly everything started going through on 12/11. a config profile we pushed out was the first thing through, then profile and cert list, then update inventory, then all the lost mode commands. when she brought from home to school it picked up our WiFi and we were able to disable lost mode without wiring up to ethernet. that device was at 11.1.1.
based on our experience - and the fact that what i've just typed contradicts the previous two responses in this discussion - i feel that lost mode is not a reliable feature. i don't know if people that use other MDMs have similar issues, but it's annoying as hell we're paying for something that we can't trust. sometimes the clear passcode command can't go through and you just know you're going to brick the thing. it results in so much lost time for us, not to mention loss of data for our students. jamf just says it's aware there is a product issue, but when jamf pro 10 came out earlier than they said it was going to, this issue was not addressed. feeling disappointed overall; just wish things would work the way they used to...
This thread seems to have veered a bit into Lost Mode recovery. My issue was not with that, but with several iPads that were given a config profile that booted them from wifi, with no way to get back on (disconnected so could not issue any MDM commands). I wanted to confirm I was able to issue a new profile command using a new install of High Sierra and tethering. It took me quite some time, however, as all the instructions I could find involved turning on "Content Caching" in sys prefs, which did not do anything - iTunes would pop up with the same old "untrusted" message. I finally unchecked Content Caching and took a poke at Internet Sharing instead (new service menu item perhaps?) Voila! Everything fell into place. I did find that you have to leave it turned off, set your options "Share your connection from xxx" (most likely Ethernet) and "To computer's using: iPad USB". Then turn the service on. In a few seconds, a usb-connected iPad should be able to receive MDM commands! Even better, you can just connect subsequent iPads without doing anything, and as soon as they are connected, they will get the command - at least that's what happened with me. I would assume Lost Mode recovery would work the same way? In any case, I think the "magic" was to quit messing with Content Caching - which now appears to be a separate/related feature, and instead use Internet Sharing. Just mentioning this, as I hadn't seen that documented anywhere.
In any case, I think the "magic" was to quit messing with Content Caching - which now appears to be a separate/related feature, and instead use Internet Sharing. Just mentioning this, as I hadn't seen that documented anywhere.
I just ran into this today and can verify that Content Caching did not work--I assume it relies on setting up a trust relationship with the iPad that isn't possible because of Lost Mode--but just enabling Internet Sharing immediately resolved the issue. In my specific case I used a MacBook Air running High Sierra connected via ethernet with an Apple ethernet-MDP adapter and had the iPad attached via a USB-Lightning cable.
I posted about this new unlock feature pre 11.3 release, as I had been pushing apple via the bug report program for about 2 and a half years.
pre 11.3 devices that have been rebooted when passcode locked out to the point of passcode disabled, would prevent the ability to connect any peripheral to lightning connection, other than power, and also prevent wifi from reconencting.
11.3 and onwards seems to now allow the ethernet method to connect the device to allow the MDM to approve the removal of the passcode command, to unlock the device.
The time this may still not work, is if there is some weird network setting or the clock is out on the device, or the MDM communication to the device is no longer functioning e.g. if the device is listed in the mdm as not being checked in for a few weeks, it could be that the devices mdm profile needs to be rebuilt.
in a school environment this is a real good reason to update the device to 11.3.1