Here are my notes from the Field that I think you will find very helpful.

Lets get started…

1) Plan for a downtime window to avoid calls to the help desk that the wireless is down.

2) Prepare your controllers by backing up the configuration.

3) Make sure you have the software and FUS you need before arriving on site. If deploying remotely– plan ahead and setup a local TFTP/FTP server for file transfers and place the software on a server local to the site to avoid firewalls and slow transfer speeds.

4) If possible be ONSITE physically to monitor the device(s) Or at least have a local out of band terminal attached to console port.

5) Attach a Serial console cable NOT mini USB to the Controller prior to FUS 1.7.0.0

6) Large Sites that are High Touch Five Nines 99999.% Work in pairs to upgrade and monitor the controllers and check the configuration and test after reboot. However if this is an old hat for you then by all means do it by yourself.

7) Log your session and watch the output from the WLC Console session when upgrading the FUS code to check for anomalies since the FUS will reload a controller twice.

8) Know what you have before you start. Preform a show sysinfo at the command line or Monitor=Summary page of the controller. For controllers that do not have a FUS applied e.g. older Factory Fresh WLC’s will show Field Recover Image Version 6.0.182.0. This means that the controller most likely came from the factory with older controller software. Don’t worry this is all good.

With only the initial release FUS image version 1.6.0, you will need to plan for more time as you may need to do multiple upgrade steps as you should go from one FUS to the next. The reason I stress this is if you need to move to a particular release because you are waiting for other controllers in the domain to either be phased out (e.g. Cisco 26xx/44xx/WiSM1. Its entirely possible that you may have to sit on a older release code for the time being. I know I will get a lot of questions on this and I know Cisco officially does say you can go directly from base FUS in the example to the latest and that may work—- but here is my two bits from field experience.

“In some cases for more complex sites, you may have for example: a foreign controller(s) with software WLC code 7.0.235.0 on a 4400 platform mixed with WLC 5508’s with mixed code 7.2.x and 7.4.0.x in the same site. Along with Guest Anchors that are 4400 or WiSM1’s Ideally this is not the best practice or design, however I run into this more often then I want.

So we all know that Guest Anchors should be on a level or higher code revision then there foreign controllers when in these mixed environments to support the above. I have seen it many times where the Guest Anchor is older and the Foreign is newer in code release and this almost always results in crapy user experience between them. You generally see this on WPA2/webAuth and sometimes just webAuth along with Mobility time outs between the controllers. This brings me to FUS versions its best to have these FUS versions running on the following codes if you are running these deployments. Now there is nothing stoping you from having the latest FUS update but realize that they were developed in conduction with the WLC code revisions. Are you confused and have I made this over complicated?”
Field Upgradable Software Version History to date.

10) Upgrading the Field Upgrade Software is done in the same manner as upgrading the WLC software code via the Commands=Download File Controller or the CLI (command line)

ONE CONTROLLER AT A TIME

DO NOT upgrade two controllers in the same site at the same time. Test your first controller before repeating the process to a secondary controller. You may need a back out plan and a secondary controller might be a good insurance policy. Also this can help in speeding up the downtime.

Also the backup software for a 7.4.121.0 controller can be and should be 7.3.112.0 until you move to 7.6.120.0 or 8.0 then 7.4.121.0 will be the SAFE Harbor backup. There are other reasons for this that will require another post, but if you dig through the release notes you will find out why you should have a good backup software to both support your Access Points and certain feature sets that may or may not work when falling back to an earlier software revision for what ever reason.(Cisco Controller) >show boot
Primary Boot Image…………………………. 7.6.120.0 (default) (active)
Backup Boot Image………………………….. 7.4.121.0

UPGRADE TIMES

Upgrade times are lengthy. FUS times are at least 40min for 1.7.0.0 and 45 min for 1.9.0.0. This does not take into account the load times of the FUS or software being transferred and loaded and reboot times. In a site with two controllers plan for 5 hours (includes site walk through testing of Access Points). In some cases you might encounter an older access point that did not or will not upgrade to a new version or is stuck. Keep in mind that this is a very rare occurrence and I have come across it twice, with both 1131 and 1142’s (AP lights up and beacons but nobody is home).

Software upgrades will be time consuming on older software platforms. 5 hours? Well yes, remember that when you are upgrading multiple controllers FUS and Software code. This means that you should plan accordingly and provide an outage window so you can back out if needed to a earlier code release if needed ( but rarely ever seen). Controllers AP software updates can be time consuming as when dealing with 300+ AP’s at a site.

Here is a quote from the release notes

When you upgrade the Cisco WLC to an intermediate software release, you must wait until all of the access points that are associated with the Cisco WLC are upgraded to the intermediate release before you install the latest Cisco WLC software. In large networks, it can take some time to download the software on each access point.

Unsure?
If in doubt and are not comfortable in deploying updates, ask someone that is well versed in Cisco Wireless or your friendly Cisco Mobility Partner

Judging from the output I’m a little confused about the Field Recover Image Version and the boot loader combination. This looks like you obtained a WLC from a previous Beta code deployment. However never fear in this case you can upgrade directly to 1.9 FUS AIR-CT2500-K9-1-9-0-0-FUS.aes = Field Recovery Image Version 7.6.101.1 and remember please DON’T double install the FUS 1.9.

Stew. Greetings.. Is there a way to view via in CLI if there’s FUS image waiting for upgrade or reboot? I went through the FUS upgrade when 1.9 came out and I was running 7.6.MR and now MR2. My sysinfo shows below.. I was hoping to see something else like 1.9 etc

Firmware Version PIC 16.0

I was expecting to see something else.. But, I’m cautious to do another upgrade..

I thought the FUS and OS were independent – no best practice on order.
If I had to choose, I would think it would be better to upgrade FUS before OS, but then i read this on thewifiguy.net ……

Recommendations
• FUS version 1.9 is the recommended FUS version
• To reduce risk of Compact Flash write errors during the initial FUS image download process, it is
recommended to update the AireOS image to 7.4.121.0 before upgrading the FUS image

So image before FUS in this instance if you are below 7.4.121.0?

I upgraded to 7.4.121.0 but held off on the FUS since I was on 1.7 and it isn’t urgent to go to 1.9 unless you are below 1.7.

Field Recovery Image Version is 1.0.0 which is not in compliance with FUS 1.9, but other version numbers are OK. Release notes for FUS 1.9 say “Field Recovery Image is upgraded from 7.0.112.21 to 7.6.101.1” is that mean that Field Recovery Image can’t be upgraded from version 1.0.0

How did this FUS update go? was it all fine? i have a similar situation with lower FUS running 8.0 on 5508.. will be updating directly to 1.9 since this is the only version available for 5508 FUS download.. RN does not provide all and exact limitaions 🙂

Two things, I would highly recommend that you upgrade from 8.0.133.0 to 8.3.141.0 then 8.5.131.0. Avoid upgrading directly to 8.5.131.0 as its always good to be able to move back to a mid-tier version in the event you run into issues with the latest code. Keep in mind that the config files are very different as well, so make sure you make a backup of the config running 8.0.133.0 before you upgrade and one post upgrade on any version of the code.

Next, I would highly recommend that you complete the FUS prior to 8.3.x and 8.5.131.0. or you will run into issues with certain aspects of the code (mostly feature sets) that depends on the FUS.

There is always a risk to any upgrade task whether its hardware or a cloud deployment. Make sure to have a backout plan, your ITIL service manager will respect you more.