本日、ちゅん氏が不在ということで連日の投稿になります。
担当おーるどです。

先日の案件についてなのですが､当町では小中学校の教員が利用するPCについては、「シンクライアント方式」にて運用を行っているのですが、そのサーバの運用事業者さんから「ストレージの空き領域がギリギリ」との連絡を受けました。
年度初めのばたばたが落ち着いたらユーザープロファイルを整理しようと考えていたのですが、ストレージの容量がギリギリということもあり、すぐに作業を行うことになりました。対象となったのは、今年度から他町の学校へ転勤され、使われなくなった方のユーザープロファイルで、以前のちゅん氏のブログ「ユーザープロファイルの整理」にも書かれているとおり削除をするためには、システムのプロパティを開き、ユーザープロファイルの設定から対象のプロファイルを「選択」して「削除」するのですが、プロファイルは一件ずつしか選択できないがゆえに、かなりの時間を要しました。
作業を終え、ある程度のストレージの空きが確保されたのを確認したあとで、プロファイルを再度確認してみると、まだまだ使われていないものが・・・。
通常このような作業を行う際は､まずリストを作ってから作業を行うのですが､リストから漏れていたものがあったのか､再度作り直すことに･･･。
ユーザープロファイルは、フォルダごとに分かれているため、なんとかこれをリスト化できないかと思い調べてみると、コマンドを使って簡単に表示できるではありませんか。
早速、フォルダ名を書き出すためのCSVファイルを用意し、コマンドを実行するとあっという間にリストの完成、ここからは先ほど同様一件一件削除をし、無事作業完了。
ある程度ストレージの容量も確保し、新たな知識を学ぶことができよかったです。
しかし、こうならないためにもアカウントを整理するタイミングで確実にプロファイルも削除していくことにしなければいけないと感じました。

表示順を変えるなど他にもいろいろとできることがあるようです。

（投稿者：おーるど）

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

本日は、先日解決しました案件についてですが、とある部署から「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分間スキャンしなければならないと。これも義務。
結果として、これが動いている間は通信が途切れてしまい、今回の案件が発生していると思われます。

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

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

（投稿者：ちゅん）