Undo a pkg install???

[nikgio]

I used Composer to create a New and Modified Snapshot that would record custom presets for a printer. All I did was print our homepage in Firefox after changing and saving the setting I needed in the dialog box. I also entered the one line command in Terminal to disable the Google Chrome print dialog box. I left Firefox, Chrome and Terminal open the entire time. After the snapshot was created, I built it into a pkg, tested it (seemed fine), and deployed it through Casper to a group of computers.

What I didn't realize was there was a whole bunch more stuff that Composer captured that I did not touch, and that got deployed too. From /Library/Application Support/ApplePushService and Avast (ok, possibly something ran in the background coincidentally at the same time), to ~/Library/containers (almost every app is listed), and ~/Library/Preferences (wayyy more plists than just the custom printer one). I didn't do anything in all of those applications for anything to have changed! I understand Saved Application State, since I had apps open I guess.

My problem lies with the fact that now some users are complaining that their computers are either randomly restarting on them, or they get the spinning wheel of death that freezes the computer until they force a hard reboot. I can't guarantee that my pkg caused the issue, but the timing of the coincidence is fishy, and I assume I can't just "undo" the whole pkg. I feel like it's going to take a lot of time figuring out what's causing the computers to crash, and then how to resolve it. I created the pkg on an iMac and the users mostly have MacBook Pro's, but we all are running the same image, so things like plists should be exactly the same.

Why is there so much extra stuff in the snapshot in the first place? Now I know to go through and eliminate what I don't want before deploying, but is there something I'm doing wrong when taking the snapshot? Now begins the long, tedious task of eliminating files. Because the problem is periodic and not with everybody, it's going to be tough to nail down the fix.

[bentoms]

@nikki A snapshot is just that, a snapshot of the system.. Either between points in time or a snapshot of all new & modified files over a time period.

You should really either go through your snapshots to clear the unneeded cruft, or set things via profiles or scripts to disable dialogs.. Lastly you can use snapshots to troubleshoot changes..

After this, you'll need to test it before deploying out.

Even if you're only changing a setting for an app... Deploying the plist will overwrite those settings that people may have... So really I'd suggest using Composer snapshots to see what's changed... Then google to see if anyone has managed or changed those strings via a script or profile.

[mm2270]

This is a perfect example of why snapshots in Composer should literally almost never be used for package building. I know that statement isn't very helpful to you, so I will try to offer some help in a bit. But I can't emphasize enough how dangerous snapshots are. There are just too many "things" being modified and created in the OS even when the Mac is just sitting idle with no applications running and no input from a user. Because you used a New and Modified snapshot, Composer just did exactly what it was told to do, which was to gather anything modified or new. It can't possibly understand what you modified or created, versus what the thousands of background OS level processes created or modified. This is just the nature of OS X.
I really do wish that JAMF would move away from teaching people to use snapshots in Composer. I'm not sure who seems to be stuck on this archaic method of building packages, but it would be nice to see a new standard being taught to new Casper Suite users.
In short, you are not doing anything wrong with snapshots, other than using them in the first place, but, I suspect you were told they were OK to use, so not really your fault. Unfortunately, it often takes near disasters like this for most folks to learn to not use them, or use them judiciously and very carefully examine the contents of the capture before packaging it up.

Now, as for what you can do, its very hard to say, but if the files that were deployed are not typically files that should be on any of the Macs, you can try indexing the package in Casper Admin and then redeploy it but use the "uninstall" method, which should remove those files. This may not work though, and in fact, could even cause more issues, especially if the original package overwrote items that are usually in the OS and need to be there.
I would start the process by examining your package in Composer and begin taking one system and removing a file or folder at a time that was accidentally deployed and see if it resolves the issue. Give a little time between each removal so you can determine if it had any effect. You're going to need a guinea pig user that will be OK with you accessing their Mac, making changes and potentially doing reboots between each, and possibly even having their system hosed if something goes wrong.

I'm sorry this happened to you. Again, its not really your fault, but like many things, this is a good lesson in how not to do something, so you'll be better informed for the next time. Good luck.

[Chris_Hafner]

I agree totally with @bentoms and mostly with @mm2270. I've always found snapshots to be an extremely useful tool. It's just super dangerous for those who aren't already deeply familiar with OS X deployment and package development. Personally, I spend lots of time working with new applications/preparing new installs and the snapshots feature allows me to quickly verify everything that gets touched for each of these new installs. That way I may better prepare for the deployment of whatever it is I'm working with.

Heck, using composer snapshots to package MS Office (6 years ago) is what led me to begin using the full Casper suite. Most of the time I use it to find out which plists and the like are being modified so that I can deal with them properly (generally not via composer). However, I'm not sure I've ever deployed anything captured via snapshot without really going through it file by file. You simply MUST NOT EVER trust a packaged up a snapshot without knowing EXACTLY what each item will do and why.

@nikki I do feel badly for you, if you were duped into thinking that snapshots are an easy and guaranteed way to create .pkg or .dmg installers. However, you really should have tested that fully first. When dealing with any type of device management you wield nearly unlimited power. There are simple checkboxes in here that can have immediate and lasting ramifications for your users. Just wait until you see someone get a profile that didn't do what was intended!

So with that all set out. What were you trying to deploy? Do you have a list of the things that you were capturing via the snapshot? We can probably help point you in the proper direction.

[mm2270]

Heh. I really should have qualified my previous post/rant by stating that, in some circumstances, using a Snapshot as a "discovery" tool can be very useful, as outlined by @bentoms and @Chris_Hafner above. I know I made it sound like you just need to avoid them forever and ever, but that isn't really what I meant. I've used snapshots to see what plists and other files are being touched or created, sometimes even with just making a change locally on my Mac and not even related to a package install. However, as already said several times here alone, don't just run a snapshot and package up and deploy anything without doing a super thorough examination of the contents. It sucks that this is how it is, but simply rolling up a snapshot and pushing it out is a perfect recipe for disaster.
Edit: And also, whenever humanly or technically possible, use prebuilt package installers from a developer. Only IF a snapshot is truly necessary should they even be used, but that's only my opinion.

If JAMF wants to continue to teach using Snapshots, they, or at least JumpStart partners need to be making a very strong point to newcomers that they have to learn many of the ins and outs of the OS and packaging, or at least get a second set of more experienced eyes on their snapshots to check the contents before just packaging them up. Doing anything else is just too dangerous.

Anyway, I hope you were able to figure out what's causing the issue with some of your Macs and get it resolved, or are close to having it resolved.
Do post back here if you need some support on what you can try. That's what where here for!

[Chris_Hafner]

P.S> You really will get the worlds best Mac Administrative advice from @mm2270 and JAMFNation. ;-) Seriously, this guys sleeps under the JAMFNation banner at the top of the page!

[Chris_Hafner]

P.P.S I hope that JumpStarts aren't pushing snapshots as the preferred packaging method are they?

[philburk]

Chris_Hafner, I will let you know as my new employer has a JumpStart scheduled for soon.

[mpermann]

@Chris_Hafner I had a CCT back in July and we were told that "most of the time repackage a PKG file with the exception being printer drivers, don't repackage those". That really surprised me based on everything I had read on JAMF Nation prior to taking the course. Don't get me wrong, it was a great course and the instructors did a nice job. I just didn't expect that to be the suggested course of action. I really would have expected they would have recommended at least trying the vendors package as is first then repackage if necessary.

[Chris_Hafner]

Ewww. I've got to ask Dusty why that would be in there.

[apizz]

During our Jumpstart this past July, we were told to ONLY use the "New" snapshot function. This had the least likely-hood to grab a ton of extraneous files that would otherwise get picked up if you did New & Modified. I've had no major problems with this, but I agree that it's quite possible if you're not careful to pick up things you didn't mean to when building your package.

[bpavlov]

That really bad advice if that's really what they are preaching. If it's too time consuming to discuss proper packaging, then they should make pre-recorded sessions that can be viewed by the admin at any time. Or not cover the topic at all. I'm not sure under what umbrella at JAMF Software that sort of training falls under but that needs to be revisited. Particularly when you pay a pretty penny for jumpstart or any of their certs, you should be learning best practice, not the opposite. Wish someone at JAMF could comment on that. It's not the first time this has come up at JAMF Nation.

[Chris_Hafner]

@aporlebeke What? Someone please correct me but the last time I checked the "New and Modified" snapshot will also grab any system file that's had any sort of metadata change. @dustydorey Any thoughts regarding the training's we've been talking about?

Here's the statement from the documentation on Composer 9.81.

Composer can take two kinds of snapshots: Normal snapshots—These snapshots capture any new files on the drive. These snapshots can take anywhere from ten seconds to several minutes depending on your hardware and the number of files on the drive. New and modified snapshots—These snapshots capture any new files on the drive, as well as any files that have been modified. These snapshots can take longer than normal snapshots, since Composer records the modifications date of each file while performing the snapshot.

[mpermann]

I should clarify, we were NOT told to use the "New & Modified Snapshot" method when we repackage. Just that we should repackage most of the time, with the exception being printer drivers. I believe the preferred method was the Normal Snapshot method. But I generally agree with what others have said above regarding repackaging.