We chose a different path to do this which mostly worked but had some unintended consequences. I am not advocating that this is a good solution nor is it a best practice. But with a few exceptions it worked for us.
The challenge was that several subcontractors were sent a ton of new APs in boxes and asked to swap out old APs. We didn't know which MAC addresses were sent to which crew. The sub then subbed out some of the work further. Because the contractors were working in multiple buildings in parallel we couldn't provision a single building all at once as we had done with initial AP deployments. Sometimes it was a room access issue or challenges with new mounts that were slowing things down. So we had a bunch of APs coming up (in default group: eth0 up, radios down) but the whole building was not completed for weeks. The subcontractor did not give us the list of MAC addresses that got installed - and not all switches supported LLDP - until they completed the entire building. We were essentially keeping the whole building down until ALL APs were connected. That was unanticipated. You can imagine the user angst. So we started provisioning APs daily, trying to get them as they came online using temporary names until the full AP-Name/MAC list came in. Unfortunately, sometimes AP provisioner staff was unavailable plus the subcontractors began working weekends.
In the end we ended up modifying the default ap-group (the original default group was copied off so we can return it to normal state). This was done in both AOS 6.4.x and 6.5x. We added our two campus-wide VAPs, chose an empty-ish "staging" controller (in ap-system-profile) for the APs to land on (not the master!), created a least-objectionable RF profile to support multiple AP models, and let her rip. The ap-name is automatically the AP's MAC address so it was unique which is mandatory.
The result was that when a freshly unboxed AP connected it came online, checked in with the Master, downloaded a new image, rebooted, came back online and immediately started serving clients on the two VAPs. Without any assistance from a controller admin. We did this for about 2500 APs during a summer of major upgrades.
Pros:
- Allows newly unboxed APs to immediately host client devices without waiting for provisioning
- Eliminated staging area pre-deployment (despite our efforts at labeling sometimes the APs were simply not installed where they were supposed to be, and sometimes the physical room numbers changed in the building!)
- No longer need to be on the lookout for new APs that come online. No more Whack-a Mole.
- No need to immediately determine AP Name, AP-Group, etc.
- No waiting for subcontractors to complete a building
- Users are online minutes after an AP is connected
- Weekend work could proceed without provisioning staff involved
- When a building was complete and we got the AP-Name/MAC hash we could then do a formal provisioning of the entire building at once in a maintenance window
Cons:
- AP models with external antennas (that end in "4") will not come up until antenna gains are specified through formal provisioning.
- Users might suffer through duplex mismatches or CRC/FCS switchport errors that would typically get discovered before provisioning
- Users often assume the whole building must have coverage when in fact only a few APs have been installed
- We lost some oversight and QC of APs that either didn't initially come up or never got swapped out (often only discovered when we got the list and formally provisioned)
- In some buildings we carry additional SSIDs. Because the default ap-group had to be "least common denominator" additional VAPs were absent until the AP was formally provisioned
- During the height of AP swap outs we almost maxed out the AP count limit of the "staging" controller due to weekend work
- Users connect right away to an AP that comes online. If the "correct" ap-group is required (e.g. need additional VAPs or correct RF profile) we either had to interrupt client connections during business hours or wait until next maintenance window
- Sometimes users opened t-tickets because of in-building coverage gaps while the process was going on. End users often don't know that a building is in the process of AP work.
- Not scalable. Not easy to redact.
That last point is a tricky one. The major upgrade work is done and I hope to restore the 'default' ap-group back to default. But it's not easy putting that genie back in the bottle. Having the AP's "radios down" until all APs in the project (bldg, floor, auditorium, etc.) are ready eliminated user confusion, held the contractors accountable and looked more polished. And ARM didn't have to work as hard. When the 'default' ap-group is actually default (the way Aruba designed it) then the user only has coverage when the AP is formally provisioned. When we were doing "all APs up or nothing" the users in a building could reasonably expect full coverage and service when they (eventually) had any coverage. It's harder to explain that an AP is in a "hobbled but up" state that will be corrected at some point.
That's our story, good bad or otherwise. Tweaking the 'default' ap-group worked for us when the big swap outs were happening. Now we're discussing whether to restore things back to "normal". I'm not advocating this as a particularly good solution but it is one that worked for us when we faced similar challenges.
Hope this helps,
Mike