@jonatronic][/url - Welcome to the Casper Suite and the JAMFNation forums!
Re: your situation, its possible to add in a preinstall script to the package you create, either in Composer or most any other packaging solution. So for example, you could put a line in a preinstall script that would look something like this (this is a simple example, and could be fleshed out with proper before and after checks for example)
#!/bin/sh
rm -Rfd "/Applications/Microsoft Office 2011/Media/Templates" 2> /dev/null
exit 0
Basically that will delete the entire "Templates" directory from that location. If it doesn't exist for any reason it will send errors to /dev/null so it won't get tripped up and report a failure. This would account for any Macs that its running on for the first time since that directory won't exist.
If you keep the Source for this package in Composer, each time you need to update it, all you have to do is replace the files being deployed to /Applications/Microsoft Office 2011/Media/Templates/ by deleting the source files in Composer and dragging the new ones back into the same location. Then rebuild and upload to Casper Admin/JSS.
So the above part is relatively easy. The bigger issue will be how you'll keep track of who needs the new files. If each time you build the package, you keep everything the same, it might be challenging to determine that. But there are a few options.
One, you could flush the existing policy log and let all scoped Macs run the policy again. That's a simple solution and would ensure all Macs re-run the policy. Its a little bit of a sledgehammer approach, but in this case, might be a good option.
Two, and I think this is a better option personally. Change the pkg bundle identifier (not the name) in Composer with some unique build number or date for example. Then rebuild and upload to the JSS. As long as the pkg name itself doesn't change, uploading it will overwrite the old one. If in your policy you create a Smart Group scoped to the policy to look for Macs that don't have a package receipt with that bundle ID, all you'd need to do it update said Smart Group for Macs that do NOT have that new package bundle identifier. If you set the policy to Ongoing frequency, it will mean as soon as a Mac falls into that Smart Group it will become scoped to the policy and run on whatever trigger you've set for it.
The reason i like the second option better is that it would make any reporting a little easier. For example, you could create a report a few days later to report on which Macs now have the new package and which still have an older one lying around. If the old and new pkg have the same bundle id, it will make such a report nearly impossible.
I have no idea if future reporting will be important to you, but whenever I plan something out I always keep that in the back of my mind, even if its not a requirement now. Knowing management, someone somewhere at some time, will eventually ask you to create a report on this :) So best to be prepared ahead of time.
Hopefully these ideas help you out. Let us know if you need some extra help getting anything set up.
