本件における無線AP以外の機器のバージョンアップ作業は、つつがなく完了した。
無線APは、reloadコマンド・電源断などの理由で再起動すると起動時にOSファイルが異常を起こす、消失するなどしてデバイス自体が起動しなくなるバグを抱えていた。再起動によるバグの発生確率はランダムで、複数のAPを再起動したときにすべてのAPで発生することもあれば全く発生しないこともあるものだった。
本案件のバージョンアップ作業は3回に分け、1回目はお客様施設の計画停電の復電作業後に実施を予定していた。
復電後、全機器の正常性確認をしていたところ、いつまでもコントローラに帰属しないAPを確認。APにコンソール接続したところ、起動しないバグが発生していた。
当バグは本案件が始まる前から既知のものであり、リリースノートには「まれに発生する」と記載があるレベルまで改修されていた。しかし180台を再起動すると47台に発生した事例があるなど「よくある」レベルのままだった。対処するにはAPにコンソール接続し、BootメニューからOSファイルをインストールし直すしかない。復電作業後、3台のAPにOSファイルをインストールし直してひとまず現状復帰を行った。
今回のバージョンアップは、アップデートパスを挟む必要があったため2回の再起動を予定していた。1回目の再起動ではまだバグが起こる可能性があり、2回目再起動以降のバージョンでは本バグは修正され、安心して再起動ができるものになっていた。それは評価で最新バージョンのAPを何度も再起動し、確認していた。
無線APのバージョンアップ作業が始まった。本APはコントローラ集約型のため、コントローラのバージョンを上げればAPがバージョン差分を認識して自動でバージョンアップをする。コントローラのバージョンを上げ、コントローラから各APの帰属ステータスを固唾を飲んで見守る。1台、2台とコントローラに帰属するログが出て、最終的にまた3台が帰属しなかった。それらはバージョンアップ前に個別対応したものとは異なるAPだった。
再度個別にOSファイルを入れ直し、不測の事態を防ぐため個別にアップデートを行い、コントローラに帰属するところまでを確認した。そしてコントローラと全APに2回目のバージョンアップをさせ、バージョンアップ作業はようやく完了した。
既設のAPは大体が天井や壁などの高い位置に個別接続しない前提で設置されているものであり、今回のお客様の環境も例にもれず脚立に乗ってのコンソール接続が必要だった。実施した内容は大したものではなかったが、不具合を解消する労力が多大な案件であった。