Here's a good tale of misdirected troubleshooting:
When we convert an existing store from (competitors poor excuse for wifi) old WLAN to Aruba iAP WLAN we start be pre-configuring a "seed" iAP and sending it out to the store. Our technician connects it to a powered switch in the network colset and leaves it hanging from the rack or ceiling.
Later a contractor hired by our wireless partner turns up with 10-15 additional iAP and runs new cable and hangs them properly etc.
As they come on line, they pull software and configuration from the seed iAP, which will be the last one hung.
Normally this has worked quite well, but this morning we had a different experience.
Only three iAP came up in the swarm while all 13 drew power and appeared to boot up correctly.
We tried powering them all down and bringing up the seed iAP, then one "failed" iAP to no avail.
We tried powering them all down and bringing up one of the "failed" iAPs which we saw pull an IP address from the DHCP, but it never presented an SSID or accepted an SSH (or telnet) connection.
We did discover that the two iAP275 (working) weren't getting proper power and fixed that, but that didn't help with the "failed" iAP.
After an hour of tests, I figured the iAP which weren't coming up must be trying to pull configuration or firmware from Activate or something which must be why they were ignoring the swarm, so I fired up a packet capture at my head office to see if I was right.
When what should I find but the 10 iAP all trying to check in to my controller infrastructure - aruba-master that is!
Turned out the installer had two iAP275 and 10 AP105 installed. No wonder they wouldn't join the swarm.
Aruba is replacing the mis-shipped APs with iAPs and we should be good next week.
Nothing really wrong here, but a clue to anyone else on something to look for.