Is there a way to separate a free app deployed through the Apple Configurator from the Apple ID that was used to download the .ipa file in the first place. The association with the original Apple ID causes the two to be linked and therefore users cannot update the App without entering the password of the originating Apple ID.
Apple Configurator-OTHER, iOS 5.1.1
You can only authorize 5 devices with a specific Apple id for use with iTunes, and use up to 10 devices with a specific id with iCloud synching. Other than that, you should not run into a problem.
I don't believe so.
You can get some detail here if you want to dig:
http://krypted.com/iphone/talking-a-look-under-apple-configurators-hood/
Configurator is probably not your tool if you are not planning on having the devices "go back to the cradle" on a regular basis. Also, many app updates are not mission critical and the end users can get usually get along just fine without constantly updating.
This particular app is actually the AirWatch Agent (MDM related App), so while it's not critical, the updated Agent does have some benefits to updating, mainly on the user support side and user information.
Is it possible to deploy a public app that initially is not associated with a specific Apple ID
That's a tough one. You are still going to have to do the initial Airwatch app install with an Apple Id and also enter a server path and Airwatch activation code. I am not sure why you are using Configurator if you have Airwatch.............
We use Configurator to take some of the manual work out of deploying iPads by deploying a Configuration profile that contains a wifi network and the AW agent since you can't deploy anything to an iPad unless the device has been enrolled through AirWatch. After AW is installed and the device enrolled, Configurator is no longer needed, but when you're deploying 200 ipads and you have 3 days to do it, you need to find some workarounds.
You could use a generic organizational Apple id for the Configurator piece just for this purpose and provide everyone with the log in credentials for it. You will get some account lockouts because some will forget the password and try a bad one too many times but other than that, as long as the id isn't used for anything else of importance, this should work to update the apps installed by Configurator.
Good idea. Thanks
I just created a discussion that's based on this issue. Have you had any issues with using one organizational Apple ID for several devices? I wasn't sure if we'd encounter some sort of limit.
By devices, are you referring to computers running iTunes, or the mobile devices themselves? We're just about to close a deal in which we'd deploy 18 iPads to a client with various apps, some of which are free (Google Earth, Concur, Citrix, etc). We just don't want to deploy all of these apps with one iTunes account only to encounter issues down the road when the users need to apply updates to the apps.
Also, does Airwatch have some capabilities that are similar to Apple Configurator's "Prepare" method? I particularly like Configurator's ability to apply a backup taken of another iPad to multiple iPads while renaming each. What I'm planning to do is to build one iPad to our client's specifications, back that up, and then apply that backup to every other device we'll deploy for them while also having Configurator install the apps. I've tested this briefly and it seems to work well -- it seems kind of similar to deploying Ghost images to multiple laptops. Can Airwatch do the same thing?
AirWatch can't take a backup of an iPad and redeploy that image such as you'd use in Symantec Ghost. It can deploy apps based on a specific configuration that you define, but it's not as seemless as Apple Configurator where you can force any app to one or many ipads at the same time with the click of a single button.
There's a downside to deploying apps via Apple Configurator though and that is the binding of the Apple ID to the app which also affects how that app is updated. Back to gyrhead's response to my question, "You could use a generic organizational Apple id for the Configurator piece just for this purpose and provide everyone with the log in credentials for it" but even this isn't fool proof.
If sharing a single Apple ID works for you, then you have your answer. As a workaround to avoid sharing Apple ID's, I've had to delete the app that was loaded by Apple Configurator and ask the user to re-install the app from AirWatch's App Catalog or push it OTA from AirWatch's console.
Apple Configurator.ipa file linked to Apple ID
