"This computer is not managed."

[DanSam]

We seem to have an issue where some of our computers are not able to install anything from Self Service. They get the error "This computer is not managed." We can push pkg's to the computers via Casper Remote, but that is more of a temporary fix.

We have tried running: sudo jamf recon, enroll, manage, policy, removeframework and reinstalling via quickadd, removing the binary manually and reenrolling via recon and none of which have worked.

When installing using Casper Remote, the following shows up in the logs:

Verifying /usr/local/jamf/bin/jamf...
/usr/local/jamf/bin/jamf is not installed properly.
Verifying /usr/sbin/jamf...
/usr/sbin/jamf does not exist.
Downloading /usr/local/jamf/bin/jamf from JSS...
Moving jamf binary to /usr/local/jamf/bin/jamf...
Created the jamf binary directory /usr/local/jamf/bin.
Moving jamf binary to /usr/local/jamf/bin/jamf...
Moved the JAMF CLI Binary to /usr/local/jamf/bin/jamf.
Creating symlink /usr/local/bin/jamf...
Enabling /usr/local/jamf/bin/jamf...
Enabled the JAMF CLI Binary.

Our computers are running OS 10.9.5 and we are running JSS 9.81 and the computers show that they are running the 9.81 binary and it is in the correct location (/usr/local/jamf/bin/jamf).

Has anyone else seen this or had a similar issue?

Any information would be greatly appreciated,
Dan

[joshuasee]

I'm running into it quite a bit. I'm reenrolling affected stations when they're found. I did not try Casper Remote.

[DanSam]

Posted: 42 minutes ago by joshuasee I'm running into it quite a bit. I'm reenrolling affected stations when they're found. I did not try Casper Remote.

Can I ask how you are reenrolling? (sudo jamf enroll -prompt, recon made quickadd, web enroll quickadd, etc.?)

[joshuasee]

This usually comes up in the context of Self Service not working, or is noticed as part of something else while in a remote session. Reenrollment is usually done via the web interface, https://yourJSShere.edu:8443/enroll/? .

[mwilkerson]

I ran into this issue yesterday on my own machine. I had recently migrated my user from an older MacBook Pro to a new one. I was then away from our JSS for over a week on vacation and when I got back yesterday, I was unable to run any Self Service policy.

The symptom was that the policy began to run, but there were no status indications above the progress bar (i.e. "mounting distribution point...", etc). After a few moments, I got the error message described above: "Self Service has encountered an error. This computer is not managed."

I tried every "sudo jamf" command that should resolve this. All of them seemed to work flawlessly. Every other thing worked on my machine EXCEPT self service policies.

The only thing that finally resolved the issue was logging in to the other Admin account on the machine and running a Self Service policy from there. That worked. When I logged back in to my user, it also began working.

I'm not sure if this was a by-product from my migration or some other unusual circumstance that my machine fell into, but since I couldn't find anyone else with this problem, I wanted to chime in.

[tomt]

Running into the same thing after upgrading my JSS to 9.82 over the holiday break. So far it has happened on machines that had been dormant for a month or so.

So far the fix has been to either install the new 9.82 QuickAdd package I created or run the jamf manage command. I'm using ARD to do this as root.

[nkalister]

interesting. I'm getting reports of this, just started in January. We've not upgraded to 9.8.x yet, we're still on 9.73.
Never EVER had a report of this before coming back from Christmas break!

[mwilkerson]

My colleague had this pop up on her own machine today, as well. She was able to resolve it much quicker than myself with a simple jams manage command.

But I agree, the fact that this is popping up now is really strange. Our JSS is at 9.81. My machine is on 10.11.2 and my colleague's machine is running 10.11.3 beta.

[nkalister]

just curious- how many of you are running something like CasperCheck
or Deadpool in your environments?

[mwilkerson]

We are not using either.

[nkalister]

thanks, mike. we deployed a similar system here recently, trying to see if it might be related, but sounds like it's probably a coincidence if you're not running them and are seeing this issue.

[rdwhitt]

We had one of our site admins report this issue on one computer; Self Service gave the "This computer is not managed" message when attempting to run anything, but the computer was managed in every other way (policies worked, remote worked, MDM commands worked).

We tried all the standard things trying to fix it; remove framework, re-enroll using the various methods, etc. In our case it turned out that the computer had incorrect permissions set on the /usr/local folder. Once permissions were fixed on that, everything began working again.

I'm not sure if this is your issue, but I figure I'd mention it here in case it helps someone.

[dag2012]

Hi Robert

Was wondering what you did to correct the permissions on the /usr/local folder and what the correct permissions are supposed to be.

I have a user who is having the same issue with Self Service and everything we've tried hasn't helped. I'm hesitant to mess with the usr/local folder as the user is a VIP.

I found this article which basically says El Capitan is preventing access to this folder even as root and in order to have anything run correctly from it, you have to change the permissions to user:admin (http://digitizor.com/fix-homebrew-permissions-osx-el-capitan/)

Thanks!

Dan

[rdwhitt]

The correct permissions on that folder should be 755 and owned by root:wheel.

If that's what you have already, I wouldn't change anything. The /usr/local directory is where 3rd party apps are supposed to be writing to so I didn't think it was SIP protected.

A little more info about our scenario: When we upgraded the JSS to 9.81, the binary location was moved from /usr/sbin/jamf to /usr/local/bin/jamf. However, the upgrade wasn't completing on that computer so the binary was still in both locations. It was stuck in a strange limbo...most everything worked except Self Service.

After correcting the permissions on the /usr/local folder, we re-enrolled with a quickadd and the upgraded completed. Self Service worked after that.

[jcwoll]

I've been seeing this since the upgrade to 9.82 as well. I just have the tech's send the user another enrollment invitation and then it works fine.

[emily]

This happens in our environment for a handful of machines that, between 9.7x and 9.8x upgrades, where the binary either doesn't upgrade correctly or which jamf doesn't seem to work. I can't for the life of me figure out why. But for the handful that have had this problem, and Self Service doesn't work, I just remove framework and re-enroll. Not an elegant solution but it is the solve for us.

[dannyd]

We started seeing a few of this when user accessing self service.
so far our work around is doing sudo jamf manage on the terminal and it gets the user going.

I've emailed tech support and they think certificates are getting deleted.

Anyone else might know the root of this issue?

thx

[znilsson]

This just happened to me today, and nothing I do fixes it, including completely wiping the machine and starting over from scratch. This Mac just refuses to be managed. It's not a Self Service thing per se, it's just not managed at all. It's not getting its policies, it's not managed by config profiles, the only thing it's doing is checking in. There is no machine information, only the IP address and MAC address, nothing else.

I tried wiping it and reinstalling OS X, I tried net booting to Casper Imaging twice and running through that, I tried creating a new Netboot image with 10.11.4 and with Casper Imaging 9.9, it didn't seem to make a difference whether it was 9.82 or 9.9. I tried an old quickadd package, and I generated a new quickadd package. I copied the quickadd from a usb stick, and I tried the enroll url to download the quick add package.

Nothing. It absolutely refuses to be managed. I also checked this:

The correct permissions on that folder [usr/local] should be 755 and owned by root:wheel.

And permissions were correct. And I found this in another thread, I'm copy pasting it here because this is what my Mac here is doing:

Mac-Netboot-Server:~ macadmin$ sudo installer -pkg /Users/macadmin/Desktop/LRNA_JSS_QuickAdd.pkg -tgt / -verboseR installer: Package name is LRNA_JSS_QuickAdd installer: Installing at base path / installer:PHASE:Preparing for installation… installer:PHASE:Preparing the disk… installer:PHASE:Preparing LRNA_JSS_QuickAdd… installer:PHASE:Waiting for other installations to complete… installer:PHASE:Configuring the installation… installer:STATUS: installer:%85.972537 installer:PHASE:Running package scripts… installer:%88.108514 installer:PHASE:Running package scripts… installer:%89.205708 installer:PHASE:Running package scripts… installer:%89.205708 installer:PHASE:Running package scripts… installer:%89.205708 installer:PHASE:Validating packages… installer:%97.750000 installer: The install failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)

That's what's happening on mine. Same 97.750000% completion, same error. I'm at a loss, it just absolutely refuses to be managed. And since 9.9 is new I haven't had a chance to try it on other Macs so I don't know if this is going to be a thing, or if this is just a one-off with this one Mac. Is anybody else seeing this on 10.11.4 clients with JSS 9.9?

[Nix4Life]

@znilsson saw this today also on 10.11.4 machine. Jumped through the same hoops you did. I was able to get it enrolled via command line. working on a script i can call from 1st boot. We are on 9.65 going to 9.9 or greater this summer

Larry

[PAC]

We are getting it at our school too.
Thought it was a bug with 9.9 but if its happening on 9.65 then maybe its something more.

Will try enrolling through command line.

Pete

[PAC]

Looks like the Macbooks that are been affected do not have the up to date jamf binary versions.
i have a small group of computers who have not checked into jss and they have the older JSS version not the new 9.9 version.

Can anyone confirm the same for your affected computers?

Cheers
Pete

[PAC]

I have fixed this issue by reading this article
[https://jamfnation.jamfsoftware.com/discussion.html?id=17564]

The computers that were been affected were missing the binary from the the /usr/local/jamf/ folder
The folder /usr/local/bin/ that has the alias could not find the files
I ended up using Apple Remote Desktop and manually adding the jamf binary across from a working computer.
Refreshed self service and it worked straight away.

Hope this kelps

Pete

[Nix4Life]

@peter.caldwell Thanks for your diligence ! This worked and I also completed the 1stboot script, so we should be covered

Larry

[znilsson]

@peter.caldwell thanks so much for that. I haven't been able to verify that it works for me yet, still have to grab that Mac and try it, but that sounds promising. Will update with results.

The question remains, why is this happening in the first place, especially on a freshly wiped Mac? In my case it's not about upgrading as it's going straight from a wipe to putting a stock El Capitan 10.11.4 on it, to running my prestage thin image config via netboot and Casper Imaging. What is interesting is that right as I start the image via Casper Imaging, I get the email that says that Mac has been enrolled into Casper, and I check and it's in there, but only the name, MAC address and IP. Nothing else.

And that's typical for the first stage of imaging, the rest of the info fills in when the image is completed, usually. But in my case, at least on this one Mac so far, that never happens. It reboots, completes the installs, reboots again and it's ostensibly finished - but still not managed. Hopefully this doesn't turn into "a thing".

[znilsson]

Unfortunately I tried manually adding the JAMF binary files, and it didn't fix the problem. The files were already there, I replaced them, and I replaced the aliases in the bin folder too, no dice. It's being really stubborn. I also ran another couple quick adds just to be on the safe side. I've never seen a Mac so completely resistant to being managed before. The agent is running, Casper does see it, it is checking in every 15 minutes. But it's unmanaged and there is no info about this machine in the JSS.

We're going to try imaging a new Macbook pro in the same way and see if it has the same unmanaged issue. Right now I don't know what to do about this one, because not even wiping it fixed it.

[PAC]

@znilsson What are you adding onto your Stock image of 10.11.4?
any other programs or scripts running after the base image?

[znilsson]

@peter.caldwell We're using thin imaging so we're not touching the OS, but in our configuration we install a bunch of applications, a couple scripts, add an admin account, add a directory binding, add the management account and that's about it.

Should be noted that so far this is the only Mac this has happened to, we have 16 others in the JSS with no issues. We are running our imaging procedure on a different mac to test this theory.

[rdwhitt]

@znilsson Out of curiosity, if you log into that machine and look at the system info, does it have a serial number? The only reason I ask is that I had very similar and it turned out the computer hadn't been properly searialized.

Not sure that's the issue but I figured I'd ask just in case.

[znilsson]

@rdwhitt I don't have access to the machine right now but Casper Imaging did pull a serial number from the Mac and slugged it in to the name field, as per my prestage image configuration. But since Casper can't pull the serial number to add it to the JSS because it's unmanaged, I don't know if what it pulled to name it is the same number as what shows up in the system profile.

[znilsson]

Working with JAMF support, we got it fixed on our end. Apparently there is a bug in the JSS 9.9 installer for Windows, in which a file or files are not installed, which causes any attempt to enroll Macs into the JSS, by any method, to fail and you're left with a kind of zombie Mac that is technically enrolled and it does check in to the JSS so the agent is running, but none of the policies or config profiles apply to it, and it shows as "unmanaged" in the JSS.

The solution for us was to re-run the JSS 9.9 installer for Windows and use the Maintenance option which did sort of a "reinstall lite" in place on the server, and that solved our problem. Once Tomcat came back up and everything was running, I was able to use a quickadd package on one test Mac, and do a Casper Imaging install via Netboot to two other test Macs, and all three of them successfully enrolled and were managed, with all appropriate policies and config profiles applying correctly.

As far as I know this issue should only affect organizations that are running their JSS on a Windows server, using version 9.9 of the JSS.

[emmayche]

Can anyone confirm that this issue is fixed in 9.99? I'm seeing something remarkably like it, and if this isn't it I don't want to start making too much noise about it.