Another MAS Question

Yeah, the old MASReceipt thing seems dead now. Now of course with free iWork on new Macs, it adds another problem. I just don't get Apple on this topic. I generally like them, but this area has created numerous headaches. No solutions for you - basically flowing this one in hopes that someone has a great idea...

I saw this with installing the most recent version, but Software Update still showing that it had an update.

I believe this has something to do with the ownership of the application. Since it is not "owned" by anyone yet, it is going to Software Update to get you to run the update and "own" it.

Just my hunch.

Just dealt with this myself, this luggage makefile solves the issue for me https://gist.github.com/arubdesu/10024912 I've built the image cleanly with AutoDMG, dropped the apps in place with munki, and then seen it asking to adopt the apps to an Apple ID, which like you I don't have set institution-wide yet. Dropping the dummy receipt worked like a charm, for iWork as well.

Thanks Banks,

Giving that a shot after I finish putting out the three other fires in front of this one.

-c

One thing to be aware of when testing receipt-less MAS apps: when it does an update scan, the MAS is aware of any applications located in /Library/Application Support/JAMF/Composer/*. Numerous times I've seen the MAS update the app located there and not in /Applications . Testing the distribution of the application on the same machine used to package it may reveal issues that might not appear on the clients.

Yes, managing MAS apps is a pain. I'm not sure yet that VPP is going to help with iLife and iWork. We also have significant numbers of systems in classrooms that will not benefit from VPP, as there is not necessarily one person to whom we could assign the app. We're just packing the app, purchased from a sys admin-managed account, and trying to get it out to clients before they start calling us about the updates.

We pretty much for what mikeh mentions, but that's as with VPP we can't do much else.

http://macmule.com/2014/01/23/vpp-2-0-a-question-of-morality/

@cstout: To be clear, all that does is stop the prompts to update in the MAS, correct? So future updates will just not show up there. It doesn't really address what to do down the road when the apps get further updates...unless you plan on packaging them again and delivering with Casper?

"It doesn't really address what to do down the road when the apps get further updates...unless you plan on packaging them again and delivering with Casper?"

That's precisely what you must do.

@boettchs, yes, that's all it does and currently that's all I'm needing. I currently manage all application updates and package the updated app when it's released. Until Apple gives us a better way, that's what I do.

@cstout: Got it - thank you. Are you actually using Composer to package iLife and iWork or other means?

@boettchs Yes, I use Composer for everything I package.

@cstout: So, one last question. What about removing the MAS receipt in the app(s) before you build with Composer? Here's what I'm thinking.

Build a Mac clean with 10.9.2. Remove the i-apps. Start Composer and take a snapshot.
* This step I am trying as to make it more flexible
Install one app at a time, i.e., GarageBand (using my Apple ID)
Remove and create the dummy MAS receipt in GarageBand.
Create the package in Composer.
That way, in theory, I could then update individual apps as they are updated and offer installs for only the i-apps people want and not have to run the receipt scripts after every install.
Thoughts?

What about just adding the fake receipt just prior to packaging?

@boettchs Removing the MAS receipt in the app before building is precisely what I do. You don't have to go through all the effort of doing a snapshot and then packaging, unless that's how you like to do it. I just drag the most recent version of the app into Composer, expand iPhoto.app (for example), expand contents and _MASReceipt, and then highlight and delete the receipt file. Add in your postinstall script and you're done. If you want to avoid using any scripts, you could do what @dpertschi stated above. I don't believe there is any problem with doing this, but that's assumption on my part since I haven't deployed it that way. All the touch command is doing is creating the receipt file with default permissions. As long as those permissions aren't changed by Composer, it should work fine.

@dpertschi @cstout:

That's what I said "Remove and create the dummy MAS receipt in GarageBand." Maybe the verbiage sucked ;) I thought the snapshot was a better route as I figured there would be stuff in /Library/Application Support/ for the i-apps.

Thanks for the feedback. I'm going to give that a whirl and see how doing them individually works out.

In the early days of 10.9 I created custom packages with dummy receipts for the new versions of iWork apps + iPhoto + iMovie. I'm no longer satisfied with this solution for my org.

I've noticed something positive in my environment with the release of 10.9.2 when it comes to Apple managing these App Store updates once again.

I'm still working on a plan to automate this as much as possible with combo of scripts for Faculty + Staff but below is my general game plan…

Confirm System is up-to-date must be running 10.9.2
Open App Store and Sign out of currently logged in user.
Remove versions of Pages 5.x, Keynote 6.x, Numbers 3.x, iPhoto 9.5.x, iMovie 10.x Apps
(Re)Install iWork 9.0.3 package (Source: Original Install DVD - site license) on 10.9.2 system. Re(Install) iPhoto 9.1 & iMovie 9.0.9 via custom packages created with Composer.

Delete the following files/directories from AD mobile account home folder on Faculty Laptop:
~/Library/Caches/com.apple.appstore
~/Library/Cookies/com.apple.appstore.plist
~/Library/Preferences/com.apple.appstore.plist

Log out of Faculty user account. Log back in. Launch App Store. Click on updates.

Notice Pages 5.x, Keynote 6.x, Numbers 3.x, iPhoto 9.5.x, iMovie 10.x Available App Updates. Update All & When prompted for an Apple ID to associate apps with ask teacher to sign in with same Apple ID they're already using with school issued iPad.

This is the only way I can best prevent shared document compatibility issues from cropping up between our Student owned iPads set to auto update and our Faculty Macs. Also great way to take some of the weight off IT for these basic App store updates.

Finally create new Policy in JSS to configure client machine to install updates automatically from the App Store via defaults write commands.

@lionelgruenberg, mind sharing the defaults write commands?

@bentoms

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate.plist AutomaticCheckEnabled -bool true

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate.plist AutomaticDownload -bool true

sudo defaults write /Library/Preferences/com.apple.storeagent.plist AutoUpdate -bool true

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate.plist ConfigDataInstall -bool true

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate.plist CriticalUpdateInstall -bool true

Just an FYI for @cstout. You don't need to repackage. You can actually use instructions created by @rtrouton for grabbing the PKG installers for these apps before they actually get installed by the App Store. See http://derflounder.wordpress.com/2013/10/19/downloading-microsofts-remote-desktop-installer-package-from-the-app-store/ for instructions.

The PKG installers that you grab using this method do not have any MAS receipts to worry about deleting. And when using Apple's installer for iMovie this also allows you to keep the pre/post-install logic that Apple uses to move the previous version of iMovie to a subfolder in Applications in case you have users that may still need to use the old version for any reason.

I used Rich's instructions to create an Automator Service called "Create Link in my Downloads" to get this entire process down to three basic actions that can be done without needing Terminal: Pause the App Store install, open the App Store download folder, right click on the PKG and select "Create Link in my Downloads".

Then to get your dummy receipt you could just create a separate payload free-package to run your touch command.

Hi everyone,

We’re running into a major problem with most Applications downloaded from the Mac App Store. Historically, organizations deploying Mac App Store Apps within to their managed clients would need to delete the [_MASReceipt] directory from within the App bundle. However as of May 2014, this no longer works.

Error = “<AppName> is damaged and can’t be opened. Delete <AppName> and download it again from the App Store.”

Neither of the following work-arounds work anymore:

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

https://jamfnation.jamfsoftware.com/viewProductFile.html?fid=690

What should we do?!!!

I just deleted the receipt on my Garageband:

sudo rm /Applications/GarageBand.app/Contents/_MASReceipt/receipt

It would not launch.
I created a blank one using:

sudo touch /Applications/GarageBand.app/Contents/_MASReceipt/receipt

Launching now works. I have a script that runs in Casper after the packages install to create the _MASReceipt directory and then the dummy receipt. Give that a shot.

One thing I have seen since this April/May is that sometimes these apps still show "Updates" in MAS, but they're up to date. Can't yet pin down exactly what is different, but it's not consistent enough to give you anything valuable.