Remove Framework after Imaging

[cstout]

Ok, disclaimer, this request is for a very small department that is fully unmanaged by our offices. I know that my question goes against the way Casper Imaging was designed to work. That said, there seems to be a work around for just about everything out there so I thought I'd throw the question out.

I built out a configuration that has our standard suite of software and OS configurations that includes a script "at reboot" which runs "jamf removeFramework" in an effort to have the binary removed post-image. Adding this script only seems to lock up the client at the Casper Imaging lock screen.

I then modified the script to add a "reboot" command after removing the framework and the result is the same. Casper Imaging sits at the imaging lock screen and doesn't reboot.

Has anyone found a way to image and un-manage the computer successfully? My goal is to not have to use multiple imaging products such as DeployStudio for this. Maybe it's something simple that I'm missing from my script?

[pblake]

I'd also be interested in this. We are in the same boat with one office that is completely unmanaged. I'd like to deploy the same way as all other machines, but pick a configuration for these machines that will remove the JAMF binary after imaging. I've been doing it manually.

[JPDyson]

First stab: Package a LaunchDaemon that runs this script, and install the package to the boot volume. That way the script doesn't run until imaging is truly done. Edit: If it wasn't clear, do NOT make loading the LaunchDaemon a part of the install. That way it will just be placed into the LaunchDaemon folder on that first boot, and not loaded until the following boot.

You'll still have to delete these devices from the JSS...

[cstout]

@JPDyson how would I go about having the daemon delete automatically after it runs successfully?

[mm2270]

In whatever script you're running as part of the LaunchDaemon, simply do an unload of the Daemon and then an rm at the very end of your script as a cleanup phase. Something like-

/bin/launchctl unload /Library/LaunchDaemons/com.mydaemon.plist
/bin/ rm -f /Library/LaunchDaemons/com.mydaemon.plist

You can also have the script delete itself if you don't need it anymore and don't want it lying around-

workingDir=$( pwd )
rm -f "$workingDir/$0"

[bentoms]

We use dummy receipts to identify macs that we don't want running a lot of our management tasks.

As per: https://jamfnation.jamfsoftware.com/discussion.html?id=10057#responseChild56157

That way you can still keep "sight" of those macs in the JSS, just don't scope polices to them.

[cstout]

@mm2270][/url I'm nearly done with my launchdaemon to run and based on what was recommended I think this should do the trick:

<plist version="1.0">
<dict>
    <key>Label</key>
    <string>removeframework.job</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/env</string>
        <string>jamf removeFramework</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

As far as the cleanup stage that you mentioned; would that go in this same daemon or would I have to create something separate?

[mm2270]

@cstout, if I were doing it, I'd place the remove framework stuff into a separate script that's called by the LaunchDaemon's ProgramArguments array. In that same script, check the exit code of the remove framework and if successful, do the unload and rm commands I mention above as the cleanup. Not saying you can't have your jamf commands right in the ProgramArguments, but in some ways that limits the usefulness of the process. It can handle some sequential commands, but you can't really place any test logic into it that way. This would then require that you build a second LaunchDaemon that would do the cleanup., which seems a little unnecessary to me personally.

[pblake]

Will this remove it from the JSS or just remove the framework off the machine? Do you then have to go to the JSS and remove it?

[mm2270]

Only removes the management framework from the Mac. The computer record stays in the JSS.

[cstout]

@pblake This will not remove it from the JSS and you'll have to remove the records manually. In my scenario, we are glad that it enters records into the JSS because then we have an initial inventory and record of the model, serial number, and date of image. All we have to do is tell the JSS not to manage those computers and we then have inventory records that won't count against our total managed computers count.

@mm2270 Thank you for your recommendation. I'll try it out today!

[ctangora]

If you don't specify an admin account, it won't show up in the JSS (and you won't have to remove it). All you have to do is remove the frameworks then.

-c

[cstout]

@mm2270][/url I may have missed a step or set this up in the wrong order. My pkg drops the script into /private/tmp/ and the daemon in /Library/LaunchDaemons/ and I set the pkg in Casper Admin to require a reboot. After reboot I see that the script has deleted itself but the binary is still installed. When I try to manually load the daemon I get an error which states, "launchctl: couldn't stat(removeframework.job.plist"): No such file or directory.

The script is:

#Remove JAMF Binary
jamf removeFramework

#Unload and delete daemon
/bin/launchctl unload /Library/LaunchDaemons/removeframework.job.plist
/bin/ rm -f /Library/LaunchDaemons/removeframework.job.plist

#Self Destruct
workingDir=$( pwd )
rm -f "$workingDir/$0"

The daemon contains:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>removeframework.job</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/env</string>
        <string>/private/tmp/removeframework.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Now, I'm assuming the daemon loads itself at reboot, which is why I required this package to reboot after dropping the files. It appears to have run, but unsuccessfully, as the script is no longer on the test machine.

Edit: To clarify, the script has deleted itself successfully, but the removeframework.job.plist daemon is still in /Library/LaunchDaemons, did not properly delete, and cannot be loaded successfully from Terminal.

[mm2270]

@cstout - Sorry. It looks like I had a typo in my command above that you copied into your script. The rm line where it deletes the LaunchDaemon should read:

/bin/rm -f

There was a space between /bin/ and rm which would cause it to fail to do the remove command on the LaunchDaemon. Fix that line in the script and it should work. Technically you don't need the /bin/, just rm -f will work fine.

[Chris_Hafner]

You should add something to pull it out of the JSS as well, post imaging. Something like what I found here:
https://jamfnation.jamfsoftware.com/discussion.html?id=10188 I pulled out the:

#!/bin/sh
set CAM=`networksetup -getmacaddress en1 | cut -c18-35 |sed 's/:/./g'`

curl -k -v -u xusernamex:xpasswordx https://yourjss.juniper.net:8443/JSSResource/computers/macaddress/$CAM -X DELETE

set JAM=`networksetup -getmacaddress en0 | cut -c18-35 |sed 's/:/./g'`

curl -k -v -u xusernamex:xpasswordx https://yourjss.juniper.net:8443/JSSResource/computers/macaddress/$JAM -X DELETE

works great in my use. We have a kind of dissociative process at the end of our school year in which we remove our restrictions, licensed software, accounts etc. I use the above lines to have the machine remove itself from the JSS when it's finished with the rest of the processes.

[Chris_Hafner]

FYI, this needed to be modified a bit to work with 10.10. Here you go.

#!/bin/sh
set CAM=`networksetup -getmacaddress en1 | cut -c19-35 |sed 's/:/./g'`

curl -k -v -u xusernamex:xpasswordx https://yourjss.juniper.net:8443/JSSResource/computers/macaddress/$CAM -X DELETE

set JAM=`networksetup -getmacaddress en0 | cut -c19-35 |sed 's/:/./g'`

curl -k -v -u xusernamex:xpasswordx https://yourjss.juniper.net:8443/JSSResource/computers/macaddress/$JAM -X DELETE

P.S. Not my work and I would attribute, but I've forgotten who's it was... again.