将棋とアニメと稀にプログラミング将棋とアニメと稀にプログラミングできることしかやらない。MEAPPLICATIONSNOVELS「Windows」カテゴリーアーカイブタスクスケジューラを日本時間午前9:00に設定してはいけないサーバーのディスク使用量などの情報を月次でメール配信するタスクを設定しているのだが、去年後半辺りから挙動がおかしくなってきた。結論から言うと、これはWindowsのバグである。以下、引用だが、以下の条件が揃っている場合、起動すべき日の前日にもタスクが起動してしまう。(起動すべき日にも起動する。つの条件がすべて該当する場合に本事象は発生いたします。バージョンが以下であること。週以降の更新プログラムが適用されていること。リリース段階から該当します。毎週や毎月の指定された曜日に実行するタスクであること。曜日指定のタスクが前の曜日に実行されてしまう問題について多分、世界標準時で0:00に実行することで前日と当日の区別がうまくできていないのだと思う。マネージャーになって工数を意識するようになると、仕事って根性でやってはいけないんだなぁと今更思うようになった。今までお世話になったマネージャーの方には頭が上がらない。KB4475591で凄く困ったタイトルは4年ぐらい前に書いた記事のオマージュだったりする。「別のユーザーがサーバー側のコピーを更新したため、今の状態では変更した内容をアップロードすることができません。」というメッセージが表示される事象が頻発するようになった。結論から言うと、これはKB4475591の影響である。Microsoft社に問い合わせたところ、KB4484198をインストールすると解決する模様。Officeドキュメントキャッシュから削除する」のオプションにチェックを入れると回避できるようになる。エラーの原因は、クライアントのキャッシュとサーバー上のファイルとの不整合のようだ。UpdateによってOfficeに更新が入らないので、この問題は発生しない。MSI形式でダウンロードしたOfficeにだけ発生する。ボリュームライセンスを買っているような大企業とかでしか発生しない。あって、仕事で昇格し、マネージャーという立場になった。技術者では完全に無くなっているけど、一般人として、だれもがなんちゃって技術者になれるように整備するのが自分の役目だと考えるようにしている。Service)上で稼働しているWebサービスを運用している。HTTPSの為、SSL証明書を定期的に更新しなければならない。更新はIISマネージャ上で簡単に実行できるのだが、運用しているサーバーが多くなってくると、煩わしい上に作業ミスや漏れが発生しやすくなる。そこで、証明書差し変えbatを作成した。内容自体は簡単なのだけど、思った以上にネット上で情報が見つからなかったので、ここにメモする。・pfxファイルは既に持っており、batと同じディレクトリに格納されている。・証明書ストアは[Webホスティング]にする。・古い証明書がバインドされているサイトはすべて新しい証明書にバインドしなおす。IISマネージャ上でできることは全てappcmdでも実行できると思っていたのだけど、どうもそうでもないらしい。技術の勉強、全然していないなぁ。30歳になり、脳が固まっているのを感じる。Serverで日時作業や定期的なメンテナンスを行う場合、タスクスケジューラで実行することが多い。そのタスクが実は失敗していたが、それに気付かずずっと運用していた・・・というシナリオは思ったより多い(自分の周りでは)。本来的にはそのタスクにエラー通知なりを入れておくのが筋なのだが、ロジックが込み入っていてすぐにはエラー通知が実装できない場合がある。暫定処理だが、そんな場合はタスクの結果を定期的に確認するタスクを仕込むと楽である。AM6時には完了しているはずのタスク「TaskName」であれば、以下のTaskCheck.ps1をAM6時に実行するように設定すればよい。このサーバーから利用できるSMTPサーバがあることを前提としている。繰り返しだが、暫定対応策である。本来は本ロジックにエラー通知を仕込むべきだと思う。タスク失敗時のイベントをトリガーにしてエラー通知をさせたいのだが、意外とその方法が見つからず原始的な方法にしている。一応、想定した時間(例ではAM6時)に終わらなかった時のことを考えて、実行中の場合は別の通知を行うようにほのかな工夫はしている。ついでもトラックパットとキーボードも新調し、20万円なり。節約しなきゃ・・・なのだが、どうも散財癖が身についている。したことで東京へ往復12,000円弱かけて行っちゃうし。訳では全くないけど、いい加減結婚したい。Routing)が含まれている。ARRの内容は下記リンクが分かり易いが、要はリバースプロキシだ。https://codezine.jp/article/detail/7018特に問題なく運用していたのだが、最近あるシステムに大きい容量のデータを送ると404エラーになることが分かった。サーバーログから調査しようとしたが、どうもサーバーに通信自体が来ていないように見える。そこで、経由しているARRのログを確認したところ、こちらで404エラーになっていることが分かった。ARRサーバーのほうのIISログを確認したところ、ステータスコードは404でサブコードは13であることが分かった。そこで検索すると以下の情報がヒットした。404.13-CONTENT_LENGTH_TOO_LARGE]ここの解決策を行い、問題は解決した。こちらの環境ではrequestFilteringノードは見つからなかったが、手動で追加して特に問題なく反映された。画像管理システムでも作ろうかしら。昔作ったのはXMLでタグ情報持たせていたからパフォーマンス面から実質使えない状態だったけど、DBにバイナリ入れて管理させるとどうだろう。DBとバイナリじゃそれはそれでパフォーマンス悪いかなぁ。Serverを運用しているのであれば、トラブル時の調査に備え、パフォーマンスモニターを設定しておくことがほぼ必須手順になる。複数台を運用している場合、どのサーバーにも共通のモニターを設定することになる。取得するカウンター設定を丸ごとコピーしたくなる。結論から言うと簡単にできるのだが、意外とネット上に情報が無かったのでメモする。パフォーマンスモニターを開く。エクスポートしたいデータコレクタセットを右クリックし、[テンプレートの保存]をクリックする。任意の場所に保存する。【エクスポート】で保存したファイルを任意の場所に設置する。パフォーマンスモニターを開き、データコレクタセットを新規作成する。[テンプレートから作成する]を選択し、[次へ]をクリックする。[参照]をクリックし、先程設置したファイルを選択する。以下、ダイアログに従って設定する。なんも難しいところもないんだけど、インポート時には「新規作成」から行うのが意外と盲点になってた。新しいのでないかなぁ。会社のお荷物になりつつあり結構鬱気味。運動して気を晴らそう。2013を構成している際に今までに見たことがないトラブルが発生した。最終的に解決できたものの、理屈が不明のため、ここにとりあえずでメモしておく。しいドメインのユーザーなのに信頼できないドメインと言われ途方にくれていたが、まさかの部分を修正して解決した。APサーバーのhostsファイルにドメインサーバ、DBサーバ、APサーバの名前解決情報が入っていた。ドメインに所属して同じDNSを用いている以上不要なのでこのhostsファイルの上記名前解決情報を削除したところ、問題が解決した。理屈は全くわからないのだが、名前解決情報があるために一部ドメインを経由せず認証を行うような挙動になったのかな、と推測している。再現性を取る時間もないので、とりあえず経験した事実だけ書き記しておこう。転職を考えなくちゃいけないかなぁ。日々勉強、常に時代に追いつき、追い越さなくてはならない「技術者」には僕は成れない。自分に見切りを付けてもいい時期かもしれないな。2013を用いたシステムを運用している。Excelブック等のOfficeファイルを今時風にブラウザ上で閲覧、編集したいという要望が出てきた。Onlineでできるのだから、Foundationでもできそうである。Serverを別途立てればできるということが分かった。サーバーの概要ボリュームライセンスが要るので、個人ではまず無理だと思う。Serverを立て、ブラウザ上での閲覧、編集ができることを確認した。運用して数ヶ月、突然「ブラウザーで閲覧」をするとエラーが発生するようになった。アプリケーションでサーバーエラーが発生しました。」で以下、ランタイムエラーである旨が記述されている。Server側には特にエラーはなかった。Server側にはアクセス毎にエラーログが出力されていた。詳細な内容は割愛するが、「ファイルが見つかりません」というもの。数回この現象には遭遇しており、それぞれの対処法を記述する。Serverを再インストールすればいい」という回答があった。Serverがあり、こちらは問題なく動作していた。Server側に問題があると思われ、この回答は当てにならなかった。回答を辿ると、再バインドでも解消する場合があるという記載があった。これに従い、以下のコマンドをSharePoint管理シェルから実行して再バインドを行った。Serverを「OWA-Server.company.com」とし、SSL通信を前提とする。"external-https"なんと、これだけで解消した。どんだけ不安定なソフトウェアなんだ。・FWで弾かれている上記対応から数日後、また再発したが、今度は上記の方法では解消しなかった。途方に暮れていると、ネットワーク管理者がFWの設定を変更したとの情報が。Serverへのアクセスを特定部署のIPのみに制限していた。「ファイルが見つかりません」エラーが発生していた。Serverへの443ポートを開放してもらい、問題は無事解決した。MS製品の情報は少ないものもあり、あまり仕事という責任が伴う場では使いたくないのが正直なところ。責任がなければ、色々実験できて楽しいんだけど。Explorerでは、現在アクセスしているページが以下のように4種類に分類される。制限付きサイト「信頼済みサイト」は手動で任意のサイトを登録して初めて分類される。ある程度権限が無いと上手く動作しないサイトではユーザーに予め登録をお願いし、セキュリティを弱くすることでサイトが正常に動作するようにすることができる。「制限付きサイト」はその逆と考えて差し支えない(業務上、今まで使たことは無いが)。そんなセキュリティを弱くしないといけないほどのシステムなんて、大抵は社内イントラネットだ。普通ならは信頼済みサイトへの登録なんてせずとも、自動でローカルイントラネットに識別され、システムは問題なく動作する。(デフォルトでは「ローカルイントラネット」の方が「信頼済みサイト」よりセキュリティが弱く設定されている)・・・と思っていたが、色んな会社を回っていると、どうもそうとも限らないらしい。社内システムの筈なのに、IE上は「インターネット」に分類されている場合がある。そこで、この分類され方について調べてみた。何とこれ、実際にイントラネットかは全く判定していなかった。URLに.(ドット)が入っていない場合は「ローカルイントラネット」、入っている場合は「インターネット」を分類しているに過ぎなかった。サイトとして判別されるだから、社内システムでもURLが「http://CompanySystem.com」みたいになっている場合は「インターネット」識別になっていたのだ。極端な話、hostsファイルを弄って「http://google」で「http://google.com」にアクセスするように設定去れば、Googleのページすら「ローカルイントラネット」判定される。何でも雑な分類すぎませんかね。IEも消えてゆくはずだし、いいか。Server等、CUIしかないものも存在する。これらはサイズも軽く、負荷も少ない(多分)という面で便利なのだが、エクスプローラもないため、ちょっとしたファイルコピー、フォルダ権限付けを行いたいときもイチイチコマンドで行わなくてはならない。共有フォルダなら外部のエクスプローラからアクセスすればよいが、そうでないとやはりコマンドでの実行になってしまう。した作業なのに一々コマンドを打つのも面倒だ。ハック的だが、Coreサーバーでもエクスプローラ(的)なものを使う方法がある。このダイアログ上でエクスプローラとほぼ同等の操作ができるちょっとした操作ならこの方がミスも少ないと思う。ネットワークの共有フォルダを見たい場合は「ファイル名」の部分に「\\」を入力すればアクセス可能だ。ex)\\TEST_Server僕はcopyコマンドでコピー元とコピー先と間違える阿呆なので、この方法をよく使う。