昔から運用しているHyper-Vで仮想化されたWindows Server 2019環境で、突然RDPが出来なくなる事象が発生した。
正確には、ID/PASSの入力は通り、画面は開くのだが、ずっとWindowsのサインイン時の背景画面のまま何も動かず、数分するとそのままRDPのウィンドウが閉じてしまう。
Hyper-V Managerからなら接続できるが、それでも数十分は上記の背景画面のまま待たないといけない状態である。

ログにも何も出ておらず、Microsoft社に問い合わせても原因不明だったので、しばらく運用回避していたが、先日ようやく対処方法が分かったので、備忘としてここに記載する。

【対処法】
1. Hyper-V Manager等で何とかサーバーに入る。
2. ローカルグループポリシーを開く。（スタートメニューを開き「gpedit.msc」と入力してEnter）
3. [コンピューターの構成]-[Windowsの設定]-[セキュリティの設定]-[ローカルポリシー]-[セキュリティオプション]を開く。
4. [対話型ログオン：最後にサインインしたユーザーを表示しない]を有効にする。

どうもユーザー数が多い環境で生じやすい傾向にあるようだ。
推測だが、ユーザーの検索か何かで時間が掛かってしまっていると思われる。

仕事柄、動作確認用に試用版Windowsを使うことが多い。
試用版はその利用期間が制限されているが、下記のように「slmgr -rearm」コマンドを実行すれば期間の延長が可能である。
（勿論、その延長にも上限回数がある。）
https://www.atmarkit.co.jp/ait/articles/1005/28/news108.html

長期間使う場合は延長が必要になるが、ついついうっかり忘れてしまうことがある。
期限が切れて一定時間経つとシャットダウンされてしまうので、お叱りを受けながら起動、延長、再起動の操作をする羽目になる。
そこで、自動で延長を行うScriptを作成した。

ちょっと強引だが、有効期限状態を取得し、期限切れを検知したら延長と再起動を行う。
期限が切れていなければ何もしない。

これをタスクスケジューラで5分毎ぐらいで実行させれば良い。
ただし、日本語版でしか動作しないのでご注意を。

別に認められた延長期間内で使うことを便利にするだけのScriptなので問題は無い・・・筈・・・

サーバーのディスク使用量などの情報を月次でメール配信するタスクを設定しているのだが、去年後半辺りから挙動がおかしくなってきた。
月末に起動するように設定しているのに、何故か月末の一日前にも起動してしまう・・・

結論から言うと、これはWindowsのバグである。
以下、引用だが、以下の条件が揃っている場合、起動すべき日の前日にもタスクが起動してしまう。
（起動すべき日にも起動する。つまり、二回起動する。）

以下の 4 つの条件がすべて該当する場合に本事象は発生いたします。
● Windows のバージョンが以下であること。
– Windows 8.1 / Windows Server 2012 R2
– Windows 10 Enterprise 2016 LTSB / Windows Server 2016
– Windows 10 Version 1903
● 2019 年 3 月 第 3 週以降の更新プログラムが適用されていること。
※ Windows 10 Version 1903 はリリース段階から該当します。
● 毎週や毎月の指定された曜日に実行するタスクであること。
● タスクの実行時間が日本時間 AM 9:00 (協定世界時 0:00) であること。

引用元: 曜日指定のタスクが前の曜日に実行されてしまう問題について

多分、世界標準時で0:00に実行することで前日と当日の区別がうまくできていないのだと思う。しらんけど。

マネージャーになって工数を意識するようになると、仕事って根性でやってはいけないんだなぁと今更思うようになった。
今までお世話になったマネージャーの方には頭が上がらない。

タイトルは4年ぐらい前に書いた記事のオマージュだったりする。

2019/10頃から、Excelでネットワーク上の同じファイルに対し、複数回保存を行うと、
「別のユーザーがサーバー側のコピーを更新したため、今の状態では変更した内容をアップロードすることができません。」
というメッセージが表示される事象が頻発するようになった。

結論から言うと、これはKB4475591の影響である。
Microsoft社に問い合わせたところ、KB4484198をインストールすると解決する模様。
参考: https://support.microsoft.com/ja-jp/help/4484198/november-18-2019-update-for-office-2016-kb4484198

直ぐに適用が難しい場合、アップロードセンターの設定画面を開き、「ファイルを閉じたときに Officeドキュメントキャッシュから削除する」のオプションにチェックを入れると回避できるようになる。
エラーの原因は、クライアントのキャッシュとサーバー上のファイルとの不整合のようだ。
参考: https://social.msdn.microsoft.com/Forums/en-US/2bb8613d-5580-441c-9049-1a43825cedbf/upload-failed-your-file-was-not-uploaded-because-your-changes-can-not-be-merged-with-changes-made?forum=officegeneral

ちなみに、「クイック実行」でインストールしたOfficeではWindows UpdateによってOfficeに更新が入らないので、この問題は発生しない。
MSI形式でダウンロードしたOfficeにだけ発生する。
つまり、ボリュームライセンスを買っているような大企業とかでしか発生しない。イジメなのだろうか。

色々あって、仕事で昇格し、マネージャーという立場になった。
技術者では完全に無くなっているけど、一般人として、だれもがなんちゃって技術者になれるように整備するのが自分の役目だと考えるようにしている。

仕事で、Windows ServerのIIS（Internet Information Service）上で稼働しているWebサービスを運用している。
当然HTTPSの為、SSL証明書を定期的に更新しなければならない。
更新はIISマネージャ上で簡単に実行できるのだが、運用しているサーバーが多くなってくると、煩わしい上に作業ミスや漏れが発生しやすくなる。

そこで、証明書差し変えbatを作成した。
内容自体は簡単なのだけど、思った以上にネット上で情報が見つからなかったので、ここにメモする。

【前提】
・pfxファイルは既に持っており、batと同じディレクトリに格納されている。
・証明書ストアは[Webホスティング]にする。
・古い証明書がバインドされているサイトはすべて新しい証明書にバインドしなおす。

IISマネージャ上でできることは全てappcmdでも実行できると思っていたのだけど、どうもそうでもないらしい。

技術の勉強、全然していないなぁ。
30歳になり、脳が固まっているのを感じる。

Windows Serverで日時作業や定期的なメンテナンスを行う場合、タスクスケジューラで実行することが多い。
しかし、そのタスクが実は失敗していたが、それに気付かずずっと運用していた・・・というシナリオは思ったより多い（自分の周りでは）。
本来的にはそのタスクにエラー通知なりを入れておくのが筋なのだが、ロジックが込み入っていてすぐにはエラー通知が実装できない場合がある。

暫定処理だが、そんな場合はタスクの結果を定期的に確認するタスクを仕込むと楽である。
例えば、AM6時には完了しているはずのタスク「TaskName」であれば、以下のTaskCheck.ps1をAM6時に実行するように設定すればよい。
なお、このサーバーから利用できるSMTPサーバがあることを前提としている。

繰り返しだが、暫定対応策である。
本来は本ロジックにエラー通知を仕込むべきだと思う。
せめてタスク失敗時のイベントをトリガーにしてエラー通知をさせたいのだが、意外とその方法が見つからず原始的な方法にしている。
一応、想定した時間（例ではAM6時）に終わらなかった時のことを考えて、実行中の場合は別の通知を行うようにほのかな工夫はしている。

ただ、ごちゃごちゃして専門家でないと分からないルーチンより、このほうがなんちゃって管理者でも理解しやすく、意外と受け入れられやすかったりする・・・

Mac miniを買った。
ついでもトラックパットとキーボードも新調し、20万円なり。
節約しなきゃ・・・なのだが、どうも散財癖が身についている。
ちょっとしたことで東京へ往復12,000円弱かけて行っちゃうし。

だからって訳では全くないけど、いい加減結婚したい。