9.8 gotchas

jwojda
Valued Contributor II

Any early reports of problems? My test environment seemed to go okay...

51 REPLIES 51

Aziz
Valued Contributor

It was a smooth upgrade in production & testing.

Windows Server 2012 R2, Java 8 Update 60

jwojda
Valued Contributor II

well, mine didn't go so well in prod, testing was fine.

i put java 8 and the ice in, upgraded to 9.8... and now I can't get to the web interface. just keeps redirecting me to the generic OS X website.

Aziz
Valued Contributor

That sucks :/

The only issue (just noticed) is that the "Scripts contain invalid references to /usr/sbin/jamf" notification won't go away. I have nothing pointing to /usr/sbin/jamf. I have stuff using /usr/sbin, but not the sbin/jamf.

Apfelpom
New Contributor III

We did the upgrade from 9.73 to 9.8 (running OS X 10.10.5) without problems. But a curious new issue affected some computers during the lunch break: the logged in user was logged out after x time of inactivity. Those with unsaved documents weren't, because a modal dialog stopped it.

Finally I found out, that a configuration profile was altered on a way I can't explain. I edited one yesterday after the JSS update to update the banner with the new JSS version. But at "Configuration Profiles > Login-Window > Options >" Log out users after 30 minutes of inactivity was checked...

mscottblake
Valued Contributor

@Apfelpom That was in the release notes as a bug fix. Previous versions of the JSS were not logging users out when that was checked. I would guess that it has been checked for quite some time, but due to that bug, no one ever noticed.

I'm actually excited to upgrade due to them fixing this bug in particular.

bkerns
New Contributor II

I'm having some struggles getting our Dev server updated - our servers are still running Server 2008 R2. I'm getting an error from the installer during the "Upgrading web app and starting up Tomcat7 service..." phase that reads "There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor."

Apfelpom
New Contributor III

@mscottblake: Good to know that the user logout after x feature now works. I looked inside older deliberately zero scoped profiles with Login Window settings and they all have the 30 minutes box checked. Even a new profile in JSS 9.8 with Login Window settings is set per default to log out users after 30 minutes.

Could somebody verify the default state of the box "Log out users after:" before updating to 9.8? Thanks :-)

Volker
New Contributor III

I can't seem to install the 9.8 JDS on OS X 10.10.5 with Server 5.0.3 already installed. The JDS installer balks at the perceived lack of Server having been launched once and "set up."

Josh_Smith
Contributor III

@Apfelpom Defaults in new config profile just created in 9.73:
e120cc2339714941b247cedf56d8c147

Apfelpom
New Contributor III

Thanks @Josh.Smith! The defaults are the same in 9.8.

Funny defaults by the way: the automatic login is enable but 30 minutes inactivity later, the user will be logged out. If he failed to remember his login credentials, he will have the choice to take the guest user or to restart ;-)

dferrara
Contributor II

@mscottblake Me too, this bug was really annoying. Do you know if this is still not a forced logout, i.e. will fail if apps need attention?

pblake
Contributor II

The move of the binary is a gotcha for me. I have to update a few scripts that call the binary. We are in the cloud so we are being updated Saturday.

hkabik
Valued Contributor

Unable to do remote enrollments via Recon in 9.8, though quickadd packages work fine.

I get:

A connection error occurred: jamf binary failed to install

When I try.

I am able to enroll folks using an earlier version of Recon (9.72), but the jamf binary is busted, when I try to do anything with it I get:

$  sudo jamf policy
Password:
/usr/local/bin/jamf: line 1: syntax error near unexpected token `<'
/usr/local/bin/jamf: line 1: `<html><head><title>Apache Tomcat/7.0.62 -
Error report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;f
ont-size:22px;} H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;f
ont-size:16px;} H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;f
ont-size:14px;} BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;}
B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size
:12px;}A {color : black;}A.name {color : black;}HR {color :
#525D76;}--></style> </head><body><h1>HTTP Status 404 - /jamf</h1><HR
size="1" noshade="noshade"><p><b>type</b> Status
report</p><p><b>message</b> <u>/jamf</u></p><p><b>description</b> <u>The
requested resource is not available.</u></p><HR size="1"
noshade="noshade"><h3>Apache Tomcat/7.0.62</h3></body></html>'

I can repair this by running a quickadd package.

JAMF support was able to recreate the issue in house while I was on the phone with them and are investigating it now. Any one else seen it?

pblake
Contributor II

@hkabik - Just a shot in the dark based on my own issues with the binary move, Have you done a sudo jam manage and a sudo jam enroll -prompt on the machine you are running Recon on. I get the feeling the binary is in the old place on your machine so Recon 9.8 can't call it properly.

hkabik
Valued Contributor

That was my gut instinct as well, but it fails to place the binary in /usr/sbin and although it creates the folder for /usr/local/jamf/bin it doesn't actually drop the binary there either.

Aziz
Valued Contributor

@mscottblake

Does the JSS auto force quit apps before logging off automatically? I think this might be the reason it's not working for me

Chris_Hafner
Valued Contributor II

@ Abdiaziz

I've got the same issue. Nothing big, but I am certainly being warned about scripts and EAs that simply have /usr/sbin in them. I really do appreciate the warnings from the JSS, but after removing any references I had to usr/sbin/jamf. Either way, it was a rather smooth upgrade for us!

hkabik
Valued Contributor

In case anyone is interested/experience my enrollment issue.

Just got off a call with JAMF, while the 9.8 (failed jam binary install) and 9.72 (failed jamf plist install/apache error) recon tools fail... the 9.73 Recon app works. So I at least have a work around for right now.

JAMF is able to reproduce my issue so they're running it up the flagpole.

Just wanted to let anyone who experiences this issue know, use the 9.73 Recon app to enroll machines.

Chris_Hafner
Valued Contributor II

@hkabik Thanks for that!

Aziz
Valued Contributor

@hkabik

Have you tried something like

/usr/local/jamf/bin/jamf manage

hkabik
Valued Contributor

@Abdiaziz

Oh yeah. it doesn't drop the binary at all.

It does make the folder structure for /usr/local/jamf/bin oddly though.

We checked both in that folder and in /usr/sbin. No binary at all.

The worst part is... no binary means no logs. We can't see where it's failing at. No /var/log/jamf.log on the machine being reconnend and without the binary no log gets reported to the JSS.

Mysterious error is annoying.

jonmacguru
New Contributor II

@Volker I was setting up a new JSS/JDS with Server 5.0.3 and found the same issue.

After extracting the contents of the JDS installer and moving files into place manually, I also ran both pre and post install scripts manually.

Finally, I followed this post https://jamfnation.jamfsoftware.com/discussion.html?id=11841 and used the script locally to finish the setup of the JDS and get it into the JSS. I did need to update the paths for the jds binary check since its in a new location with 9.8

Kind of a pain, but I imaging 9.8.1 will include support for the new OS X Server.app

skoonin
New Contributor

Hi guys,

Adding onto this post with a strange issue I just encountered. I upgraded to 9.8 (and open jdk 8) in my test environment and they no longer can run jamf commands from ARD. Commands run from remote desktop return "/bin/bash: line 1: jamf: command not found"

If I SSH in, they work fine locally on the machine. I re-added the computers in ARD, but still nothing. Anyone else see this?

Aziz
Valued Contributor

@skoonin You're not the only one!

skoonin
New Contributor

thanks for confirming that I'm not alone in this. such strange behavior! seems there's a variable somewhere not updated?

Aziz
Valued Contributor

My previous post didn't complete because the spam bot blocked me, here' a link. @skoonin ]

https://jamfnation.jamfsoftware.com/discussion.html?id=17031

mscottblake
Valued Contributor

@skoonin You can fix this by either calling /usr/local/bin/jamf instead of just jamf or by adding /usr/local/bin to the path for the user ARD uses.

rtrouton
Valued Contributor III

ARD's PATH environment variables don't appear to include /usr/local/bin. When I ran echo $PATH via ARD's Send Unix command, here are the PATH variables I received back:

/bin:/sbin:/usr/bin:/usr/sbin:/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support

To address this, I've added a task template to my copy of ARD:

#!/bin/bash

CheckBinary (){

# Identify location of jamf binary.

jamf_binary=`/usr/bin/which jamf`

 if [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ ! -e "/usr/local/bin/jamf" ]]; then
    jamf_binary="/usr/sbin/jamf"
 elif [[ "$jamf_binary" == "" ]] && [[ ! -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]]; then
    jamf_binary="/usr/local/bin/jamf"
 elif [[ "$jamf_binary" == "" ]] && [[ -e "/usr/sbin/jamf" ]] && [[ -e "/usr/local/bin/jamf" ]]; then
    jamf_binary="/usr/local/bin/jamf"
 fi
}

# Run the CheckBinary function to identify the location
# of the jamf binary for the jamf_binary variable.

CheckBinary

$jamf_binary command_goes_here

The script above contains a function called CheckBinary, which populates a variable named $jamf_binary. The script calls the CheckBinary function before running commands which reference $jamf_binary, in place having to hardcode /usr/sbin/jamf or /usr/local/bin/jamf in the script.

For more information about ARD and task templates, please take a look at the links below:

http://www.peachpit.com/articles/article.aspx?p=606979&seqNum=3

http://www.peachpit.com/articles/article.aspx?p=606978&seqNum=6

jhuls
Contributor III

It was reported to me that some systems have Self Service broken but the one I looked at later was fine. I'm getting hit with a number of things right now so I've not had a moment to look at the others.

jwojda
Valued Contributor II

I'm getting reports of ss not working too on 10.10.x too. Ss starts to run a policy, then errors out.

powellbc
Contributor II

Count me in on the Self Service issue. Thread dedicated to it here: 9.8 Upgrade Self Service Down.

andrew
New Contributor

Same here on the Self Service issue. Just opened a ticket with my rep. Quite frustrating.

rcorbin
Contributor II

There is another thread called 9.8 Upgrade Self Service Down. I've stayed with 9.73 thus far. I'm hoping they iron this out for 9.81.

mcmaddog
New Contributor

I upgraded my JSS to 9.8 from 9.72 and also upgraded Server.app to 5.0.4 which broke http on port 80 and 443, which in turn broke HTTP installs from Self Service. I disabled HTTP installs and Self Service is working using AFP/SMB. I see other threads stating Server.app 5.x is not being recognized by the installer which prevents JDS install for some people and they have had to revert back to Server.app 4.1.5.

gokoudes
New Contributor III
New Contributor III

Same http distribution issue, running 9.73. Updated Server.app only to 5.x to see this issue. Ended up rolling back Server.app 4.1.3 to resolve for now.

Chris_Hafner
Valued Contributor II

Oh yes. I should have though to ask which version OS X you were running. Version 5 seems to have broken a large number of things for a wide variety of people, though this last update was supposed to help resolve those. I've happily stayed on 10.9.5 and the associate version 3 server (3.2.2) as it continues to work beautifully while still allowing me to aggregate ethernet ports and assign the bond to the NetBoot service.

yellow
Contributor

So far so good.. except imaging using 9.73 Casper Imaging seems to drop the Adobe Temporary Installer user forever, despite try to use the splash screen fix. When I tried with 9.8 Casper Imaging, it appears to have worked (or I got lucky). Still testing. I know all our techs are going to be THRILLED to have yet another CasperBoot Key! THRILLED!

Addendum: Which will finally motivate me to use Master @rtrouton's scripting mojo from CasperCheck.sh to apply this to the Casper Imaging app on people's boot keys.

mcmaddog
New Contributor

Our JSS is running 10.10.5

We also have a problem using Casper Imaging 9.72 with our JSS 9.8. The computer reboots after completing the initial installs (AutoDMG 10.10.3 base image and some third party applications), logs into the Temporary Adobe Installer account, but doesn't install the First Run items and just sits there. Using Casper Imaging 9.8 works fine so I'm updating our NetBoot images, however the release notes state that Casper Imaging v8.6 or later is supposed to work.

jstine
Contributor

@Chris_Hafner I'm currently using a bunch of scripts that point to /usr/bin/jamf. What did you update your scripts to for them to work in 9.81?