Way to time imaging process?

There is this really cool stopwatch app with the clock on my iPhone. =D

I am guessing you mean to somewhat automatically track this? Is there a
little more detail on what you are attempting to do that could help with
this?

The only thing off the top of my head I can think of os parsing stuff out
of the jamf.log somehow, which sounds like a huge pain in the butt.

Craig E

There is a stopwatch app on iOS devices :)

I think you should feature request time/date stamps in logs. Including when a policy or image begins and is completed. That info could be handy.

Does Console Log Casper events? I know that Disk Utility does for running
disk image restores to a disk.

Ya, well, the idea is to press "Image" and walk away, come back and find the amount of time.
Can't be sure we'll be there to hit "Stop". :)

Don

the binary logs lots of things to /private/var/log/jamf.log

Errrrr

Well u hit start when you start it

Then walk away

Then when you come back u look at the Casper image look, it had a time when submitted, u subtract the start time and you have your imaging time

As for at reboot install, cs logs the user in as a adobe and reboot after, use the login log times to work out the time

Simples

Criss Myers

Nice, I'll follow this routine on the next round of testing.

Thanks,
Don

Wouldn't be difficult to create a Before script and an After script that
On 3/23/11 2:03 PM, "Don Montalvo" <donmontalvo at gmail.com> wrote:
logs the time to a file such as /private/var/log/casperimagingtime.log.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

I actually would like last imaging time as an inventory field and put that in as a feature request awhile back. Not sure if anyone else would find it helpful, but when mass imaging at a school each summer it would be nice to be able to easily run a report on what computers has/haven't been imaged since June 15th, etc.

Seems like something that could be done with a local file on the system
and an extended attribute. I'm never good at whipping up the scripts when
I'm not at my desk, but ideas...I got those.

A script can be used to create a dummy file at imaging time that's maybe
just got a date in the name or something, and an extended attribute script
could parse that data from the file name during an inventory cycle.

Probably a billion ways to do that...

Craig E

Now I like that idea , I might use that idea for other stuff

Basically log something to a file and use extension attributes to gather it

Criss Myers

What would be even sweeter would be to log directly to the JSS durin
the imaging process. So you have a pre-image script that partitions
your drive or does something, and that script communicates back to the
JSS the start time. Then when finished it logs the end time

I'm sure this wouldn't be hard to implement, right? Just need the
Computer ID from the JSS to be able to slot to the correct machine.
Probably can send the data up like an extension attribute wrapped in
<result> tags.

Of course it may already be found in the jamf.log file. Not at my
computer to check.

Steve

Sent from my iPhone

Also keep in mind in the log detail of a box there is an entry for Casper
Imaging logs with a date and time under the logs section, so some of that
data is in the JSS it appears. At least the last time it reported back
after imaging. It does NOT include what was done during FirstRun it
appears so there is a lot of data missing there IMO. But at least you have
a date somewhere...

Extension attributes don't override each other do they? Otherwise you are going to have a lot of spam in your attributes tables in your database. I only say this because over a life cycle of 4 years, some machines get imaged a lot. I am sure some of my machines have been imaged 100 times easily in 4 years. Not all of them have been imaged that much but I am sure a lot of them have.

I would prefer to just keep it in a log, which shows start and finish time for imaging and policies. In fact, I already asked for more robust logging in a previous feature request, I do not see why Jamf just couldn't date stamp the logs from start to finish. The logs already exist, they just need a start time, a finish time, and maybe a diff between them so that you can easily see the total time it took.

i thought they did override

Criss Myers
Senior IT Analyst (Mac Services)
iPhone / iPad Developer
Apple Certified Technical Coordinator v10.5
LIS Development
Software Management Team
Adelphi Building AB28
University of Central Lancashire
Preston PR1 2HE
Ex 5050
01772 895050

An attribute does get overwritten with every recon cycle. I do not believe it retains a history.

Craig E

so every time I use the <result> and </result> tags in a script the attribute gets over written? I think if you maybe recon the same script it will get overwritten, well, I guess your date stamping would be the same script, but would you then have to maintain a script for each policy you wanted to time?