I'm dreading the same thing at my place of work. We have a large scale (>2000) deployment all using WPA2 Personal password. The only way I have figured out how to do it is a script using system setup. Even with that, there will be downtime during the change over UNLESS the SSID is different. With a different SSID, you can have 2 (or more) entries in the preferred network list. However keeping the same SSID, I believe you will have to have downtime.
Workflow would be push out the script, change the WPA2 password, then deal with computers that didn't accept the change.
Neither of my networks are as large as yours, but I've had the same anxieties. You guys obviously know the problems with making hard change on SSIDs so there's no need to labor that point any more.
I was lucky to be able to do more of a 'soft' transition when I changed SSID's...but one option that I thought I may have used if I needed it was to create an SSID that didn't broadcast its name. Then if something got screwed up in my main SSID transition, my users would be online, they just be on a hidden SSID.
I would recommend moving to an authentication based system to avoid having to do this.
WPA2 Enterprise can authenticate against your OS X OD with RADIUS. Then users just need their username and password. As users come and go they are locked out of the network as you remove/add accounts.
If you have to do it. Do it to future proof yourself. It won't be easy either way.
In a past position we accomplished this pretty smoothly by spinning up a new SSID. These are the steps we took if my memory servers me correctly.
- First we created an extension attribute to grab the current SSID the computer was connected to.
- Next we created some Smart Groups to track and scope computers
- Then we created my first policy to run a script to join the any computer in the Smart group with the Old SSID to the New SSID and then ran a Inventory Update. Once the computer finished submitting the recon, it would end up in the Smart group with the New SSID.
- We then had a second policy that would run a script on any computer in this Smart Group to remove the Old SSID from the Preferred Network list.
I believe we made the Old SSID hidden so users wouldn't reconnect themselves to the old network. Eventually, all your users end up in the new Smart Group and thats when you cut off the Old SSID.
One caution I'll give you on using RADIUS and having users authenticate which may or may not effect you. When a users logs out, they loose network as well. So connecting to those machines remotely or to run policies on them may not work. It all depends on how things are setup in your environment.
Hope this helps.
Great responses folks--much appreciated! We're migrating some network hardware and introducing a controller-based environment/thin APs, so we're weighing options. We are also going to do some in-depth RADIUS testing in the coming months and see what we get. Right now, if we had to do it tomorrow, I think we'd roll out a new SSID and migrate via script, then remove or hide the old SSID, as suggested by krichterjr/jrippy.
Our students are adept at obtaining any wifi password we use, so we aren't super-concerned about who connects, but we want to have some type of authentication in place so it's not just a free-for-all. I'd love to use a massive complex password, but it becomes obtuse when we're trying to reconnect a board member at a meeting and fat-finger the password 3 times. We're anticipating some type of BYOD (they do it now, anyway) but with more access control and, hopefully, some more responsibility on the part of students & staff.
I truly appreciate the responses and I know we'll be using a combination of everything suggested--thank you all!
