@jbourdon this is in the letter I think it answers your question:
Watch for another announcement in a few weeks: we'll provide another product update to support OS X El Capitan when it's publicly available. This next release will add support for the new DEP and VPP enhancements that were announced at WWDC this summer.
Thanks for the post, we are jacked up about device based VPP managed distribution too. Please keep an eye on JAMFNation for a beta release very soon that will give you a chance to start trying out your workflows with iOS 9 and this new functionality.
Check out the newly updated GSX KB here
In the past, updating to a new version of iOS before the JSS has been upgraded generally doesn't break communication, but you won't be able to take advantage of the new iOS 9 features on the JSS side until you've upgraded. I have been able to manage iOS 9 devices with a 9.73 JSS, but as always test for yourself and YMMV.
In the presentation about the AppleID less VPP they said that app developers had to opt in to let their app be pushed to devices instead of users.
I'm wondering on the list of apps we support how many won't opt in. It will make the idea of apps being sent to devices instead of IDs much more difficult to implement if there are a few apps not on the opt in list that our district already bought hundreds of copies of & wants to use.
The update went flawlessly, although there was an issue with the DEP after the update that a quick upload of new server tokens fixed. Now I'm just waiting for the VPP enhancements and not requiring Apple IDs to install apps to come through.
*As a note, someone asked about people updating to iOS 9 before the JSS is updated to 9.8 - They only issue is if they are wiping and starting it from scratch. It doesn't seem to get the Self-Service app correctly, but if they just update, the Self-Service App is already there and works fine. No other noticed issues beyond that! We've had two students testing the beta iOS 9 on our server for a few weeks.
Has anyone else had issues with remote recon via the 9.8 recon app? I'm getting a communications error and the binary fails to install. JAMF was able to recreate the exact issue internally. Just curious if anyone else has encountered it and if they found a quick work around.
Quickadd packages still work, so I'm not totally dead in the water for enrollment.
I agree CasperSally - it should been opposite, automatically enabled after a month unless specified by the developer otherwise.
I think you will find most apps will support it, otherwise it doesn't hurt tot send them feedback, indicating you were going to make further VPP purchases but cause they don't support it your not going to purchase.
Odd...manually building a test box. I have the latest Java 8 installed (JDK & JCE), and the latest MySQL installed (5.6.20). I configured MySQL, first by memory, and sighing and going line by line in case I forgot a step. The JSS 9.8 installer doesn't seem to want to install.
I did not change the defaults:
Server Name (localhost)
Server Port (3306)
Database Name (jamfsoftware)
The installer gives me the dreaded Error: Please verify server, port, username and password error.
Yes, MySQL is running. This is on a Mac Pro running 10.9.5.
@donmontalvo youre using Java 8? I tried that last week but the JSS installer complained and wanted either 6 or 7. Is this a new thing for JSS 9.8?
I saw that MySQL thing last week, something about the method you use to enable it, some ways it's 3306 and some are 3307 with the same files installed!
That option has always been available; it was just tucked away in menus that users would typically never go into without Support telling them to.
In the older versions of the JSS Database Utility, the option was under Main >> Preferences, and was a checkbox at the bottom of the dialogue that came up.
It had to be manually turned on and manually turned off again after the backup without the encryption key was made to send in to Support for troubleshooting.
If the step of going back in and unchecking that box again was missed, it tended to eventually end in catastrophe if it wasn't caught and re-enabled before a situation occurred in which we needed to restore a backup of the database.
There is only ever one reason we would check that box: The person you're working with, on an existing case, from JAMF Support has requested you to send a copy of your database to us for in house testing. Even in that scenario, it is ONLY checked for that ONE backup, then we would immediately go back and uncheck it again.
In 9.8 making the option more visible also helps to reduce the chance that it will be accidentally checked and left checked. It should NOT affect scheduled backups, even if it is checked but I like to err on the side of complete caution with this option and just leave it unchecked and only check it for a single backup under the direction of JAMF Support.
The reasoning for that is kind of the story you'd tell new admins to terrify them away from even looking at the checkbox without someone from Support on the line:
Omitting the encryption key from the backup means you are left with no workable backup if you ever need to restore a backup for any reason. The long and short of it is: The restore won't be successful, you won't have a working database that you can use in production, and there is no way to 'fix' it if a backup from prior to the encryption key omission is not available.
...to put it another way, you have to start over in that scenario. From the ground up, every policy, every profile, every distribution point, every network segment, every setting, every certificate, just like you were setting up a brand new JSS, complete with having to re-enroll all of your devices.
We can't fix it, you can't fix it, and information it wants to function properly isn't there anymore and there is no secret backdoor to get it back.
Nobody wants that.
Nobody wants to be the Support person that has to tell someone that either (I've had to three times since I've been at JAMF, not fun, 0/10, do not recommend.).
The short, short version of the above is: Please do not check that box unless someone from JAMF Support has specifically told you to do so, and always make sure it is unchecked after using the option to make a backup without the encryption keys.
If you have more questions on that particular option, or want some more in-depth information on it, please get in touch with your Technical Account Manager, either by giving them a call, sending an e-mail to email@example.com, or using the My Support section of JAMF Nation.
JAMF Software Support
I do apologize for the issues the binary location move has caused for some scripts; the move is not something we just did arbitrarily, however, and it was documented in the 9.8 Release Notes on pages 4 and 7.
The location change is due to the System Integrity Protection (SIP) being implemented in OS X 10.11 El Capitan.
This change will limit what sorts of processes can run from which locations, and one of the locations that has restrictions on it is /usr.
In 9.8, the change was made in preparation for the change that is coming in El Capitan.
The location of the following files has moved in 9.8 due to this:
/usr/sbin/jamf has moved to /usr/local/jamf/bin/jamf
/usr/sbin/jamfAgent has moved to /usr/local/jamf/bin/jamfAgent
The binary and jamfAgent on the client's side, will be moved to its new location the first time the computer checks in to the JSS after the upgrade to 9.8.
We have included a symlink so typing in the usual sudo jamf verbgoeshere should work, but it seems to not always work with scripts (and certainly won’t work if your script is calling the full path of /usr/sbin/jamf or /usr/sbin/jamfAgent) and older versions of Recon will not work with the symlink either.
In those cases, we will need to manually update the scripts that are not working and, for older versions of Recon, we’d simply need to upgrade to the latest version.
In addition, because of the change coming to 10.11, we highly recommend getting your environment updated to at least 9.8 before upgrading any OS X devices to 10.11 just to ensure that the binary move goes as smoothly as possible.
If you have additional questions or would like some more in depth (or environment/script specific info), please get in touch with your Technical Account Manager by either giving them a call, e-mailing firstname.lastname@example.org, or using the My Support section of JAMF Nation.
JAMF Software Support
Thanks for the info. The issue I have seen is not a script related issue, but connected to Apple Remote Desktop. Up until 9.8, I could easily send commands to computers by just using the jamf command (eg. jamf recon) and run as the root user. In 9.8, this does not work in ARD and the full path to the binary is needed (eg. /usr/local/jamf...)
Seems that the upgrade of the binary on machines also should be updating all the appropriate PATH variables in the OS, no?
In theory, yes, the symlink should work, but it's possible that it may not when using ARD or with non 9.8 versions of Recon or Remote.
Unfortunately, I'm not terribly familiar with the inner/backend workings of ARD, and am not certain how it normally handles symlinks for things like that.
In those cases, a potential workaround may be pushing out a small script that adds the new path of the binary & jamfAgent to the system path, however, that is not something we've tested here and I can't guarantee it would work (so would recommend, if you try, only push it to a handful of test machines to verify that it works as expected), but it may still be something to try.
In regards to the binary upgrade also updating the appropriate system path variables, that would be something that I'd recommend opening up as a Feature Request.
JAMF Software Support
ok thanks. I'll submit a feature request, although this seems that is should be a requirement?
just stranger that locally on the systems the binary works as expected, so the path is in there somehow. but in ARD the response is "/bin/bash: line 1: jamf: command not found"." So, it somehow pulls from a different PATH variable.