Deployment Dependencies

Before the first access point is turned on, the first cable laid, or the first client device enabled, you need to be aware of some fundamental deployment dependencies. Your team may have finalized the architecture and technical design, but you should ensure that centralized infrastructure and system-wide policies are installed and implemented before the installation of the access points begins. You do not want engineers turning up at a site to install access points or distribute clients before the site is ready for them. We recommended that you perform at a minimum the following preparatory steps.

Change Management Process

Most large enterprises already have a Change Management process defined. The use of Change Management will ensure that your deployment plans, or indeed the underlying architecture, does not change during the implementation phase. Managing change and reducing "operational churn" reduce the program costs and therefore help ensure a successful deployment.

Note

Change Management

The objective of change management is to execute changes economically and in a timely manner while mitigating their risk and impact. Every carefully managed enterprise project and services should have a change management process defined. This ensures changes do not happen on a haphazard or uncontrolled manner.

This is achieved by the following formal steps. First, all requests for change are documented, reviewed, and approved. Second, changes are appropriately developed and tested before and after implementation. Third, implementation plans are documented, communicated, and coordinated between change implementers and relevant end-users.

The effectiveness and benefits of change management include

Early detection of risks
Fewer service quality problems
Information on planned and implemented changes
Increased service stability leading to increased productivity
Ability to revert to prechange state
Improved management of high amount of change

Put the Supporting Infrastructure in Place

Ensure that sufficient wired and supporting infrastructure is in place. This includes providing sufficient wired Ethernet ports for each access point and confirming that you have sufficient power capacity (whether AC sockets or Power over Ethernet ports on your switches). Additionally, if your architecture calls for a dedicated wireless switch or WLAN controller, ensure that your existing infrastructure supports it or any additional integration testing, equipment, and design has been completed.

Provision AAA Capabilities

Ensure that the AAA architecture is in place, tested, and functioning. It's important not to end up testing your AAA system on the first day of production services. Stress test the AAA solution. Depending upon the size of your client base and the mobility, you may see a dramatic increase in the number of authentication transactions. Be sure that your AAA servers are capable of supporting the additional load created by roaming clients. You may also be deploying your WLAN across geographically disparate locations, either nationally or internationally. Investigate whether you need to place AAA servers at other locations to ensure service stability or to avoid WAN congestion.

Define Security Standards and Policies

Make sure your security standards and policies are defined, published, and clearly communicated to your users. For example, you may have decided that wireless networking hardware is prohibited unless installed by your IT department, yet discover that certain departments or workgroups are already using self-installed networks when your deployment team arrives onsite. Besides being a security liability equivalent to rogue access points, this will cause problems during the site survey and disruption to the productivity of the workgroup involved. It is important that you share your plans, policies, and procedures before you begin because this will avoid unnecessary confusion among your user community.

The following sections clarify the differences among security standards, policies, and procedures.

Security Standards

Security standards industrywide and are defined by external bodies such as IEEE or the WiFi Alliance. 802.11i is an example of an IEEE standard. WPA (WiFi Protected Access) is an example of a WiFi Alliance standard. Security standards define technical specifics on how security controls are applied or implemented by wireless hardware, and sometimes how compliant devices must interact and operate with each other.

Security Policies

Security policies are the management, business, and technical decisions that your enterprise has made regarding wireless security. For example, you may have a wireless security policy that states that only your IT staff members are permitted to install access points. You may have decided that only devices that support WPA (a cross-industry WLAN standard) are allowed on your network; that would be a policy defining what standard is to be used on your network.

Security Procedures

Wireless security procedures are business processes that dictate how your staff members handle and deal with specific events. It is no use defining what standards should be used or restricting what devices are permitted unless your staff members know what to do when these standards and polices are contravened. Wireless security procedures can effectively be thought of as "operating instructions" on what your staff should do in certain circumstances.

Put the Support Plan in Place

Make sure you have clearly defined a support plan and that your IT staff understands it. This defines how your user population is supported, who they call, how their questions are handled, and so on. For example, your support plan should detail who staff call with problems (usually a helpdesk of some sort), what level of technical expertise the helpdesk should have, how they handle cases they cannot answer, and to whom they escalate to. It effectively should define who shall provide frontline, second line, and third line escalated support; this is also known as Tier 1, Tier 2, and Tier 3 support.

As you deploy your solution, you will almost certainly enable each site in turn. The initial period of user adoption and familiarization is perhaps the most turbulent and support-intensive in any solution lifecycle. Your users will undoubtedly require and request support, training, perhaps electronic learning, and maybe even simple presentations on the benefits of the new technology. Many deployments have failed or resulted in poorer than expected adoption simply because the IT department installed the infrastructure and "walked away." Your support staff, whether the IT department itself or a dedicated support desk, must be aware of the project, appropriately trained, and capable of resolving the most common errors.

Put the Communication Plan in Place

Always think about the customers. In this case, the customers are the users of the WLAN. Users like to be kept informed and are more willing to embrace a technology or solution if they understand both its benefits and limitations. Make your users aware of what the WLAN solution provides, when it shall be made available at their sites, how to use it, and where to turn for help. Not only will it help market the WLAN to your end users, but it will also ensure that they understand the benefits and goals of the solution. User satisfaction is an often overlooked but very important factor in any successful technology solution.

Make sure your users are aware of the deployment schedule. Not only will this help manage their expectations, but it also will help avoid constant support calls requesting service and dissatisfaction on the progress of implementation. It may even help avoid or reduce rogue deployments.

Explain the basics of WLAN security and networking concepts. Many users will be vaguely aware of security concerns associated with wireless. Some will have no experience with the technology and may be skeptical of its benefits. Others may be early adopters who have already embraced the technology. By sitting down and sharing a broadly based communication plan, you can inform your users of the project's goals, who and what will be supported, and when they can expect service at their location. Explain the basics of WLAN security and networking concepts. Users like to be kept informed and are more willing to embrace a technology or solution if they understand both its benefits and limitations.

Clearly state what is permitted and what is not. Then explain why. Most users will modify their behavior if they fully understand the repercussions of their actions and will gladly conform to security policies if they understand that they are based upon sound business reasons and not simply diktats from a shadowy IT or Information Security department.

With the advent of cheap access points, the likelihood of self-installed, rogue deployments has increased dramatically. Users should be made aware of the risks associated with non-IT endorsed solutions, the risks of enabling ad-hoc wireless networking, why enabling both wired and wireless interfaces on their computer at the same time is not recommended, and so on. You should also consider going one step further and offering your staff basic instructions or "best practices" on how to securely configure their own home wireless networks.

Develop and publish FAQ (Frequently Asked Questions) sheets. Identify what you believe will be the top 10 or 20 questions from users and make this available via e-mail, a company internal website, or even in hardcopy during client distribution.

Finally, you may also wish to develop electronic learning collateral. The larger your corporation and deployment, the more likely you will already have an official internal training and learning service available. Even if you do not have such a division, producing simple and relevant material is worth the time and effort. You may consider creating a solution web page or "dashboard" on an internal corporate intranet. This would be an ideal location for communication and training collateral and somewhere to refer interested users for project updates and schedules.