This is funny

[#1]

Ok who can tell me how little resources are used and the process that JAMF uses to get basic inventory from machines? I ask this because one of the buildings that I will be fully supporting is claiming JAMF has caused their server to have issues and crash. He looked at the JAMF process running in the background and assumed that it caused issues with his Mac Server (which I will be taking over soon). Just to be clear, I have been inventorying machines for the last two months with no problem.

Crazy!

Neal Smith | MAC Systems Engineer | Perrigo IT

[donmontalvo]

Neal Smith <Neal.Smith at perrigo.com>,

In our environment, administrators that are not working on the casper project blame everything that they can't explain on casper. We check log files and work towards proof instead of mass hysteria. Dan

Ahhh...well, time has a way of dealing with the rogue administrators. Someone at the Firm is responsible for compliance, so eventually the rogue administrators reach a fork on the road.

To the left is cooperation...let us gather the required inventory data (we have a special "hands off" Casper agent that does just that) so everyone is happy.

To the right there is the soup line.

'Nuf said.

Don

[donmontalvo]

Neal Smith <Neal.Smith at perrigo.com>,

In our environment, administrators that are not working on the casper project blame everything that they can't explain on casper. We check log files and work towards proof instead of mass hysteria. Dan

(I should have prefaced this response for context...Don)

[EDIT] We've been there, where the administrators remove or disable Casper agent because they can't figure out how to fix a problem. [/EDIT]

Ahhh...well, time has a way of dealing with the rogue administrators. Someone at the Firm is responsible for compliance, so eventually the rogue administrators reach a fork on the road.

To the left is cooperation...let us gather the required inventory data (we have a special "hands off" Casper agent that does just that) so everyone is happy.

To the right there is the soup line.

'Nuf said.

Don

[bentoms]

Other than what the others have said.

Has the server recently been updated? Wasn't there an issue that 10.6.8 1v1 fixed that caused servers to lock up under some circumstances??

Regards,

Ben.

[tlarkin]

Before anyone jumps to conclusions we should look at log files. There
have been many problems I have seen in my life time that ended up being
something totally unpredicted. Look at the logs, see what it
happening, reproduce the problem, etc. You know, use standard
troubleshooting methods, process of elimination, deductive logic, and so
forth.

Is there a sample of the JAMF process causing this issue with proof it
is eating resources?

On a side note I do not run the Casper client on my servers at all, as
I see Casper more as a client management suite than a server management
suite. Although, completely possible to build Server images and deploy
packages and stuff to servers, server setup assistant does well enough
for me and all my servers just need vanilla installs and services turned
on.

-Tom

[Walter]

Are you collecting application statistics? You might have the data right there in your JSS already.
--
Walter Rowe, 301-975-2885
Supervisor, System Hosting Services
Enterprise Systems Division
NIST, US Dept of Commerce

[tlarkin]

Couple questions....

On the server, there is a jamf client running? Are these servers in inventory?

To answer your question, it uses built in Apple stuff, a lot of what recon does is from the Apple System Profiler command line binary.

-Tom


[dderusha]

Neal-

In our environment, administrators that are not working on the casper project blame everything that they can't explain on casper. We check log files and work towards proof instead of mass hysteria.

Dan

[#9]

No client running I only did a recon to it and it is only reporting to the JSS.

[jarednichols]

In cases where "Casper broke my machine" I often point them to where Casper stores log files (same as everywhere else) and ask them to prove it to me.

j
---
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436