@rmhughes Why are you trying to repackage iTunes? The installer package from the website is a perfectly fine install package. Just drag it into Casper admin and use it.

I know in the CCT classes you may here different opinions on when you should repackage things or not (DMG files with dragging the app into Applications is a perfect example of when you would repackage). But, if the installer works fine on its own, you really shouldn't repackage it as you are gaining nothing.

iTunes.app has System Integrity Protected (SIP) enabled. It simply won't work without SIP disabled.

Download iTunes from here and deploy the .pkg https://www.apple.com/itunes/download

We generally re-package because we prevent students from having write access from the package contents of an App.

Workflow
Drag install Install iTunes.pkg to Composer
Convert to Source
Create package
Run package - Hit with “Installation failed” error

Or are you suggesting, just use the “Install iTunes.pkg” as the file and not use composer at all?

Thanks a lot

@rmhughes

On OS X 10.11 iTunes.app is SIP protected. That means you cannot write to it, only Apple can.

Take the "Install iTunes.pkg" and don't use Composer.

https://support.apple.com/en-us/HT204899

https://derflounder.wordpress.com/2015/10/01/system-integrity-protection-adding-another-layer-to-apples-security-model/

Yes, there is no need to repackage. Use Install iTunes.pkg

What do you mean when you say "prevent students from having write access from the package contents of an App."

In general, try to avoid repackaging at all costs.
Use vendor provided packages.

@rmhughes the workflow for iTunes would be to simply drag the Install iTunes.pkg file into the Casper Admin window to upload the package and deploy the package as it is. You should not repackage the iTunes application using Composer. If you have a .pkg file, you're better off trying to use it simply as it is rather than repackage it. Test it and if it doesn't work then maybe you might have to repackage it. Try it with iTunes and see how it works for you.

In general, try to avoid repackaging at all costs.
Use vendor provided packages.

Hi Guys,

Thank you for the responses. It's cleared it all up for me. We generally re-packing so we can restrict write access, but as you guys say, it's fine in this case.

Cheers
R

Still not sure what you mean by restrict write access though....

Just preventing clients from having write access anywhere in ~/Applications :)

Preventing clients having write access in Applications? I simply don't get it. One thing I've learned from casper training and i have been managing apple devices for a long long time before integrating Casper, the process of overthinking things and making things more complex then they need to be, is easy to get caught up on when managing systems.

So you have to find a point where, this is the big picture and end goal. does this whole "prevent clients from having write access anywhere in Applications" fit in to how your managing your devices overall. whats the big picture management structure.

@rmhughes wrote:

Just preventing clients from having write access anywhere in ~/Applications :)

M'yea, not sure why you would ever want to micromanage your users' home directories, did you mean /Applications? A lot depends on the minimum/baseline security requirements laid out by the business.

Don