I'm finally getting ready to start migrating to configuration profiles. Everything seems to work fine when testing internally, but noticed that profiles only seem to work when the machine is reporting in to the internal "full access" jss.
Nothing happens when the machine is off of our internal connection, however machines seem to check in and find policies just fine from the outside if allowed to do so. Packages fail due to not exposing our distribution points. Most have a network scope to prevent the attempt.
Am I correct in thinking that machines should be able to get configuration profiles from inside AND outside of our network?
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 126.96.36.199/8 address block in order for computers, iOS mobile devices, and the JSS to communicate with APNs.
Thanks for the help!
@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 (188.8.131.52)
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!
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.