はじめに

職場の先輩再鑑の上、表題の作業を先日実施しました
初めての作業だったので、重要だと感じたことを記事にまとめ、備忘録として活用できるようにします

今回はWindow 2019で動いているADの設定を変更しました
ADは4台構成で、設定値の変更などは速やかに同期されます

作業概要

1:既存のADサーバにログインし、Powershellを用いてログを取得する
2:FSMOを持っているAD上で対象OUのオブジェクトの保護設定を外し、OUを削除する
3:対象OUの削除が他のADにも同期されていることを確認し、各サーバからPowershellを用いてログを取得する
4:1で取得したログと5で取得したログを比較して、本作業で業務に影響のあるエラーが出ていないかどうか確認する

1:既存のADサーバにログインし、Powershellを用いてログを取得する

以下コマンドをそれぞれのサーバにRDPした状態で実行します

powershell.

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と同様に以下コマンドを実行し、ログを取得します
次に出力されたログを、作業後というフォルダ作成の上、その中に全て格納します

powershell.

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で取得したログを比較して、本作業で業務に影響のあるエラーが出ていないかどうか確認する

最後に、以下コマンドで作業前フォルダと作業後フォルダを比較し、問題がないか確認します

powershell.

$A = get-content .¥作業前¥GetApplicationLog_.txt
$B = get-content .¥作業後¥GetApplicationLog_.txt
Compare-Object $A $B

こちらのコマンドではあくまでApplicationLogの差異のみを確認しています
同様に他のログも上記コマンドのファイル名を変更し、実施する必要があります

リモートデスクトップ接続ができなかった場合

本旨から逸れますが、本作業でRDP接続する際に、以下の記事を参考にしました

背景として、以下にあるようにNLA認証によってパスワード変更処理を受け渡せないことにあります
NLAとは、接続先サーバが資格情報をクライアントに要求した後、その確認をドメインコントローラーに確認した上で、接続を許可する仕組みです
仮に接続先サーバでパスワードの変更を強要していると、NLAの使用上パスワード変更処理をクライアントに受け渡せないため、ログオンに失敗するといったことが発生します

参考リンク

おわりに

今回の作業で、作業そのものというよりも、むしろPowershellのコマンドに詳しくなった気がしました
上記のようなコマンドの活用で1時間かかる作業も、30分で終わることがあるかもしれません。

まだまだエンジニアとして未熟ではありますが、日々覚えたことを積極的にアウトプットし、成長を続けたいです