Not that I expected it to work, but I did just confirm that Casper does not work with El Capitain beta 1. With the new security settings on OS X, /usr/sbin (along with a number of other system directories) are now read-only, even for root. I haven't tested installing with the new security restrictions disabled yet, right now I'm just trying to figure out what isn't working.
At least I'm completely confident JAMF will have an update out for us when El Capitain ships this Fall, unlike some other vendors I have to deal with...
I figured they would be as soon as WWDC was over. There's a couple really nice features for MDM in 10.11 and iOS 9 (assigning apps to devices not users, skip account creation during setup, etc.)
For now for anyone who is testing, disabling Rootless with "sudo nvram boot-args=rootless=0" does seem to fix things. At least it's working in the VM I'm using to test El Cap, since I'm nowhere near crazy enough to put it on real hardware yet. Sophos AV/SafeGuard and VMware Tools also are getting bit by Rootless.
I just updated a currently enrolled mac to El Cap, it is still enrolled and can do recon reports, however it does error at the end:
2015-06-11 09:49:33.318 jamf[2197:37610] -[NSError init] called; this results in an invalid NSError instance. It will raise an exception in a future release. Please call errorWithDomain:code:userInfo: or initWithDomain:code:userInfo:. This message shown only once.
It was able to send the report to the jss, and the jss is reporting the mac as 10.11.0 I was able to remove/add configuration profiles without issue, self service is functioning properly. I don't see anything at issue besides the recon error so far (knock on wood)
Can someone check to confirm whether the Restrictions Config Profile bug which causes Safari Autofill to be mandated when "Allow Safari Autofill" is checked is resolved in 10.11.0. The user should be able to select their Autofill settings when this is enabled. It looks that way on my test box...
Yes, I had the same results. I upgraded an existing enrolled Mac and it can submit inventory and check ins just fine, but does note the same error at the end that @jjones posted.
So far I also see everything working fairly well despite this being essentially beta 1. I haven't tried to enroll a newly set up 10.11 Mac, but sounds from above like that won't work right now.
My guess is JAMF probably won't need to do a major amount of work to get the JSS to at least work correctly with 10.11.
Supporting new features will be a different story of course.
Edit: OK, spoke a little too soon. We're on JSS 9.65 and looks like Self Service isn't really working. I can run policies from it, but every one of them fails immediately with an error. We'll be updating our JSS to 9.72 in a couple of weeks, so we'll see if its just the 9.65 version or something else.
@ZachB Tried it but yeah it won't work. /usr/sbin/ is where the jamf binary gets installed to normally. That is one of the directories that the new protection system doesn't let 3rd parties write into so it will just immediately fails to install. JAMF will have to move that binary to another location on the system like /usr/local/bin/
Just moved both binaries on my El Cap to /usr/local/bin and rebooted. All works fine, except recon. That one is still giving the same problems:
[NSError init] called; this results in an invalid NSError instance....
I did have to install and enroll manually though. No quick add package support
i still get the recon errors. But when i do a recon, manually the inventory is update on the jss. I tested this by removing an app. Then re-ran recon and the app was gone in the inventory.
Also check out this post https://jamfnation.jamfsoftware.com/discussion.html?id=15299 from @bradtchapman