9.8 is out...

davidacland
Honored Contributor II

Would be good to hear your experiences upgrading to the new version, good or bad!

40 REPLIES 40

bumbletech
Contributor III

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.

andrew_nicholas
Valued Contributor

I updated my test instance from 9.73 to 9.8 with no issues. Windows Server 2012r2, Java 8, MySQL 5.6.25.

nessts
Valued Contributor II

@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.

CasperSally
Valued Contributor II

Is there a KB/walk through on the GSX set up somewhere?

bcourtade
New Contributor III

No issues here, other than the missing VPP enhancements. We really could have used those... K-6 iPads with Apple IDs are a PITA.

eleven
New Contributor III

@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.

@CasperSally,

Check out the newly updated GSX KB here

powellbc
Contributor II

I noticed Java 6 is not supported on the JSS anymore. Looks like I will be upgrading that first.

cdenesha
Valued Contributor III

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?

bbelew
Contributor

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.

donparfet
Contributor

addressing the Java upgrade I posted a related question here
https://jamfnation.jamfsoftware.com/discussion.html?id=16954

kitzy
Contributor III

@cdenesha

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.

maysm
New Contributor

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".

bcourtade
New Contributor III

+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.

CasperSally
Valued Contributor II

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.

Brjinx
New Contributor II

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.

tim_rees
Contributor

Absolutely flawless upgrade on win 2008 R2! (nice change from the chaos I had with 9.73!!)

hkabik
Valued Contributor

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.

Matt_Sim
New Contributor II

Upgrade went without issues, as normal.

Was disappointed to see no Device assigned VPP though

Malcolm
Contributor II

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.

donmontalvo
Esteemed Contributor III

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?

--
https://donmontalvo.com

donmontalvo
Esteemed Contributor III

donmontalvo
Esteemed Contributor III

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.

5fe2cbe7767e45c28e2d7befc6fa29db

--
https://donmontalvo.com

davidacland
Honored Contributor II

@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!

were_wulff
Valued Contributor II

@donmontalvo

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

lkrasno
Contributor II

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 ?

ImAMacGuy
Valued Contributor II

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

gjsmith62
New Contributor

Upgraded 9.72 to 9.8 on Windows server ( 2008R2 ).
Worked perfectly, first time I've done an upgrade on windows without major grief !

skoonin
New Contributor

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?

davidacland
Honored Contributor II

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?

tim_rees
Contributor

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.

skoonin
New Contributor

yea using the full path works, however this is not ideal. seems that the path variables for 9.8 need to be updated

nessts
Valued Contributor II

that is a user/admin responsibility, update your .bashrc .cshrc etc files.

bbelew
Contributor

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

were_wulff
Valued Contributor II

@skoonin , @bbelew

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

gachowski
Valued Contributor II

I'm with Todd, no way for the "vendor" to "read the admin's mind" on what and if change. : )

C

skoonin
New Contributor

@amanda.wulff

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?

were_wulff
Valued Contributor II

@skoonin

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

skoonin
New Contributor

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.

rtrouton
Release Candidate Programs Tester

There's a thread going about ARD and environment variables:

https://jamfnation.jamfsoftware.com/discussion.html?id=16970#responseChild99805