Updating iWorks on Yosemite

@Matt.Sim, did you by chance request free iWork and iLife apps from the VPP program for the new 100 machines you are having problems with? We requested managed distribution of iLife/iWork apps with the last round of computers we purchased and we received the message you note when staff tried updating the Apps through the App store. We found that if we invite people to the VPP program through Casper and they link their iTunes credentials they are able to update the apps. Not sure if your issue is the same or not.

Here is the best techcnical way to download App Store apps for deployment before they are "claimed" by someone's AppleID. Technically you could ask for VPP licensing, but there are more hoops to jump through with this...

https://derflounder.wordpress.com/2013/10/19/downloading-microsofts-remote-desktop-installer-package-from-the-app-store/

@mpermann][/url][/url We only got a few new machines this year, the majority of the 100 are previously owned devices.
I haven't been using VPP for my OS X devices, at least haven't really looked in to it yet.

@RobertHammen][/url Using this method, are updates deployable do you know, or does it need to be a fresh download of the App? Since all of my users already have the Apps installed, but are just not able to update I don't want to be re-installing the whole app if possible, and just updating it. And this will not make it claimed to the Apple ID that I download the update with?
Edit: Read some of the comments on the above link, it doesn't seem to work for iWorks apps.

@mpermann][/url, the issue I have with managed distribution is: what happens when the macs is used/given to someone else?

As the Apps are tied to someone else's AppleID, as per what @Matt.Sim][/url is saying, they can't be updated unless he App Store is logged into the same account they are downloaded under.

We have been claiming the licensed under VPP & then deploying them via an institutional Apple ID. This means we need to push the updated apps to clients & bypasses caching server etc. which is less than ideal.

Another method would be to leverage VPP & also delete the Apps that aren't under a users AppleID & get them to reclaim the licence via VPP.. But that's a pain too! Especially in a multi-national org with multiple app stores.

Education (lab Macs) have a similar issue. We can't have the kids owning the Apps and, in theory, Apple IDs are limited to 10 devices you own.

Apple's own deployment guide for FCP X is to download it on one Mac, package the .app and push it out. However, (and my understanding is it's down to the developer of the app) some apps register the Macs hardware details (MAC, UUID or something like that) and ask to be re-autherised with the purchasing Apple ID when 'deployed' this way.

Thats my two cents, please correct me on anything I've got wrong / or that doesn't match your experiences!

Darren

I usually package up the updated App and make it available via self service. If they were going to download and update it from the app store, might as well download the latest version from self service. That is my take.

@bentoms, we haven't actually started using VPP managed distribution for Macs yet. We've only done some very preliminary testing. It may be more trouble than it is worth but we won't know until we actually start using it. Whenever we give a previously used computer to a different staff member it is re-imaged. Our staff don't share a computer with anyone so we don't have to worry about the person using a different AppleID than their own to update the apps. But everyone's environment is different so I can see this being a concern for some environments. But for us, I think managed distribution of iLife/iWork should be ok. Our challenge will be getting people to understand that we want them to accept the VPP invitation using the same AppleID that they are using for their agency supplied iPad and not attempting to use two different AppleIDs. It's surprising how many people have multiple AppleIDs and they don't even realize it.

@Matt.Sim, I think @pblake's suggestion might be a viable option for you if you don't mind repackaging the app each time an update is released and making it available in Self Service. I've tried to use the process @RobertHammen mentioned and while it works for some apps it doesn't work for everything. We may end up going this route if we're unhappy with the way managed distribution works in our environment.

Using the method documented on @rtrouton's blog, I have deployed both the original as well as the updated iWork apps for Yosemite via Self Service with no issues, so... YMMV.

@RobertHammen, I've also been successful in using the information from Rich's blog to create and deploy the current iWork and iLife applications with the exception of GarageBand. I've never been successful in creating an installer for GarageBand. Due to that fact, I chose to not deploy any of Apple's iLife/iWork apps using this method as I didn't want to have one app that was done differently than the rest. Have you had any success in getting the technique to work with GarageBand?

@mpermann, I think I had to create (touch) a dummy _MASReceipt. Also, there are a number of packages as part of GarageBand. Took me awhile to figure it out, but deployed it just fine this summer.

Let me look at that client's JSS tomorrow and get back to you.

--Robert

+1 for @RobertHammen's comment. We use Rich's method https://derflounder.wordpress.com/2013/10/19/downloading-microsofts-remote-desktop-installer-package-from-the-app-store/ for deploying iWork updates with no issues. We use this for some third-party programs too but it can be problematic if the developer requires the correct AppleID to be signed in.

The only problem I had deploying GarageBand using Rich's method, was the additional components. There's a download you can push to the machine and it installs the additional components. I used information in these two posts for getting the files and installing them:

https://jamfnation.jamfsoftware.com/discussion.html?id=8751

https://jamfnation.jamfsoftware.com/discussion.html?id=6464

@pblake @mpermann My issue with re-packaging each update and making it available via self service is not all of my users are especially willing to take any notice of it, no matter how much I have tried to push it as a positive and useful tool. Unless I was to force the updates on a check-in or login/logout I don't think this method would work too well for my environment, and due to the file size of the apps it's not really something I am wanting to do.

@Matt.Sim. Do you have notifications on for self service. They would alert them to it. Just like the App Store. Then they can't really complain.

@Matt.Sim
so re-package it, cache it, then install it on a particular date and time.
you can offer updates in self service
if they don't install them just have a smart group that finds those who haven't updated, then cache the updates and
write a script to pop up a jamfagent message to nag them about it for a couple days
if they still don't install it. then on next login just force install it, display a message telling them it is being installed blah blah

I don't think i see a problem here technically. i think the only problem is legality around the distribution and the EULA - check with your apple rep

@RobertHammen, can apps without a MASReceipt or with a dummy one then be updated via anyone via the App Store?

iWork and iLife apps can be updated and packaged pretty easily via AutoPkgr. On 10.9 I believe they included a dummy receipt so it wouldn't show that they needed to be updated via MAS. But in 10.10 the MAS shows that there is an update available even if they're up-to-date.

@bentoms I'll test this tomorrow and let you know.