Self-Service Troubleshooting Steps on iPad

Are you using a proxy on the iPads?

Check the Date and time. Changing it causes all kinds of weird stuff to happen

IOS 10.2 is having an adverse affect on Self service. Not able to connect to server on a Gray screen. date and time is correct. Everything else works except self service.
IOS 10.1.1 issue with self service has the app opening, but a blank white screen with "unable to connect to server" on the top line. Dat and time are correct. iPad was restored via iTunes then through JSS. Everything works except self service.

Yep, its our Proxy. JAMF support confirmed there is a bug with 10.2 and Self-Service with a Global HTTP Proxy Config Profile. Since all of our students have Managed IDs and cannot install from the App Store...this isn't going to be pretty.

Ditto here. I mean about this not being pretty.

This could get very bad for us.

Our TAM said it has to do with this:
https://techcrunch.com/2016/06/14/apple-will-require-https-connections-for-ios-apps-by-the-end-of-2016/

We use a cloud-based filter so the students can be 'safe' to bring their iPads anywhere. All we have to do it provide the HTTP Proxy URL and a Cert in a Config Profile. It has been working great so far. Our TAM said we might be able to get around the issue if we can switch the Proxy URL to a HTTPS URL so we are going to try that on a few iPads and see if it helps.

We are running into the same problem. Our proxy provider does supply an https url for the PAC file. In limited testing, this seems to fix the problem. The proxy provider, however, has warned us that they've seen unexpected behavior on iOS when the global proxy is defined with https. I haven't seen any evidence of this and am waiting on an answer from Apple if this is true before updating the config profile for everyone.

We just noticed this problem today with an iPad running 10.2. Either grey screen "Cannot connect to server." or no action when the "Install" button is pressed from the Self Service app. We were able to install from the Self Service Web Clip.

We changed our proxy url to include an 's' - and the issue cleared up. We are using Securly as our filter.

Thanks for this post. We thought maybe it was an issue specific to JSS 9.97 and ios10.2 but looks like it was an ios10.2 issue since lehmanp00 started this post and is/was on 9.96.

After testing we pushed the config change out to our 1000 Student iPads.

Just encountered our first iPad, probably of many yet to come. Following this thread.

Thanks lehmanp00 & murray! I added the "s" to the Proxy PAC URL in our Securly Configuration profile and all is good again.

We are experiencing the same issue here with 10.2 devices. We are still on JSS 9.96. I have changed the Proxy PAC URL to use HTTPS instead, however, the Self Service app continues to display the "Cannot connect to server" message. I tested the same configs on a 9.35 device and Self Service seemed to be working properly.

We are also experiencing random issues with other apps while on Proxy. I think our content filter vendor will need to come up with a fix for this as everything seems to be working fine without the Proxy setting...

I am encountering this problem today as well with our 10.2 devices. Is there fix yet?

No updates on this?

We are also having this issue. We have modified our mobile pac file to go over https. I contacted our content filter (iBoss) and they pointed the finger at Jamf. I got up to tier 2 support with Jamf and they seem to be convinced it had something to do with how our mobile pac file was written. No idea how to modify it though.

@cortday I would drop iBoss as soon as you can. We had so many issues with iBoss handling SSL decryption. We made the move over to Securly and has been incredibly smooth and fantastic support. I don't have have nice things to say about iBoss support.

We're still fighting this issue, trying to determine how to fix it, if it's an Apple issue, a filter issue, an MDM issue, or an app developer issue.

We've been talking with our filter folks, Content Keeper, for some troubleshooting. From our testing, some of the fault appears to be with how the Global Proxy PAC file is handled. Either it's a problem with the PAC file itself or how the MDM is processing it.

In general we have our PAC file on all iPads, with the idea that we can say they're filtered anywhere they go. The PAC file isn't supposed to hit the iPads when they're on the local network because of the way it's designed with IP ranges excluded, but that doesn't seem to be the case for us because we've tested by excluding a few iPad groups from the PAC file and for the most part they seem to be playing nicer. So that definitely points to this being an issue with the PAC file itself or how the MDM is handling it.

JAMF and our VPN provider have been looking this over the last couple of days. We are seeing the PAC file, that prevents the connection to the Self Service app on 10.2, works correctly on the iOS beta of 10.2.1 without making any changes. So for now we are using the web clip, and hoping those changes in the beta carry over to the final release.

@promalley Good to know. I've never cared for it, but my boss did check out Securly a while back and liked it.

As far as our problem with Self service goes. Make absolutely sure that the web server hosting the mobile pac file supports HTTPS TLS v1.2
Ours was hosted on a Mac Pro running 10.9 and server 3.xx. Apparently that only supported TLS v1.0 so the iPads couldn't communicate at all.

We were experiencing this issue with iBoss as well. We changed the PAC page to https and it is working fine now.

Our iBoss is working as well, only had TLSv1.0 previously was the issue.

Just spoke with our CK filter guy - he says they found out that their settings were enabled to allow all versions of TLS, and if in that scenario you have TLS v1 enabled it causes havoc. It sounded like it's a "one or the other" kind of thing. Now they have disabled TLS v1 so that the higher versions can be used, which means potentially some older devices may experience issues. We don't think that would be too bad for us.

We're testing now.