Enterprise-class Wi-Fi for the SMB: 15 best practices from the field

Pitiful Wi-Fi implementation is so prevalent these days that people take it for granted. From the hotels we visit, to the cafes we frequent, down to the offices we call home 9-5 daily. And that's unfortunate, because when done right, Wi-Fi is an enabler for connecting us wherever, whenever.

Why can't most organizations get Wi-Fi right?

It comes down to this simple fact: Wi-Fi is more of an art than an exact science. Every vendor is guilty of pushing their own FUD around the market, enticing purchases for gear that either is either chock full of features a client will never need, or underpowered for the environment they're intended to serve. Add in channel mismapping, SSID bloat, and click-thru portal hell, and you've got a recipe for what makes Wi-Fi stink.

While it's still hard to compare the entire market's offerings apples to apples, there are some battle tested best practices which have stood the test of time.

All of the following industry guidelines are gleaned from a position of evaluating and installing Wi-Fi gear since the heyday of 802.11b. We're overhauling or implementing new Wi-Fi setups for our clients every month. And regardless of what gear you end up choosing for your network, the same common sense planning approaches apply to any Wi-Fi network in the planning stages.

Is there such a thing as enterprise-class Wi-Fi for the SMB? Absolutely. My company FireLogic sets up such networks all the time using these best practices.

15. Ditch the Portal: Use SSID Scheduling and WPA2 Instead

Many organizations have a business and technical need to keep "squatters" in check. But more often than not, they tend to tarnish the right intentions with the wrong methodology. And if you've used any form of public corporate Wi-Fi in the last decade, you've encountered our nagging little friend: the portal.

While portals are commonly used as a stopgap to help prevent squatters and advertise Wi-Fi ToS for an organization, I have little love for these bastions of last-generation Wi-Fi planning. Why?

They are rarely mobile optimized, and even tougher to navigate on non-computer devices like traditional Kindles or game consoles/set-top boxes.

The local library in my hometown sticks out in my mind as being a poster boy example for the problem with portals. On laptops, their click-thru loads just fine. But on tablets and mobile phones, getting the acceptance checkbox to behave properly is part battle of patience; part finesse of the finger to zoom in exactly right. For elderly users, this is downright painful on mobile devices when poor vision is added to the mix.

Business-class, modern Wi-Fi equipment has functionality called SSID Scheduling (or availability) which stops abuse after hours. In short, the SSIDs of your choice can be automatically disabled during hours when no one should be accessing them anyway. Meraki's MR access points which we use heavily allow us to customize different schedules per-day, per-SSID to match business needs.

Couple SSID Scheduling with a simple WPA2 password that gets changed every quarter for guest-facing SSIDs, and you've got the intended results of a captive portal without the awkward limitations that accompany them.

14. Use More Access Points, Not Stronger Antennas

There is a common misconception among SMB owners that singular high-powered routers or WAPs are most effective in blanketing a large office with good quality Wi-Fi. While this may be a cost effective compromise that potentially works in some scenarios, it's NOT in any way the answer in blanketing large spaces with Wi-Fi; especially in high-density situations.

The biggest argument in favor of the "more WAPs" approach comes down to physical limitations on everyone's favorite Wi-Fi clients: mobile devices. As opposed to laptops, which have more plentiful antennas and higher powered Wi-Fi chips, tablets and smartphones battle with the realities of having to optimize for battery life.

And herein lies the misconception with these over-powered routers and WAPs. Just because you can get a powerful broadcast out over a long distance to a small client like a phone, doesn't mean the other side can respond in tow. It's in essence like someone shouting out to you from afar but you don't have the vocal power to respond back to them. It's an asymmetrical broadcast situation which is heavily weighted against the mobile devices.

The real world symptoms of such situations are seen all the time in poorly designed office Wi-Fi configurations. Clients show as having full or near full strength signal, but upon inspection, packet loss is wreaking havoc on their transmissions.

For smaller rollouts, single high-power WAPs may be OK -- and we go this route in some situations. But larger locations, both vertically and laterally in size, will do better with more access points that are strategically placed to balance the client load.

One final caveat in favor of more WAPs is the fact that each access point has a theoretical limit to how many devices it can support. Most enterprise Wi-Fi manufacturers claim this to be in the 50-75 device range, perhaps slightly higher, but I use 50 as a simple realistic figure. This ensures we are not placing too much reliance on a single WAP in situations where Wi-Fi performance is critical for areas with high concentrations of users.

13. WAP Placement: Mount 'Em High, In the Open

It goes without saying that your Wi-Fi signals are only as good their ability to traverse the open air. Obtrusions like walls, floors, metal cabinets, and even lower-lying Wi-Fi interference sources such as microwaves all degrade Wi-Fi signals to different degrees.

Every organization has different aesthetic and ethernet-port placement limitations to account for when placing WAPs. But when possible, a few simple guidelines to follow:

1. Mount as high as you can. Ceilings are best, with wall mounting close to ceilings being second best.
2. Keep WAPs as much "in the open" as you can. Don't hide them in cabinets or above suspended ceilings, when possible. Every extra layer of obstruction is one more barrier that is beating down your signal strength.

A lot of companies we get called in by complain of Wi-Fi coverage problems even when their WAP counts are good. But their Wi-Fi planning downfall was concealing WAPs in obscure locations close to the ground, and signal was being eaten up by traditional enemies of Wi-Fi like concrete or metal-studded walls.

Hang 'em high. That's the goal for the best Wi-Fi coverage possible. We always prefer ceiling mounting access points where allowed. This not only provides nice blanketing of large areas with excellent open airspace, but also ensures no obstructions are placed in front of WAPs to degrade signal. (Image Source)

Most business class Wi-Fi gear has a good balance on the performance and aesthetics front. Our favorite, Meraki's MR line, has clean-cut matte white designs, and others, like Ubiquiti's Unifi units, follow suit. Manufacturers are trying to create appealing designs that don't have to be concealed in closets anymore.

12. Only Use 20MHz Channel Width in High-Density Scenarios

Channel bonding technology, or 40MHz channel width as it's also called, is a great idea in theory, but it has numerous drawbacks in the real world. It was designed to allow 802.11N and 802.11AC Wi-Fi to achieve the high throughput figures manufacturers love to advertise. But it causes additional inter-channel interference and doesn't "play fair" with neighbors, per se.

Without getting too technical, channel bonding above the standard 20MHz standard channel width takes two or more channels and binds them into one fat channel. The upside is doubled (or greater) bandwidth per-client, allowing for faster transfers of extremely large files.

But the true justification for using fat channels is short sighted in most scenarios. First off, a large majority of users don't have a need to transfer massive files over the LAN via Wi-Fi. Keep in mind that fat channels ONLY have a benefit for local transfers -- WAN speeds rarely touch the 150Mbps+ range yet, so you are almost always limited by the WAN pipe, NOT the LAN pipe.

And secondly, for high-bandwidth scenarios, it's usually better to run hardwire ethernet, which is much better at sustaining near gigabit speeds than Wi-Fi ever can. If you have a business need to transfer large files on a consistent basis, hardwiring these machines is a much better investment and will save time as well, since file transfers will still be much faster for the foreseeable future.

The bigger issue with fat channels is that they eat up critical airspace with "bloated" signals compared to standard 20MHz channels. Not only does this reduce airspace for natural Wi-Fi neighbors you may have, but it also reduces the airspace for high density situations like conference halls or public cafes where client counts bloat quickly and easily. Giving so much airspace to each individual client in high-density situations causes performance headaches for everyone in the end.

Stick with 20MHz bandwidth, play fair, and allow your Wi-Fi deployment to serve the most number of clients possible. Fat channels are rarely, if ever, necessary in most Wi-Fi deployments, and we never roll them out.

11. Future Proof: Run Dual Ethernet Lines Per New WAP

For most situations where new WAPs are being installed, we're running dual ethernet drops per location. While there is little on the market yet that takes advantage of dual lines, numerous experts are pointing to 802.11ac Wave Two and beyond as requiring the use of dual lines at some point.

The reason for this is due to the increased baseline bandwidth that 802.11ac Wave Two and beyond will be pushing in deployments. Once we start touching closer to the 1Gbps barrier and higher, a single ethernet cable won't be able to deliver both the power and data necessary. While a few forward-thinkers believe that 10Gbps lines may be necessary at some point, most (including myself) see this as wishful thinking and quite unrealistic.

The cost of running an extra CAT6 line to each new WAP location is marginally more expensive. Compared to the cost of having electricians or LV wiring folks engage in a separate project to run extra lines later, putting in the dual Cat6 lines now is realistic and ideal.

When 802.11ac Wave Two (or later) starts requiring dedicated PoE and Data lines, you'll be ready for an easy change out of your WAP equipment.

10. Don't Forget the Switches: Go Gigabit and PoE

Some businesses will plan on spending oodles for advanced access points, but will skimp on the switches for the backbone. This is a recipe for disaster. Lower end, or generic, switching equipment has software quality to match, and thus leads to hard-to-track issues that eat up consulting labor time or prolonged downtime -- or both.

There's no need to overspend on the highest end switches out there, either. If budgets allow, going with Meraki's cloud managed switches are ideal to keep control and oversight centralized, but we routinely opt for lower cost Cisco Small Business or NETGEAR Prosafe products. Both alternatives come with lifetime warranties on the equipment just like Meraki's devices, minus the rock-solid 24/7 telephone engineering support.

Lastly, while it's attractive to stick to switches that lack PoE across the board with their low price tags, the pains this introduces when it comes to powering WAPs isn't worth the small cost savings. Remember, if you are skipping on using PoE to push power over data lines to WAPs, you will need to accommodate for power outlets near every single WAP being deployed. That gets expensive fast.

Add in the headaches from potential AC adapters getting unplugged from outlets, or having issues/dying, and you can see why this is a flawed approach and not recommended. The same advice goes for deploying VoIP phones, which I covered at length in a separate best practices guide.

When it comes to switches, stick to full gigabit for all ports, and get units that have as many ports pushing PoE as possible. You'll be glad you did.

9. Get Access Points With Bandwidth Limit Controls

This is another area where consumer line routers and access points just don't hold their own. Bandwidth logic, or bandwidth limiting as it may be called, is the capacity for access points to literally play traffic cop against hungry client devices. Seeing as most companies cannot afford or don't have access to Google Fiber-class WAN connections yet, we need to ensure clients are playing fairly on the wire.

The thinking behind this feature is to cap the amount of upstream/downstream bandwidth that any single client can suck up. Without controls -- which is what most consumer routers are stuck with -- your internet connection can quickly get drowned by just a handful of hogs downloading large files or using torrent services.

Meraki's WAPs and firewalls have native bandwidth limit controls, as shown above. Rate limiting on individual SSIDs, or across your whole network, is made dirt easy. For high density client environments, this is a downright requirement.

On almost every deployment we do with Meraki access points, we enable Bandwidth Limits with asymmetric caps on download/upload, reflective of the lopsided nature of most symmetrical WAN pipes these days. For most regular offices with decent pipes, I place caps onto guest Wi-Fi for about 500Kbps down / 150Kbps up, with slight adjustments per situation. We can make the caps for staff Wi-Fi much larger, or remove them altogether if necessary.

In high density Wi-Fi deployments, like a banquet/conference hall we just deployed recently, we bring this cap down lower into the 300Kbps down / 90Kbps up range.

If a Meraki firewall is deployed in the environment as well, we can extend these bandwidth caps to all wired devices too. This is a fantastic, easy to manage feature which allows us to ink the most out of smaller WAN pipes instead of purchasing larger WAN lines, which some owners mistakenly believe is the only way out of bandwidth-starved situations.

8. A Word on DHCP Scopes and Lease Times

When we plan out for high density Wi-Fi deployments at FireLogic, two things which are always kept in consideration are the number of DHCP scopes we will be advertising, along with the lease times for client devices. Standard SOHO routers offer single scopes in the /24 range which equates to 254 client addresses. After you trim out the addresses lost to static devices, staff computers, and other special needs, you can end up with very little left to dole out for guest devices, especially when you are hosting a lot of guests.

What approach you take with higher density deployments depends on the equipment you have to work with. If you're sticking with Meraki WAPs, then you can easily enable SSIDs to use Meraki's NAT DHCP service, which opens up a subnet in the 10.0.0.0/8 scope and offers an innumerable amount of address space for clients. This also means you don't have to manage your own DHCP server for large loads and worrying about associated downtime if things go awry.

But you don't always have situations that allow for Meraki's nice gear. When we setup a banquet hall a few months back that wanted to host upwards of 500-700 devices at any given time during business conferences, budgetary constraints on the client's end forced us to use standalone Engenius access points, which meant we had to manually configure and push unique DHCP scopes for various VLANs off a Meraki MX100 firewall.

The situation ended up working out, as we created half a dozen dedicated DHCP scope ranges for pre-planned sets of APs to use in the /24 subnet range. In the end it worked out, but it required some decent up front planning to determine which WAPs would run off which VLAN/subnet combos, to ensure that we didn't run out of addresses. But ideally, I'd rather not play with this as guest Wi-Fi works great off Meraki NAT DHCP in other setups including our own main office.

One last thing to keep in mind if you are manually planning VLAN/subnet separation between WAPs is that lease time should be carefully considered. In a /24 traditional scope with 254 addresses, using a standard 24 hour (or week) lease may bring a conference or other high density Wi-Fi situation to its knees unexpectedly; especially where clients may be moving large numbers of devices between conference hall rooms constantly throughout the course of a day.

7. Use Band Steering To Push Devices to 5GHz

The 2.4GHz spectrum of Wi-Fi is drowning with problems these days. The biggest issue comes down to how many competing access points are fighting for the same limited, non-overlapping channel airspace. In the late 1990's when Wi-Fi was just becoming a reality, no one thought airspace would become so contested and oversaturated.

But we're at the point where 2.4GHz is so congested that it should be pinned up as a last resort for legacy devices -- with newer, more capable ones riding on 5GHz lanes when and where possible.

5GHz brings along the nicety that it offers up 23 non-overlapping channels, which means interference from competing access points is far less of a problem. It also means that we can pack more devices in the same airspace compared to 2.4GHz.

To ensure we are providing the best possible experience for devices, Band Steering is something we deploy on any WAPs that support it. For Meraki's MR series of WAPs, it's an easy switch to flip on a per-SSID basis. Other devices also carry this feature. In high density deployments like conference halls or hotels, band steering should be a clear requirement for your new equipment.

Otherwise, leaving the decision up to non-intelligent devices will cause quick overuse of the 2.4GHz spectrum and in turn, lead to less than optimal results for all client devices.

6. What Kind of WAN Pipe Do You Need? An Easy Way to Calculate

I've written about bandwidth estimating before, and have usually relegated the practice as a part science, and part guessing game. Luckily, there is an easier way now to estimate your bandwidth needs for a WAN pipe, especially if you are enforcing bandwidth limits on your SSIDs.

The calculation you can use to estimate your backhaul (or WAN needs) is fairly simple in this scenario.

1. Take your download / upload limits per client (as discussed earlier).
2. Multiply each figure by the number of clients you wish to support.
3. Your end results should represent the rough WAN bandwidth needed to support a "perfect world" situation where everyone is eating the max pipeline given to them.

So, in my 500Kbps / 150Kbps per client limit example above, if I wanted to allow for 25 devices on my network, I'd need a pipe the size of:

• Download: 0.5Mbps x 25 = 12.5Mbps Down
• Upload: 0.15Mbps x 25 = 3.75Mbps Up

And that's it. Keep in mind these estimations are assuming that every client is needing to use 100% of their given piece of the pie at all times. This assumption is clearly not how situations play out in the real world. The numbers are more so meant to be guidelines for how to size your WAN pipe needs; NOT to give you exact figures in any way.

Depending on your scenario, Wi-Fi clients may be needing less bandwidth depending on the time of day, type of device being used, and type of application being utilized over the pipe. You can take your planning from there in fine tuning your WAN size.

Most new offices we are setting up these days are getting dual cable-coax business lines, or a hybrid with coax/fiber, coax/metro ethernet, or another viable combination. Keep in mind that firewalls like Meraki's MX-series units can perform load balancing which can virtually offer up bandwidth from two separate pipes to endpoint devices. Don't overspend on a single fat pipe if you can get away with more affordable dual pipes.

5. Use Common SSIDs Across WAPs with Roaming Enabled

Too many poor deployments we've come across have had every kind of SSID configuration under the sun. The worst offenders are the ones where each WAP is broadcasting its own unique SSID. And if dual band 2.4/5GHz is being used, they go a step further and separate the SSIDs per band, per staff/guest network, leading to potentially 4 or more SSIDs coming off each WAP.

This is obnoxiously difficult to manage, and creates a nightmare for devices that need to roam a location with multiple WAPs.

Avoid that colossal mess. Modern business class access points are built to allow for seamless roaming between WAPs on the same SSID, as long as coverage zones are slightly overlapping without dead spots. In homes and offices where we deploy Meraki, testing has shown that roaming across a single SSID between WAPs works extremely well as long as channel mapping is set to auto or is properly manually mapped.

Best practice for a multi-WAP office is to always use matching sets of universal SSIDs across WAPs. This ensures easy roaming for clients, and reduces the number of WPA2 keys people have to connect to. Many enterprise class WAPs, like Meraki and Unifi units, allow for seamless roaming as well. (Image Source: No Strings Attached Show)

Best practices for business Wi-Fi these days is to use a single private SSID, a single guest SSID, and have these matching SSIDs cover both the 2.4 and 5GHz spectrums alike. Band Steering comes into play and allows clients that work on 5GHz move to that spectrum, with legacy devices sticking on 2.4GHz as needed.

4. Always Use Separate Staff, Guest Wi-Fi SSIDs

Any business class WAP worth its weight allows for the creation of a private, staff SSID where clients can access internal network resources; and a secondary, guest-only Wi-Fi SSID that maps clients to a different VLAN or standalone DHCP scope, like Meraki's included NAT DHCP service. The added benefit of the latter feature is that isolation is enabled by default, which means potential nefarious guests cannot interact with other devices on the same subnet even if they wanted to.

Offices that covered by HIPAA regulations should note that using a single Wi-Fi network for guests and staff is a BIG obvious violation, and will easily fail risk assessments and any subsequent HHS audit, until staff/guest Wi-Fi separation is enabled. This is because HIPAA rules place "reasonable expectations" on offices to keep devices storing/accessing PHI separated from outside guests.

I went into some more detail on what HIPAA covered entities need to worry about on a separate article.

3. You Don't Need a Hardware Controller-Based Solution

There is a lot of FUD being passed along by hardware vendors who have natural vested interests in peddling their expensive hardware controllers. Ruckus, Cisco (non-Meraki, first party), Meru to name just a few, are all guilty of this. You should be advised that we've tested most of the hardware controller-based solutions out there, along with many software/cloud controller-based products.

Hint hint: the days of needing a hardware controller for awesome Wi-Fi are gone.

The good news? Software or cloud controllers work extremely well today -- so well, that we don't go with hardware controller-based solutions any longer. The hardware/licensing costs for the controllers alone, plus the added installation costs, are not worth it in my eyes. They don't provide any value-add over that of similar cloud-based controller solutions; don't perform any better; and are just one more item that can break down on a client's network.

We started off with, and still deploy on a limited basis, Unifi access points. This is the low cost leader when it comes to a software controller, but there are two main limitations that are not apparent up front. First, Unifi access points rely on a software controller that must be loaded and running on a server of some sort. While it doesn't need much horsepower, the Unifi software is notoriously plagued by its reliance on Java; as such, we've also seen configurations get corrupted between Java updates or Unifi controller upgrades.

Secondly, if you are planning on managing multiple sites with a single Unifi controller, the platform still has a tough time managing WAPs in different subnets. The functionality is advertised as being fully supported, but in reality, it is buggy at best, with access points on non-native subnets getting lost for periods at a time.

Hardware controllers introduce increased up-front product costs, long term licensing costs, labor costs, and one more link in the chain that can cause downtime. Going with a software, or cloud-based, controller system brings the flexibility of being able to stay up to date at all times, and manage your system from anywhere. Unifi APs come with a free software controller, and our favorite Meraki provides a cloud-based controller.

Our company prefers the 100% cloud based solution which Meraki offers. We can control all access points for a single given client's sites in a single web base dashboard, and likewise, we can access all our clients' Meraki networks from a simple dropdown menu on our MSP dashboard. It's fast, simple, and is always up to date. We don't need to maintain a server of our own, either, and clients also get access to the dashboard if they want to be hands on.

Whatever path you decide to go down, be sure to do your homework. While there is nothing wrong a hardware controller solution, the days where this was required to gain the bells/whistles that enterprise Wi-Fi has to offer are long gone. Software controlled (or cloud based) solutions like Meraki or Unifi are just as good, and in many cases better, than the more expensive hardware-based controller routes, even for the biggest rollouts.

2. Channels Matter: Use Auto-RF Assigning WAPs, or Do it By Hand

The crazy channel usage I've seen in the wild still astonishes me. Supposed "corporate" Wi-Fi networks that have APs with channels outside of the 1/6/11 range, or that are overlapping channels in close proximities. Don't fall victim to Wi-Fi hell by making the same mistakes others have.

There are some common guidelines that apply to any Wi-Fi rollout, small or large.

• Remember the 1/6/11 rule for 2.4GHz. As shown in the graphic below, WAPs being used on the 2.4GHz spectrum should ONLY be using channels 1, 6, or 11. Anything else in between is considered an overlapping channel which will lead to reduced performance due to increased interference. Just because others mistakenly assign channels like 4 or 8 doesn't mean you should.
• Use power output tuning to reduce client bleed between WAPs. In a multi-WAP environment, you want clients connecting to the closest access point to their current location. Power settings that cause signals to overlap too heavily between WAPs causes client confusion and does nothing to ensure maximum end-user performance. Most business class WAPs allow for reducing transmission power so that there is small but manageable signal overlap between them.
• Use Auto-RF when possible. There are a lot of side benefits to auto-assignment of channels besides reducing your manual legwork during setup. They are useful in allowing for dynamic reassignment of channels if misc sources of interference crop up in your location. This is especially useful in areas like highrises or high-density residential neighborhoods -- where the number of competing WAP signals can change significantly on a monthly or even weekly basis. Auto RF ensures your WAPs are always working with an optimal channel layout per current conditions.

In short, Auto RF assignment is king these days as Wi-Fi is becoming more prevalent en masse. While we do our best to plan out channel assignment during installation, you have zero control over what your neighbors do over the long haul. Having access points that can rework their channels on the fly is key to sustaining an optimal Wi-Fi environment for your organization.

A solid Wi-Fi network is only as good as its channel map. Either leave the heavy lifting to automated logic, like Meraki's Auto RF feature on their MR WAPs, or do it yourself. While the 5GHz spectrum has plenty of non-overlapping channels to choose from, the 2.4GHz spectrum is rather landlocked with only channels 1, 6, 11 being considered kosher for usage. The above sample WAP layout shows how an office should be configured with overlapping WAPs in both spectrums. (Image Source: Cisco)

1. Great Wi-Fi Doesn't Have to Break the Bank

While you don't have to go broke on the most expensive wireless gear to achieve awesome Wi-Fi, it's also not recommended to buy the cheapest gear on the block. I've been installing and troubleshooting Wi-Fi in some capacity for the greater part of the last decade, and have put my hands on most of the common gear available on the market.

I will spare many of the "hot air" pushers on the Wi-Fi market some shame and not point them out by name. Instead, I'd rather provide recommendations on the equipment we have consistently seen work well in customer scenarios.

• Meraki MR-series WAPs: By far our new favorite, and considered our company's gold standard for installs that require excellent performance and high levels of uptime. Meraki is best known for providing equipment that is all managed under a single unified cloud management interface. Their WAPs have all of the best features I discussed above, and come in various flavors for indoor/outdoor capacities and client load requirements. We also use their firewalls for most of our client sites, and our own office -- I wrote about their firewall line separately some months back. Meraki's premium Wi-Fi gear comes at a matching price, which includes necessary licensing for the life of the product. But we find the cost worth the price of entry.
• Ubiquiti Unifi: These used to our favorite WAPs until we ran into some of their limitations, like a buggy software controller and no telephone support. They are still an excellent close second pick however. Our favorite models for recommendation are the Unifi Pro and Unifi AC, the latter which is merely a Pro with the added benefit of AC Wi-Fi. The relative price point of Unifi is considerably lower than that of Meraki's hardware, namely because Ubiquiti doesn't require any kind of licensing. If you are OK with rolling your own support and can forego the centralized Meraki cloud dashboard, then Unifi may be a great low priced solution with great performance.
• EnGenius WAPs: A solid pick that we still use in some situations are units by EnGenius. This company got its claim to fame in the Wi-Fi arena through its high-performance antenna technology that pumps quite the RF for a fairly low price point. Their units are slightly lower priced, on average, than Unifi's upper end hardware, but have until recently never had a good software controller for management. However, these devices are still excellent bang for the buck if you are looking for access points that are like tanks and you don't mind managing APs individually. We use these as fillers for single WAP situations where cost is a heavy factor for clients.

What's the pattern among all of the WAP makers we recommended above? None of them require a dedicated hardware controller. That's right -- we're considering those days long over. We've helped on large corporate installs, namely with Meraki gear, and the lack of a hardware controller has never been a detriment for us.

Don't be afraid to evaluate gear before installation. Various vendors are willing to provide loaner or demo gear from the likes of Unifi or EnGenius, and Meraki offers weekly webinars where they hand out a free access point just for attending -- it's honestly the way we got hooked on their awesome gear.

Above all, keep this in mind: paying a little more up front for quality Wi-Fi gear usually results in less management headache, more uptime, and much happier end users in the long haul. After literally over a hundred business and residential Wi-Fi installations, I can safely say that we have by and far had the least trouble with well built business class Wi-Fi equipment.

Some clients that had us roll out Wi-Fi on the dirt cheap were frustrated when we had to come and overhaul their installs just a few years out because the implementations didn't meet their longer term needs. No Wi-Fi install will last an eternity; but you can help keep upgrade cycles in the 6-8 year range by planning out for the right gear up front.

Further Reading

A lot of the best practices I referred to are cross-referenced in other good reads for those looking to deploy rock-solid new Wi-Fi networks. The bigger the client load, and greater the distance your deployment needs to span, the more important it is to ensure you are properly planning your rollout.

Meraki has an excellent whitepaper which goes over many of the items you should be planning to implement, especially in high density deployments. Aerohive, a Meraki competitor in the cloud-managed Wi-Fi space, has a similar whitepaper that goes over some related concepts.

A great infographic-style guide was published by ekahau which goes over a lot of great topics, including some good coverage on site survey planning.

And finally, Aruba published a lengthy whitepaper with some further considerations around highly reliable business Wi-Fi.

Photo credit: Shutter_M / Shutterstock

Derrick Wlodarz is an IT Specialist who owns Park Ridge, IL (USA) based technology consulting & service company FireLogic, with over eight+ years of IT experience in the private and public sectors. He holds numerous technical credentials from Microsoft, Google, and CompTIA and specializes in consulting customers on growing hot technologies such as Office 365, Google Apps, cloud-hosted VoIP, among others. Derrick is an active member of CompTIA's Subject Matter Expert Technical Advisory Council that shapes the future of CompTIA exams across the world. You can reach him at derrick at wlodarz dot net.