EDIT: I have taken out the majority of this post.
Start packaging receipts with an AppleID you control and control your users access to MAS and keep on top of updates.
Academically it's useful to know you can use information from these two posts to get .pkgs out of the MAS so I have included it below, but DO NOT try to use this method to distribute MAS apps to end users.
Read Rich's original post:
My small post describing success using this with iLife apps:
Solved! Go to Solution.
Using Rich's awesome post:
I was able to capture iLife and (fully licensed) iWork apps from the MAS, and add them to my Mavericks configuration (YAY!)
After imaging, the apps all open and work (YAY!) however when I open the MAS it shows updates needed for all same apps (BOO!) despite the installed versions being the newest available.
The Apple ID prompt came up autofilled with my institutional ID (BOO!), however I was able to remove that ID and enter a random ID and download these updates…(YAY!… sorry that's enough of that :)
Not sure yet if the Apple ID autofill is coming from somewhere else (another package or the core OS)… will continue to examine this.
Any ideas on how to convince the MAS I already HAVE these current versions?
I probably should have clarified my original post. This helps avoid the specific issue of AppleID prompts for the AppleID tied to the app receipt that would normally be packaged. For iLife/iWork this appears to be beneficial if you want users to adopt the apps to their own AppleID (assuming you are licensed).
I haven't seen the issue where updates don't show though, but the note about seeing someone's institutional ID makes me think that perhaps some other piece of the image has a MASReceipt that is throwing this for a loop.
I think for managed environments without admins restricting MAS access and staying on top of updates via policy for MAS apps is the preferred solution.
I wiped and imaged again and this time I got the prompt for apple ID but it did not auto-fill my institutional ID
Nice that a user could then do their own updates with their own apple id.
Updates are still showing up though.
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:
What should we do?!!!
Agreed with Greg. Methods to trick the MAS by deleting receipts and getting signed packages by stopping MAS before it finishes downloading might work, but you're always in danger of having issues, and Apple definitely doesn't encourage it.
Keep the _MASReceipt and try to stay on top of app updates so your end users don't see App Store prompts for signing into another AppleID to update that app (or make sure your users can't get in MAS).
@cstout yes... except for Garageband at the moment. I have a work around for that as well. Regardless, use links from the original post (http://mattzago.com/blog/2013/10/21/getting-packages-out-of-the-app-store and the other like it) but don't kill the receipts. Technically you get 'receiptless' apps by following those posts. Garageband is a different story all together. It will NOT work in this manner and HAS to have a receipt, so I replace it with a blank receipt file and then tell my users to go "re-download" it. Not the prettiest way, but it gets the software there, and gives them ownership until I can take some time and come up with something more elegant. Actually, I do keep hoping for Apple to come up with something elegant instead.
That's what I'm seeing unfortunately. At least it's a process that I've been dealing with for some time. The biggest problem that I'm having now is that I'm embracing apples mentality by WANTING my users to gain ownership and update rights to these apps WITHOUT having to have them install them first. Go figure!
The biggest problem that I'm having now is that I'm embracing apples mentality by WANTING my users to gain ownership and update rights to these apps WITHOUT having to have them install them first.
With VPP you're injecting the app into the user's App Store purchase history. They don't really "own" the app, since you can revoke it at any time and assign to someone else.
I'm marking Greg's early succinct reply as the real answer.
Don't delete receipts and deal with the pain of packaging things as soon as they're updated. The "Getting Packages Out of the App Store" was something I did a while ago to more easily get things like RDC, Server.app, etc. out. But it's ended up being the wrong approach where dealing with receipts is just a burden we kind of all take on.
For iLife adoption, admin's should be disabling app adoption via Configuration profile. Remember that the free iLife/iWork stuff is tied to consumers and their hardware. If you're managing all of these computers, the "free" apps aren't for you and you should be buying them through VPP. So either let the user's adopt the apps themselves (assuming you didn't kill MAS or enable restrictions preventing non-admins from installing via MAS), or package it up receipts and all, but make sure you actually bought the software.
autopkg might have processors to make this work in a good workflow.
FWIW, we deploy with receipts intact & package the .app with composer when an update comes out.
Then deploy to those whom have the app installed.
Has worked so far for us, & VPP is not an option as not all territories we have macs in have VPP.
@donmontalvo quite correct... unless we're talking about iLife or iWork correct? Regardless, I am trying to pre-load said software and then associate it with a users Apple ID. Mostly, because I don't want them to have to wait for the apps to download and install.
P.S. I like the updated mug shot.
@mzago While I understand a lot of environments don't support iLife or iWork for their users but that's not the case in education (where I work). There are VPP solutions of course. Yet, those solutions are no different (legally) from my option of grabbing pre-installed .pkgs form the App store and installing them for our users and then allowing them to "serialize" the apps to their own accounts. FYI, Apple's VPP for iLife and/or iWork do not require payment so this really is just a convenience type issue for our users. Primarily, during imaging.
P.P.S. We did have a site license for things like iLife, iWork, OS etc... Apple refunded our money last year and suggested we go this way. ;-)
Use this script as an after action for your app store packages that require a MAS_Receipt
# Creates MASReceipts for specific applications.
# Set $4 as the full app name ie, iphoto.app
# Geoffrey O’Brien
# Last Modified - 062214
# CHECK TO SEE IF A VALUE WAS PASSED IN PARAMETER 4 IF NOT, EXIT.
if [ "$4" == "" ]; then
echo "Error: No Application Specified."
I finally tried @rtrouton's method of pulling the package from the App Store download directory, but I'm experiencing a frustrating issue that I can't quite pinpoint. These packages install the app quickly and efficiently but even though they're fully up to date, as soon as they're installed on the client machine it shows in the Mac App Store as needing an update. When I click update it prompts for Apple ID credentials, I enter my own to check for any errors, and then it proceeds to download the same pkg I just installed.
Anybody else seeing this? Workarounds? Why would it show as out of date if it's fully up to date?
@mzago][/url][/url, right, I understand that. Part of my original question was asking if there is a way "to generalize/unregister these apps so the end user will be prompted for their Apple ID?"
To clarify: I'm trying to achieve the application state where these apps are installed like a new Mac out of the box. When the user opens App Store for the first time it prompts the user to enter an Apple ID to associate the i-apps with and allow updates.
That, specifically, is what I'm most curious about. For the computers that will be maintained by our technical departments, we will be using the method you and others have mentioned which is what we've been doing for some time now.
I just tried installing these PKG's taken from the App Store with a different Apple ID and it appears to have worked the way I was hoping for. Not sure why it didn't work with the previous Apple ID as it didn't have an association with the apps I was testing with. Thanks for all the help and ideas on this thread.
@cstout, I was able to accomplish what you want by using Composer to capture the iApps that came with a brand new computer. All but GarageBand involve grabbing the application located in the Applications folder and packaging it with Composer. GarageBand has some additional parts located in the /Library/Application Support/GarageBand and /Library/Audio folders that needed capturing. The problem with this method is the apps installed on the new computer may not be the most recent version of the app from the App Store. But I can confirm that using this version will prompt the end user for their AppleID credentials in order to update the Applications.
@mpermann, Thank you for sharing. That method works great as well. I don't see any problem in using slightly outdated versions of it for this specific purpose. Even if you package the most recent version using the MAS pkg method it will still prompt you for an update and an Apple ID and re-download the entire app. Thankfully, we don't have very many computers we need to do this to as we control the updates for these apps through Casper.