We are happy to announce the successor of the Batch Apple ID Creator AppleScript, "Apple ID Automation Builder," a self-contained app written by the Great iTunes Automator Greg Moore, aka Eight_Quarter_Bit.
Purpose & Features
Deploying a great quantity of iOS devices means creating a great quantity of Apple IDs. This script allows automated Apple ID creation from a spreadsheet. Apple IDs are created without a credit card, which is great for many deployments. There is a "dry run" feature to test the script without actually creating the Apple ID.
Enterprise iOS is hosting a forum for any comments or discussion.
The current version is downloadable here: http://bit.ly/AIDAB ... This file is a disk image (DMG) containing a bundled app.
There is also an RSS feed for when I upload new versions or additional files:
- IMPORTANT: Apple uses a velocity check to prevent too many Apple IDs from a single IP address. You must contact your Apple business representative to request that your IP address is whitelisted for a short time.
- Being AppleScript, this runs only on Macs.
- UI Scripting allows us to script otherwise non-scriptable interfaces. Turn this on in System Preferences > Accessibility and check "Enable access for assistive devices."
- Apple has strong password requirements. Account creation will fail if the passwords are too weak.
About Version 2.0
After many months of work (and almost as many of silence on my end, for which I do apologize) version 2.0 of this script is nearly ready for beta testing. I was never really happy with the version available here, because (as you have all seen) it's incredibly fragile and needy. The level of knowledge needed to fix this version is also high, the internal design ranged from poor to non-existent, and major features were never fully developed.
In short, this version of the script was never intended for public consumption. It was an ugly hack from the get-go, barely "alpha" levels of quality, and really only designed to be used within my department. Heck, I never anticipated it would even leave my machine, much less be used all over the world. I'm glad it has served as a stop-gap in the meantime, but frankly I'm embarrassed to have put you through its numerous quirks. Time to give this guy a well-deserved retirement.
Version 2 is a complete from-the-ground-up redesign. 98% of the code has been freshly written (pretty much only a few portions of the CSV parser made it unscathed from v1,) weighs in at roughly 2500 lines, and the method of operation is completely new. In v2 the script builds the setup process itself, outputting the constructed process into an independent app, rather than relying on brittle, hard-set UI element references. When the ID setup process changes you just use the script's GUI to build a new process -no knowledge of AppleScript required! This also allows for constructing multiple setup processes, for instance one with no payment information and one with a payment method, or one method for operating on the CSV output from a user management system and a second for a different CSV source of user info.
Because v2 constructs the setup process, it is now fully system-language and Apple Store location independent by design. Finally you guys living outside the US can stop having to hack away at the script every time it is updated. I haven't forgotten about you.
Version 2 also outputs and updates three CSV files during operation: one containing the accounts that were created successfully, one with the accounts that encountered some sort of error (which the script is now vastly better at recovering gracefully from,) and one with the accounts that have yet to be run. Accounts that encounter an error report what step they encountered the error on, the time the error occurred, and even tries to record the error reported by Apple. All of these are in standard CSV output, so if something terrible happens and the script explodes in a giant fireball you can just re-launch, open the "pending accounts" CSV that the script was updating as it ran, and pick back up where you left off. Need to re-try the accounts that encountered errors? Just grab the CSV that recorded accounts with errors and pop it right back into the script.
Also planned for the new version is inherent support for being used as a library in a larger project, for those of you who are script-heads and want to work Apple ID creation into a larger workflow. This feature likely won't be ready by the first beta, but the groundwork is laid.
There are lots of little niceties as well, including some pretty icons, boatloads of error checking, a highly verbose GUI that walks you through every step of constructing a sign-up process, support for customizable pauses to avoid tripping Apple's velocity limit if need be, and more.
I hope to put the final spit-and-polish on version 2 beta this weekend, and be able to remove the beta tag within a month. Over the past two days I've successfully run roughly 2000 accounts through it, and just need to touch up a few remaining areas. I will get in contact with Mr. Freimark as soon as I have killed the last few big issues, and see if we can't get a new post put up.
Your patience with v1, as well as your enthusiasm, have been astonishing. I thank you.
Here's too many more automatically created Apple IDs, in the days to come!
Enterprise iOS is hosting a forum for any comments or discussion.
In the recent years we all have seen the many revisions of iOS and with each one comes the famous "my battery is draining because of the upgrade" As we all do as techs and support we look for the usual, such as exchange settings and apps currently running. Recently, I came across a user that is claiming that he is losing battery so rapidly he can't get through a few hours, when on-site to evaluate this claim no such situation exists. So I have decided to start taking action as convincing Apple to swap out the phone may not actually be the answer. Wanted to hear what the communities strategy has been to evaluate, support and explain to a client "it might be you"
[Editor's note: This was originally posted on tekserve.com, but I thought it was useful enough to post here too.]
Apple recently enabled a new security feature for Apple ID accounts called “Two-Step Verification.” This is a form of multi-factor authentication that can help keep your account more secure. I am a huge fan of multi-factor authentication and have enabled it on almost every account that offers it. This post will explain just what the technology is, why it’s helpful, and how to use Apple’s implementation specifically.
What Is Multi-Factor Authentication?
In order to log in to an online service, such as my email, I need to authenticate with the server. When I go to Gmail, for example, Google does not intrinsically know that it’s me trying to connect. I need to first provide the server with proof that I’m the owner of the account before being allowed access to my data. My password is one possible “factor” for authentication. It proves to Google’s server that it is indeed me, and not someone else, who is trying to access my data, and allows me in to see it.
The Register has an article on an important but often overlooked aspect of iPads in business. Users want them working, all the time.
My iPad is more robust than most of the appliances in my kitchen never mind an enterprise data centre... As a result of this turnaround, the role of an IT architect has got even harder, especially in the small- and mid-enterprise sectors where arguably the pace of IT change has never been faster and the lack of IT governance has never been lower
Have you noticed this too?
We use x509 TLS certificates as part of our authentication to activesync. When the certificate renews, the way this works is the profile is removed from the device and re-added with the new credential.
Unfortunately, this means that the activesync account settings are reset to defaults (folders to sync, days, etc) as well as if the user had set the activesync as default account for mail, calendar, contacts.
Under the principle of least surprise, I'd like to force the activesync accounts to be default when provisioning or renewing. I haven't found any way of doing this with the standard AirWatch profile settings, so I was wondering if there's any MDM features I should be asking AirWatch for, or even if there's any custom XML that I can apply.
(Via travel blog Gadling.com)
We have developed an enterprise app as add on to our backend system, which our customers can download from the app store. The app is not working standalone, but requires the corresponding server. Of course our customer don't want to allow their users to install all app updates we provide (~1 update every 2 month), since every release must go through a comprehensive testing process (with their customized backend system) before internal rollout. They either have a mdm solution in place, or have built up their own company app store. Due we are not developing this app for a single customer, we cannot hand out the ipa file. So my question is, how our customers can organize their deployment process to prevent/control updates via the app-store? I really hope you can help me!! THANKS
Apple has added two-factor authentication to some Apple ID functions.
Two-step verification is an optional security feature for your Apple ID. It requires you to verify your identity using one of your devices before you can:
- Sign in to My Apple ID to manage your account.
- Make an iTunes, App Store, or iBookstore purchase from a new device.
- Get Apple ID-related support from Apple.
Turning on two-step verification reduces the possibility of someone accessing or making unauthorized changes to your account information at My Apple ID or making purchases using your account.
We've noticed that at least some users (including me) are subject to a three day waiting period before activating 2FA. This may be a smart idea to prevent someone else from locking me out of my account. (Or it is paranoid.)
Apple has more information in an FAQ about the feature.
Does it work for you?
I have been struggling with the VPP store (education), specifically, the purchase history section for a while now. It was always a nightmare when I needed to go back into my purchase history and find a specific App and re-dwonload the CSV( for that app.
It can be a huge pain because the site will only show the 20 most recent purchases until you click “show more”. Then you get another 20… and so on… and so on… and you get the pain. It would take me 5 min. just to get all my history to show. Then I would need to use a find command to find all the instances of a particular apps purchase. Again, a pain…
I decided that I MUST find a better way! I went to the Purchase History page, clicked show more until all my history was showing. Selected all the info, copied and pasted it into a Numbers spreadsheet. To my delight all the info coped over perfectly: Order date; Order; Name (with links to app page); Type; Order total; Licenses; Codes (WITH DOWNLOAD LINK).
Now I have a spreadsheet that I can do all the fun things you can with a spreadsheet. Most importantly is has all the live links! As long as I am logged into the correct account on the apps store all the App and download links work perfectly.
From here I will simply add to this spreadsheet as I make purchases and never need to use the stupid purchase history on the Apple site again! Not sure why I didn’t think of this sooner!!! Dense I guess!
Loving life a little more now…
We have a field team of reps that visit retail stores. They are issued an iPad Mini to conduct their reports in the field. We would like to give the District Managers the ability to share their screen with their employees (between 30 and 40 people) to conduct trainings. We will at times need to share documents which I know there are lots of solutions, i.e. Join.Me Pro, but what we really need to be able share the actual screen so we can train them on how to access and fill out the call reports that they will use.
I am having a challenge finding a solution that will allow us to share our iPad screen with 30 to 40 people at once on their PCs or iPads where they can actually watch us using iPad Apps.
It would also be a bonus if this would allow the District Manager to also view an employee's iPad screen to help trouble shoot or answer an individual's question. This only has to share with one or two others at most.
Apple has released iOS 6.1.3, fixing a recent lock screen vulnerability.
The update is available via software update. And as usual, http://ios.e-lite.org/ has compiled links for direct download.
I'm trying to understand how iOS deals with certificates and I'm wondering if anyone can explain a few things to me. I'm working on a system that would provide users with a personal identification certificate for authentication to various services (email, Wi-Fi, websites, etc.) via a configuration profile. Profile creation isn't a problem, but in testing website authentication, it seems that iOS (or Mobile Safari) requires me to provide the CA certificates that should already be on the device.
Here is the certificate chain that my colleague provides me with when I get the user's cert:
AddTrust External CA Root ↳ UTN-USERFirst-Client Authentication and Email ↳ InCommon Standard Assurance Client CA ↳ User's personal certificate
At first, I added the certificate as a single payload of type com.apple.security.pkcs12 with all the CA certificates in the chain included in the p12 data blob. This didn't seem to work since I'd get a warning from MobileSafari in the console log:
no itentities, but we have a challenge <NSURLAuthenticationChallenge: 0x1ddccd90>
Along with the following dialog in the browser:
This website requires a certificate The required certificate is not installed. Dismiss
The server's ssl_error_log reported:
Re-negotiation handshake failed: Not accepted by client!?
So I tried breaking out the certs into individual payloads. According to this article, iOS 5 and 6 has "AddTrust External CA Root" and "UTN-USERFirst-Client Authentication and Email" preinstalled and I shouldn't have to install them again. So I just included "InCommon Standard Assurance Client CA" and the user's cert as two separate payloads (of types com.apple.security.pkcs1 and com.apple.security.pkcs12 respectively), but that didn't work. I was only able to get it to work if I installed the entire cert chain (using com.apple.security.root as the payload type for the root cert).
Why is that? Shouldn't it already know about the two CAs? I can understand adding the "InCommon" CA since it's not preinstalled, but It seems strange that I have to explicitly provide the other CA certs.
FWIW, I've found out that there are at least three versions of "UTN-USERFirst-Client Authentication and Email":
Intermediate CA (expires Saturday, May 30, 2020 6:48:38 AM EDT) Intermediate CA (expires Sunday, December 31, 2028 6:59:59 PM EDT) Root CA (expires Tuesday, July 9, 2019 1:36:58 PM EDT)
The root version is the one preinstalled in iOS. When I evaluate the user's cert with the Certificate Assistant in OS X, the cert status is good no matter what chain it uses, but could this multiple CA certs thing be an/the issue?
About This Site
- Comparison of MDM Providers (602,074)
- Complete List of iOS User-Agent Strings (243,328)
- How to get remote viewing/control of the IPAD screen via internet or preferably 3G? (160,337)
- Apple Configurator vs. MDM (117,511)
- Mobile Device Management (78,798)
- Apple Profile Manager (67,164)
- AirWatch (63,785)
- Gartner Magic Quadrant for MDM (2014, 2012, 2011) (62,386)
- Batch Apple ID Creator (60,238)
- Absolute Manage (55,932)
Comparison of MDM Providers
Forum topic comment by michael@abovest... 8 hours ago
Story comment by webdesignvalley 11 hours ago
Mobile Management Provider changed by simon.bonello 14 hours ago
Forum topic comment by colesy 3 days ago
Wiki Page added by Aaron Freimark 5 days ago
Wiki Page comment by poorya.0991 6 days ago
Mobile Management Provider changed by Cortado 6 days ago
Mobile Management Provider changed by jvolzer 1 week ago
Wiki Page changed by dpmc 1 week ago
Mobile Management Provider added by ZuluDesk 1 week ago
Forum topic comment by azzie61 1 week ago
Forum topic comment by azzie61 1 week ago
Forum topic comment by bweicks 1 week ago
Story comment by webdesignvalley 1 week ago
Forum topic comment by betolley 1 week ago
Mobile Management Provider changed by twalker 1 week ago