Reimage Computer Best Practice

[mrhollywoodgate]

Hi, Everyone,

My employer just got JAMF about a month ago, and I've gone through the Jump Start and have been getting things all setup and computers enrolled. We're on version 9.72

I'm wondering what you all do when you need to reimage a computer. Here's the specifics of what I'm thinking about:

1. Computer History - do you delete the computer from the JSS so that it creates a new entry upon image / enrollment? When I reimage a computer, it does not flush the policy logs, so policies that I have set to install when a computer is imaged don't get installed. (From looking around the forums, maybe this is a bug? Or I'm doing something wrong?). Thus, deleting the computer, or at least flushing all the logs pre-re-image.

2. User Assignment - easy if the computer is going back to the same user, but if it's changing hands, do you just update it in the JSS web interface? Or is there anything else you do with the user at the time of reimage? I guess this largely depends on the answer to the previous question about computer history.

Thanks!

[Simmo]

There is a useful command you can run on the machine to remove all policy logs for that machine, I have this as a part of my first boot script.

jamf flushPolicyHistory

There should also be a way using the JSS API to change the user and location information via script. Would potentially be easiest if you have the name of the user in your computer name.
However I am not familiar with how to use the API so I can't help on that one.

[jchurch]

as for the assigned user... is the device just being handed from one user to another, or is this in a shared environment, like on a cart or in a lab? in a shared environment i wouldn't worry about assigning a user, but if its just changing hands there is a scrip you can run at logon to add currently logged in user to the JSS. we don't use that one, but if you search the forums you can find it.

[mrhollywoodgate]

Thanks for the replies. I'm going to look into that script to assign user based on currently logged-in user. The computers are changing hands, they are not in a shared environment, so that could be useful.

For the jamf flushPolicyHistory - where would I put that in the imaging workflow? I tried it out in my imaging configuration, adding it as a script with the "at reboot" priority, but it didn't work. Should it be a policy that runs a script with some different priority option?

[gachowski]

We delete the machine before re-imagin. There are a few scripts floating around in Jamf nation that can do that automatically.

C

[Simmo]

@mrhollywoodgates It should work as expected as an at reboot script. You can test it on a machine manually with sudo jamf flushPolicyHistory to check it is working.

I went digging in my scripts and I found one to clear previous user and location information also.
You will need to create an API user with read and write privileges.
This should be set to Before for imaging.

#!/bin/sh

## Change these 3 variables to match your setup. API account must have API write privs
apiUser=""
apiPass=""
jssURL="https://my.jss.url:8443"

## get this Mac's Serial number
SNUM=$(ioreg -l | grep IOPlatformSerialNumber | awk '{print $4}'| sed 's/"//g')

## Create the xml for upload via API
echo "<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<computer>
    <location>
        <username/>
        <real_name/>
        <email_address/>
        <position/>
        <phone/>
        <department/>
        <building/>
        <room/>
    </location>
</computer>" > "/tmp/blank_location.xml"

## Now upload the xml file
curl -s -k -u "${apiUser}:${apiPass}" "${jssURL}/JSSResource/computers/serialnumber/$SNUM" -T /tmp/blank_location.xml -X PUT

[AVmcclint]

What if I have to replace the hard drive and the computer needs to be re-imaged and re-enrolled but I don't want to have to repopulate the user and location etc information? I'm in that situation. I want to keep the entry for the computer because it will retain the same computer name and it's the same user and location and asset tag (and more). In the past I've just deleted from JSS and treated it as a brand new Mac, but with all this extra info I've been adding to the computer records, I really don't want to have to redo all that every time. The only thing I know I'll have to do is delete it from Active Directory, but that's fine since we aren't keeping track of all this extra info there.

[stevewood]

@AVmcclint You do not need to delete a machine from inventory to do a re-image. If the same user is getting the machine, you can just re-image the machine and issue a flush to clear policy history so that policies will run again:

jamf flushPolicyHistory

Record will stay in JSS along with any user info you've added.

[AVmcclint]

That command only works though if there is a working OS with jamf binaries installed on it. If the OS is hosed and won't boot.... if the hard drive is blank, empty, slicked, completely void of data, how is this done?

[stevewood]

@AVmcclint During the re-image process. You can create a first boot script and have it run the command.

When I re-image a machine, for example, my Capser Imaging config is simply to place the OS on the machine and a package (set to install at boot in Casper Admin) that contains a shell script and a launchdaemon. Casper Imaging lays down the OS, reboots the machine and lays down the package which installs the LaunchDaemon and then reboots, then the LaunchDaemon kicks off. The LaunchDaemon kicks off the shell script that takes care of some settings and installing all of my apps by calling policies (jamf policy -id xx), and finally it issues the flushPolicyHistory command so that any other policies will run.

[stevewood]

There's a discussion around the FirstBoot script here: https://jamfnation.jamfsoftware.com/discussion.html?id=10491#respond

[Chris_Hafner]

There are many ways to skin this cat. For us, the machines to be imaged are generally experiencing problems and needed repair. We simply re-image using autorun data to catch any optional installs/printers the user may have use Self-Service to install.

If the machine is going to a new user then it's zero formatted and the JSS record deleted before being reimaged. Mostly because it's simple (my help desk has no issue doing that) and reliable in our environment. Anything that needs to end up on the unit, that wasn't optional or on the initial configuration ends up there by virtue of being placed in a specific department that trigger whatever policy is necessary.

[Look]

I have been using this to get the last 15 logins reverse sorted based on frequency (I then work through it in a script until I find a staff AD account to assign to the machine).

last | awk '/console/ { print $1 }' | head -n15 | sort | uniq -c | sort -k1 -nr | awk '{print $2}'

But you could just grab the most common user (local or otherwise) by piping it through another head command i.e.

last | awk '/console/ { print $1 }' | head -n15 | sort | uniq -c | sort -k1 -nr | awk '{print $2}' | head -n1

This allows a technician to log in and correct things, but they would have to log in 8 times or so in succession before they would take away assignment from the currently assigned user.