Posted on 09-16-2015 07:33 AM
Would be good to hear your experiences upgrading to the new version, good or bad!
Posted on 09-16-2015 07:55 AM
I'm hoping someone can confirm if the new AppleID-less VPP distribution is available in this release. I was under the impression that this was ready on Apple's end in the iOS 9 beta in some part, but I haven't seen anything about it in the release notes.
Posted on 09-16-2015 08:03 AM
I updated my test instance from 9.73 to 9.8 with no issues. Windows Server 2012r2, Java 8, MySQL 5.6.25.
Posted on 09-16-2015 09:06 AM
@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.
Posted on 09-16-2015 09:42 AM
Is there a KB/walk through on the GSX set up somewhere?
Posted on 09-16-2015 09:47 AM
No issues here, other than the missing VPP enhancements. We really could have used those... K-6 iPads with Apple IDs are a PITA.
Posted on 09-16-2015 09:50 AM
@jbourdon and @bcourtade ,
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
Posted on 09-16-2015 09:57 AM
I noticed Java 6 is not supported on the JSS anymore. Looks like I will be upgrading that first.
Posted on 09-16-2015 10:01 AM
From the email announcement:
Support for iOS 9 so you can maintain device inventory, deployment workflows, and security policies during the OS upgrade process
If we do not upgrade to 9.8 and a user updates their iPad to iOS 9, what are the consequences?
Posted on 09-16-2015 10:06 AM
My work iPad has been on iOS9 for like 2 months now in JSS and hasn't thrown any issues.
The only issues i've had is with El Capitan and package deployments using file share distribution points.
Posted on 09-16-2015 10:20 AM
addressing the Java upgrade I posted a related question here
https://jamfnation.jamfsoftware.com/discussion.html?id=16954
Posted on 09-16-2015 10:30 AM
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.
Posted on 09-16-2015 12:15 PM
The faster we can get our hands on the AppleID-less VPP distribution the better. We have some students that are unable to get apple ID's and we are a month into classes. We thought iOS 9 was going to be our "Golden Goose".
Posted on 09-16-2015 12:20 PM
+1 on that. We are trying to get the U13 kids through the Apple ID for students program, but we only have ~70% adoption so far. Teachers are frustrated and not needing the Apple ID would be a godsend.
Posted on 09-16-2015 12:28 PM
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.
Posted on 09-16-2015 01:53 PM
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.
Posted on 09-16-2015 04:03 PM
Absolutely flawless upgrade on win 2008 R2! (nice change from the chaos I had with 9.73!!)
Posted on 09-16-2015 05:22 PM
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.
Posted on 09-16-2015 05:30 PM
Upgrade went without issues, as normal.
Was disappointed to see no Device assigned VPP though
Posted on 09-16-2015 06:20 PM
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.
Posted on 09-16-2015 07:40 PM
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)
Username (jamfsoftware)
Password (jamfsw03)
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.
Any ideas?
Posted on 09-16-2015 08:10 PM
Figured it out...MySQL 5.6.20 installer uses port 3307 instead of 3306...ugh...fixed.
Posted on 09-16-2015 09:45 PM
Nice, we can "Omit encryption key from this backup" using the 9.8 JSS Database Utility.
Sounds like a FV2 th'ang...nothing in the admin guide...leaving it off until we know what it does.
Posted on 09-16-2015 11:22 PM
@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!
Posted on 09-17-2015 11:56 AM
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 support@jamfsoftware.com, or using the My Support section of JAMF Nation.
Thanks!
Amanda Wulff
JAMF Software Support
Posted on 09-17-2015 12:33 PM
Curious if 9.8 JSS would be compatible with 9.4 Self Service app? (allowing me time to rebrand and distribute later)
How about JDS 9.73 ?
Posted on 09-17-2015 01:15 PM
we had a LOT of problems installing on a split DMZ/JSS/MySQL environment. Eventually had to turn off clustering and then I was able to upgrade both DMZ and Internal JSS to 9.8
Posted on 09-17-2015 02:04 PM
Upgraded 9.72 to 9.8 on Windows server ( 2008R2 ).
Worked perfectly, first time I've done an upgrade on windows without major grief !
Posted on 09-22-2015 03:23 PM
Upgraded 9.72 to 9.8 (ubuntu 14.04) and Apple Remote Desktop (ARD) can no longer run jamf commands. I get an error saying "/bin/bash: line 1: jamf: command not found". Posted in another thread about this as well. Is there any way to submit a bug report that I'm not seeing?
Posted on 09-22-2015 03:30 PM
JAMF moved the binary in the last version to get ready for SIP in El Capitan. I think it's in /usr/local now. Are you specifying the full path to the binary?
Posted on 09-22-2015 03:31 PM
Hi @skoonin
Are you referencing the full path to the binary or just calling jamf and hoping the system knows where to look?
To do a policy update try
sudo /usr/local/bin/jamf policy
and see what happens.
Posted on 09-23-2015 11:04 AM
yea using the full path works, however this is not ideal. seems that the path variables for 9.8 need to be updated
Posted on 09-23-2015 11:06 AM
that is a user/admin responsibility, update your .bashrc .cshrc etc files.
Posted on 09-23-2015 11:08 AM
To me personally if a software vendor changes the path to the files they use, it is in fact the software vendors responsibility to update the path, or at least put symlinks in place pointing to the new location.
Just my two cents
Posted on 09-23-2015 11:38 AM
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 support@jamfsoftware.com, or using the My Support section of JAMF Nation.
Thanks!
Amanda Wulff
JAMF Software Support
Posted on 09-23-2015 12:06 PM
I'm with Todd, no way for the "vendor" to "read the admin's mind" on what and if change. : )
C
Posted on 09-23-2015 12:15 PM
Hi Amanda,
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?
Posted on 09-23-2015 12:22 PM
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.
Thanks!
Amanda Wulff
JAMF Software Support
Posted on 09-23-2015 12:26 PM
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.
Posted on 09-23-2015 12:29 PM
There's a thread going about ARD and environment variables:
https://jamfnation.jamfsoftware.com/discussion.html?id=16970#responseChild99805