Configuration Profiles and Limited Access JSS Not working

Yes, you should be able to send profiles to external devices.

I just installed a new internal JSS with a limited in the DMZ a few weeks ago, and had the same issue.

I found that I had forgotten to 'Enable push notifications' on the DMZ JSS. (Computer Mgmt > Security)
(Grrrr, Rock Head!!)

OK. I moved the limited access JSS to allow logins, logged in, verified that Enable push notifications is enabled. I moved it back to allowing "computer and mobile device access only".

So, as I sort of mentioned, this is a clustered setup, JSS version is 9.72 on windows, with the Limited Access JSS sitting in our DMZ. Clients get Configuration profiles just fine when internal to our network. but not from the outside. The external JSS only has 8443 open inbound and, should have unrestricted access outbound.

What's the best way to troubleshoot? I could have a client point to the limited access JSS from an internal address to see if still got a config profile. If that's the case, it would seem firewall related? If it still didn't work, isolated to the DMZ server?

Per some of the jamfnation KBs , it seems that 8443 is all that's needed inbound, and with unrestricted outbound, I should be OK?

*Ports 443, 2195, 2196, and 5223 must be open outbound to the 17.0.0.0/8 address block in order for computers, iOS mobile devices, and the JSS to communicate with APNs.

Thanks for the help!
Aaron

@adroitboy just out of curiosity, how are these profiles scoped? Are they limited to LDAP groups or network segments?

If they're limited to LDAP groups, you should double check that your DMZ server can communicate with your LDAP server.

@kitzy , they are scoped to the machine itself. It's a VPN configuration, and only select machines get it. The machine that made me realize that they weren't working was added when it was offsite, and...nothing happened.

As soon as I added the VPN config manually and connected via VPN, it picked up the Configuration profile and installed it as expected.

Update: I found that configuration profiles are sometimes applying (at least I'm my test case), so this doesn't seem to be what I initially expected. Essentially I was basing my "it doesn't work" on the JSS status in the web interface. However, it does work sometimes, and only works partially at other times. To repeat the test, I'd remove the profile from system preferences after it applied.

Checking Network Access:
- The machine on the outside had access to gateway.push.apple.com on ports 2195 and 2196
- The external JSS can also access gateway.push.apple.com on ports 2195 and 2196
- The client had an established connection to port 5223 to an apple IP (17.172.232.64)

After distributing the configuration profile from the JSS (choosing distribute to all)
- The Client machine DID get the configuration profile almost immediately
- The JSS event logs (Global Management > Event logs) showed that the configuration profile had "started"
- The JSS never showed the status as being completed (Global Management > Event logs)...only started
- The Configuration profile > logs shows the profile status is "Pending" - Nothing that I did to the client caused the status to update for hours (The machine could recon, check for policies, etc).

So, has anyone else experienced issues with configuration profiles indefinitely showing a status of "pending" in the profile or "Started" in the event logs, even though they did install? Hopefully I'm not the only one!

Thanks!
Aaron

Check the time on your external and internal JSS and make sure they are the same.

That caused this issue for us where external JSS was behind. We would scope a config profile or other MDM Command from the internal JSS. So when the client would get push notification and check in with JSS for new MDM commands the command's time stamp set by the internal JSS was technically in the future of the time on the external JSS. So it would fail to run until the next time a client checked in for an MDM command and the old commands were now in the past according to the external JSS's time.

Making sure their times were in sync fixed this.

Time and everything were correct. Problem was intermittent, but was always "fixed" as soon as the machine can onto the network with the internal JSS. Have opened a ticket with JAMF and will try to report back on the solution.