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

結論から言うと、これは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円弱かけて行っちゃうし。

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

会社のネットワーク関連の一部を管理しているが、
そのうちの一つにARR（Application Request Routing）が含まれている。
ARRの内容は下記リンクが分かり易いが、要はリバースプロキシだ。
参考: https://codezine.jp/article/detail/7018

特に問題なく運用していたのだが、最近あるシステムに大きい容量のデータを送ると404エラーになることが分かった。
サーバーログから調査しようとしたが、どうもサーバーに通信自体が来ていないように見える。
そこで、経由しているARRのログを確認したところ、こちらで404エラーになっていることが分かった。

ARRサーバーのほうのIISログを確認したところ、ステータスコードは404でサブコードは13であることが分かった。
そこで検索すると以下の情報がヒットした。
インターネット インフォメーション サービス 7.0 を実行しているサーバー上でホストされている Web サイトにアクセスするときにエラー メッセージ:「HTTP エラー 404.13-CONTENT_LENGTH_TOO_LARGE]
ここの解決策を行い、問題は解決した。
なお、こちらの環境ではrequestFilteringノードは見つからなかったが、手動で追加して特に問題なく反映された。

画像管理システムでも作ろうかしら。
昔作ったのはXMLでタグ情報持たせていたからパフォーマンス面から実質使えない状態だったけど、
DBにバイナリ入れて管理させるとどうだろう。
やっぱりDBとバイナリじゃそれはそれでパフォーマンス悪いかなぁ。

Windows Serverを運用しているのであれば、トラブル時の調査に備え、
パフォーマンスモニターを設定しておくことがほぼ必須手順になる。
複数台を運用している場合、どのサーバーにも共通のモニターを設定することになる。

なので、取得するカウンター設定を丸ごとコピーしたくなる。
結論から言うと簡単にできるのだが、意外とネット上に情報が無かったのでメモする。

【エクスポート】
1. パフォーマンスモニターを開く。
2. エクスポートしたいデータコレクタセットを右クリックし、[テンプレートの保存]をクリックする。
3. 任意の場所に保存する。

【インポート】
1. 【エクスポート】で保存したファイルを任意の場所に設置する。
2. パフォーマンスモニターを開き、データコレクタセットを新規作成する。
3. [テンプレートから作成する]を選択し、[次へ]をクリックする。
4. [参照]をクリックし、先程設置したファイルを選択する。
5. 以下、ダイアログに従って設定する。

まぁなんも難しいところもないんだけど、
インポート時には「新規作成」から行うのが意外と盲点になってた。

Mac Miniが欲しい。新しいのでないかなぁ。

会社のお荷物になりつつあり結構鬱気味。
運動して気を晴らそう。