Issues deploying using Policy- dmg mounted twice

[ewinterbourne]

Casper is quite new in my office. We are still on version 8.7. By next year we will have moved to version 9.x, but for the meantime we are stuck with 8.7

Having a number of issues, but the main one that is bugging me is deploying a DMG for CS4. This was originally packaged in Filewave many moons ago using snapshots. It was then re-captured for Casper also using snapshots (this time in composer).

We have three distribution points. The main one is running on a windows share using ExtremeZ-ip (AFP). The other two are AFP connections on two Mac OSX servers running 10.6.

I have created a policy to deploy CS4, initially with the trigger ANY and once per computer. I was on the client Mac and in terminal I ran the sudo jamf policy -trigger any command to kick it off. I did this seconds after finalising the policy. This is when I noticed two issues!

First issue is that two instances of the CS4 DMG were mounted at the same time. In the logs it stated it was running the policy and copying the files over using ASR. In the terminal window where I had run the jamf policy trigger command it stated it had failed to install so was reverting to ditto to copy the files. I then started to monitor Activity monitor as about 45mins had passed and it still hadn't completed. I spotted two instances of ditto running. So it appeared that one process for ditto was running for each mounted instance of the DMG. I killed one of them and the install continued and completed successfully. It was apparent that both DMGs mounted simultaneously was causing the install to hang.

The second issue that has also had a major impact on the time it takes to deploy the CS6 PKGs we have (much cleaner than our CS4 packages) is Symantec Endpoint Protection. SEP is scanning the mounted DMGs. This is totally undesirable as it adds on total length of time to deploy. I'm having to force quit it in Activity Monitor to speed it up, although it will kick off again and again. So I doubt I am saving that much time. In reality I will not be doing this if deploying to multiple clients. Unfortunately I have no access to the back end of SEP, but if anyone has found a solution for this please let me know what you had to do. If exceptions can be added to the SEP admin console then I can arrange for this to be done.

Apologies for the long post, just trying to capture as much info as possible to paint a picture for you.

thanks
Ed

[nessts]

since CS4 days i have always wrapped the Adobe installer and actually run the installer local on the disk. I do not rely on checking this must install on boot volume button. I have a launch daemon that launches the CS install with the login of the first user, gives them Cocoa Dialog information boxes about to not do anything while CS installs give them a status bar so that they know something is happening etc. This method has a much higher success rate for me.

[ewinterbourne]

hi Nessts That sounds like a really neat solution. Unfortunately I'm not really in the position to redo the CS4 installer. The version we have has been modified slightly to include some custom actions/scripts. And we will be eventually moving away from CS4 so it wouldn't be worth the time spent setting it up all over again. I would love to know why the DMG is being mounted twice and how I can possibly prevent Symantec from scanning the mounted DMGs.. anyone else experienced this behaviour before?

[tkimpton]

Been using my dummy receipt method for ages now

https://jamfnation.jamfsoftware.com/discussion.html?id=4482

[nessts]

i would guess that if you do launchctl unload /Library/LaunchAgents/com.symantec.??.plist for each of these plists before you start the install and then start them up afterward it might stop the scanning. com.symantec.quickmenusa.application.plist
com.symantec.savdiskmountnotify.application.plist
com.symantec.scannotification.application.plist
com.symantec.symsecondarylaunch.application.plist

The second mounted version is likely SEP mounting it to scan it. and really it should not be causing a problem, because the second mounted one has a 1 after it right? and the installer is using the path to the one without the 1 in it. I could see it slowing things down greatly as older versions of SEP can control the system resources.

[ewinterbourne]

thanks for the help guys. I have found a solution it seems. The policy was set to run with the Any trigger. I was installing the software under this policy again today. As I monitored it I noticed the DMG mounting again, this time there were three instances of CS4 dmg on the desktop. It looks like there is an issue with the any trigger.. The policy was running under three different process ids. In the logs I could see that each process id was related to a different trigger type.

So I had the policy being kicked off by Every15, login and startup!!So not entirely sure if Symantec was causing the multiple mounts, but I can confirm that the extra DMGs did end with a 1... and then a 2 for the third instance.

I have changed the policy to run at login.. it is going through the various installers/dmgs nicely and only one instance of it. Symantec might be slowing it down still, but possibly not as bad as I initially thought. The real slowness I think was down to having multiple processes trying to do the same thing.

The policy deploys a bunch of fonts/CS6 and CS4 DP/various smaller apps and drivers

[tkimpton]

@ewinterbourne

All there in the link ;)