It might be easier just to use sudo jamf flushPolicyHistory as a post imaging script. That should flush the policy logs for that machine so the run once items will execute again.
Deleting a computer automatically would need the rest api. Completely doable, but much more complex.
As @davidacland said, put a script into your JSS that runs
1#!/bin/sh
2jamf flushPolicyHistory
and you'll be all set.
Done this way, you won't need sudo as it will run as root. Set it to run at reboot and throw it into your re-image configuration.
Jeff
Awesome!
Thank you both so much!
I will test this today!
Hi ,
I just happened to be looking for a way to automate deleting a computer before re-imaging as @jeffrey_ngo mentioned. However, I am using Deploy Studio to image my macs and things just seem to run better if the computer account was deleted before getting re-enrolled. Any ideas?
Thanks
Mark
Deleted as the reply was not relevant to the previous post.
Man, I shouldn't just reply to the email notification obviously!
@msnowdon
Hi ,
I just happened to be looking for a way to automate deleting a computer before re-imaging as @jeffrey_ngo mentioned. However, I am using Deploy Studio to image my macs and things just seem to run better if the computer account was deleted before getting re-enrolled. Any ideas?
Thanks
Mark
We also use DeployStudio. We have a script at the end of our workflow that does the /flush policy as well as another script to remove the user associated with the computers. That seems to work well for us.
enroll.pkg installs on first reboot, the two scripts run after that. We haven't had a problem since we've been doing that, in fact we just finished up our summer imaging of about 1600 desktops.
As I understand it this shouldn't be necessary, but I use this as a workaround because the existing computer record has caused issues with imaging for me.
I use a Self Service policy and a script that uses the API to delete the JSS computer account for that machine. We run the Self Service policy before re-imaging a machine. Essentially it reads the machine's serial number then deletes the record for that serial number:
1#!/bin/sh
2SERIAL=$(system_profiler SPHardwareDataType | grep 'Serial Number (system)' | awk '{print $NF}')
3curl -ksu username:password "https://jss.com/JSSResource/computers/serialnumber/$SERIAL" -X DELETE
The SS policy also removes the EFI password and reboots the machine into Target disk mode so it's ready to image.
@rleatherwood , Im not very good with scripting. I usually find what I'm looking for and edit it. Do you use the above script and place it in DeployStudio's workflow?
Since it runs after the enrollment, it doesn't mess anything up with the new policy history?
And @Josh.Smith , would that script you use work in my environment? I'm assuming I would have to change the URL to the JSS but would that be it? Again, I'm not a big scripting person.
Thanks for the help,
Mark
@msnowdon You'd need to modify the username, password, and URL for your environment. I have added logging and some error checking, but that's the heart of it.
I created a JSS user account that only has access to delete Computers specifically for this purpose, and those are the credentials in the script.
@msnowdon
Im not very good with scripting. I usually find what I'm looking for and edit it. Do you use the above script and place it in DeployStudio's workflow?
Since it runs after the enrollment, it doesn't mess anything up with the new policy history?
It clears jamf policy history completely before the first boot. I just throw it at the end and have it set to run after first boot, but after the enroll.pkg file runs.
So anything set to run once per computer will run again.
@rleatherwood , I used that script as the last part of my workflow and it worked. Now I'm debating whether to play with deleting the entire computer record prior to imaging because not everything gets reset.
Thanks
Mark
@Josh.Smith @msnowdon
I have it run during imaging with the priority of "Before". It just makes life easier in a school.
You could still mass delete the computers ahead of time if you wanted to do that still by deleting them by Smart group, in the action tab at the bottom right corner.
One of my concerns with deleting the computer out of Casper ahead of time is if something goes wrong during the image you might not know until you physically saw the computer. (Froze during imaging? Power went out?) Though I guess you could go and count the computers, we just have everything automated on our end and don't need to touch the computer again once the restore kicks off barring a failure. Actually next year we shouldn't even need to physically touch them, and we could technically re-image all of our classroom computers (1600ish) within a week automatically using a combination DeployStudio & Casper.
@Josh.Smith
I ran into an issue with this script, it prevented Casper Imaging from mapping printers during imaging. I turned on debug mode in Casper Imaging and nothing useful. It stated that all printers were mapped, but System Preferences said otherwise.
I'm going to so some more testing with this.
Edit:
Don't set this as a "Before" script, it doesn't map printers at all. Using Self Service, it works.
Hi All,
I'm pretty sure that the below has been included in the First Run script that is run post imaging since v8.x
1sudo jamf flushPolicyHistory
So should be no need for this, which means i'm confused by the behaviour @jeffrey_ngo is seeing.
The flush policy history command hasn't been necessary since 8.62. I used to use it, but imaging does a policy flush on it's own as part of JAMF's first run scripts. Assuming you're using Casper Imaging.
Not sure if using a quick add pkg as part of DeployStudio has the same effect.
@bentoms
I need to use this otherwise I will occasionally get "Device signature error" when I re-image a computer too many times (test machines for example). Using "flush policy" will not fix this issue. Take a lab of 30 machines for example, guaranteed two of them will get that error. Everything is up to date in the JSS (certs, JSS, the server).
Deleting the computer from the JSS (before or during imaging) fixes this issue completely.
@Abdiaziz hmm I don't see that error & have multiple iMacs that i bludgeon with imaging tests regularly.
I wonder what I do that differs to you?
@bentoms
Good question really.
JSS 9.73, Windows Sever 2012, self signed certificate.
NetBoot made with AutoCasperNbi (thanks Bentoms!)
Imaging config for test machines:
Wipe HDD
OS X 10.10.5 mad with AutoDMG
Apple Remote Desktop
Active directory bind (built in)
Admin packaging account.
@Abdiaziz Well this is my workflow, have a ganders & see if much differs.
@Abdiaziz You know, I'm starting to see more of these "device signature error" as well. I've just been re-enrolling and moving on but it is starting to get to a point where I think something is wrong in my environment. I'm still on 9.72 though.
@jrippy Even adding a quickadd package to the end of the configuration doesn't fix it :/
I have experienced "Device signature error" since version 9 so I do need to delete any computer record where duplicate or a refresh. I like @Abdiaziz have the JSS on JSS 9.73, Windows Server 2012 but with a third party cert.
This is a script cobbled together from what I have seen here on jamfnation and also picking up on what @Josh.Smith had posted.
It is a work in progress and I am sure it could be approved. The idea of it is to run before a computer is provisioned.
1#!/bin/bash
2
3# Variables needed to match the environment
4JSSURL="https://xxxxxxxl.com:8443"
5LOGIN="xxxxx"
6PASS="xxxxxxx"
7LOGFILE="/private/var/log/xxxxx.log"
8SERIALNO=$(ioreg -rd1 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformSerialNumber/{print $4}')
9COMPUTERNAME=$(hostname)
10MACHINEID=`/usr/bin/curl -sS -k -u "${LOGIN}:${PASS}" -g "${JSSURL}/JSSResource/computers/serialnumber/${SERIALNO}/subset/General" | awk -F "<id>" '{print $2}' | awk -F "</id>" '{print $1}'` 2>&1 >> "${LOGFILE}"
11MACHINEGENERAL=`/usr/bin/curl -sS -k -u "${LOGIN}:${PASS}" -g "${JSSURL}/JSSResource/computers/serialnumber/${SERIALNO}/subset/General" | head -1` 2>&1 >> "${LOGFILE}"
12DATE=`date "+%d.%m.%Y - %H:%M:%S"`
13
14
15# Creating Log file
16/usr/bin/touch "${LOGFILE}"
17/bin/echo "" >> "${LOGFILE}"
18/bin/echo "" >> "${LOGFILE}"
19/bin/echo "${DATE}___Logfile created" >> "${LOGFILE}"
20
21
22#/bin/echo Machine name, serial number and JSS Computer_ID
23/bin/echo "${DATE}___Machine name is: ${COMPUTERNAME}" >> "${LOGFILE}"
24/bin/echo "${DATE}___Serial number is: ${SERIALNO}" >> "${LOGFILE}"
25if [ -z "${MACHINEID}" ] || [ "${MACHINEGENERAL}" == "<html>" ]; then
26 /bin/echo "${DATE}___Could not find any Computer_ID for machine ${SERIALNO}" >> "${LOGFILE}"
27 osascript << EOT
28tell application "System Events" to display dialog "Looks good, could not find any computer record matches." with title "XXXXXX" with text buttons {"OK"} default button 1
29EOT
30 # add dialog Looks good, could not find any computer record matches
31else
32 /bin/echo "${DATE}___JSS ID for machine is: ${MACHINEID}" >> "${LOGFILE}"
33 # add dialog Found matching serial number, check yes to delete from the JSS
34theAnswer=`/usr/bin/osascript << EOT
35tell application "System Events"
36activate
37display dialog "Found matching computer record, should we delete?" with title "XXXXXX" buttons {"Yes","No"} default button 1
38if the button returned of the result is "Yes" then
39 set theAnswer to Yes
40 end if
41end tell
42EOT`
43/bin/echo "${theAnswer}"
44if [[ ${theAnswer} == "yes" ]]
45then curl -ksu username:password "https://xxxxxxxxx.com:8443/JSSResource/computers/serialnumber/$SERIALNO" -X DELETE
46osascript << EOT
47tell application "System Events" to display dialog "Computer record deleted." with title "XXXXXX" with text buttons {"OK"} default button 1
48EOT
49else
50osascript << EOT
51tell application "System Events" to display dialog "Computer record not deleted." with title "XXXXXXX" with text buttons {"OK"} default button 1
52EOT
53fi
54fi
FYI,
When I was testing years ago I could't get curl to JSS to work with a bash script had to use cshell
C
