Posted on 11-03-2015 07:38 AM
The Environment:
- Scanner running, large majority of machines from a pre-existing non casper environment already added to JSS.
- Some computers may not be onsite for periods of time
- Some computers that are onsite may not be turned on frequently enough for Scanner to find them
- No good source of one to one matching of a machine to its record in Casper (most computers have asset tags but were never named to reflect this, there are even a TON of Mac Mini (##). Not as simple as walk up and match the tag to the JSS record and move on.
- Our admin account "should" be on all computers
The Situation:
I have a temp working with us that is going to have to be running around and trying to get as many computers as possible managed by our JSS. As explained by the list above, the scanner wont get all computers so this means a bit of foot work for the temp. They are new to Casper but seemingly pretty good with Mac OS. I can think of a couple of ways, but not only for time, but also for minimal skill, what would you all recommend as the easiest/quickest way to check if a computer is already enrolled (has JAMF binary on it)? Boot the machine and...
Posted on 11-03-2015 07:43 AM
Not strictly what you are after, but we've found this extremely useful.
Posted on 11-03-2015 07:49 AM
If the Mac is connected to the network that can talk to Casper, simply running a sudo jamf recon in Terminal should give you an indication if its under management. If you can't recon it, either because the jamf binary is missing, or it attempts to recon but can't submit inventory, then something is broken and it probably needs to be (re)enrolled. Its not enough just to check for the jamf binary existing on the Mac as has been discussed many times on the boards here. The machine needs a valid record to connect with in the JSS and any necessary certificates, etc. to truly be under management.
Going forward, you may want to look at something like CasperCheck from Rich Trouton so as to keep them under management a bit more reliably.
Posted on 11-03-2015 07:59 AM
Second to all that mm2270 said... CasperCheck is quite useful.
You could just see if the Self Service.app is there (if you use it), but I think mm2270's suggestion might be better since your JSS is only as good as the info in the database.
Posted on 11-03-2015 08:36 AM
Thanks for the tips so far folks. I do want to clarify that right now I am more interested in the computers in the environment that I know are out there that are NOT in casper. Casper is just entering this environment so I started at a 350+ install base and 0 managed. I am up to just over 300 managed now. There is no current directory and no ultimate source of all assets, the existing spreadsheet does not have it all (as proven by computers managed that are not in the asset spreadsheet.) Wanted or not, walk arounds are gonna have to happen, and I just want the best/quickest way for the temp to walk up to a computer and turn it on and find out if the Binary is on the computer or not. I sadly can't rely on looking at the asset tag and trying to find it in casper to check it off, I am simply gonna have to check for Casper, and if not there, enroll it. When all desks have been visited, thats the best I'm gonna get. Hope that helps clarify what I am after.
Something like turn on, log in, open terminal, type jamf help, hit enter, get result=managed
But is that the quickest way, anyone got any quicker/simpler ideas? I understand this is not really enough to know its fully managed, but likely it will be as it will only have ever gotten the binary in the past week or two, so I'm trusting it's still talking.
Posted on 11-03-2015 08:44 AM
You more or less have the framework there.
Turn on, login, open terminal, type jamf help, get info... that doesn't mean it's manage, just that it has the binary.
You could also go with something like:
Turn on, login, open terminal, type which jamf, get correct output...
Or if you have Apple Remote Desktop, you can run this on all Macs it finds. Or even better, just have the temp enroll all of these so you don't have to duplicate the process later once you know which ones are enrolled and which ones are not. Re-enrolling doesn't hurt existing devices.
Posted on 11-03-2015 08:48 AM
Well, technically the only jamf binary command you can run without sudo is 'help' If you feel you can rely on that alone to check on management that should be fine. Any other verbs require sudo, so, maybe that's your best bet.
Posted on 11-03-2015 08:53 AM
Not sure it's any quicker, but you could drop into Single User mode instead of booting all the way to the OS, and then check for the binary in either /usr/sbin for 10.10 and below, or /usr/local/bin for 10.11 and up.
Posted on 11-03-2015 09:31 AM
Another idea: You don't need to elevate to look at the jamf log. They'd be able to tell if the machine has the binary running and a pretty good idea if it has been working recently:
The temp just has to know:
tail /var/log/jamf.log
Example output:
COMPUTERNAME:~ tempuser$ tail /var/log/jamf.log
Tue Nov 03 08:42:46 COMPUTERNAME jamf[47]: Informing the JSS about login for user tempuser
Tue Nov 03 09:00:52 COMPUTERNAME jamf[869]: Checking for policies triggered by "recurring check-in"...
Tue Nov 03 09:19:30 COMPUTERNAME jamf[949]: Checking for policies triggered by "recurring check-in"...
Tue Nov 03 09:36:14 COMPUTERNAME jamf[1019]: Checking for policies triggered by "recurring check-in"...
Tue Nov 03 09:54:29 COMPUTERNAME jamf[1095]: Checking for policies triggered by "recurring check-in"...
Tue Nov 03 10:12:02 COMPUTERNAME jamf[1164]: Checking for policies triggered by "recurring check-in"...
Tue Nov 03 10:27:16 COMPUTERNAME jamf[1280]: Checking for policies triggered by "recurring check-in"...
Tue Nov 03 10:45:08 COMPUTERNAME jamf[1406]: Checking for policies triggered by "recurring check-in"...
Tue Nov 03 11:03:07 COMPUTERNAME jamf[1491]: Checking for policies triggered by "recurring check-in"...
Tue Nov 03 11:20:37 COMPUTERNAME jamf[1603]: Checking for policies triggered by "recurring check-in"...
Posted on 11-03-2015 09:41 AM
That's a great idea from @Josh.Smith In fact, the recurring check-in trigger should happen soon after the Mac is booted up and on, so if the last entries in the log show the "recurring check-in" happening with a recent timestamp, it should be good.
The previous caveats all still apply though. Just having the jamf binary on the machine and it checking in doesn't mean it can run policies or is under correct management. Unfortunately, actually being under management is a semi-complex set of items that all need to be working together.
Posted on 11-03-2015 09:49 AM
Agreed, that is a good idea from @Josh.Smith!
Posted on 11-03-2015 09:50 AM
OK 2 more ideas....just remembered we should use this software!
Create a new policy and have a simple script touch a file in a location that is easy for the temp to check on each machine.....if the file isn't there then the machine needs to be enrolled/re-enrolled.
If it is easier to have a temp click in the GUI, create a dummy Self Service policy to run a script that just returns "I work" in a message box. (If Self Service isn't there then the Mac goes on the naughty list anyway)