Deploying Office Templates (or any other files) which are updated frequently

[PF-Admin]

Hi
I've only been running Casper for 10 days so far so please excuse if any of this sounds pretty straightforward!
We use custom company Office templates which are installed into the application folder on each mac that has the software installed i.e /Applications/Microsoft Office 2011/Media/Templates/xxxx. In the past I used ARD to first delete the contents and then install a fresh set of templates. The reason for this is that some of the files were removed or renamed and didn't want old files to remain in the folder.
I want to achieve the same thing in Casper as it was quite time consuming and also machines were missed if they weren't connected to the network.
I have packaged the templates and configured a policy which adds them to a new mac successfully. However I actually want to first remove the old templates folder and the MS standard templates, then install the new set of templates in their place. The package will need to be updated regularly as and when required and when this happens the old templates will need to again be deleted so the new set can be added. Hope that makes sense.
Any help would be greatly appreciated!!

Thanks
Jon

[mm2270 · Accepted solution]

@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.

[PF-Admin]

Wow. Thanks so much for spending the time to help me out. That works great and pretty much covers me for what I need it to do. However I am going to attempt to get more control with the reporting you mentioned. I'm certainly happy with the 'sledgehammer' approach for now though.

:-)

[chuck3000]

I found that by creating my own "Receipt" that I can then create smart groups on that receipt. This allows you to simply add this line into the Advanced tab of a policy so that once a package is deployed, a receipt is written.
I use a command similar to: touch /Library/Application Support/JAMF/Receipts/SPECIFIC_RECEIPT_NAME.pkg I then complete the install with the checkbox checked to run an inventory.
This allows you to build policies based on scoped smart groups which are based on the receipt(s) you've deployed. Good luck. Please share your results.

[mm2270]

@chuck3000][/url that sounds like a good idea, but I see one problem with this approach. Namely, any commands in the Run Command field actually run even if the main policy portion failed. So in other words if the Mac failed to install the package, it will still end up with that receipt file, which will throw off any future Smart Group or reporting results.
If we lived in a perfect world where policies didn't fail sometimes for a variety of reasons, it wouldn't be an issue, but we don't live in a perfect world.

I only know this because we at one time were using the Run Command to display a message after a Java installation. Only problem was, users were receiving the message even if the installation failed for some reason.

[laurendc]

@jonatronic What we do for our templates is we deploy the most current ones via a policy scoped to a smart group that does not have the current version of the templates installed. You can set the policy up to remove the old ones and install the new ones. Here is what ours looks like:

-Uninstall OldTemplate
-Install NewTemplate
-Update Inventory

Template packages are currently .dmgs

@mm2270 I like the second option you've described and may modify our package/policy to get rid of the multiple package versions that we have for our templates.

Good luck and welcome!