はじめに
職場の先輩再鑑の上、表題の作業を先日実施しました
初めての作業だったので、重要だと感じたことを記事にまとめ、備忘録として活用できるようにします
今回はWindow 2019で動いているADの設定を変更しました
ADは4台構成で、設定値の変更などは速やかに同期されます
作業概要
1:既存のADサーバにログインし、Powershellを用いてログを取得する
2:FSMOを持っているAD上で対象OUのオブジェクトの保護設定を外し、OUを削除する
3:対象OUの削除が他のADにも同期されていることを確認し、各サーバからPowershellを用いてログを取得する
4:1で取得したログと5で取得したログを比較して、本作業で業務に影響のあるエラーが出ていないかどうか確認する
1:既存のADサーバにログインし、Powershellを用いてログを取得する
以下コマンドをそれぞれのサーバにRDPした状態で実行します
Get-EventLog -LogName Application | Format-Table -autosize -Wrap > GetApplicationLog_$filename.txt
Get-EventLog -LogName System | Format-Table -autosize -Wrap > GetSystemLog_$filename.txt
Get-Service -Sort-Object name | Format-Table -autosize -Wrap > GetService_$filename.txt
csvde -m -u -f export_ou.csv -r objectCategory=organizationalUnit -n
ログの取得では、実行コマンドにFormat-Table
と-autosize
と-warp
とを加えることで、見やすく出力し,Out-File(>)
でテスクトップにテキストファイルとして出力しています
OUの出力ではファイル名をexport_ou.csv
とし、OUのみを出力しています
※あらかじめ実行するコマンドが決まっている場合は、以下工夫すると作業時間が短縮されます
1:実行するサーバのデスクトップに拡張子がps1のテキストファイルを用意する
2:テキストファイルに実施予定のコマンドを記載しておく
3:Powershellを起動し、cdコマンドでデスクトップに移動し、上記テキストファイル名を入力し(一文字入力してtabがおすすめ)実行する
参考リンク
2:FSMOを持っているAD上で対象OUのオブジェクトの保護設定を外し、OUを削除する
OUはデフォルトだと間違って削除されないようコンテナーを保護する
項目が有効になっています
そのため、OUを削除する必要がある場合は、こちらを無効にしたのち対象のOUの削除を実施する必要があります
参考リンク
3:対象OUの削除が他のADにも同期されていることを確認し、各サーバからPowershellを用いてログを取得する
ログの取得前に、デスクトップに出力されているファイルを、作業前
というフォルダを作成し、その中に格納します
その後で、1と同様に以下コマンドを実行し、ログを取得します
次に出力されたログを、作業後
というフォルダ作成の上、その中に全て格納します
Get-EventLog -LogName Application | Format-Table -autosize -Wrap > GetApplicationLog_$filename.text
Get-EventLog -LogName System | Format-Table -autosize -Wrap > GetSystemLog_$filename.text
Get-Service -Sort-Object name | Format-Table -autosize -Wrap > GetService_$filename.text
csvde -m -u -f export_ou.csv -r objectCategory=organizationalUnit -n
4:1で取得したログと3で取得したログを比較して、本作業で業務に影響のあるエラーが出ていないかどうか確認する
最後に、以下コマンドで作業前フォルダ
と作業後フォルダ
を比較し、問題がないか確認します
$A = get-content .¥作業前¥GetApplicationLog_.txt
$B = get-content .¥作業後¥GetApplicationLog_.txt
Compare-Object $A $B
こちらのコマンドではあくまでApplicationLogの差異のみを確認しています
同様に他のログも上記コマンドのファイル名を変更し、実施する必要があります
リモートデスクトップ接続ができなかった場合
本旨から逸れますが、本作業でRDP接続する際に、以下の記事を参考にしました
背景として、以下にあるようにNLA認証によってパスワード変更処理を受け渡せないことにあります
NLAとは、接続先サーバが資格情報をクライアントに要求した後、その確認をドメインコントローラーに確認した上で、接続を許可する仕組みです
仮に接続先サーバでパスワードの変更を強要していると、NLAの使用上パスワード変更処理をクライアントに受け渡せないため、ログオンに失敗するといったことが発生します
参考リンク
おわりに
今回の作業で、作業そのものというよりも、むしろPowershellのコマンドに詳しくなった気がしました
上記のようなコマンドの活用で1時間かかる作業も、30分で終わることがあるかもしれません。
まだまだエンジニアとして未熟ではありますが、日々覚えたことを積極的にアウトプットし、成長を続けたいです