WSUSサーバー管理コンソールが接続エラー

木曜日にWSUSサーバーのインデックス再構成をした結果、
金曜の朝にはCPU使用率は30％くらいまで低下していた。
続いて、WSUSサーバークリーンアップウィザードを実行しておいた。

今日もアカウント切り替え作業だ。
取り掛かる前に、WSUSサーバーを見に行くと、
WSUSサーバー管理コンソールが接続エラーになっていた。
クリーンアップ対象が多すぎるのだろうか。
下から順にひとつずつ実行してみる。
置き換えられた更新プログラム・・・すぐに完了
期限の切れた更新プログラム・・・すぐに完了
不要な更新ファイル・・・すぐに完了
サーバーにアクセスしていないコンピューター
・・・都合により接続していなかったPCがあるので、これは実行しないでおく
不要な更新プログラムと更新プログラムのリビジョン
・・・なかなか終わらないので放置

昼休みに再度WSUSサーバーを見に行った。
またしてもWSUSサーバー管理コンソールが接続エラーになっていた。
不要な更新プログラムと更新プログラムのリビジョンは、一番の難関らしい。
確か分割して実行する方法があったと思うけど、覚えていない。
また家で調べてから再チャレンジしよう。

デスクトップ通知はいつもどおり消えた

「デスクトップ通知を消すために操作が必要」を試してみたけど、
ダメだった。通知はいつもどおり消えた。
その後Mさんが通知ダイアログの表示時間を5秒から5分まで
変更できることを見つけてくれたけど、
考えてみたらすべての通知が長い間表示されたら邪魔かもしれない。
在席時はすぐ消えて、不在時はずっと表示されたら良いのかな。
何だかわからなくなってきたので、この件は一旦保留にしよう。

宿直業務の情報化について急いで見積を取得してほしいと依頼があったので、
要件をまとめていたら、電線が垂れ下がっていると通報があった。
雪の重みでファイバーが垂れ下がるなんて聞いたことないし、
きっと通行する車両が引っ掛けたのだろう。

現場を見に行くと、うちの光ファイバーが道路まであと5Mくらいの高さまで
垂れ下がっていた。
垂れ下がっている区間の両端の電柱の装具はしっかり付いている。
垂れ下がっている中央付近を見上げて観察するとケーブル被膜が痛んでいる。
（ひっかけて引っ張ったような跡と、重機のグリースが付いていると、後でわかった）
間違いない、誰かわからないけれど、犯人がいる。
とにかく応急処置をしなきゃ。

jitsi meetのクライアントではない

なんとjitsi desktopは、jitsi meetのクライアントではなかった。
うそー、他にないのー、と検索したら、
Electronで構築されたJitsi Meetのデスクトップアプリケーション
というのがGit Hubにあった。

インストールして起動してみると、meeting idを指定して、
単に会議に参加できるだけのアプリだった。
常駐して呼び鈴を鳴らしてくれるようなものではなかった。
とっても残念。

夕方サーバー室へ不要なPCをしまいに行ったら、
教育委員会のWSUSサーバーのファンが激しく回っていた。
1Uのサーバー本体を触ってみると、ちょっと熱い。
管轄外なんだけど、気になってログインしてみると、CPUが100%に張り付いている。
導入以来メンテされていないせいだろう。
何日間この状態だったんだろう。
放置されても必死に頑張っているサーバーが、急に可哀そうになって、
勝手にメンテすることにした。

まずは、SQL Serverのインデックスを再構成しよう。
SQL Server Management StudioからTransact-SQLを実行した。
明日の朝、結果を確認しよう。

jitsiでLINE電話みたいに呼び鈴を鳴らせないことが不満で、
帰宅してからもういちど考えた。
現実に使う際は、突然jitsiでコールしないだろう。
まずチャットで「ちょっといい？」と投げて、
「何だい、ダーリン？」と応答があったら、ビデオ通話開始ボタンを押すと思う。
だから、チャットの通知が目立てばいい。

目立つ音を鳴らすとか、何か気づきやすい方法はないだろうかと
Rocket.Chatの設定を見ていたら、「デスクトップ通知を消すために操作が必要」
というのを見つけた。これで気づきやすくなるかも。
これをユーザーのデフォルト設定にできないかな。
「デフォルトのユーザー設定」の中にあった。
よし、明日出勤したら試してみよう。

jitsiで呼び鈴を鳴らしたい

職員係にMosPを見せに行った。
オープンソースでこんなに良いものがあるのかと驚いていた。
有償サポートなしで運用するには、
事前に操作方法についていろいろ検証する必要があるけれど、
機能的には問題なさそうだった。

課題は、すべてオフラインで行っている勤怠管理を、
すべてオンラインに切り替えて、こけずに運用できるかどうかだ。
反発もあるだろう。
月末にまとめて事後処理している点もいくつかは改める必要がある
（本来その都度申請すべきだけど）。
負担の少ない運用方法の落としどころを見つけてから、
上に導入を相談しようということになった。

雪の降る中を駅まで歩いていたら、jitsiでLINE電話みたいに呼び鈴を鳴らせたら、
電話の代わりに使えて便利だなーと思いついた。
そしたら公民館などの出先とのコミュニケーション用にjitsiを広めることができそうだ。
ブラウザでは難しそうだけど、デスクトップアプリならできるかも。
jitsiについて調べていたときに、公式サイトだったかな、
ブラウザ版の方がおすすめだけどデスクトップ版もあるよと書いてあった気がする。

夕飯後早めにギルド戦をしてから調べると、あった。
明日出勤したら試してみよう。

MosP用Hyper-V Server設定

昨日OSのリビジョンアップをしてから、セキュリティソフトの管理サーバーが
リモートデスクトップできなくなっている。
セキュリティソフトの管理コンソールも応答しない。
出勤してすぐサーバー室へ見に行くと、OSはちゃんと起動している。
あれ、どういうこと？

とりあえず再起動したけど改善しない。
ネットワークの状態を見ると、パブリックネットワークになっている。
こういうときは、DNSと通信できていないらしい。
でもnslookupすると、DNSはちゃんと応答する。
ネットワークをリセットし、設定しなおした。
でも、パブリックのまま。
イーサネットアダプタを無効にして再度有効にする。
これでどうかな・・・あれ、ダメだ。
もう一度マシンを再起動。
ドメインネットワークに戻った。
やれやれ。

NICが壊れかけなのかもしれない。
セキュリティソフトの管理コンソールはつながるかな？
応答なし。
サービスの状態を見てみると、起動していなかった。
サービスを起動してみる・・・すぐ落ちる。
もう一度・・・また落ちる。まずい。
イベントビューアに何か出ているかな。
エラーが出ている。ファイルの不整合。
管理サーバーをアンインストールしてから再度インストールし、
バックアップからリストアしてだって。

困ったなー。サポートに問い合わせながら修復すると、数日かかるよ。
その間はすべてのクライアントが管理外になり、
デバイス制御やパターンファイルのアップデート等、何もコントロールできない。
そしてもし修復できなかったら、クライアント達を管理下に戻すのがかなり大変だ。
とりあえず自分でやってみるか。

まず管理サーバーをアンインストール。
データの保管場所に使っているSQLServerもついでにアンインストール。
DBが最適化されて速くなるかもね。
そして、再インストールして、データをリストア。
できた。管理コンソールに接続してみる・・・・・つながらない！
きっと、リストアしたばかりでビジーなんだよね、お願い、そうだと言って。
タスクマネージャーを見ると、ほら、ディスク100%だよ。
しばらく後に再接続すると、無事動作を確認できた。
あー、午前中がつぶれてしまった。

午後は、非課税世帯臨時特別給付金用のデータを作成してから、
MosPの環境づくりにとりかかった。
まずは古いサーバーを家で焼いてきたHyper-V Server 2019のDVDでブートする。
セットアップは、ほとんど選択肢がなく、あっさり終わり、再起動した。
起動時のスプラッシュウィンドウが、見慣れたWindowsらしいものだったので、
GUI使えるかもと期待したけど、立ち上がるとDOS窓だけが表示されていた。
でも、ちゃんとメニューが用意されていて、
コマンドを調べる必要がないのは親切だ。
ここでホスト名、IPアドレス等必要事項を設定できる。
驚いたことにドメインに参加できるし、リモートデスクトップも有効にできる。
リモートデスクトップで接続するとどんな画面だろう、と接続してみると、
ウィンドウ内にさっきと同様コマンドプロンプトのウィンドウだけがあった。
そりゃそうか。

では、仮想マシンをインポートしよう。
まずは自席PCにWindowsの機能の有効化または無効化で
Hyper-Vマネージャーを追加する。
そして、Hyper-V Serverに接続を試みると、
「このコンピューターは、ユーザー資格情報の委任を許可するように構成されていません。ほげほげへのユーザー資格情報の委任を許可しますか？」
と尋ねられ、何のことかわからないけれど、「はい」と答える。
「CredSSP認証は現在ローカルクライアントで無効になっています。
CredSSPを有効にするには、管理者権限で実行する必要があります。」
というエラーで接続できない。
？？？

うーん、「別の資格情報でログイン」したからいけなかったのかな。
じゃ、もう一度Hyper-V Serverにリモートデスクトップで接続して
DOS窓内にあるローカル管理者の追加メニューで自分を追加し、
もう一回Hyper-Vマネージャーで接続。
「コンピューター***.***.***.***上での操作が失敗しました：WinRMクライアントは要求を処理できません。トランスポートがHTTPSであるか宛先がTrustedHosts一覧に含まれており、明示的な資格情報が提供されている状態で、IPアドレスと共に既定の認証を使用できます。TrustedHosts一覧に含まれるコンピューターは認証されていない可能性があります。TrustedHostsの設定方法の詳細については、次のコマンドを実行します：winrm help config」
？？？？？？？

ニホンゴニミエルガ、リカイデキナイ。
ひっとしてホスト名で接続しろということかな。
IPアドレスではなく、ホスト名で接続・・・できた！
さあ、仮想マシンをインポートしようと思ったら、
サーバーにブート用パーティションしかなかった。
コマンドラインでディスク管理なんて、MS-DOS以来だよ。
GoogleでDISKPARTの使い方を調べつつ、データ用パーティションを作成し、
ドライブレターを割り当てた。

Hyper-Vマネージャで仮想マシンをインポートし、
仮想スイッチマネージャーで外部仮想スイッチを作成し、
仮想マシンを起動した。
固定IPを設定し、ブラウザでMosPにアクセスしてみた。
あれ、503エラーだ。
httpdのエラーログを見ると、tomcatさんが連携をお断りしているらしい。
Connection refused: AH00957: AJP: attempt to connect to 127.0.0.1:8009(localhost) failed
試しに8080ポートへ直接アクセスしてみると、ちゃんと表示された。
自宅では連携できていたのに、職場へ引っ越したら連携できなくなるって、
どういうことなんだろう。居心地が悪いのだろうか。

httpd.confとserver.xmlを何度も見直して、やっと見つけた。
server.xmlに問題があった。
    <Connector protocol="AJP/1.3"
               address="::1"
               port="8009"
               secretRequired="false"
               redirectPort="8443" />
addressに設定している::1というのは、ipv6のループバックアドレスだって。
知らなかった。
自宅とは仮想スイッチの設定が違っていたんだね。
addressの行を消したら、無事連携できた。
居心地のせいに違いないと思ったんだけどなあ。