Posted on 12-05-2013 02:48 PM
Hello,
we are a school and we have a fleet of 10.7 and 10.8 macbook (pro and Air) which have configuration profile deployed from JSS (v9.2).
We had MASSIVE ISSUES with wireless dropping off and on again (in authentication stage) constantly, regardless of the signal strength; I tried troubleshooting it with our Wireless Controller and AP provider (Meru Networks) but the configuration seemed to be ok. We also have few Windows machines left that are working beautifully with strong and fast wi-fi connectivity.
At this stage we figured that the issue was related to JSS Profile Configuration or to the Mac not being able to manage 802.1x sessions properly.
The issue was that the client was able to connect to the wireless, but then the "connect" or "disconnect" button below, that establish the MCHAP2 Authentication, was getting stuck and greyed out.
Not even turning wi-fi off and on waas able to unlock that button; in fact we figured that the eaopolclient Process (visible in Activity Monitor) was the one that had to be killed to allow the machine to be reconnected right away.
Wi-fi dropouts kept happening though, so we decided to remove the wi-fi profile from clients.
Since then, our laptops fleet has been stable in terms of connectivity.
Suddently Mavericks came along and i decided to test it out with our previous config.
Since i upgraded to 10.9, my wi-fi has been super stable and it never dropped since.
So, my conclusion is that the issue may reside in JSS and OS X too.
My suggestion now, after testing this with several other 10.9 machines, is to DEFINITELY UPGRADE to Mavericks and keep configuration profile with wi-fi settings in it (even with multiple payloads).
Posted on 12-05-2013 02:51 PM
@nkalister has seen similar I think...
Posted on 12-05-2013 02:54 PM
yeah, I dealt with this quite a bit for the last year. Our issue was that we were doing certificate-based 802.1x authentication. 10.8 has a bug that can cause repeated wifi drops when a certificate from the system keychain is used for authentication. the bug has been fixed in 10.9.
If you're not using certificates for authentication, then this particular bug was not the cause of your issue.
Posted on 12-05-2013 04:45 PM
Thanks Guys!
Although the issue is not totally resolved for us, this confirmation reassures me of the flakyness of the system itself.
We will try to move to 10.9 in the near future FOR ALL OUR CLIENTS (even though Mavericks has big issues with smb network shares mapping at the moment). Damn.
Thanks again.
Posted on 12-05-2013 07:06 PM
We had this issue as well. It seems that the JSS changes the WiFi in some weird hidden way. Our issue was that we had a WiFI configuration profile prior to getting casper that we used without any issues. (this was a WiFi profile and was set as a Login Window Configuration, with NO certificate) We took that configuration profile and uploaded it into the JSS and created a policy to deploy it, instantly we had issues with connections dropping. We thought maybe it was because it was created in Server and not with Casper, so we copied the settings and created a new one with Casper identical to the one we had, then deployed it, again we had connection issues. After doing some testing we noticed that if we hand installed the configuration profile by coping it from a share or external drive it would work just fine, but deployment through Casper caused issues. So here is the solution that works for us:
1: On a 10.7 -10.9 machine open composer,
2: Copy your configuration profile (yourprofilename.mobileconfig) from a share or external drive to a location on your computer. We chose /var/tmp
3.Take another snapshot and create a .dmg
4. Upload the .dmg to your distribution point.
5. Create a POLICY
6. In packages payload choose your .dmg and pick "install" under "Actions"
7. Scroll down on "Options" window and pick "Files and Processes"
8.In "Execute Command" area type /usr/bin/profiles -I -F /var/tmp/NAMEOFYOURPROFILE.mobileconfig
OPTIONAL: you can add a line to remove the profile after install, but with the small file size of profiles and with the benefits of having them hidden on the local machine, we chose not to delete them.
This "install" will really just copy your configuration profile to the location you chose. Then the Command does the following -I installs your configuration profile from -F which is the path you saved your configuration profile to. (this will work for other profiles as well)
This replicated the "hand install" and worked perfectly for us, give it a try and see if it works for you. The users will need to do the following, Reboot the computer or log out and log back in, if the wifi doesn't automatically connect, from the WiFi drop down menu pick the SSID you installed the profile for and input the credentials for the network. After that it will connect on it's own without issue.
Posted on 12-06-2013 08:31 AM
I'll confirm that there were bugs with cert-based, system-level 802.1x on Lion and (primarily) Mountain Lion. We pulled our hair out and worked with Apple for months, and then as soon as Mavericks came out they acknowledged they fixed a few things. It was pretty frustrating.
We're basically just moving everyone to Mavericks as soon as possible.
Posted on 01-31-2014 05:22 AM
Has anyone here had any issues resurface after the update to 10.9.1?
We had massive problems with wireless login on 10.8, but as soon as 10.9 dropped, everything became stable and started working very quickly.
Now, though, as soon as we update a machine to 10.9.1, the wireless login box completely disappears on the login screen (and it actually doesn't work, it didn't just become invisible). Our config profile is still installed, it just doesn't do anything.
Posted on 01-31-2014 05:22 AM
Update--
9.22 caused the issue, it had a bug in the config. 9.23 fixed the bug.
Posted on 04-01-2014 10:28 AM
I'm on 9.30 and I'm experiencing the same issues with Wireless profile.
JSS 9.3
Mavericks 10.9.2
Thanks mahghost for the solution.
Posted on 04-01-2014 10:55 AM
i always use profile manager on OS X server to generate my profiles. No worries about the XML itself that way. I've seen too many bugs with the XML that the JSS generates to trust it.