ども。
お昼またぎでの外勤では、昼食（外食）が楽しみな担当ちゅんです。

本日は以前からの懸案事項であった「施設間通信」の再構築を行うべく、朝から熊石地域に出かけておりました。案件としては、昨年も当ブログで試験の様子を記事にしておりましたので、よろしければご参照を。

情報政策室ブログ：施設間通信不調の原因は（2017-08-21）

状況などはこの記事のとおり。このたびは、その際に試験を行ったものと同じアンテナに交換することとなりました。

今日の作業は当町にしては珍しく、全てを業者さんにお願いするかたちをとりました。というのも、これまでの施設間通信で利用してきたアンテナには「同軸ケーブル」が利用されておりましたが、今回のアンテナには通常の「LANケーブル」が利用されます。アンテナを取り換えるだけではなくケーブルの交換作業も発生するため、我々のような素人では危険が伴う（高所です）と判断。もしかしたら、レジェンドの元上司92氏だったら「甘えるな」と言いそうですが、今回ばかりは許してもらいました。

現場に到着して、業者さんと合流。すぐさま「やっぱり頼んで正解でした」と言葉が出ました。事前の想定ではアンテナ設置場所の屋上へは施設のベランダから外に出て、そこから壁のハシゴを上っていくものとばかりに考えておりましたが、なんと高所作業車で来ていただきました。これなら、わざわざ建物の中に入る必要もなく、外から一気に屋上へ。それだけではなく、ケーブルの取り換えも高所作業車のおかげであっという間に終了。さらに、既存の配管も想像以上にスムーズに通線でき、当初は2日がかりで作業が必要と思われた現場でしたが、ものの半日程度であらかたの作業を終了してしまいました。やはり、プロは違います。

結果、施設間通信のスループットはおよそ30倍にもなりました。元の状況がひどすぎたため、その違いは歴然です。現場の職員も「速いね～」と言ってくださり、ようやく肩の荷が下りたような気がします。これまで、通信速度が遅く、不安定な状況で我慢して使ってもらっていました。これからは快適に業務を行ってもらえるものと思います！

写真だと伝わりづらいですが、結構な高さなんです。

（投稿者：ちゅん）

ども。
我が子からもれなく風邪をもらってしまう担当ちゅんです。

今日は少しだけマニアックな話題になります。
この2日間くらい、びっちりと風変わりな仕事に着手しておりました。とある部署で利用している「情報政策室謹製」のアプリケーションもどきがあり、それを大幅に刷新しなければならなくなったのです。

このアプリケーションもどきですが、なぜもどきかというと、HTA(HTML Application)というがっつりWindowsでしか動作しないレガシーな技術を用いているのです。VBとか.netでアプリケーションを作るのは無理でも、私のような「得意分野はウェブ（HTML＋CSS）です」という人間にとっては最終手段というか、むしろこれでしかやりようがないのではないかと思うほど、それっぽくなります。

簡単に言えば、普通にHTMLでページを作り、拡張子をHTMLからHTAに変更するだけ。すると、通常はブラウザで読み込まれるはずのページが、あたかもアプリケーションのように振る舞うという仕掛けになっております。HTAでのみ利用可能なタグもいくつか定義されているので、ある程度設定もできますし、外部スタイルシートもOKです・・・というか、やってみたら動きました。普通に考えれば所詮HTMLなので、たぶんJavaScriptなんかも大丈夫なんだと思います。

今回の案件では、アプリケーションもどきを起動させると八雲町の地図が表示され、行政区域ごとにボタンが用意してあって、それを押すとメールの送信ができるというもの。先方から色々と改修要望があり、それに対応すべく作業。通常、ウェブサイトの場合だと「誰でも、どんな環境でも」といった点を考慮する（だから難しい）のですが、今回のようなケースだと「特定の人が、特定の端末で」が前提なので、スタイルシートには「position: absolute;」ばかりが並んでいます。でも、これでいいのです。
思いのほか捗ったので、今回はメールの送信先アドレスの保守を行うための保守メニューまで作ってしまいました。こういうことをする知識や技術を持たない人間なので、それっぽいことができるようになるとついこだわってしまいます。

こんな感じでそれっぽくできます

（投稿者：ちゅん）

ども。
いま一番必要なのは時間だと感じている担当ちゅんです。

当町ではICT部門の業務継続計画（ICT-BCP）の初動版を策定し運用しています。平成26年度に策定後、机上訓練や定期見直しなどを繰り替えし実施し、ようやく計画自体が「自分たちのもの」という実感が沸くようになりました。それと同時に不足している点や課題も目に付くようになり、今年度はこれまで未検討となっていた熊石地域（総合支所）のICT-BCPについて検討していくこととしました。

計画の策定にあたり、先日、熊石総合支所の防災担当職員を交えて意見交換を実施しました。実際に災害が発生したと想定して、現場の職員はどのような動きをするのか。また、何が無ければ困るのか、どういう順番に復旧しなければならないのかなど、実際に災害対策を行う職員から生の声が聞けたことで、かなり具体的なイメージがわきました。

現在、熊石総合支所の情報システムについては、基本的には八雲地域の役場本庁舎とネットワーク接続されていることが前提で動作するように設計されています。ですから、災害などによってこの「通信」が切断されてしまうと、業務の継続に大きな影響が出るということがわかりました。ICT-BCPとして考えなければならないこととしては、この「通信」をどのような手順により最短で復旧させられるかという点と、そもそも復旧が困難な場合は代替手段は考えられるかという点で検討を行う必要がありそうです。今回、状況を改めて確認したことで、早急に対策を行わなければ大変なことになるという危機感を共有することができました。

おそらく、ICT-BCPが策定できたとしても、全ての点においてすぐに完全な形で実行できるものにはならないかもしれません。項目によっては数年かけて徐々に整備・整理が必要な項目もあろうかと思いますが、まずは手の届く範囲から、確実に一歩ずつでも「前進」することが重要なのだと思っています。熊石総合支所の防災担当職員の「不安なので何とかしたい！」という熱い思いも受け止めながら、しっかりと計画策定に向け頑張ります。

総合支所の職員体制として「情報担当職員がいない」ということも大きな課題です

（投稿者：ちゅん）

ども。
名刺入れを上着のポケットに入れたまま洗濯してしまった担当ちゅんです。

さて、本日は結構大変だった話をご報告します。「にわか」ではない「本物」の方にとっては「そんなことも知らないでよく仕事できてるね」という話かもしれず、ちょっと恥ずかしい話になるかもしれません。
先日、とある業務システムで利用してきた「リモートデスクトップ接続（RDS）」が突然つながらなくなってしまいました。

接続しようとすると、エラーメッセージが表示されます。内容は「要求された関数はサポートされていません」です。「関数？？」なんのこっちゃ。とりあえずエラーの内容をメモに書き止め、すぐさまネットで検索してみます。すると、想像以上に原因はすぐ特定できました・・・と、同時に口から出た言葉は、

「またか・・・」

またしても某窓のアップデート。今回の件については、某窓が2018年5月に実施したアップデートにより、「リモートデスクトップのクライアント、サーバーそれぞれで利用できる認証プロバイダ（CredSSP）のバージョンに差が生じた」というのが原因のようです。簡単に言えば、クライアントとサーバーとの間で同じ某窓アップデートを適用していないとRDSに接続できなくなるというもの。う～ん、なぜこんな重大なことが知らないうちに実行されてしまうのか。私のアンテナが低いだけなのでしょうか。正直、もうついていけません。

で、業務が止まってしまいましたので、これを手っ取り早く解決する方法はないかと調べました。正攻法であれば某窓アップデートを実行するという手順になるのでしょうけど、軽はずみに実行して業務システムのサーバーが再起動でもしてしまっては大変です。そこで、とある「本物」の方にお尋ねしてみたところ、「サーバー側でリモートデスクトップを許可する際に、ネットワークレベル認証で・・・（推奨）というオプションがあると思うのですが、そのチェックを外せばいいんですよ」と教えてもらいました。なるほど、よくわかりませんがそういうことであれば「えい！」。

結果、無事にRDSに接続できるようになり一安心です。「推奨」というオプションですから、本来はこれを利用している方がセキュリティレベルは高まるのでしょうけど、そもそもFWの配下にある、クローズドネットワーク内でのRDSです。さほど気にする必要はないのでしょう。それにしても、RDSへの依存度が高い昨今の状況で、いきなり接続できなくなるアップデートは勘弁してほしいです。

で、結局このオプションの意味は分からないまま。

（投稿者：ちゅん）

ども。
宇宙飛行士の地球への帰還をリアルタイムで見て、鳥肌が立つほど感動した担当ちゅんです。

そんなスケールの大きな話とは打って変わって、今日はズッコケ話を。先日より、多くの職員から「共有フォルダを見つけられなくなった」と問い合わせを受けていました。このフォルダは、職員が自由に利用できる「一時保管場所」の位置づけで運用しているもので、誰でも使うことができる代わりに一定期間でファイルを全削除するバッチを仕込んであります。通常はキッティングの中でデスクトップ上にショートカットを出してあげて、使ってもらっています。

そのフォルダが見つけられないとのことで、実は私自身は何の話だかよくわかりませんでした。自分のPCでアクセスしてみるとちゃんと利用できますし、ファイルサーバにも普通に表示されています。
でも、新しいPCを展開する作業をしていて、その作業中にファイルサーバを見てみると確かにそのフォルダだけが見つけられません。臨席の相棒にその旨を話してみると「僕も同じです。だから直接パスを手打ちしていました」とのこと。どうやら見つけられない現象はこのことのようです。

調べました。今回の現象は、つまり「ある共有フォルダが、特定の環境にあるPCからのみ見ることができて、圧倒的多数のPCからは見ることができない。でも、パスを直打ちすれば利用は可能」という案件。不思議ですね。
ちょっと状況を解決できずにいると、隣席から「あれ！？」と声が聞こえました。見ると相棒は共有フォルダのプロパティを開いています。「・・・まさか！」と思いましたが、そのまさかでした。何と、その共有フォルダ、いつの間にか属性が「隠しファイル」に変更されていたのです。

これ、にわかSEによくある話かもしれませんが、共有フォルダを作るとき、誰でも自由に使うことができる権限を「Everyone – フルコントロール」としがちです。今回のケースもこれに該当していました。だからユーザー側で任意に（おそらく意図せずに）属性を変更されてしまったというわけです。

共有フォルダの利用だけのことでいえば、「Everyone – フルコントロール」の設定でも正しいといえば正しいのですが、ドメイン環境下ではEveryone よりもAuthenticated Users を使うほうがセキュリティ的には正しいですよね。Everyone は本当の意味で「全て」になってしまうので、Guest も含まれてしまいます。
で、今回の問題である権限ですが、フルコントロールもEveryone 同様に、本当に何でもできてしまいます。例えばその共有フォルダの削除や属性の変更までもが可能。この場合は、フルコントロールではなく「変更」が正しいのです。設定は簡単で、フルコントロール以外の権限を全て付ける。そうすると属性は「変更」となり、そのフォルダの内部では何でもできます、ただし親フォルダに対しては何もできませんとなります。ある日突然、共有フォルダが消えてしまわないように、今一度チェックしてみようと思います。

なぜこれにチェックが入っていたのか・・・

（投稿者：ちゅん）