Using Self Service to Direct Users to Apple App Store for Free Apps

Every app in the Mac App Store (and iOS one as well) has a link to it. For example, search for a free app like Evernote and Control click on the little down pointing arrow next to the "Free" label. Choose "Copy link" from the context menu that appears there.
Paste that into the Run Command in a policy with 'open', like so:

open https://itunes.apple.com/us/app/evernote/id406056744?mt=12

When they run the Self Service policy, it should open the app page in Safari, or whatever their default browser is. From there they should be able to redirect to the App Store to purchase it.

There may be a way to actually get App Store to open the link instead of a browser, but I'm not certain.

open 'macappstores://itunes.apple.com/us/app/evernote/id406056744?mt=12' will open EverNote in the App Store.

It looks like after you get the link in the above format you can change "https://" to "macappstores://"

Slight aside:

The "itms://" URL does the same thing for iTunes Music Store purchases, including iOS app purchases or iTunes U subscriptions.

Does anyone know how to tweak this command to have the Mac App Store actually open? (eliminating one step)

open 'macappstores://itunes.apple.com/us/app/evernote/id406056744?mt=12'

or
open -a App Store "macappstore://itunes.apple.com/us/app/microsoft-remote-desktop/id715768417?mt=12"

Both of these I tried putting into a SS policy. It opens the Mac App Store, but it just bounces in the dock and won't open. However, if you run the command via terminal, it works. Also, if the MAS is already open, the link opens just fine. So it looks like a permissions thing to me. Maybe I have to script it?

@lpnicholas][/url - you could try wrapping it all up into some Applescript commands like this-

tell application "App Store"
    open location "macappstore://itunes.apple.com/us/app/microsoft-remote-desktop/id715768417?mt=12"
    activate
end tell

It seems like it would be counterintuitive to put the 'activate' after the 'open location', but in my quick test that seemed to correctly make the App Store come to the foreground with the app page already loaded.

You could of course place all that into a shell script using osascript. I don't know how well it will work when run from a Casper Suite policy since the OS tends to be finicky about what it allows for user interaction, but worth giving it a try.

@mm2270][/url Thanks SO much. This helped tremendously. I had to save it as an .scpt and then I could use it as a Casper policy. The MAS opens "behind" Self Service... however, when I chanced "activate" to "launch" it opened in front! For some reason, it doesn't seem to want to work the first time it kicks off the policy. But it usually works the 2nd time. Weird. I set the script to "before" and tried "after" just for kicks. Same behavior--1st time doesn't do anything. 2nd or 3rd time works. Any ideas on that?

Thanks for the help!

@lpnicholas][/url Hmm, not really sure why it would only work on the 2nd run forward. That does seem strange. I did say that sometimes the OS is picky about what kind of operations it allows. Applescripts are, for whatever reason, particularly susceptible to getting stopped in their tracks by the OS. Perhaps we have to take a slightly different approach.
My suggestions to try would be:

A) wrap it up in a bash script with an osascript HEREDOC style block
B) expand it to use tell application "System Events" to tell application "App Store", etc.
C) add a small delay in between telling App Store to open the URL and telling it to launch or activate

Example:

#!/bin/bash

/usr/bin/osascript <<EOF
tell application "System Events"
    tell application "App Store"
        launch
        open location "macappstore://itunes.apple.com/us/app/microsoft-remote-desktop/id715768417?mt=12"
        delay 3
        activate
    end tell
end tell
EOF

If using "System Events" doesn't work, switch it to "Finder" Sometimes it doesn't like having System Events make a call to another application when being run from a Casper Suite policy.

If the above works, to make this whole thing a bit more flexible, you can specify the URL to open by defining the variable in the script, possibly by doing a do shell script command to echo something like parameter 4 ($4) That way you can use the same script over and over again and simply define the URL in the script parameter.

#!/bin/bash

/usr/bin/osascript <<EOF
set theURL to do shell script "echo $4"
tell application "System Events"
    tell application "App Store"
        launch
        open location theURL
        delay 3
        activate
    end tell
end tell
EOF

You can test if this works before uploading it by doing this from Terminal:

sudo jamf runScript -script "name_Of_Script.sh" -path "/path/to/script" -p1 "macappstore://itunes.apple.com/us/app/microsoft-remote-desktop/id715768417?mt=12"

HTH

@mm2270 thanks! I tried that first script and it opened the MAS right away but it opens on the dock, but not the actual window, and it doesn't open to the link at all. Hmmm...

out of curiosity, if you have the MAS blocked (restricted process), does this still work?

@lpnicholas][/url - hmm, the only thing I can figure is that its because its running in a root context when run from a policy. Truthfully I never tested this as a policy, only as a locally run script, so that could be affecting things.
I'm not in the office now, but when I have some time I'll play with this and see if there's some way to get it to work more reliably as a policy item.

@jwojda][/url - if you're blocking the App Store from launching. or you're allowing it to launch but blocking access to App Store content on your firewall, then in either case, no, this wouldn't work. How could it since it requires the App Store application to open and load up a URL? Even if an app is launched as "root" the Restricted Software process should see it and kill it.

@mm2270 thanks much!