Who Imaged What?

Pretty sure there is a Feature Request out there asking for this exact capability. It seems like a very logical thing to include since you need to log into Casper imaging to image anything. Why wouldn't that be captured in the standard imaging log once an imaging session is started?

I agree.

I would love it if we could also run some metrics against it to see who images the most machines, or who has to have the machines they imaged re-imaged and such.

Found it... and voted it up...

https://jamfnation.jamfsoftware.com/featureRequest.html?id=145

date/time of image would be a nice searchable inventory field as well.

We already capture imaging date & time in an Extension Attribute, but only because we use DeployStudio, not Casper Imaging. However, the same method may work to capture the image date/time from a "Casper Imaged" Mac.

@mm2270, what extension attribute are you using to achieve this with DS?

Hey @cstout,

So, our EA script actually looks for the file system creation date on 3 files/folders in order of preference. Every Mac imaged with DS gets a ds_finalize.log or ds_imaging.log file created on it, placed in /private/var/log/
We use mdls, which is the command line interface to Spotlight to get the kMDItemFSCreationDate metadata.

Here's the relevant script syntax to get you in the right direction.

mdls -name kMDItemFSCreationDate /var/log/ds_finalize.log | awk '{if ($1 != "(null)") print $3,$4}'

The output is something like:

2014-03-12 04:24:01

which incidentally is perfect for a Date data type Extension Attribute.

The script first checks for the existence of the file, standard if [ -e /path/to/file/ ]; then stuff.
If it can't find "ds_finalize.log", it next checks for "ds_imaging.log" which in some of our older imaging configs it was creating instead. If it can't find that, it next moves to looking for the "/Library/Application Support/JAMF/Receipts/" folder and if found, gets the file system creation date. Finally, if that can't be found or the output isn't as expected, it reports "N/A" for imaging date.
For us, it works in about 99% of cases. The "Receipts" folder isn't typically as accurate a date since it can be created hours after a Mac is imaged, but it should at least be in the ballpark.

BTW, the if ($1 != "(null)" check in the awk part is because in some cases mdls was pulling a null value, so that tells awk to only print $3 and $4 if $1 is not "null"

Interesting side note: At one point in time we attempted to use the creation date for our Casper service account, figuring this would be good since it would indicate date of enrollment. Problem was, for a QuickAdd.pkg created from Recon.app, the service account creation date gets hardcoded, in that it seems like it creates the user account within the pkg and simply deploys it down when the QuickAdd is installed. I had assumed it was creating the account fresh using dscl . create commands or something, but it isn't doing that. (Not sure if the same holds true for when a Mac is enrolled during a Casper Imaging session) So if you re-use that same package for all imaged Macs, they all have the same creation date for the service account. That's why we use the logs or the Receipts folder, which seems to get created new once the first package is downloaded and installed.

One final note. Using creation dates for things like log files is admittedly fragile since they can easily be deleted by a user or through some process. In particular, the Receipts folder could get blown away if a remove framework command is run on the Mac and re-enrolled. But its all we have. You can't use creation dates for almost any System file/folder because they have dates that are from the time the OS installer was built, not when the Mac was imaged. If anyone has a more solid suggestion for something to use for this, I'd love to hear it.

Dang double post

@mm2270 Do you happen to teach classes for JAMF? I'm never disappointed when I get a reply from you. Thank you for that detailed reply. My list of "things to try" just keeps growing.

I did end up voting up that feature request as well since I do believe it would be simple to implement since, like it's mentioned in the request, the feature already exists in Casper Remote.

Would be great for training, accountability, and I sure know our security department would love it.

If you're not using Deploy Studio, you can drop a file somewhere on the system with the imaging date (and time if you want) and then read that into an EA. I use the following snippet in my Post Imaging script:

modelName=`system_profiler SPHardwareDataType | awk -F': ' '/Model Name/{print $NF}'`
TODAY=`date +"%Y-%m-%d"`
touch /Library/Application Support/JAMF/Receipts/$modelName_Imaged_$TODAY.pkg

You can then check for that file and grab the date.

Of course an even easier method (and I really just thought about this while writing this) would be to create your own plist with your own key value in it. Then you could just use defaults read to ingest that into an EA.

So in your imaging script:

TODAY=`date +"%Y-%m-%d"`
defaults write /private/var/<somefolder>/logs/imagedate.plist imageDate $TODAY

Then for your EA you'd simply need to do something like this:

defaults read /private/var/<somefolder>logs/imagedate.plist imageDate

I believe that would read directly into a date formatted EA, but I haven't tested that.

The only way I can think of to grab the name of the person that did the imaging is to make that a manual process at this point. Make it a policy (not a JSS one but a written policy) that whoever does the imaging needs to enter into an EA on the computer record their Name. Then create an EA that takes text as input (or a drop down if you have a set list of folks imaging).

@stevewood Great suggestion for keeping track of a last-imaged date. I will try that out Monday. Very useful information to have. Thank you.

@stevewood, yeah those are great suggestions. The only issue I see is that of course it will only work for anything going forward. Older imaged Macs won't have those files on them so nothing to pick up in the EA. But for anyone first starting out with a JSS or beginning to set up their process this probably makes the most sense. in our case, we needed a more reliable way to get that information from the Mac for systems imaged long ago.

@mm2270][/url you're absolutely right. I know we've had the very same discussion on here multiple times over the years, and each time we come down to the same thing: it works great going forward, but sucks going backwards. :-)

IIRC somewhere on JAMF Nation there was a discussion about using some system generated files, but alas, it is 5 pm on Friday and my brain is fried. Perhaps one of the other "older folk" can recall those discussions and dig them up.

Yeah, this thread did seem strangely familiar, so I went searching and pulled up a few, some of which also have some good hints and information:
https://jamfnation.jamfsoftware.com/discussion.html?id=7729
https://jamfnation.jamfsoftware.com/discussion.html?id=6020
https://jamfnation.jamfsoftware.com/discussion.html?id=8995

I see I was quite prolifically posting in some of those threads too :o
And you're right. Each one ends with basically the same conclusion - We can build EAs/scripts for this, but it sure would be nice if it was included by default.

Haha, I took a look and i even replied to some of those. I guess I forgot all about it, or was wishfully thinking that something new was coming down the pipes.

-c

As far as knowing who imaged a Mac, I'd be far more interested in having that information in a database record so you can use it in your reports, smart groups, scripts, etc. I would use this record to send an automated email to the person that started imaging the Mac once it is finished. Check out these feature requests:

https://jamfnation.jamfsoftware.com/featureRequest.html?id=1803
https://jamfnation.jamfsoftware.com/featureRequest.html?id=200