We built our own MDM server using OSX Server and an apple mini to manage about 100 iPads. Everything worked great then ios 7 was released.
We have various pads that have different things happening to them.. some are getting the app push but the app never installs, some never recive the push at all, and some pad's have our apps disappearing...
Has anyone found what needs to be done to update the server so that it will function again? I've found 150+ page document on the apple developer site that walks you though setting up the entire process but most of it we have already, that document does not call out the changes so it's certianly not ideal at all to try to pick out what needs to be updated (I did also update the OSX Server software to the newest version)
The only real errors I have to run on right now are from the device logs.. here is what is happening.
Oct 2 11:51:14 iPad mdmd[477] <Notice>: (Note ) MDM: Transaction completed. Status: 200
Oct 2 11:51:14 iPad mdmd[477] <Notice>: (Note ) MDM: Attempting to perform MDM request: InstallApplication
Oct 2 11:51:14 iPad mdmd[477] <Notice>: (Note ) MDM: Handling request type: InstallApplication
Oct 2 11:51:15 iPad mdmd[477] <Notice>: (Error) MDM: Enterprise app installation failed.
Error: NSError:
Desc : The app “com.app.Damages” is already scheduled for management.
US Desc: The app “com.app.Damages” is already scheduled for management.
Domain : MCMDMErrorDomain
Code : 12026
Type : MCFatalError
Params : (
"com.app.Damages"
)
Oct 2 11:51:15 iPad mdmd[477] <Notice>: (Error) MDM: Command Status: Error
Error: NSError:
Desc : The app “com.app.Damages” is already scheduled for management.
US Desc: The app “com.app.Damages” is already scheduled for management.
Domain : MCMDMErrorDomain
Code : 12026
Type : MCFatalError
Params : (
"com.app.Damages"
)
Anyone know what needs to be changed? There can't be that much.. we are still pushing the apps just the device is not communicating with the server now
Let me break it down to couple of subquestions:
1) Has anyone found what needs to be done to update the server so that it will function again?
Generally speaking, nothing needs to be changed on the server. iOS 7 introduced couple of new features to MDM. However, the whole protocol is still backward compatible. So, if you have older server, it should (in the ideal world) work fine with your new iOS 7 device.
2) We have various pads that have different things happening to them.. some are getting the app push but the app never installs, some never recive the push at all, and some pad's have our apps disappearing...
Welcome to the post Steve Jobs era :) Golden iPhones, eyes popping color schemes and unbaked sofware.
I noticed serious degradation of MDM stability from iOS 6 to IOS 7, especially around app distribution. I posted about 3-4 bugs to Apple and I would recommend to do the same (hopefully, the sheer number of bug reports will force them to concentrate on it).
As you I saw apps not being installed, leaving placeholder icons behind and a lot of other crappy behavior.
3) "The app “com.app.Damages” is already scheduled for management."
This messages mean that you already tried to install it and it sits somewhere in iOS installation queue, but waits for something. I am not sure what is exactly the list of possible reasons why it waits.
One of the reason which I observer is that if a user is required to enter AppStore password for a first time, it can stuck on this for quite long time (not sure why).
We have been having this problems since iOS 7 was released. We have also been working directly with Apple and our MDM vendor since then and Apple has just recently confirmed to us that this is fixed in iOS 7.1, though Apple has not announced a release date for 7.1.
We have recently found one workaround. Using our MDM, we send a command to remove the app from the device (even though it's not even installed). Once the device processes the remove command, we are then able to push the app down to the device.
I just encountered the exact same problem as well and completely agree with instability in iOS7 MDM.
The ipad I was testing is on iOS7 and here is the result what I observed in iPCU.
Oct 25 11:41:44 Devs-iPad mdmd[312] <Notice>: (Error) MDM: Command Status: Error
Error: NSError:
Desc : The app com.custom.myapp is already scheduled for management.
US Desc: The app com.custom.myapp is already scheduled for management.
Domain : MCMDMErrorDomain
Code : 12026
Type : MCFatalError
Params : (
"com.custom.myapp"
)
Removing the MDM profile and re-installing to re-provision device didn't help as well.
In the end I wiped (factory reset) the device and the next time device pull application install command for that app name it works.
Hopefully Apple fixes this issue in next software update.
we have the same situation on 20/700 Devices managed by BES10. The only workaround for us is to install the app update outside the mdm world
I just encountered this issue on iOS 9.3.4.
ErrorChain: [ {
'ErrorCode'=>12026,
'ErrorDomain'=>'MCMDMErrorDomain',
My solution was:
Remove the app from the device in the MDM
Restart the device
After the iPad started, the app icon appeared on the home screen, but it was disabled, then i uninstalled the app on the device
Assigned the app in the MDM and pushed it onto the device
Don't know what caused the app to hang out in the install queue like that, but I worked it out after a while of troubleshooting.
Related
I figured out this issue when I wasnt getting the notification through workmanager when the app was killed from background tasks in Android 10.
It is working fine for all the android version till Andorid 9.
To test this, I run the app simultaneously on both 9 and 10 versions.
Is someone else also facing this issue? I searched the web but no support solution for Andorid 10 based issue.
Note: As soon as the app is opened and the workmanager is triggered,
I get the notification in 10 but not when the app is completely
closed. Also, I have tested this scenario on Google Pixel device as well for Android 10 but no success.
There is vast fragmentation in the android world. The background task management is the worst scenario as it will behave different in different devices. Please read the post below to get better understanding.
https://medium.com/mindorks/enable-background-services-in-chinese-roms-32e73dfba1a6
http://pguardiola.com/blog/darealfragmentation-alarms/
We are using Firebase to push notification to our users.
Here is the statistics when trying to send a notification to 1000 users that have stopped using our app since 2015 :
Android NotRegistered 566
Android success 181
IOS NotRegistered 253
It is obvious that almost 100% of such old users should not be not reachable. (That would mean they have our app still installed in their device without having opened it for 5 years).
Statistic for IOS look good.
But as for Android, there are >20% of tokens for which we receive a successful respons which is unrealistic
I suspect the following reason :
When someone has definitely stopped using their device without having removed the app (a new device was bought and the old one was thrown into a drawer), Google still believe it is alive.
Can you confirm, this is the case. If yes, do you know if Google will end up detecting the device is no more in use (with probability 99.9%), maybe if it fails to send our notification after some days ?
Actually, it is useful to have a relevant estimation of how many users I can reach with push notifications.
WatchOS app works normally if being opened from home screen. If I try to open it from remote notification screen (by tapping title label) two app behaviors can be spotted:
If application was loaded previously (I don't know how to name it, maybe better to tell that app is not killed by system or still present in memory). In this case application will load normally and do some action if asked (for example open some Interface Controller and show remote notification details).
If application was launched long time ago (or killed by system, unloaded from memory, in my case I'm stopping it in Xcode). If app receives remote notification in this state after tapping on title label of notification scene it will try to load for some time and finally crash (this may take 1sec or 1min). Or it will stuck with loading indicator shown - what is interesting that in this case if I'll try to attach watch extension process to Xcode debug it will show that app is launched and works (for example I can send some data from parent iOS app and watchOS app will receive it - triggered method in Extension delegate and do some stuff).
Googling I have found that watch apps can be killed by system if they take to much power when being launched, so I tried to remove any load while app is starting itself but with no success - it still keeps crashing.
The only close to mine situation that I've found so far was a topic in apple developers forum:
https://forums.developer.apple.com/thread/20553
I have been spotting the same logs like in topic when watching how watch app behave in Xcode/Devices, but after updating to WatchOS 3 (now 3.1 beta) and using new Xcode 8 (now 8.1 beta) I can't see any logs from WatchOS at all (just some system messages that watch screen was turned of and on).
Have any one spotted such issues while working with watchOS remote notifications? Any suggestion where to search for solution?
I'm trying to take users of My App to the AppStore for several different functions - like Upgrade to Full Version, Rate/Review or simply View another App I've developed. However, all of these are causing my App to Terminate when iTunes is launched on the device. I'm using some simple code and
have tried many combinations of URLs, all of which successfully get to where they are going. Here are the behaviors:
User clicks Rate App
Code directs them to the web via:
[[UIApplication sharedApplication] openURL:
[NSURL URLWithString:[[MyApp defaultApp] itunesLink]]];
My App goes to the background, and my delegate's applicationDidEnterBackground is called successfully
As iTunes is coming up, my App is terminated. Happens whether I run via X-Code or on the device directly.
When I quit out of the store and look at the running processes on the device, my App is still shown there. I know it has been terminated from X-Code console, and when I try to restart it it starts fresh.
I've tried the itunesLink as either itms://itunes.apple.com/app/ or with http - all of which get to the correct end point. If I use www.google.com it works fine and my App is NOT terminated, just sent to the background and the website is displayed OK.
Other points are that when I run via the simulator, the openURL call returns failure and doesn't open any URL.
Any insights as to why my App would be terminating? It's acting like an iOS security feature or something which is shutting my App down, but I thought what I was doing was pretty standard stuff.
If anyone has seen anything similar, I'd really appreciate advice on the situation.
Your app could be terminated for a number of reasons. The best thing is to look at the device console using Xcode's Organizer:
Your app may simply be terminated as a result of low memory notifications. As soon as it moves to the background and the app store launches (iTunes and the app store both use plenty of memory) it can be killed to free up memory. In this case you will set messages from "jetsam" like this:
<Notice>: jetsam: kernel termination snapshot being created
<Warning>: Application 'UIKitApplication:com.yourapp[0x6337]' exited abnormally with signal 9: Killed: 9
You should use the Activity Monitor in Instruments to see how much memory your application is using. iOS will terminate the most memory-intensive applications first, so you should try to reduce your app's memory footprint.
While testing our iPhone app in devices with iOS 6 beta 4, we found an issue wherein if any notification like reminder alert is received or when we pull down the notification curtain, the application is restarting from beginning.
It never used to happen like this till iOS 5.X. Apple release notes or known issues of iOS 6 beta did not mention anything regarding this.
Did anyone faced this issue?
Any comments on whats going wrong?
Check in the app's .plist file to see if application somehow got set not to run in the background.