DmitriAltum's Posts

We updated our on-prem from 9.6 to 1811 on Tuesday in our Lab environment and haven't seen these issues. All our devices are still visible and within their normal OG's and enrollment has been going into the proper OG's. We went straight from 9.6.0.8 DB to 1811.0.03 DB & same with application

So we actually ended up finding a way to do this, sort of. We ended up getting VPP licenses for the application and assigning it to all our macOS devices which forces the download of the application. Then we pushed a product to the devices with the command line ' sudo /Applications/Install or macOS or  Mojave.app --agreetolicense --nointeraction'  which forces the application to run, automatically agree to the license, and not prompt anything for the users. Obviously that last part is a bit tricky since it could shut down in the middle of something important so we haven't pushed it live yet, plan to test with taking the --nointeraction off today.

Not to resurrect a dead thread but... Mike did you ever succeed in this endeavor? We're starting to look at the benefits of implementing this due to some security software we use and I haven't seem to have had much luck in our QA environment this morning. I have a compliance policy set to check for OS version and if it is less than or equal to 10.13.6 install a compliance profile which tells it to automatically install updates and check every 30 minutes. I put High Sierra 10.13.3 on 5 macs this morning and now 4 hours later none of them have prompted or installed an update to Mojave even though they do show the profile installed.   Edit: 2 of the Macs have now prompted for Software updates, I accepted and they went through the whole ' Installing macOS update'  progress bar, etc. But then 30 minutes later when done they are still on 10.13.6 so going to edit the compliance policy to say update if less than 10.14 instead of 10.13.6 and see if that fixes. 2nd Edit: The above did not fix. It went through the exact same thing, one of the macs two macs that updated previously gave the notification to update again, it ran through the macOS install but still came up to 10.13.6 at the end instead of Mojave.

Do you by chance mean the Remote View that was implemented in 9.7 (just want to make sure I'm not mixing up features)? If so, I would check to verify that your company has purchased the Advanced Remote Management Sku as said in the Release Notes: ' To make use of remote view, you must have purchased Advanced Remote Management SKU and must be using iOS Agent v5.8.1+.' We are an On-Prem who were going to update to 9.7 recently for this feature but decided against it due to budget.

Have either of you checked Devices > Lifecycle > Wipe Log? Our console was configured a bit oddly to only allow 10 devices within an hour to be wiped and so I had to change that restriction and approve the commands that were pending in the wipe log. More info here: https://docs.vmware.com/en/VMware-AirWatch/9.2/aw-mdm-guide-92/GUID-014MDM-ViewWipeLogs.html

Apple is having a Business event in my area next week and supposedly will have a few engineers there. Having worked for Apple and being able to attest to their ' tight lipped'  attitude, I don't imagine I'll get much but I definitely plan to grill them on it and find out if it is something they are at least aware of internally.

Brian, we had a similar issue for On-Prem. We ran the iOS12 patch for 9.2.2 then a week later updated to 9.6. iOS12 devices could still enroll no problem, but all of a sudden Xs & Xs Max models stopped being able to enroll. Re-applying the patch for v9.6 fixed it.

Patrick, We are in the same boat. I've seen a huge leap in the Invalid Profile errors in recent weeks which is becoming a huge problem as we too ship devices all over (though the US/Midwest not Switzerland). I've reached out to our Rep to see if he can find any internal information (though we all know how tight-lipped Apple loves being)

We seem to have found an additional piece of info. A device that gets stuck during the enrollment lists the account simply as ' Android Enterprise'  whereas a successful enrollment lists the account as ' Managed Account'  which when selected shows something along the lines of ' 67645486734486543578@android-for-work.gserviceaccount.com'  we aren't sure if this is of any significance yet but it seems to be, at the very least, related.

We are using agent 8.3 and currently using Android 6.0.1 on these specific devices (Bluebird Handheld EF500's), so I agree that the known issue does not appear to be the root cause. For us this started on Thursday last week. We encounter the issue whether we are using email address to enroll or QR code. John, most of the time if we reboot it does not work, however every once in a great while after rebooting we can open the agent and it prompts ' Login to your corporate Google account with {emailaddress}@meijer.com to complete set-up'  we click login and it finishes enrollment.