From my previous post about the ASA, you might expect that I would say to manage the WLC (Wireless Lan Controller) via CLI as well. The WLC is enough different that the GUI is much easier to handle and a lot more intuitive. In this case, I would recommend managing the controller via GUI and doing the troubleshooting via CLI. The CLI is much better as a general rule on troubleshooting. When you need details as to why a particular device is having problems getting onto the network via an AP, you can get some very good details on what is going on than what you may be able to get via the GUI.
The GUI on the WLC is good for giving you a go/no go indication of why a particular device is having problems getting on the wireless network. For example, if you are implementing 802.1x using WEP, you can tell very quickly if the problem is at the device or the AP. If you see the Active Directory or LDAP credentials but the device doesnt get an ip address, look at the details for the client in the WLC. If you dont see any signal level information for the client or a signal level of -72 or higher ( 73 to 100), then the client is just barely being heard by the AP but not enough that the handshaking process that occurs during the DHCP process is having a a problem in completing.
Depending on the number of AP’s or locations that you have WLC servicing, using WCS to help the troubleshooting process by giving you a historical perspective on the AP / Client combination and the success vs failed attempted on accessing the network. Like the WLC, there is a cost associated with WCS which is based on the number of AP’s that are being serviced and the level of redundancy in WCS that you need to have. For a small WLC implementation, WCS will be a nice to have. For larger/multi-site WLC implementations, WCS should be viewed as a requirement and not a nice to have.