I simple changed the file extension to .sh and then went to line 2090 and hard coded the case to "-A". I did this back on 6/3/15 and it has never had any problems uninstalling versions of SEP.

I have a smart group populated with macs running SEP 11.XXXXX
I added this symantecremoval.sh script to a policy, policy runs once per-computer, scoped to this smart group. Never had an issue. runs the .sh straight through, no command entered if files and processes

I have a second policy that installs my updated version of SEP and I also install the SEP uninstaller.pkg with it.

For anyone else who happens to try to run this script with Casper, I was able to get it to work by doing a few things:

• Instead of reading the choice, comment it out and set it to "1" manually
  

     printf "Enter choice (1 or 2): "
  
  # read choice
  
  choice="1"



• Comment out the if statement that makes you confirm you want to remove Symantec
  

  # if [ $RemoveFromAllVolumes = true -a $CreateFilesRemovedListOnly = false -a $RemoveCrontabEntriesOnly = false -a $RemoveInvisibleFilesOnly = false -a $AutoRunScript = false -a $RunningFromWithinAppBundleOrSupportFolder = false ] ; then
  
  #    echo
  
  #    printf "Are you sure you want to remove Symantec files from ALL mounted volumes (y/n)? "
  
  #    if YesEntered ; then
  
  #       echo
  
  #    else
  
  #       echo
  
  #       echo "Script aborted. No files were removed."
  
  #       ExitScript 0
  
  #    fi
  
  # fi



• Comment out the section that asks to restart when the script is complete
  

  # if YesEntered ; then
  
  #          RestartAutomatically=true
  
  # fi



• Change the all parameters argument $@ to be the home directory "/" instead:
  

  ProcessArguments --OptionIsOneArgument="-QQ" --OptionIsOneArgument="-re" "/"

Since any script run by the JSS passes parameters $1 through $3, we need to make sure they are not passed to a script not designed to run from the JSS.

Hope this helps someone! I spent more time than I'd like to admit on it.

Hey I have to say THANK YOU VERY MUCH as this worked for me. I wanted to use the more recent version of the Symantec script and your tweaks made it possible. I don't know how many people actually scroll all the way down here to read your post but I'm glad I did and I encourage anyone else getting this far to give this grahamfw suggestion a try.

Symantecs Tech Article for all this is here:
https://support.symantec.com/en_US/article.TECH103489.html

If you look at the bottom of the page, there is another script named SymantecRemovalTool.command that runs with no user input designed for ARD and of course casper

(ftp://ftp.symantec.com/misc/tools/mactools/SymantecRemovalTool.zip)

SymantecRemovalTool (ftp://ftp.symantec.com/misc/tools/mactools/SymantecRemovalTool.zip), a modification of RemoveSymantecMacFiles, is a script that is designed to be pushed out via Apple Remote Desktop. It requires no user input when run as root. As with RemoveSymantecMacFiles, all files and folders that Symantec OS X products (except Symantec Administration Console for Macintosh files) have created will be removed; therefore, you will lose all files that reside in those folders, including any that you have created. For more information, please see the Read Me file included with the SymantecRemovalTool download. SymantecRemovalTool is provided for your convenience only and is not a supported utility.

Posted what @grahamfw did on a gist if anyone else needs it. Here

I used the 2nd script on the Symantec page, but it didn't work the 1st few times, Then I stole part grahamfw idea (Change the all parameters argument $@ to be the home directory "/" instead) and it worked on the 1st test.

Thanks @grahamfw

Tried this today, but it doesn't seem to work anymore. For some reason it's throwing an error "Invalid option or volume name"...

Hi,

I also used the replace option with $@ to "/".
This did the trick for me !

Thanks!

Greetings,
Thijs

https://support.symantec.com/en_US/article.TECH103489.html

As you can read in the above article there are two versions of the script to remove Symantec files.
- One with user input - (RemoveSymantecMacFiles)
- One without user input - (SymantecRemovalTool)

Symantec suggests you use SymantecRemovalTool when using a remote deployment tool.

I tried doing this using the most recent SymantecRemovalTool and @grahamfw 's recommended tweaks. I saved the file as .sh, uploaded to JSS, created a Policy in JSS, and scoped it to a test computer. It seemed to run (had a spinning star at the bottom of the screen) and then rebooted the computer, but I found that if I looked in JSS logs after the reboot that it didn't seem to register that the policy had run. That's happened to me before if a script triggers a reboot without giving time for the script to pass information back to the JSS. From looking at the script it looks like what's triggering the restart is:

osascript -e 'tell application "System Events" to restart'

My test computer to 10.13.2. Did anyone need to change the above command (or add some sort of delay/pause) to get the JSS to register that it completed?

@el2493 it is probably good to comment out any references to the restarting function RestartComputer. That's what is actually doing the restarting.

It is a best practice to let Jamf Pro do the rebooting as part of the policy. The script needs to send Jamf an exit code for the script to be deemed a success or failure, and if it sends nothing, Jamf assumes it didn't actually finish running yet (it eventually times out though).

Just set your policy to reboot automatically after commenting out the RestartComputer function calls and that should clear it up for you.

Thanks, still running into issues (still restarting while running the script). When you wrote:

Since any script run by the JSS passes parameters $1 through $3, we need to make sure they are not passed to a script not designed to run from the JSS.

...does that mean I need to make any changes to the script, or is that just generally useful information to keep in mind?

@el2493 Yes, any script that you shoehorn into Jamf Pro will need to be edited to run successfully. Script parameters 1-3 (i.e. $1 $2 and $3) are passed when Jamf runs any script. If you catch it in flight, the actually see the script parameters running as part of the script.

Quick primer just in case you're not aware: in bash, script parameters are just arguments you run in addition to the script. If a script I run outside of Jamf is called updateUser.sh and script parameter $1 is the username I want to update, when I run it, I'll run it like this:

./updateUser.sh username

As such, Jamf runs each script with the second and third parameters including the user and computer name I believe.

Really, any script like this that you run from Jamf will need to have the parameters removed unless you know exactly what you're doing here.

Thanks again, I tried commenting out the entire RestartComputer function as well as the two times the script tries to invoke the function and it's still restarting when running the script. It's not doing the exact same thing (before there was a spinning star when the policy was running then it rebooted, now if I start the policy from the Terminal it starts running then the screen goes black then makes the startup sound). I also checked to make sure I definitely commented out the items that you mentioned.

Then I started from scratch with an unedited SymantecRemovalTool.sh and tried just replacing the "$@" instances with "/" (which a few people seemed to indicate was all they had to do) but it still restarted while running the script. If I look in jamf.log it shows as:

Executing Policy Symantec Uninstall

Daemon shutdown completed

Daemon exiting

Then tried commenting out RestartComputer invokations (toward the end of the script) and it still rebooted. Also went through the script and any time I saw $1, $2, or $3, I replaced it with $scriptVar1, $scriptVar2, or $scriptVar3 (hoping that would keep it from clashing with Jamf) but still restarts. I'm definitely aware that what I tried for that might not be the right thing, but I'd think that if it was just a matter of a variable not being assigned correctly then it would throw an error message and report the error back to JSS rather than doing a Daemon Shutdown. I saw what you wrote about updating the parameter to be an actual value (like username) but the Symantec script uses $1 for different things (at times it's for the volume, at other times it's the path of a directory or an exit code).

Plus after every Daemon shutdown it seems to not accurately pull recurring checkin policies, so I have to wait an hour before trying again.

Hopefully I'm just missing something obvious, I'd really like to use this since the alternative (based on the complexity of the script) is packaging (which doesn't work as well for logging in Jamf) or reimaging.

I used @rderewianko 's Gist link and it seemed to work correctly. There must've been some changes to the script/command since 2016 that require some additional tweaks, but the older version seemed to work for me.

@grahamfw thanks again!

I also used @rderewianko 's Gist link, and it is working for us! THANK YOU SO MUCH, and thank you to @grahamfw as well.

Hey, sorry to revive this but I'm curious this uses this today as a solution for removing for my company. I've gone ahead and packaged up the .command in Composer and now I've added the script from https://gist.github.com/rderewianko/6aa0032f19e57b595e0fdae4470f6286
into my scripts in Jamf. Am I supposed to create a policy to run the pkg then script? Any and all help appreciated. Have some exp with deployments but no silent uninstalls like this.

cheers