Hi guys,
I recently upgraded to OS X Server 5.0.4 and JSS 9.81. Since I did this HTTP downloads are not working.

Os X Yosemite 10.10.5
Os X Server 5.0.4
JSS 9.81

I uninstalled/reinstalled OS X Server, commented out all references to "8443" in apache_serviceproxy.conf rebooted - nothing is fixing the problem.

I do notice that in "Overview" on Os X server I see Internet: Reachable at my ip, no services available. Under Websites The status says Users may not be able to access websites from the internet. Note that before the upgrades HTTP worked perfectly. Any thoughts?

@kirkd I would be inclined to go back to Server 4 if you still have a copy of it. I don't think you are going to gain anything by going to Server 5 on your JSS. You probably don't want to run Caching server or any other services on your JSS intense anyway. I'm actually still running my JSS on 10.9.5 and Server 3.2.2. I haven really seen anything to gain by upgrading it.

@rcorbin In retrospect yes I would have certainly avoided the Server upgrade. Unfortunately I am unable to locate Server 4 anywhere online. If I had it I would downgrade.

I wonder if this will be updated so you can grab Server 4 as well. https://support.apple.com/en-us/HT203137
But maybe they are not bothering because of the fact that Server 5 runs on 10.10 and 10.11 so maybe they don't feel like it is needed.

https://derflounder.wordpress.com/2014/11/01/downloading-server-app-for-mavericks-and-mountain-lion/

Actually @kirkd I am having the same issue, but it happened after the upgrade to Server 5. Predated the 9.81 release. Curiously our other distribution points are working fine over HTTP, even the ones running Server 5. They handle the bulk of our packages so I have been putting off troubleshooting it (didn't even notice the problem at first). Curious to hear if anyone else has any ideas.

Not loving Server 5 I have to say.

@mtruskowski I worked with Kelly from Jamf for quite a long time yesterday, she really put forth the effort and got things working again.

Here's what we did, I can't say for sure which of these fixed the issue:

Re-installed Server 5 after uninstalling and deleting the server folder in /Library/Server
Edited /Library/Server/Web/Config/Proxy/apache_serviceproxy.conf to omit all references to 8443.
Re-created the symlink to Shared Items/CasperShare per the info in this link:
https://jamfnation.jamfsoftware.com/article.html?id=116
In Server5 - Websites - Server Website (port 80) - Edit - Store site Files in Shared Items/CasperShare
Deleted one redirect that should not have been there, no idea how that showed up.
Who can access - Everyone
Enabled Allow Folder Listing under advanced settings.

After all that I was finally able to access packages/run policies via http. Server5 still shows the http website as Not reachable, this website is not available over the internet. Right now I am just pleased that http downloads are working again.

Thanks @kirkd! I will give that a try soon.

So, can it be confirmed that the problem with relocating the jamf binary on the clients is solved with 9.81? It's a little bit difficult to assess as it's random if clients work or not, with 9.8 only about 10% was affected.

I agree with @bollman about knowing if the problem is solved. We didn't upgrade to 9.8 due to this issue and I've been sitting on the sidelines with 9.73 waiting for confirmation that it is resolved in 9.81 before upgrading. Anyone at JAMF able to confirm? Paging @amanda.wulff. You always have great insight.

I had an issue with server 5.0.4 where it appears it enabled port 8443, even though web services is completely turned off.

We were once upon a time using the server with calendar and contacts which were using 8443, but this had been turned off for over a year, and no posed any issue in the past, but it was still listed under server > hostname> access tab. Which I have just removed altogether.

So far so good.

Now I am considering moving to el capitan, cause I am just crazy like that.

@mpermann

It looks as though that issue may not be fixed in 9.81. We have D-009724 still open.

This does seem to still occur with a small percentage of machines in a very large environment in combination with heavy load on the network, however, so that is something to take into account. In smaller environments, it will likely not be an issue. The open defect is a very specific one.

The workaround for machines affected, if it does happen, is to run a sudo jamf manage (If SSH is enabled we can use Casper Remote to run a 'sudo jamf manage command' to repair the issue as well.), delete /Library/LaunchDaemons/com.jamfsoftware.checkForTasks.plist if it exists, and reboot the machine.

Grabbing the machine and pulling it back via Recon also seems to do the trick.

If you have additional questions on D-009724, please get in touch with your Technical Account Manager either by phone, by e-mailing support@jamfsoftware.com, or by using the My Support section of JAMF Nation.

Thanks!
Amanda Wulff
JAMF Software Support

Thanks @amanda.wulff for the heads up. I knew I could count on you!

@mpermann

I chatted with one of the people involved in working on D-009724, and have edited/updated my original comment.

If your environment doesn't fall into the specifics of a very large environment (50k+ devices) with an exceptionally heavy network load, the defect will very likely not affect you, so that is something to take into account when deciding whether to upgrade to 9.81.

Thanks!
Amanda Wulff
JAMF Software Support

@amanda.wulff What about a environment of 6000+ clients where students are opening/closing laptop lids all day long? Maybe our network load is considered heavy, hard to judge that.

We lost connectivity to 5% of our clients when we upgraded to 9.65 & really trying to avoid that when going to 9.81. Remotely running ssh commands isn't an option for us and doing a quickadd isn't practical.

I'll reach out to our TAM as I was thinking this drop off issue was addressed in the 9.81 release.

@CasperSally

I'd agree with the reaching out to your TAM for this one, because the defect that is open and the one that was previously closed (D-009659) were new with 9.8 and appeared to be a timing issue related to the binary move vs. policies trying to run before the computer checked in to get the new, upgraded binary, so if you had machines lose JSS connectivity when upgrading to 9.65 (which did not have a binary location move), it likely had a different root cause.

Your TAM probably knows your environment much better than I do, so they'll be the best resource to go over everything and determine if you'll be at risk for seeing the behavior.

Thanks!
Amanda Wulff
JAMF Software Support

We're in the same boat as @CasperSally and have held off until confirmation of resolution. 9.73 is ok for now. We're not trying to push the bleeding edge since school only started 4 weeks ago.

Bumping this looking for any other folks input out there not mentioned to look out for. Testing now, but want other's (additional) take.

We upgraded and our clients are 90% upgraded so far. I'm hoping the remaining 10% just haven't been powered on yet. I did have a 9.81 casper imaging 'bless' issue with multiple partitions. If you have this issue, search JAMFNation for my name and you should come across the fix.

The upgrade on our 2008R2 server was easy BUT since the upgrade our distro point server cannot be mounted to machines. It's also a windows server with an SMB share. Can manually mount it to machines but anything from Self Service or policy pushed is failing. Trying to work out if it's a coincidence. Any suggestions or should I get on the horn to Jamf Support?
Thanks, Matt

The only thing I can suggest is if you have a "workgroup" configured for the SMB shares, try removing it and leaving it blank. We ran into that issue with an earlier JSS version this year and that resolved it.

That said, I upgraded from 9.63 to 9.81 on Saturday. Most of our clients have updated and I am not aware of any issues. The server upgrade went smoothly and I only had to update the Casper Imaging app on our boot media, it was dying partway through the adobeinstall process when installing packages on reboot.

I just upgraded to 9.81 from 9.61 and we noticed a problem with our iOS PreStages. We have a PreStage for each of our schools and all the iOS PreStages that were using the "List of Names" option for naming were deleted after the upgrade. If I re-populate the list, it'll stick for awhile and the JSS will name some, but it'll eventually delete itself again. Anyone else seen this behavior? I already submitted a support request, just curious if someone else already found a fix.
Thanks!

Yes, we've seen a few machine lose their connection to the JSS as per @CasperSally 's question. It was further complicated by a very recent change in our SSL certificate and trust. We've captured those units and re-enrolled them without issue.

We have a really bad problem upgrading from 9.73 to 9.81.
Luckily the JSS is running within a VM - so I can just rollback the snapshot.

Anyway, if I upgrade i seem to loose all devices, which would mean quiet a lot work to fix it.
After Upgrade I get the following error running recon:

sudo jamf recon

Password:

There was an error.

Device Signature Error - A valid device signature is required to perform the action.

Did anyone have the same error AND has a suitable Solution for it (Sneaker Management isn't suitable!)?

I already opened a Ticket, just if anyone asks :)
Also tried the solutions which were suggested and failed again (changing the ciphers, checking the cert)

Thank you SnapShot you saved my Ass ;)