投稿

ラベル(Get-Eventlog.Get-winevent)が付いた投稿を表示しています

キーボード修理

イメージ
前回 調子が悪くなったと書きましたが、部品が手配できて時間が取れたので直しました。 茶軸のスイッチを購入 Cherryの茶軸は 10個で1,399- ということで購入。 本当は1個で充分なんだけど、仕方なく残りは予備部品として保管。 作業手順 キーボードの裏側ネジを3箇所外します。 左右と中央の丸シールの下。 左右はパッドを貼っているので、少しめくって外します。 (あとで綺麗に戻るので心配なしです) ケーブルが出ている方は、スッと外れ、手前(下側)は、内部に爪が有るので、ピックやカード、マイナスドライバなどで少し隙間を開けるようにして広げれば外れます。 自分は親指の爪で空きました。 今回は「E」が調子悪いので、該当のピン2箇所をハンダ吸いで綺麗に取り除いて、裏側から引き抜いて完了。 基板にしっかりとどのキーかがプリントされているので分かりやすいですねぇ 入手した新品の茶軸を差し込んでハンダ付けします。 この時点で動作確認が可能になるので、直したキーとその周辺が正しく入力できるのをチェック。 問題なく、無事に動作しました。 最後にカバーを取り付けて完了! 残ったのは9個の茶軸…。 今回の費用 Cherryの茶軸10個セット :1,399- キーキャップ引き抜き工具 : 475-  ちなみに10個セットには、簡易引き抜きがついてきますが、ちゃんとしたもののほうが楽に作業できます。(昔買ったのに、どこかに行ってしまったので再購入)  ということで、1900円ほどで完治しました。  手間賃考えると買ったほうが安いかも(笑)

ログの整理 #3

PowerShellでは遅すぎて… 実際問題、ログからcsvに切り出すことは可能になったものの、10MBのログから200kb前後のcsvファイルを生成するのに前回のスクリプトだと約2時間かかるんですねぇ。 そりゃ、1レコードを生成するのに、ログオンIDで再度全部ログを舐めて、PCの名前とIPを拾っているわけで…。 単純に考えればO(n^2)というわけですね。 ログのローテーションというか上限を5MB(半分)にすれば、多分処理速度は1/4程度にまで下がるとは思われるけれど、120分が30分になって、ファイル数が倍なので実質1時間かかるわけで…。orz。 何が遅い? 実際、何に時間がかかっているのかを調べ始めたのだけれど、まずwhere-Objectが結構な時間を消費している。その後foreachで回す処理は激遅い。 結局、イベントログからオブジェクトとして扱っているのが、遅さの原因ぽい。 最適化しようにも、PowerShell自体の扱いに慣れていないので、とっても疲れるです。 他に良い方法は無いものだろうか?と思案し始めた時に、以前オライリーの本で見た記憶があったので、ちょいっと検索してみる。 方針変更! perlのモジュールにW32::EventLogが有るじゃないですか。 早速、マニュアルを参考にテスト用のコードを書いてみる。 さすがに、サーバ上での作業は心配なので、VM上のWindows7にActivePerlを入れてテストすることに。 細かい仕様を決めようか、汎用的に作ろうかと迷いつつも、現状の作業をサックリ行えることを目的に作成した。約1日かけて、コーディング終了。前回までのスクリプトと同じ結果を返すようにするところで、少々苦労したわ。 なので、若干コードは汚い(perlなのでさらに汚いww)とは思うのだけれど、これが素晴らしい性能を発揮してくれた。 コードは以下全体を載せておくので、もし万が一使いたい人は、自己責任にてお願いします。 さて、実際に同じデータを食わせてみると、なっなんと、2時間かかっていた処理を1分以内に終えてくれる!!! あぁ、これで今後のログの整理が快適になる。 1週間分、いや1ヶ月分まとめて処理だって怖くない! あとは、コマンドラインでイベントログを引数として渡せば良い仕様...

ログの整理 #2

直しを入れてみた 前回のスクリプトでは、切り出したログを処理すると、対応するログオンIDが見つからないことがあり、ホスト名やIPが空欄になる現象が発生していた。 そこで、後から確認するためにログオンIDをフィールドに付加する仕様に変更した。 こうすることで、手動で該当するログとの突き合わせが可能になる。切り出したcsvだけだと情報が欠落してしまい、再度全部チェックしないといけなくなるを避けるためだ。 さらに仕様変更 ログファイルは、キーボードから入力(といっても、Drag&Dropで入力できるので面倒ではないのだけれど)して、画面に出力していたものを、直接csvファイルに落とすことにした。 ファイル名も面倒なので、入力したログファイルの拡張子をcsvに変更するだけにした。 まあ、少しは手間が省けることでしょう。 ということで、以下がそのスクリプトの全体。 今のところ、最低限のチェックしか入れていないので、暇があれば修正をしようと思う。 誰かのお役に立てれば幸いですが…。 #requires -version 2.0 # 2012/10/04 add field logon-id #     direct write csv-file  function GetValue([String]$category, [String]$key, [String[]]$properties) {   $b = $false;   foreach ($property in $properties) {     if ($b -eq $false) {       if ($property.contains($category)) {         $b = $true;         continue;       }     } else {       if ($property.contains($key)) {   ...

ログの整理

イメージ
ユーザの操作を記録 Windows Serverで、ファイルの監査を行なって、「誰が・いつ・どのファイル・どうした」という統計と、問題が発生した場合にその原因を特定するために、詳細なログを取ることに…。 手順は簡単。まあどの本を見ても書かれているので、詳細は必要ないとは思うけど、参考にした資料くらいは載せておこうと思う。 マイクロソフトが出している文書 「ファイルサーバー上のファイル操作における監査」 が、2000/2003用ではあるけれど、きちっと書かれていますので、これに従えばOK。 ローカルポリシー→監査ポリシー→「オブジェクトアクセスの監査」で成功・失敗をON その他「アカウント ログオン イベントの監査」「ログオン イベントの監査」も設定 エクスプローラで監査したいフォルダを選択。→プロパティ→詳細設定→監査タブで追加→グループもしくはユーザもしくはeveryoneで設定する。 設定内容は「ファイルの作成/データの書き込み」「フォルダの作成/データの追加」「サブフォルダとファイルの削除」「削除」「アクセス許可の変更」「所有権の変更」あたりでOKかと…。必要に応じて設定してください。 あとは、セキュリティログに記録されるので、イベントビューワーあたりで確認すればOK。 大量のログが… ところが、訳の分からない大量のログが発生していて、すぐに溢れてしまう。上書きに設定してもⅠ時間と持たない。アーカイブするようにしても滅茶苦茶な量になる。 どうやら「フィルタリングプラットフォームの接続」に関するログががががが…。 ということで、これじゃログが使いものにならないクズだらけのログになってしまうので、対策を練ることに。 探してみると グループポリシー→Windowsの設定→セキュリティの設定→監査ポリシーの詳細な設定→監査ポリシー→オブジェクトアクセス→「フィルタリングプラットフォームの接続の監査」が有るじゃないですか。 思い切って、「監査なし」に設定する。 すると、今度は全くログを取らなくなってしまう。悩ましい。 そこで、ポリシーを探してみると、 詳細な設定→監査ポリシー→オブジェクトアクセス→「ファイルシステムの監査」と ログオンログオフの監査→「ログオンの監査」「ロ...