最近、暑い日が続きバテ気味の月末担当のおーるどです。

本日は、先日解決しました案件についてですが、とある部署から「Excelが令和にならない」との連絡がありました。
どういうことかというと、Excelにて「2019/5/1」と入力し、表示形式を変更すると自動的に「令和1年5月1日」と変換してくれる機能がありますが、この機能がうまく動作していないとのこと。
この改元に関する部分に関しては、windowsアップデートにて更新プログラムがインストールされることで対応完了となるため、windowsアップデートに関する不具合かなとおおよその目星を付け現場へ。
問題のPCの中身を確認してみると、やはりwindowsアップデートが正常に完了していない状況でした。
早速、対応策を調べてみると、コマンドを用いて、溜まったキャッシュをリセットすることで修復可能となり、正常にインストールができるとのこと。
早速、修復に必要なコマンドを入力し実行すると、無事更新プログラムをインストールし始めました。
ややしばらく時間がかかるため時間をおき再度確認にいくと無事すべての更新プログラムのインストールが完了し、Excelの令和への対応も無事完了していました。

今回の原因になったものについては、たびたび起きることがありそうなので、個人的にもとても勉強になる内容で解決することができ良かったです。

定番のコマンドらしいです。

（投稿者：おーるど）

ども。
自転車に乗る時間がなかなか確保できない担当ちゅんです。

本日は町内小中学校の教員の方を対象とした「とある説明会」を開催しました。あえて「とある」としたのは、機が熟したら大々的にPRしようと思っている案件であるので、あえて今日の時点ではボカしておきます。

説明会を開催すること自体は年に数回は必ずあるので、会場の準備から進行まで特段いつもと変わらないのですが、参加者が役場の職員ではなく教員となるだけで妙に緊張してしまいます。そもそも、普段から「先生」と呼ばれている人たちに対しての先生をやらなければならない、さらに言えば参加者の中には「校長先生」までもが含まれているということで、普段は滑らかに動くはずの口が妙に重く感じられます。喉も乾き、声も擦れ・・・。それでも何とか終えることができました。

それでも、今回の件は我々のホームグラウンドである役場庁舎でできたので精神的にはまだ楽でした。というのも、説明会を開催するとなっても、いざPCは誰が用意するのか、そのネットワークはどうするのか、そもそも電源設備の整った広い会議室は確保できるのかなどなど、不安要素がたくさんあります。役場ではネットワークこそインターネットに接続できないLGWAN環境ではあるものの、普段からこういうときのためにある程度の台数、PCを確保しています。先生方にはご足労を頂くことになりますが、やはり環境の整った場所でやらせてもらうことが確実です。

こうして考えると、例えば災害が起きた際などに急遽役場外の場所で執務を行わなければならなくなったとき、どうするのかという思いにも至ります。「役場で行う説明会だからいつも通りにできる」ということをヒントにすれば、今後、役場以外の場所に執務室を移した場合ということを想定して「移転訓練」をしておけば、いざというときにスムーズかも・・・と、なぜかICT-BCPのことまでもを考えてしまう説明会となりました。

先生の先生はかなり緊張します。ちなみに、明日もあります。

（投稿者：ちゅん）

ども。
ここ数日、八雲地域もようやくカラっと晴れました。心も晴れやかな担当ちゅんです。

本日は、とあるネットワーク系の調査を行っていた時の話です。そのネットワークは我々の管轄ではないネットワークで、よくある「〇〇システム一式」として整備された機器一式の中にHUBやらルータやらが含まれていた的なそれ。もちろん、そのシステム自体の保守はしっかりと行われています。なので、情シスとしては日々の保守として触れることはなかったのですが、今回は庁内LANと接続している部分で不具合を生じたため、念のためその謎のネットワークも確認させていただいた、という内容です。

存在は知っていましたが、ちゃんと見たことがなかったサーバーラック。とりあえず前面のドアを開けて、ルータやスイッチの動作確認。LANケーブルの配線状況をチェックしつつ、次は背面のドアを開けてみます。
ここで大きな驚き。何と、別な部屋から延びてきた幹線のLANケーブルが、ラック内部で「延長コネクタ（JJ）」に接続されていたのです。これ、どう見てもダメでしょう！

正直、我々のような「にわか」はよくやります。離れた場所からLANケーブルを通してきて、あとわずかというところで長さが足りなくなるというミス。通常、こういう時にはもう一度最初からLANケーブルを引き直さなければなりませんが、このJJを使うことで延長ができます。急場しのぎでは大変便利な道具ですが、これをプロが、まして施工時に行っていたとしたら、大問題なのでは？と。

今更この話をしても仕方がないとは感じましたが、当町のネットワーク保守業者さんにも相談。すると、やはり私と同様「JJはあり得ませんね」と。ただ、こういう工事を目の当たりにすると、もしかしたら我々の目に見えない場所、例えば天井裏などでJJが使われていても間違いなく気がつけません。JJ自体は電気を使わないし、物理的に壊れることもなさそうですので、一見、これを使うことでの明確なリスクは無いように感じられますが、単純に「抜ける」可能性はあります。あと、これははっきりしませんが、やはりスループットだって多少は落ちるでしょうか。いずれにしても、無いに越したことは無い、ということですよね。

便利ではあるのですがね･･･｡

(投稿者:ちゅん)

ども。
スマホが壊れ3日間ほど不自由していた担当ちゅんです。

とある出先部署に設置している屋外無線LANの調子が悪くなり、先日から調査を行っておりました。北国の厳しい冬を乗り越え、しかもその間は何の障害もなく元気に動いていたのに、比較的天候が穏やかな5月にすこぶる調子が悪いとは一体何事でしょうか。

現場からは「ネットがつながらず仕事にならない」という悲痛の叫びが。我々としても現地にも足を運び、原因の特定作業を急ぎました。
ようやく、不具合が発生している箇所を特定。どうやら子局側には特に問題がなく、無線が途切れるタイミングで、親局側のAPから5GHzの電波が発射されなくなっているようです。APのログを取得し確認してみると、そこには次のような記述が残されておりました。

Radar was found on station.
DFS start, use JAP table
br0: port 2(peer1) entering disabled state

最初にこれを見つけた時には「すごく珍しいものを見た！」という気分になりました。実は5GHz帯の無線の屋外利用では、同じ周波数を利用する気象レーダーなどの電波を感知した際には速やかにチャンネル変更することが義務付けられています。
上記ログからはその時の動きを読み取ることができ、レーダーを見つけたので停波した様子が記録されています。ちなみに、DFS（Dynamic Frequency Selection）というのがレーダーの検知機能です。

ならば、「原因はコレだったんだ」「無線機は正常だったんだ」と結論付けたくなるところなのですが、今回はそうもいかないようです。
なぜなら、このログをもう少し読み進めていくと、

DFS start, use JAP table
autoch_select: Auto Channel select ch=136
DFS start, use JAP table
autoch_select: Auto Channel select ch=104
DFS start, use JAP table

こんなログが延々と繰り返されているのです。これでは通信などまともにできるわけがありません。このDFS、調べてみるとどうやらレーダーとチャンネルがバッティングした場合、そのチャンネルは30分間利用できなくなり、さらに別なチャンネルに移動する前にはレーダー波の有無を1分間スキャンしなければならないと。これも義務。
結果として、これが動いている間は通信が途切れてしまい、今回の案件が発生していると思われます。

業者さんとも連絡を取り合いながら、本件は「おそらく機器の故障ではないか」ということで代替機と交換する方法で検討を始めました。しかし、本当にレーダー波との周波数バッティングであれば、一体何が起きているのか。空から降ってくる謎の電波、少し不気味ですね。

何の電波が降ってきているのでしょうかね・・・

（投稿者：ちゅん）

ども。
イベントの後片付けをするたびに歳を重ねていることを実感する担当ちゅんです。

先般、とある重要なシステムで障害が発生しました。このシステムは出先部署に置かれている端末と本庁舎に置かれているスイッチとで通信することで情報がやり取りされるもの。大人の事情で詳しくは書けませんが、物理的に建物が分かれているために、ネットワーク的にはルータ同士がVPNで接続されています。本来、入口から入ってきた情報は出口から出て来なければならないのですが、どこかで詰まってしまったらしく、今回は出口から出てこなかったという状況です。

すぐに関係する保守業者さんも交えて原因の調査が始まりました。今回は「システムの構築保守業者」「システムの開発ベンダー」「ネットワークの構築保守業者」と3社が関係する案件。それに加えて我々「役場の情シス担当」が呼ばれました。この時点でかなり嫌な予感がしたのですが、やはり。

「システム的には正常でした」「機器の故障は無いようです」とすぐさま中間報告が上がり、結果として「回線の問題ではないでしょうか」と。今回の件だけではなく、どうも回線（ネットワーク）というのは悪者にされがちです。それは、おそらく通信というものが「直接目に見えない」からだと思います。しかし、こういう言い方をしてはなんですが、ろくに調査もしないで「システムは問題ない」「機械は壊れていない」となぜ言い切れるのか疑問です。ネットワークを再度見直した結果、それでも現象が収まらなかったときにはじめて「ネットワークではないようなので、もしかしたらシステム（機器）かも」と。こんなケースになることが多いです。

悔しかったのであの端末、その機械、このスイッチに思いつく限りの「仕掛け」をしました。常時通信を監視し、入口から出口までの経路のどこで障害が起きているのかを突き止めるためです。すると、当初「ここが原因では？」と言われていた経路は限りなく「白」という結果に。まだ油断はできませんが、この調査結果からは「機器の故障」もあり得るのではないかと。ここまでやって、ようやくシステム側と同じ土俵で話ができるというのが現状です。そもそも、我々だってネットワークに絶対の自信があるわけではありませんし、むしろ疑われても反論ができません。でも、「不思議なことが起きたら、きっとそれはネットワークのせい」という決めつけは、時に問題解決の大きな障害になると思います。「にわか」が言っても説得力に欠けますがね。

ここまでやらないとマトモに取り合ってもらえないのが悲しいです

（投稿者：ちゅん）