jamf.log File Question

@asd_software This doesn't sound possible to me. If the Mac truly was nuked and paved, the jamf.log file would not have survived with older data in it. I suspect the drive was not erased.
There are cases when a drive can't be unmounted due to a variety of reasons, and Casper Imaging will drop back from block copy to file by file copy instead. The latter method simply copies over your base image on top of what's already there and can leave older files intact, especially something like the jamf.log since that probably isn't in your base image.
I would check to see if that's what happened.

Something else you can use to verify is the Creation Date on the /Library/Application Support/JAMF/Receipts/ directory. Not Date Modified since it will be changing all the time, but the creation date, which should closely match up with your imaging date (if it was really fully re-imaged)

I see the same behavior and have just always assumed that Casper Imaging restores the jam.log after imaging. The computers are definitely fully re-imaged and the hard drive is wiped, but in the log you will see entries like this in between formats:

*****************************************************************
Formatted Macintosh HD on <date> at <time>
*****************************************************************

When I checked that folder, it did have a recent creation date. When I checked other logs, they only showed information following the imaging. The jamf.log file was the only one with older data in it. It even specifically states "<computer> was formatted on <date>" in the jamf.log file. As another test, I wiped the system using Disk Utility in the Recovery Partition. In that case the jamf.log was wiped. Therefore, I'm wondering if Casper Imaging does something different when you select "Erase Target Drive." Maybe it makes a copy of that log or something?

I suppose its possible it backs up the log and restores it afterwards, just like @rdwhitt stated, but that would be strange. I'm not sure what the reason would be for that unless its strictly for troubleshooting purposes after a re-image?
I can't effectively test anything as we use DeployStudio for imaging, not Casper Imaging.

A little off topic, but where is the jamf.log file stored on client machines?

/var/log/jamf.log

I have also seen this happen. Normally, when we reimage a machine, with Casper Imaging 9.7, it will wipe the drive and everything is fine. (no old log entries), but once an while, I see the

Has anyone had issues when reimaging, where it has a problem enrolling in JSS or sometimes, it will enroll, but not create my management account. This only happens if you don't delete the old computer from the JSS before imaging.

@jleomcdo

Has anyone had issues when reimaging, where it has a problem enrolling in JSS or sometimes, it will enroll, but not create my management account. This only happens if you don't delete the old computer from the JSS before imaging.

Happens with my test machines (re-imaged often).

It's almost like the JSS doesn't see it as a "new" enrollment, so it doesn't create the admin account / "enroll" the computer. (which really go hand in hand) I wonder if this "working as designed" or do we have a problem in our environment with imaging?
Maybe I should be running a script at the very beginning to remove the computer from the JSS? Thoughts?

@jleomcdo

Maybe I should be running a script at the very beginning to remove the computer from the JSS?

This is probably the only solution, unless your techs delete the computer from the JSS prior to re-imaging (people will always forget).

Delete the machine before imaging, run a quickadd during imaging

Would this be done using an API or a pre-exsisintg JAMF command?

i just figured this was a feature. Doesn't bother me except when I'm searching the log file for errors and its full of stuff from previous imaging.

I just noticed the same exact issue on a test machine that asd_software mentions in the first post in this thread.

To add to the variable isolation, this occurred on a test computer that was imaged and enrolled in a JSS that had no computers in it at all. In other words, it's not a matter of a device record saving this information to the jamf.log on that computer at the time of imaging. The jss that this computer was enrolled in had no computer records, thus it had no data that could be written to the jamf.log for this computer.

To summarize:

• test computer had been previously enrolled in JSS-1
• test computer was imaged using casper imaging and enrolled in JSS-2
• jamf.log on computer after imaging with erase and enrollment into JSS-2 that had no device records of any kind had log data going back months, log data from when this computer was enrolled in JSS-1

Has anyone found any answers on this issue in the meantime?

Working through this issue with support now. In my case:
caspermgmt account gets created but not added to ssh group

@jleomcdo Looking to talk to you about your Managed by EA. Trying to get it to work.