Posted on 09-17-2015 05:12 AM
Any early reports of problems? My test environment seemed to go okay...
Posted on 09-17-2015 05:53 AM
It was a smooth upgrade in production & testing.
Windows Server 2012 R2, Java 8 Update 60
Posted on 09-17-2015 06:02 AM
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.
Posted on 09-17-2015 06:10 AM
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.
Posted on 09-17-2015 06:25 AM
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...
Posted on 09-17-2015 07:05 AM
@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.
Posted on 09-17-2015 07:07 AM
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."
Posted on 09-17-2015 07:21 AM
@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 :-)
Posted on 09-17-2015 07:48 AM
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."
Posted on 09-17-2015 07:57 AM
@Apfelpom Defaults in new config profile just created in 9.73:
Posted on 09-17-2015 08:21 AM
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 ;-)
Posted on 09-17-2015 08:42 AM
@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?
Posted on 09-17-2015 09:02 AM
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.
Posted on 09-17-2015 09:04 AM
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?
Posted on 09-17-2015 09:15 AM
@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.
Posted on 09-17-2015 09:44 AM
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.
Posted on 09-17-2015 10:19 AM
Does the JSS auto force quit apps before logging off automatically? I think this might be the reason it's not working for me
Posted on 09-17-2015 01:17 PM
@ 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!
Posted on 09-17-2015 02:07 PM
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.
Posted on 09-17-2015 02:17 PM
@hkabik Thanks for that!
Posted on 09-17-2015 02:55 PM
Posted on 09-17-2015 03:09 PM
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.
Posted on 09-19-2015 10:21 AM
@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
Posted on 09-22-2015 02:55 PM
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?
Posted on 09-22-2015 03:12 PM
@skoonin You're not the only one!
Posted on 09-22-2015 03:25 PM
thanks for confirming that I'm not alone in this. such strange behavior! seems there's a variable somewhere not updated?
Posted on 09-22-2015 03:27 PM
My previous post didn't complete because the spam bot blocked me, here' a link. @skoonin ]
https://jamfnation.jamfsoftware.com/discussion.html?id=17031
Posted on 09-22-2015 05:20 PM
@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.
Posted on 09-23-2015 03:56 AM
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
Posted on 09-23-2015 02:58 PM
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.
Posted on 09-23-2015 03:24 PM
I'm getting reports of ss not working too on 10.10.x too. Ss starts to run a policy, then errors out.
Posted on 09-24-2015 05:56 AM
Count me in on the Self Service issue. Thread dedicated to it here: 9.8 Upgrade Self Service Down.
Posted on 09-24-2015 01:05 PM
Same here on the Self Service issue. Just opened a ticket with my rep. Quite frustrating.
Posted on 09-24-2015 01:09 PM
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.
Posted on 09-28-2015 10:26 AM
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.
Posted on 09-28-2015 10:47 AM
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.
Posted on 09-28-2015 11:18 AM
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.
Posted on 09-28-2015 11:21 AM
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.
Posted on 09-28-2015 02:19 PM
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.
Posted on 10-14-2015 12:55 PM
@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?