An App Store knowledge base article ( https://jamfnation.jamfsoftware.com/article.html?id=206) says to download an app and use composer to distribute it like other apps.
Is it possible to have Self Service direct people to the App Store to download it themselves? My idea here is to save having to keep our distribution point up to date with the latest software for certain applications. This seems like a time saver, especially for free apps, like iBook Author.
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:
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://"
Does anyone know how to tweak this command to have the Mac App Store actually open? (eliminating one step)
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
#!/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"
@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.