SuperfluousAdjective

Not every system will call home, and if it does it is often an opt-in model or at the very least well documented. It is odd to secretly push a change to a product to allow for call home functionality with no statement on privacy or what is being transmitted. This should have been made clear. There are many organizations who cannot have network equipment in their environment that call home. Ubiquiti should have known this. Even if the data is anonymized it can still be a security risk or a compliance violation.

They are fourth. Cisco, Aruba, Ubiquiti, Ruckus... Beamforming is not unique to Ruckus. And coverage per AP is not something that anyone should brag about. Don't get sucked into Ruckus marketing. It doesn't matter if your AP can beamform around and through your crazy difficult environment. Wireless frames must be acknowledged by the client back to the AP. If the client can't reliably reach back to the AP you will have a lot of retransmissions and add RF interference. Proper RF site planning is still needed and highly dependent on client connectivity to the AP. Ruckus and their partners are well known for doing site surveys that say you need less APs to start due to beamforming as a method of trying to undercut their competition on price. Then when/if you need more APs for performance reasons they'll say it could have happened with anyone... which is true it could have happened with any other vendor, however, it is much more likely to happen from the vendor who is purposefully ignoring the challenges of client to AP connectivity to make a sale. Interestingly, a comparable Ruckus AP with the same QCA and CPU/RAM is often slightly more expensive from Ruckus than say Aruba, but they often say you need less APs to show a reduced overall cost. This is dishonest in my opinion and if your Ruckus reseller is promoting less APs due to beamforming without properly explaining the downsides they are not trustworthy. It depends on the use case and the needs/budget of an organization. Cisco and Aruba are best for on prem wireless. Meraki and probably Mist are best cloud based. Mist is still new so they lack a lot of features. A lot of their marketing is nonsense, but they do have an interesting approach. Most Meraki vs Mist bakeoffs will go to Meraki though due to it being the more complete cloud product. And Ubiquiti for the super budget conscious. You can do a lot better.

Ruckus only has ~5% market share. I wouldn't consider 5% a "top brand." They also had the Broadcom issues where they wouldn't or couldn't stop using Qualcomm QCAs in their APs so they got their R&D budget cancelled until their business unit was sold to a cable modem company. I wouldn't use Unifi because it lacks enterprise grade features and they don't have the capability to resolve bugs and firmware issues in a timely fashion... which is a problem when their latest APs don't work or they suddenly decide to start sending your data offsite.

If your organization deployed a self signed cert inside IOS they put themselves on notice when the cert was created. It is not a secret or mystery to see when it expires in IOS. The person who created the certificate is the one who is responsible for making sure it does not expire and create and unplanned outage. It is not the responsibility of your hardware vendors to proactively reach out to you when your self-signed certificates expire. Maintaining good documentation is a best practice... as is not self-signing certificates on routers in the first place. Use a real CA or at the very least an open-source certificate.

This FN won't impact the vast majority of users. This is only if you used an IOS device to create a cert which is typically done on ISR routers for voice configuration. As a general best practice you shouldn't be self signing certs with your network hardware. Just because you have the capability to it doesn't mean you should. Use a private or open source cert provider or your own CA. If you do issue a cert it is your responsibility to keep track of its expiration, not your hardware vendor. If for some reason you don't want to do this you could also just recreate a new cert, but it would be continuing bad practices.

What your asking is a violation of the EULA, so publicly you shouldn't have any luck posting here for it. You should always maintain support on your controller when running a WLC, especially Meru since they have a history of end-running RFC standards and have far more client compatibility issues than any other vendor on the market.

Their business model is to convince customers to improperly set up their wireless networks.. ignore surveys, ignore client density, ignore interference and just willy-nilly place APs anywhere you want on the same channel and like magic the laws of physics disappear. And if your performance sucks, or if your clients don't work with their wireless system because they break RFC standards it's not their fault.. simply wait for a firmware upgrade (if it comes) and add more APs while crossing your fingers that it'll work the next time. The benefits of adjusting NAV values on a single channel architecture only exist in low client density deployments, that's why Meru uses multiple channels for their benchmarks. But, in low client density deployments you don't need to mess with the RFC and WiFi in that way, modern wireless systems are more than capable of supporting the environment. However, if you need more performance or if you have a lot of interference, you're fubared on Meru's single channel deployments. At the end of the day they can't get around physics.

Their product was started to solve a specific problem that was prevalent in early stages of WiFi. With the advent of modern technology and protocols like 802.11r/k/v, etc it becomes less relevant and the architecture itself creates a bottleneck. Meru recognizes this which is why when they do deployments for high performance networks they turn off their single channel architecture and when they run their own benchmarks they use multiple channels. Using the auto-rf channel assignment functionality of modern enterprise grade wireless systems will provide you better performance than a Meru single channel architecture. And if you're using Meru as a multiple channel architecture over their competition you've seriously purchased the wrong product for the task at hand...

Whoever told you Meru is a big boy in the wireless space lied to you. Their single channel architecture is counter intuitive with modern wireless advancements and their marketshare is abysmal.

Yes they are. You get what you pay for. Compared to the low end APs from other manufacturers they have half the RAM, lower CPU, less performance. All reputable benchmarks show they fail to properly serve all associated clients higher density environments (40-50+ users per AP). If that performance is acceptable to you, that is one thing. But, they are not enterprise grade compared to the competition. In what way are they superior? What feature or hardware component exists within their product portfolio that makes them superior in any way to the enterprise grade WiFi product portfolios on the market? The fact is they lack standard enterprise grade features like advanced RRM, DFS, basic roaming standards, fails to see any benefits of 802.11acw2 MuMIMO over 20 clients (due to hardware constraints), etc. It is 100% about cost. There is no technical reason to use them over the competition unless the decision is being made on cost. Other solutions can be easier to setup and manage and provide more features and hardware performance. The reason you'd use Unifi is because you can't afford or don't want a true enterprise grade platform.

No reputable person sells Meru... let's put that on the shelf. Unifi is not in the same league as Aruba or the rest of the enterprise wireless marketplace. They are low end, underpowered APs with limited features. You get what you pay for.

This test was commissioned by Ruckus and is actually quite laughable in how biased the results were created. Unlike most wireless tests the configuration of each product was not released, despite asked for, and in some instances they purposely used outdated/deferred version of code (months prior to release). As Devin points out in his report, QoS is critical to a test like this where we are basically testing wireless video QoS. That is all this test is, a wireless video QoS stresstest/benchmark. But, we know from the results that Ruckus did not enable wireless QoS on competing products, which is why you see the results you have. Best practice configurations of competing products was not used for a specific type of testing that Ruckus knew they would win if they handicapped their competition with deferred code and no QoS. Additionally, Devin who isn't the most unbiased character in the industry, didn't actually run the tests. He simply observed. Ruckus designed and ran the tests themselves. Whenever doing competitive tests like this it is common practice to allow the respective vendors to set up their own gear or to release the configs to show there was no monkey business (as there was in this test). The truth is most of these APs use the same/similar Qualcomm chipset and the performance results for each would not be very far off with a properly configured system and unbiased testing.

The biggest difference is that Meru runs in a single channel architecture which isn't the best for higher density environments and can cause issues with certain clients. From everything I've read Ruckus has better management and performance. Meru has some marketshare in EDU in Europe, but is generally non-existent elsewhere. Meru was recently acquired by Fortinet for a the cost of a toy in a Cracker Jacks box. If choosing between the two it's a no brainer to give a stronger look to Ruckus. Just don't let them convince you that you need less APs to get coverage as a method of lowering their cost. That's their sales strategy and is FUD.

Meraki MDM is free and works well. Airwatch is worth looking into as an affordable enterprise grade alternative. There's only so many hooks you can use so most MDM products will have the same features.

Todd Lammle and Wendell Odom books are great. Jeremy Cioara from CBTNuggets also has some great resources and explains the material in ways that is typically very easy to understand. You're asking for a broad range of knowledge, in order to configure this stuff you really need a background in networking. CCNA study materials are probably your best bet, even if you don't use Cisco equipment. One thing I noticed from your post is that you didn't mention the use of a firewall. That may be something you would want to include in your network upgrade if you don't have one already and this site has a direct link to the internet.