This document provides troubleshooting procedures for basic problems
with the Cisco Wireless Control System (WCS).
Cisco recommends that you have knowledge of these topics:
This document is not restricted to specific software and hardware
Technical Tips Conventions for more information on document
If you experience problems when you try to install WCS, first check to
see if the system on which you plan to install WCS meets the minimum system
This is the prerequisite checklist to use before you install Cisco WCS:
Check if the system on which you are about to install the Cisco WCS
meets the necessary hardware and software requirements for Cisco WCS. For
information on the minimum software and hardware requirements for the
installation of the WCS, refer to the
WCS Configuration Guide, Release 4.0.
Ensure that you have updated your system with the necessary critical
updates and service packs. Refer to the latest release notes for information on
the service packs and patches required for correct operation of the WCS.
Note: Before you install the WCS on Linux, a full install of Red Hat
Linux is required.
Backup the existing WCS database. Refer to
Up the WCS Database for information on how to perform a Windows
Uninstall the older version of the WCS. Refer to
Cisco WCS for information on how to perform an uninstall.
Once you ensure that you have the prerequisites, you can install the
WCS. Refer to
WCS for Windows for information on how to install Cisco WCS for
Note: WCS only runs on 32-bit Windows; 64-bit operating system
installations are not supported.
WCS for Linux for information on how to install the WCS on Linux.
When you install WCS to manage the WLCs, ensure that the WCS and WLC
versions are compatible. This information is available in the release notes of
the WCS version that you install.
For example, Cisco WCS 184.108.40.206 supports management of these wireless
This information is available in this document:
Notes for Cisco Wireless Control System 220.127.116.11 for Windows or Linux
If you use incompatible versions of WCS and WLC, you will not be able
add your WLCs to the WCS.
This occurs because WCS is supported only in Windows 2003 with English
or Japanese versions. If you use operating systems translated to other
languages, it causes WCS to fail after installation. In order to avoid this,
use WCS on Windows 2003 English or Japanese versions.
WCS and location appliances do not support international characters in
general. If you use non-English characters for map names, asset information,
etc., it can generate display errors (wrong characters displayed) and errors on
Sometimes we are not able to start WCS and open its web interface. Even
if you try to open WCS with the ".exe" file in the WCS\bin\ folder, it can
fail. This message can display while you try to start WCS.
Checking for Port 21 availability... OK
Checking for Port 8456 availability... OK
Checking for Port 8457 availability... OK
Starting database server ...
The Nms_Server service is starting........
The Nms_Server service could not be started.
The service did not report an error.
More help is available by typing NET HELPMSG 3534.
Failed to start WCS server.
One possible reason for this issue can be the bug
(registered customers only)
As per this bug, WCS database can fail to start because of corrupted
log files. In order to resolve this issue, go to the subdirectory
standalone through the path
webnms\eval_kit\standalone within WCS directory. In that
subdirectory, find the highest numbered sol####.log file,
where #### is a four digit number. Delete it and reboot the
server. Attempt to start WCS. If WCS does not start, repeat for the next
sol###.log file, and so on. This workaround will resolve the issue.
If the WCS does not function as expected, first check the status of the
WCS. Complete these steps in order to check the status of the WCS when it is
installed as a Windows application or Windows service. You can check the status
at any time.
Log into the system as administrator.
Perform one of these actions:
Go to the Windows Start menu and choose Programs >
Wireless Control System > WCSStatus.
From the command prompt, navigate to the WCS installation
directory (C:\Program Files\WCS32\bin) and enter WCSAdmin
The WCSAdmin window appears and displays messages that indicate
the status of the WCS:
Click Close in order to close the WCSAdmin
If the WCS is installed on a Linux system, complete these steps in
order to check the status of the WCS:
Log into the system as root.
Use the Linux CLI in order to perform one of these tasks:
Navigate to the /opt/WCS32 directory (or the
directory chosen during installation) and enter ./WCSStatus.
Navigate to the /opt/WCS32/bin directory and
enter WCSAdmin status.
The CLI displays messages that indicate the status of the WCS.
When a new WLC is added to the WCS, ensure that the SNMP version
configured on the controller matches with the SNMP version on the WCS. If the
versions do not match, the WCS does not detect the controller and this error
appears on the WCS.
No response from device, check SNMP.
Also ensure that SNMP write access privilege is enabled on the
controller. If you enter read-only access parameters then the controller is
added to the WCS, but the WCS is not able to modify the configuration on the
In summary, check these items if there is a problem adding the
controller to the WCS:
The controller service port IP address might be set incorrectly.
Check the service port setting on the controller.
The WCS might not be able to contact the controller. Make sure that
you can ping the controller from the WCS server.
The SNMP settings on the controller might not match the SNMP settings
that you entered in the WCS. Make sure that the SNMP settings configured on the
controller match the settings that you entered in the WCS.
When you upgrade the WCS to the latest version, you need a license
from Cisco. If your WCS is not licensed, you are not able to add a new WLC. In
order to obtain a license, you need to call TAC
Note: If you make any changes on the WCS, then make sure you forward the
changes to your controllers. Then refresh the configurations of the controller
in order to make it up to date. See the Refreshing WLC
Configuration from WCS section of this document to know how to refresh
WLC from the WCS.
Perform these steps in the WCS in this order to refresh the controller
configuration from WCS.
Choose Configure > Controllers.
The Controllers page lists all the added WLCs. From the list of WLCs,
choose the WLC to be refreshed.
In the resultant controller page, from the Select a
command drop-down menu, choose save configuration to
flash and click Go.
After the configuration is saved in Flash, you receive a successful
message on the screen. After the successful screen appears, choose the same
controller whose configuration was saved to Flash and, on the Select a
command, choose Refresh config from
This prompts you to retain or delete the old configuration. Choose
Delete and press
When a WCS server and a WCS user interface are on different sides of a
firewall, they cannot communicate unless these ports on the firewall are open
to two-way traffic:
80 (for initial http)
162 (trap port)
Open these ports in order to configure your firewall to allow
communications between a WCS server and a WCS user interface.
Complete these steps to reset the controller to factory defaults using
Choose Configure > Controllers in order to
display the All Controllers page. This page lists all of the controllers that
are discovered by the WCS.
Click on the IP address of the controller that you want to reset to
factory defaults. The Controller Properties window
From the left side menu, choose System >
The Controller Commands window appears.
Under Administrative commands select Reset to factory
default and click Go.
Choose Reboot from the Administrative Commands
menu in order to reboot the controller without saving the configuration on the
controller. This resets the controller to factory defaults.
Note: Once the controller is reset to factory defaults, the WCS is not
able to discover the controller unless it is configured with the management IP
address. For this, you need to configure the controller using the start up
configuration wizard on the controller.
All regular WCS operations, such as the deletion of alarms, events,
adding/deleting controllers, etc. involve SQL operations internally with the
WCS database (DB). Such internal SQL operations naturally increase the database
size, which, in turn, have an impact on the performance of WCS.
For example, a delete operation in WCS leaves empty space in the
deleted portions of the database. This can result in the discontiguous location
of data in the database, which, in turn, affects the WCS performance.
Defragment WCS database to overcome this issue.
Defragmentation makes all used and unused space contiguous. The
contiguous unused/unused space improves performance. If you defragment the
database, you can reclaim allocated but unused disk space. A database
defragmentation can be beneficial if free disk space on the system runs low due
to a large database size or if the response time of the WCS application is
noticeably slower when data is requested from it.
In order to perform defragmentation manually in WCS, stop the WCS
application. In order to do this, click Start > Programs >
Wireless Control System > Stop WCS. Then open a command line box,
change to the C:\Program Files\WCS4.0\bin directory (the
default directory where WCS is installed), and run the command DBAdmin
defrag. This initiates the defragmentation process. Once the process
is completed, restart WCS with the Start > Programs > Wireless
> Control System > Start WCS operation.
Note: Defragmentation works automatically after the database restores.
Still, in some cases, manual defragmentation is done to free up some disk
space. A manual defrag is not really necessary. That space likely is regained
within a few days when WCS starts to create and delete alarms.
Cisco Unified Wireless Network Software Release 4.0 enforces
software-based licensing. Customers are prompted to enter license certificates
by all new Cisco WCS SKU families (except the Cisco WCS Demonstration License).
Current customers that migrate to release 4.0 are also affected by licensing.
Cisco WCS licensing enforcement is tied to these parameters:
Host name—The host name of the Cisco WCS server is
now required during the registration process. Licenses issued are tied to the
original host name designated during the registration process.
Feature option—The Cisco WCS feature option
purchased, Base or Location, is now tracked by the Cisco WCS licensing
Access points—The number of access points supported
in set increments of 50, 100, 500, 1000, or 2500 is now tracked by the Cisco
WCS licensing system.
Demonstration license—This free, location-enabled
Cisco WCS demonstration license supports 10 access points for up to 30
Refer to the
WCS Licensing and Ordering Guide for more detailed information about the
Cisco WCS license and the different types of licenses available.
Select the correct license based on your deployment situation, the
number of access points to be supported, and Cisco WCS options (Base or
Location). All SKUs within a SKU family can be combined with equivalent option
levels such as Base-to-Base or Location-to-Location. Unequal option levels
(Base and Location) cannot be mixed. Only one type of license can be used on
the WCS at one time.
For example, if your computer has a location license, you cannot add a
base license. You can add to the current license by purchasing a license to
increase the access point count. For example, if you have a location license
with an access point count of 50 and in a year you need to add more access
points, you can buy another location license with an access point count of 100,
apply it to the WCS, and have a WCS with a location license for 150 access
points. You can add a license to increase the number of access points in
increments of 50, 100, 500, 1000, 2500, or unlimited.
If you have a base license and want to upgrade to a location, you need
to purchase a location upgrade license. You need to purchase a location upgrade
license equivalent to the total number of access points with a base license.
For example, if you have three base licenses with support for 50, 100, and 200
access points (for a total of 350 access points), you must purchase a single
location upgrade license with support for 350 access points.
All Cisco WCS SKUs require a PAK certificate to register the Cisco WCS
license. The PAK is a paper certificate sent via U.S. mail from Cisco Systems
upon purchase of the Cisco WCS license. The PAK certificate allows customers to
receive a Cisco WCS license. It is used to register the Cisco WCS and generate
license files. All customers must go to the PAK registration site listed on
their PAK certificate to complete their Cisco WCS registration. The PAK
certificate provides clear instructions on how to complete the Cisco WCS
All customers that purchase Cisco WCS from Cisco.com via download or CD
must activate their Cisco WCS license by registering at the PAK site. Customers
will receive the PAK via U.S. mail. Cisco WCS is not activated until the PAK
registration process is completed. Refer to
Licenses for information on how to install and manage a WCS license.
The Security Summary page provides the user with information about all
security related events. This page provides information about rogue access
points, information on signature attacks, information on attacks on the access
points, and information related to client security.
This page is an effective troubleshooting tool specifically if the
problem is related to security threats. This page also provides information on
the most recent security alerts.
Here is an example of the Security Summary
When the Cisco LAPs are powered up and associated with Cisco WLCs, the
Cisco WCS built into the Operating System immediately starts to listen for
rogue access points. When a Cisco WLC detects a rogue access point, it
immediately notifies Cisco WCS, which creates a rogue access point alarm. WCS
considers any access point which is not part of its wireless network as a rogue
When Cisco WCS receives a rogue access point message from a Cisco WLC,
Cisco WCS generates an alarm, with an indicator visible in the lower left
corner of all Cisco WCS User Interface pages. This example shows 72 Cisco WCS
rogue access point alarms.
Complete these steps in order to detect and locate rogue access
Click the Rogues indicator in order to display the
Rogue AP Alarms page. This page lists the severity of the alarms, the rogue
access point MAC addresses, the rogue access point types, the date and time
when the rogue access points were first detected, and their SSIDs.
Click any Rogue MAC Address link in order to display the associated
Alarms > Rogue - AP MAC Address page. This page shows detailed information
about the rogue access point alarm.
Choose one of these commands from the Select a Command menu and click
GO in order to modify the alarm.
Assign to me—Assigns the selected alarm to the
Unassign—Unassigns the selected
Delete—Deletes the selected
Clear—Clears the selected alarm.
Event History—Enables you to view events for rogue
Detecting APs (with radio band, location, SSID,
channel number, Wired Equivalent Privacy (WEP) state, short or long preamble,
Receive Signal Strength Indicator (RSSI), and SNR)—Enables you to view the
access points that currently detect the rogue access point.
Rogue Clients—Enables you to view the clients
associated with this rogue access point.
Set State to `Unknown - Alert'—Tags the rogue
access point as the lowest threat, continues to monitor the rogue access point,
and turns off containment.
Set State to `Known - Internal'—Tags the rogue
access point as internal, adds it to the known rogue access points list, and
turns off containment.
Set State to `Known - External'—Tags the rogue
access point as external, adds it to the known rogue access points list, and
turns off containment.
1 AP Containment through 4 AP Containment—When you
select level 1 containment, one access point in the vicinity of the rogue unit
sends deauthenticate and disassociate messages to the client devices that are
associated to the rogue unit. When you select level 2 containment, two access
points in the vicinity of the rogue unit send deauthenticate and disassociate
messages to the rogue's clients and so on up to level 4. That is, the access
point chosen for containment prevents clients from communicating to the rogue
access point. This effectively neutralizes the function of the rogue access
Go to the Select a Command drop-down menu, choose Map (High
Resolution) and click GO in order to display the
current calculated rogue access point location on the Maps > Building Name
> Floor Name page.
If you use WCS Location, WCS compares the RSSI signal strength from two
or more access points in order to find the most probable location of the rogue
access point and places a small skull-and-crossbones indicator at its most
likely location. In the case of an under-deployed network for location with
only one access point and an omni antenna, the most likely location is
somewhere on a ring around the access point, but the center of likelihood is at
the access point.
Here is an example that shows a rogue access point on a map:
If you use WCS Base, WCS relies on RSSI signal strength from the rogue
access point and places a small skull-and-crossbones indicator next to the
access point that receives the strongest RSSI signal from the rogue unit.
With the location appliance, rogues can be tracked, are shown in the
Monitor > Map drop-down menu, and have the Show Rogue AP
and Show Rogue Clients options. Without the location appliance, these options
are not present, and you can only see the location of the rogues when you go to
the rogue alarm and select the MAP (high resolution) command
from the drop-down menu.
On the WCS Base, the rogue is shown next to the detecting AP (not the
closest), without location information. For more detailed information on the
features that are supported in WCS Base and WCS Location, refer to
of WCS Base and WCS Location.
Note: Firmware release 4.0 has Cisco bug IDs
(registered customers only)
(registered customers only)
that always show rogue client counts at
zero in the rogue access point list. The workaround for this problem is to see
the rogue access point list directly on the controller for correct
The AP Impersonation feature improves the detection of rogue APs that
attempt to impersonate valid Cisco 1000 Series LAPs. This feature creates a
radio frequency (RF) network group, and the Cisco 1000 Series LAPs in the same
group distribute radio resource management (RRM) neighbor packets to each
other. If a Cisco 1000 Series LAP hears packets from another Cisco 1000 Series
LAP from which it has not received any RRM neighbor packets, then the Cisco
1000 Series LAP can assume that the new AP is impersonating a Cisco 1000 Series
LAP and therefore reports it as a rogue AP.
When the WCS finds an AP that attempts to impersonate another AP on the
WLAN, you see this alert on the WCS server:
AP Impersonation with MAC '00:14:1b:62:4e:42' is detected by authenticated
AP '00:14:1b:62:4e:40' on '802.11b/g' radio and Slot ID '0'
On the controller, this trap log message shows the source MAC address
that causes the issue:
Apr 10 11:21:16 <SomeIPAddress> [WARNING] apf_rogue.c 1890: Possible AP
impersonation of 00:14:1b:62:4e:42, using source
address of 00:90:4b:8a:de:c3, detected by 00:14:1b:62:4e:40 on slot 0.
Refer to Cisco bug ID
(registered customers only)
for more information on AP impersonation
related WCS error logs.
AP impersonation is reported by IDS when you see an AP that advertises
a Cisco MAC address that does not communicate through Lightweight Access Point
Protocol (LWAPP) or Wireless LAN Context Control Protocol (WLCCP). In the LWAPP
model, WCS can map an approximate location of a rogue AP from the controller
interpretation of all AP readings.
The Cisco WCS allows system operators to locate clients in the
enterprise. Complete these steps:
Choose Monitor > Devices > Clients in order
to navigate to the Clients Summary page.
On the Clients Summary page, in the left sidebar, search for
All Clients in order to have Cisco WCS display the Clients
From the Clients page, click the User Name of the client you want
to locate. Cisco WCS displays the corresponding Clients <client name>
From the Clients <client name> page, you have two choices for
locating the client:
In the drop-down menu, select Recent Map
(high/low resolution) in order to locate the client without
In the drop-down menu, select Present Map
(high/low resolution) in order to disassociate and then locate the client after
reassociation. If you make this choice, Cisco WCS displays a warning message
and asks you to confirm that you want to continue. Here is an example:
Refer to this illustration for a Heat Map that shows client
Note: Cisco WCS Location compares RSSI signal strength from two or more
Cisco 1000 Series LAPs in order to find the most probable location of the
client, and places a small Laptop icon at its most likely location. Cisco WCS
Base compares RSSI signal strength from the client, and places a small Laptop
icon next to the Cisco 1000 Series LAP that receives the strongest RSSI signal
from the client.
Note: Usually, when you shut down your laptop, it takes a long time (in
minutes) before the WLC or WCS removes the client from the Clients list. It
continues to show "associated". This is because there are two timers that
control the users association information called Idle Timeout and Session
Timeout. Both of these timers can be changed. These are the default
Coverage holes are areas where clients cannot receive a signal from the
wireless network. The Operating System Radio Resource Management (RRM)
identifies these coverage hole areas and reports them to Cisco WCS. This allows
the IT manager to fill holes based on user demand.
When Cisco WCS displays the Top 5 Coverage Holes, click the
Coverage indicator on the bottom left of the Cisco WCS User
Interface page (or choose Monitor >Alarms and then search
for Alarm Category - Coverage) in order to have Cisco WCS
display the Coverage Hole Alarms page. On the Coverage Hole Alarms page, choose
Monitor > Maps and then search for Access Points by Cisco
1000 Series LAPs Name (this search tool is case-sensitive). Cisco WCS displays
the Maps > Search Results page, which lists the Floor or Outdoor Area where
the Cisco 1000 Series LAP is located. Click the link to display the related
Maps > <building name> > <floorname> page.
On the Maps > <building name> > <floor name> page,
look for areas of low signal strength near the Cisco 1000 Series LAP that
reported the coverage hole. Those are the most likely locations of coverage
holes. If there do not appear to be any areas of weak signal strength, make
sure that the floor plan map is accurate. Also, if you have used the Floor Plan
Editor to create .FPE files, that you have not left out any metal obstructions,
such as walls, elevator shafts, stairwells, or bookcases. If so, add them to
the .FPE floor plan file and replace the old floor plan with the new floor
Cisco WCS enables the user to view the managed WLAN network on
realistic campus, building, and floor plan maps. You can import the floor,
campus, or building plan to the Cisco WCS as an image file and you can add
devices at the appropriate locations. Cisco WCS supports these image
If you face an issue when you import maps to Cisco WCS, it could be due
to an unsupported image format. In order to resolve this issue, open the image
with Microsoft Paint and save the file as
<filename>.GIF. Then try to import the image again.
At times, the imported image file can display in WCS with very poor
quality, even though the original image file is of high quality. One possible
reason for this problem is with the image itself. WCS incorporates the white
space that surrounds the image under the assumption that it is part of the map;
this can lead to poor display quality in the WCS map editor. Try to crop the
image file to remove the white space and then import the new image into
and Using Maps for detailed information on adding maps to the Cisco
Complete these steps in order to ping other devices from a Cisco
Choose Configure > Controllers and click an IP
address under the IP Address column to have Cisco WCS display the
<IPaddress> > Controller Properties page.
On the <IPaddress> > Controller Properties page, go to the
left sidebar and choose System > Commands to have Cisco WCS
display the <IPaddress> > Controller Commands
On the <IPaddress> > Controller Commands page, choose
Administrative Commands > Ping from Switch and click
In the Enter an IP Address (x.x.x.x) to Ping window, enter the IP
address of the network device that the Cisco WLC is to ping, and click
Cisco WCS displays the Ping Results window which shows the packets
sent and received. Click Restart in order to ping the network
device again, or click Close in order to stop pinging the
network device and close the Ping Results window.
After you add Cisco WLCs and Cisco 1000 Series IEEE 802.11a/b/g LAPs to
the Cisco WCS database, you can view the Cisco WLAN Solution status.
Note: When you search for clients or tags without a location appliance, you
need to specify WLC Controllers in the WCS database. This is because the WCS
always defaults to "location servers".
Note: The WCS application must be manually stopped/ shutdown before you
make any changes to the server IP address. If you reboot the server without
stopping the application, then there are chances that the database might get
In the Cisco WCS User Interface, choose Monitor >
Network in order to display the Monitor Network Summary. Here is an
Cisco WCS periodically collects statistics, such as RSSI, SNR, profile
failures, client counts, rogue access point trends, and busy clients, and
organizes them into reports. Use the Monitor > Reports
windows in order to view these reports.
Here is an example of the client count report for the 802.11a/b/g
clients for the last seven days:
These reports can also be used as an effective troubleshooting tool.
The Inspection of Location readiness is a feature introduced in
Location Appliance version 18.104.22.168. With this feature, WCS can verify the
ability of the existing access point deployment to estimate the true location
of an element within 10 meters at least 90% of the time. The Location readiness
calculation is based on the number and placement of access points.
In order to inspect Location readiness from WCS, choose Inspect
Location Readiness from the menu found on the Monitor >
Maps page. A color-coded map appears that shows those areas that do
(Yes) and do not (No) meet the 10 meter, 90% location specification.
Sometimes there might be problems with the WCS getting synchronized
with the location appliance. The network diagram in the WCS might not
synchronize with the location appliance. There are quite a few reasons for this
The size of the network design might have exceeded the maximum limit
of 30 Mb. Cisco bug ID
(registered customers only)
addresses this issue more clearly.
Hence, while you attempt to synchronize a campus diagram whose
overall size, including the number of buildings inside that campus and the
number of floors on each building, on a whole might have exceeded the maximum
limit of 30 Mb, this synchronization process fails.
This problem can be further verified when you view the logs of the
location appliance for this message.
TRACE[com.aes] THROW com.aes.server.cmn.AesServerException:
Server Exception: Message size exceeded: 37176782
This limitation in size is overcome in the upcoming WCS
Another possible reason is that the resolution of the image loaded
into the WCS is too high, and probably exceeds the acceptable resolution of
1024x768. While trying to synchronize such an image with the location
appliance, the synchronization process fails. In such cases, reduce the
resolution in order to help this issue.
Ensure that you run the latest version on your WCS and location
server. Also ensure that the time and date match exactly on all the devices.
This can be verified when you look at these outputs.
Output of the date and
time command on the WCS
Output of the date on the locserver
Output of the show time command on the
Another possible remedy is to stop the location-server, and remove
the database using this command at the location server console:
is the directory for location-server db.
Restart the location server with the command
Then try to resynchronize the
Synchronization problems might occur between the WCS and the WLC.
Because of this issue, the number of active clients might be different on the
WLC and the WCS. In order to synchronize the controllers and the WCS, complete
Choose Configure > Controllers, and click the
check box at the top of the IP Address list to choose all
From the Select a Command drop-down list, choose Save Config
This is a basic test to verify that SNMP works correctly, and the
controllers will do as the WCS tells them.
Choose Configure > Controllers, and click the
check box at the top of the IP Address list to choose all
From the Select a Command drop-down list, choose Refresh
Config from Controllers.
This action tells the WCS to believe the new information from the
controllers over anything it previously had
When a general template is pushed from the WCS to the Wireless Services
Module (WiSM), the Dynamic Host Configuration Protocol (DHCP) configuration in
the controller becomes corrupted. The template can have exactly the same
options that are present in the WiSM.
The main effect is that DHCP offer messages are dropped, so clients do
not receive a DHCP address. This message is logged in the controller:
Thu Jul 13 05:05:07 2006 [VERBOSE] dhcpd.c 164: Dropping packet from
192.168.80.23 (unable to match to a dhcp scope)
This problem is due to Cisco bug ID CSCse98623
(registered customers only)
. Do not use general templates in the
WCS. The configuration has to be restored manually in order to recover the DHCP
forwarding. This bug is fixed in WCS firmware version 22.214.171.124 and
WCS Heat Maps show incorrect square coverage holes. The coverage holes
should never be square or rectangle. The heat map radiation pattern is
circular. This issue is a specific square hole on the map, which should not be
possible. No trace editing has been performed on the map. With the use of a
site surveyor tool, it is verified that no coverage hole exists. The connection
is very strong in these areas.
This is related to Cisco bug ID
(registered customers only)
. Choose the option Recompute
Prediction from the drop-down menu and recompute the prediction. The
heat map becomes circular and no square coverage holes exist. This issue is
fixed in version 4.0, but if you migrate from version 3.0 then the issue might
exist for small size floors.
The rogue access point (AP) template gets applied to the controller
only if these two conditions are true:
When you run a firewall on the server where the WCS application runs,
you need to open up some ports in order to communicate with the WLC. There are
some services that run on the WCS servers such as Apache.exe, JavaService.exe,
and Solid.exe. In TCPView, the output appears similar to this output:
Apache.exe:1712 TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
JavaService.exe:1680 TCP 0.0.0.0:21 0.0.0.0:0 LISTENING
solid.exe:2672 TCP 0.0.0.0:1315 0.0.0.0:0 LISTENING
Apache.exe:208 TCP 127.0.0.1:1268 127.0.0.1:8009 ESTABLISHED
JavaService.exe:1680 TCP 127.0.0.1:1067 127.0.0.1:1315 ESTABLISHED
JavaService.exe:1680 TCP 127.0.0.1:1068 127.0.0.1:1315 ESTABLISHED
solid.exe:2672 TCP 127.0.0.1:1315 127.0.0.1:1083 ESTABLISHED
solid.exe:2672 TCP 127.0.0.1:1315 127.0.0.1:1082 ESTABLISHED
In order to work with the WLC, open up only a few ports like UDP 161
(SNMP), UDP 162 (SNMP Trap), and TCP 443 (HTTPS). This table shows a list of
ports which might be useful if some of the traffic is blocked.
HTTP Connector Redirect
Complete these steps in order to verify that WLANs are set to
Choose Configure > Controller.
Click on an IP address under the IP Address
Click WLAN on the left.
Click on each WLAN ID in order to verify that it is not set to
Complete these steps in order to troubleshoot exclusive-list
Track the client.
Verify the WLAN for the exclusion client.
Select the exclusive client to
Delete the clients from the exclusive-list under the specified
Complete these steps in order to view and delete globally disabled
Choose Monitor > Devices >
Click Manually Disabled
Select the MAC Address to access this page.
For security purposes and several other reasons, certain clients can be
blacklisted as "Manually Disabled Clients".
Complete these steps in order to view manually disabled clients
individually on each controller added to the WCS:
Go to the WCS GUI.
Choose Configure > Controllers.
Click on the IP address under the IP Address column for the
controller to which manually disabled clients need to be
On the page that appears, choose Security and click
Manually Disabled Clients in order to display the list of
Manually Disabled Clients for this particular
From the drop-down menu on the left, choose Delete Manually
Disabled Clients in order to delete manually disabled clients.
This problem can be due to Cisco bug ID
(registered customers only)
. A WCS search for clients on a floor on a
building works correctly, but a search for clients on all floors in a building
does not work. The fix for this bug is available with WCS version 126.96.36.199. If
you use WCS versions earlier than 188.8.131.52, the workaround is to search for
clients in a floor area.
This problem is due to Cisco bug ID
(registered customers only)
. WCS reports client counts that are way
too high when H-REAP is enabled on the controller. The workaround to find out
how many clients are associated to the APs or the given controller is to use
the WCS Monitor > Clients feature, search by the AP or controller, which is
limited by the radio type to avoid duplicates, and use the total number of
items found as your true population number. The bsnMobileStation table also has
the correct number of rows for the number of clients. You can also use the WLC
to find the correct client count.
Underscore characters '_' are not supported in the WCS server name. If
you use an underscore in the Server/Host name on a WCS installation, WCS fails
to start. The installation of the software does not report any issues and
installs as normal, but the RFC-952 states that the underscore is an
unsupported character, which is why this causes the WCS software to
It is essential that the controllers, location servers, and WCS all use
Network Time Protocol (NTP) to ensure accurate local time. The location server
drops any date from the controller that is outside of its 15 minutes window.
The controller keeps only one time internally but modifies it for
display if an offset is specified. If you specify an offset, you tell the
controller that the time which was entered was UTC time [local time for London,
UK] and that you want the controller to display your local time with the
addition of the offset. NTP is always in UTC time, and an offset is required if
you want the controller to display it in your local time. For example, EST has
an offset of -5. If you have NTP configured, the controller gets UTC time but
adds the offset to get local time for the timestamps in the logs.
The controller, location server, and WCS must all be
within 15 minutes internal time (not local time [internal time with offset]),
or the location server does not display or track clients; instead it shows this
error message in the location server log:
3/08/07 00:46:59 ERROR[location] Failed to create heat map for MAC: xx:xx:xx:xx:xx:xx Reason:
Failed as the RSSI list is empty after time pruning
The location server only has enough real time storage for the last 15
minutes of stored data. Remember that the location server tracks clients in
real time, while the WCS archives the data over longer periods of time. WCS can
track clients but updates only every few minutes - not real time. If the clocks
are off between the devices, there is no client data after the location server
removes the ones outside the specified time interval in the request. In fact,
if the location server receives data from the controller with the internal
timestamp more than 15 minutes outside its internal time, it tosses the data
into the bit bucket.
You must turn on NTP for the WLC, WCS, and location server to
automatically synchronize the internal time to UTC.
If WCS uses a third party application, such as MATLAB Compiler, and
MATLAB uses a specific version of the DFORRT.dll library, when an application
has already installed the DFORRT.dll library in c:\windows\system32, the WCS is
not correctly installed. As a result, when you start WCS, this error message
The procedure entry point _FIIfexp_ could not be located in the dynamic link library DFORRT.DLL
In order to correct the problem, remove the DFORRT.dll file in
c:\windows\system32 and reinstall WCS.
For the location server: Refer to the
and Configuration Guide for information within the initial
After the appliance is started, you must stop the location server
before you can change the date, time, or time zone. Follow these
In order to change the location appliance time zone, copy the
appropriate time zone file to /etc/localtime:
# cp /usr/share/zoneinfo/<your country>/<your timezone> /etc/localtime
Verify that the file /etc/sysconfig/clock is defined as is this
without any ZONE specified:
# more /etc/sysconfig/clock
Verify the date and time with the date
command on the location server CLI.
Restart the location server with the instructions available at
Note: If you want to use the NTP server for the location appliance, refer
For the WCS: WCS relies on Windows for the correct
time. It checks the Windows OS once every 24 hours for the system time. It does
not immediately know about system time changes unless you stop and re-start the
WCS server. Right click the clock and choose change time/date. Use an NTP time
source to set the clock and manually set the offset for your timezone.
Typically this is already set.
For the Controller: On the controller, use the CLI
command show clock to verify the time and offset.
You can do this through the GUI, as well. Uncheck the DST checkbox or use the
command config time timezone disable -8 0 -8
After you finish the time synchronization between the devices, you
need to synchronize the location server with the WCS (under
location-server > synchronize). This is done so that they
have the same data with the same timestamps.
Notice that the WCS, controller, and location software are released
on the same date.
After you create WLAN templates and load them into the WLC through WCS,
the "Broadcast SSID" field remains checked in the individual controller WLAN
configuration screen, regardless of the setting in the WCS WLAN template. This
always broadcasts the WLAN SSID information.
In order to disable broadcast SSID on the current WLAN template with
WCS, perform these steps in WCS with versions earlier than 4.1.83.
Note: If you upgrade the WCS to Version 4.1.83, it also resolves this
issue. Also, such problems occur mainly when the controller and the WCS are out
of sync. In such cases, synchronize the WLC and WCS.
In the WCS WLAN template, disable or uncheck the
Admin status box and make sure that the Broadcast
SSID is unchecked.
Save the template.
Apply the template to the controller.
Reenable the admin box of this WLAN.
Save the template
Apply the template to the controller again.
Now, you can find the "Broadcast SSID" field as turned off in the
individual WLAN configuration of the controller.
When you create WLAN templates to push the WLANs to the controllers,
check the 7920 CAC checkbox to enable that feature and save and redisplay that
same WLAN. The template shows as unchecked even though it is really checked and
does enable that feature on the controller when pushed to it.
This is due to bug
which is associated with this issue.
Upgrade the WCS to Version 4.1 to resolve this
In certain cases, users cannot delete WLCs that are no longer used from
the WCS. This is because of issues with the database structure of WCS in
Version 184.108.40.206; as a result, WCS tends to lock up resources. The entire
database was restructured in Version 4.0 and has enhanced the performance
There are two workarounds for this issue:
With the first option, in order to delete the off-line controllers, do
When WCS monitors a very large pool of controllers, the best thing
is to first delete the audit reports of those controllers, one by one, and then
try to delete those controllers. In order to delete the audit reports, follow
Go to Configure Controller.
Check the box of the desired controller. Only one controller at a
time is allowed.
Choose the command View Audit Reports from the
Click the Go button.
Delete the audit reports.
Then try to delete the controllers.
Try this procedure on all other controllers. Make sure that the
user accounts that you use to carry out these tasks are part of the SuperUser
On occasion, it deletes some of the audit reports but not all
reports for a specific controller.
The audit reports that have the synchronization status of
Same in WCS and Controller can be successfully deleted, but
audit reports with the synchronization status of Different in WCS and
Controller cannot be deleted.
You can see this error message when you try to delete audit reports
with the status of Different in WCS and Controller.
The resource you are trying to delete seems to be busy
In this case, the controller cannot be deleted. This error message
means that the database has locked the resource. This can happen if the user
hit the delete button, did not wait long enough, and then hit the
Back to go to previous page. This was an issue in Version
3.2; just wait and see if the resource frees up.
Alternatively, you can use the second option to upgrade WCS to
220.127.116.11 or above, which has great performance enhancements from 3.2 due to a
restructure of the WCS database.
In an attempt to push the template, the error message SNMP
operation to Device failed appears.
This is because of bug CSCsh89306. WCS gives the SNMP error when it
pushes a web authentication template to a controller that runs Version
The workaround is to configure a web authentication directly on the
Navigate to the web authentication customization template
Choose the web authentication type as
Enter some dummy URL text.
Change the web authentication type to Default
Enter a Custom Redirect URL.
Save and apply the template.
Basically, the External and Custom Redirect URL must not be left
blank on the page even if they are not relevant to the current web
authentication application type.