SYSVOL複製機能をFRSからDFSRへ更新

DCサーバ移行時に、Win2000時台から移行で引き継がれてきた機能を更新しました。

FRS から DFSR への移行 (SYSVOL)

https://docs.microsoft.com/ja-jp/archive/blogs/jpntsblog/frs-dfsr-sysvol

 

注意事項

・ドメイン機能レベルが2008以上である事

・ドメイン内に存在したDCを強制降格した事がある場合、本作業実施前にメタ情報の削除が必要

・設定コマンドはドメインのPDC操作マスタ保持サーバで実行する

・確認コマンド、イベントログ確認はドメイン内の全DCで実行する

 

 

1. 事前確認
①    コマンドプロンプトから下記コマンドを実行する。

netdom query fsmo

 

②    PDCの項目に作業実行サーバのホスト名が表示される事を確認します。

 

③    下記の設定コマンドを実行します。

dfsrmig /CreateGlobalObjects

 

④    下記の確認コマンドを実行します

dfsrmig /GetMigrationState

 

⑤    以下の表示になっている事を確認します。
 

2.機能バージョンアップ
①    下記の設定コマンドを実行します。

dfsrmig /SetGlobalState 1

 

②    下記の確認コマンドを実行します。(ドメイン内の全DCで実行)

dfsrmig /GetMigrationState

 

③    以下の表示になっている事を確認します。

 
④    イベントビューアを起動し、。「イベント ビューアー (ローカル)」 →「アプリケーションとサービス ログ」 →「DFS Replication」をクリックします。


 

⑤    イベント ID 8010(移行準備開始)、 8014(移行準備完了)が表示されること を確認します。
 
   
⑥    下記の設定コマンドを実行します。

dfsrmig /SetGlobalState 2

⑦    下記の確認コマンドを実行します。

dfsrmig /GetMigrationState

⑧    以下の表示になっている事を確認します。
 

⑨    イベントビューアにイベント ID 8015(リダイレクト処理開始)、 8017(リダイレクト処理完了)が表示さ れることを確認します。


 
   
⑩    下記の設定コマンドを実行します。

dfsrmig /SetGlobalState 3

⑪    下記の確認コマンドを実行します。

dfsrmig /GetMigrationState

⑫    以下の表示になっている事を確認します。

 

3.最終確認
①    下記の確認コマンドを実行します。(PDCからの実行のみでOK)

dfsrmig /GetGlobalState

②    以下の表示になっている事を確認します。
 

③    イベントビューアにイ ベント ID 8018(削除済み開始)、8019 (削除済みリダイレクト処理完了)が表 示されることを確認します。
 

 

④  ドメインログオンするクライアント端末から、エクスプローラで\\DCサーバへアクセスします。

NETLOGON、SYSVOLフォルダが表示される事を確認します。

 

以上です。

 

ドメインコントローラ移行手順(Win2008→2016) 1.事前作業

移行の全体概要はこちらの記事で。

https://ameblo.jp/m-o-q/entry-12617997296.html

 

 

1.事前作業

1-1.新下位DCサーバ(正副)のセットアップ

移行前仮ホスト名・IPを設定

社内規定に沿ったセキュリティ製品の導入/Windows更新パッチ適用

 

それぞれの環境によって異なる内容だと思いますので、詳細には触れません。

 

①に関連して、今回の移行では新サーバへ現行サーバのIP・ホスト名を引き継ぐ前提でした。

その為、IP・ホスト名と詳細情報を紐付けるようなソフト(資産管理製品など)では、注意が必要なケースがあるかも知れません。例としては下記のようなケースです。

 ・IP・ホスト名変更後の環境情報が上手く反映されない

 ・既存サーバに紐付く旧情報を削除したいが、サーバが変わった為処理に失敗する

 ・既存サーバで実施済の処理が、IP・ホスト名が同じになる為新サーバに対して実施できない

 

 

ADDS、DNS、WINS(既存DCと同じ役割・サービス)の追加

サーバーマネージャから役割と機能をインストールします。特に注意すべき手順はありません。

弊社環境ではADサーバ上にDNSを構築し、AD統合ゾーンの構成で運用しています。

 

 

1-2.既存上位・下位DCサーバ(正副)のシステムバックアップ

wbadminコマンドでバックアップ

wbadmin

https://docs.microsoft.com/ja-jp/windows-server/administration/windows-commands/wbadmin

ここで実施するバックアップの目的は、「機能レベルの変更」で悪影響が出た場合に環境を元の状態に戻す事です。(機能レベルの設定変更は不可逆の為)

wbadmin start backup -backupTarget:バックアップ先 -include:C: -allCritical -vssFull -quiet > bk.log

 

バックアップ先は、別サーバ上のフォルダをUNCパスで指定しました。

ローカルパスの指定はドライブ単位でしか出来ないため、空のドライブが必要になるようです。

 

 

今回はフォレストの機能レベルも変更する想定だった為、リストア方法はMicrosoftサイトの情報を参考にしてCDブートからのシステムイメージの復元を想定しています。

AD フォレストの回復-サーバーの完全回復の実行

https://docs.microsoft.com/ja-jp/windows-server/identity/ad-ds/manage/ad-forest-recovery-perform-a-full-recovery

サービスの停止等は特に実施せず、運用状態でそのままバックアップしました。

テスト環境でも同じ手順でバックアップ→リストアのテストを実施していますが、ログイン認証等特に問題なく実施出来ています。

 

 

1-3.既存上位・下位DCサーバの設定変更(正側でのみ実施)

機能レベルを2003→2008に更新(下位ドメイン→上位ドメイン→フォレスト の順)

Active Directory の機能レベルを上げる際の影響について
https://docs.microsoft.com/ja-jp/archive/blogs/jpntsblog/ad-functional-level

1.「スタート」→「管理ツール」→「Active Directory ドメインと信頼関係」

 

2.「ドメイン名」を右クリックし、「ドメインの機能レベル を上げる」

 

3.機能レベルを選択する(Win2016サーバをDCにする場合は2008以上)

 

4.ダイアログでOKをクリック

 

5.「ドメイン名」を右クリックし、「プロパティ」をクリック。機能レベルの変更を確認。

 

 

フォレストの機能レベル変更の際は、「Active Directory ドメインと信頼関係」を右クリックです。

 

 

SYSVOL複製機能をFRSからDFSRへ更新(下位ドメイン→上位ドメイン の順)

DFSRへの更新手順は、少し長めになりそうなので別途記事を作成しました。

SYSVOL複製機能をFRSからDFSRへ更新

https://ameblo.jp/m-o-q/entry-12618834838.html

 

 

1-4.新下位DCサーバ(正副)のドメインコントローラ昇格

機能レベルが2008になった事で、Win2016サーバをDCとして運用出来る環境が整います。

 

1.サーバーマネージャを起動

 

2.DC未昇格の状態だと、あ画面上に「警告」が表示されると思います。右端の「その他」をクリック

 

3.[このサーバをドメインコントローラーにする]

 

4.[既存のドメインにドメインコントローラーを追加する]を選択し、[ドメイン]欄にドメイン名を入力

 

5.DCの機能として、DNSやGCの機能をもたせるか、等を環境に合わせてチェックし、サイト名、ディレクトリサービス復元モードのパスワードを指定

(パスワードはActive Directory復元モードでシステム状態を復元する際に必要になります)

 

6.DNS委任のチェックは上位DNSがある場合はその設定に合わせます。弊社環境は上位DNSが存在する為チェックを入れました。

 

7.インストールオプションとレプリケート対象のDCを選択します。任意のDCで特に問題ないと思います。

 

8.ドメイン管理者のアカウントを指定します。

 

9.オプション指定内容を確認します

 

10.事前チェックが実施されます。問題がなければ、インストールを実行します。

 

 

これで、新旧のDCサーバが一堂に会した環境が出来上がりました。

続きは次回

 

ドメインコントローラ移行の注意点 その1.コンピュータ名引継の条件

ActiveDirectoryのドメインコントローラ(DC)を移行する際、

既存サーバのIPやホスト名を引き継ぎたいケースがあると思います。

 

IPアドレスについてはバッティングしないようにさえすれば、

普段通りにアダプタ設定のGUIで問題なく設定できます。

 

ホスト名についてはGUIだとうまく設定出来ないため、

インターネットでよく見るのは以下の流れです。

 

1.代替名の設定

netdom computername 自ホスト名 /add:既存ホスト名

2.代替名を優先名に変更して再起動

netdom computername 自ホスト名 /makeprimary:既存ホスト名

3.入れ替わった代替名(=元の自ホスト名)の削除

netdom computername 既存ホスト名 /remove:自ホスト名

 

この手順を、テスト環境を作って実際に試した所、1でつまづきました。

要は「その名前は使われてます」という内容。

 

 

既存ホストはDCから降格させた状態でシャットダウンしていましたが、

AD上にはまだ情報が残っている為に起こるようです。

この対処として、1のコマンドが通るようにする為に行ったのが下記2点の削除です。

①Active Directory ユーザーとコンピューター

 Computerに登録された既存ホストを無効化→削除

②Active Directory サイトとサービス

 Serversに表示される既存ホストを削除

※DNSの情報はDCから降格させた際に消えてました。

 

①と②を実施してから前述の3コマンドを実行すると、エラーは発生しなくなりました。

その後FSMOの移行などの作業を終えて、

DCとして認証・権限制御の正常動作も確認出来ています。

利用方法によっては他の情報も消す必要が生じるのかも知れません。

 

 

お盆休みが始まりましたが、システム屋さんにとっては繁忙期ですね。

当方も週明けにADサーバの移行を実施予定です。

今回の手順は、移行用のテスト環境で手順確認実施の際に見つけた気付きでした。

 

本番移行後に、最終的に上手くいった状況を改めてまとめたいと思います。

 

ドメインコントローラ移行手順(Win2008→2016) 0.概要

移行作業が無事成功しましたので、手順を公開してみます。

 

まずは前提条件とそれに基づく作業の全体概要から。

 

■環境情報

1.ドメイン構成

  ・フォレストルートドメイン foo.bar.com

  ・移行対象ドメイン sub.foo.bar.com

2.サーバ構成

  ・既存上位DCサーバ(正) DCsv001.foo.bar.com(Win2008、FSMO)

  ・既存上位DCサーバ(副) DCsv002.foo.bar.com(Win2008)

  ・既存下位DCサーバ(正) subDC01.sub.foo.bar.com(Win2012、FSMO)

  ・既存下位DCサーバ(副) subDC02.sub.foo.bar.com(Win2012)

  ・新下位DCサーバ(正) subDCS1(Win2016)

  ・新下位DCサーバ(副) subDCS2(Win2016)

3.NW構成

  ・foo.bar.com   192.168.18.0/24

  ・sub.foo.bar.com 192.168.16.0/24

  ・ゲートウェイは、両セグメントとも上位L3SWに構成(L2SWを介して接続)

 

 

■ポイント

①移行対象はサブドメインのDCサーバ

 →作業日程の都合上、フォレストルートのDCのサーバは移行しませんでした(本当はしたかった)

②新DCサーバはWindows server 2016

 →私が携わった時点で既にハコだけ用意されていたので、選定基準は不明です。2019…

③新DCサーバには既存DCのホスト名・IPアドレスを引き継ぐ必要あり

 → 宗教 運用 上の理由から新しい名前でサーバを構築する事は許可されませんでした。

④対象環境のフォレスト及びドメインの機能レベルが2003になっている

 →Win2016は機能レベル2003ではサポートされないそうです。

フォレストとドメインの機能レベル

https://docs.microsoft.com/ja-jp/windows-server/identity/ad-ds/active-directory-functional-levels#windows-server-2003

⑤対象環境のフォレスト及びドメインはFRSで稼働している

 →今後の事も考えて、DFRSへ早めに移行すべきと判断しました。

  (移行NGならシステムバックアップからリストアする事になりそうなので)

Windows Server バージョン 1709 では FRS がサポートされなくなった

https://support.microsoft.com/ja-jp/help/4025991/windows-server-version-1709-no-longer-supports-frs

 

■作業概要

1.事前作業

1-1.新下位DCサーバ(正副)のセットアップ

  ・移行前仮ホスト名・IPを設定

  ・社内規定に沿ったセキュリティ製品の導入/Windows更新パッチ適用

  ・ADDS、DNS、WINS(既存DCと同じ役割・サービス)の追加

1-2.既存上位・下位DCサーバ(正副)のシステムバックアップ

  ・wbadminコマンドでバックアップ

1-3.既存上位・下位DCサーバの設定変更(正側でのみ実施)

  ・機能レベルを2003→2008に更新(下位ドメイン→上位ドメイン→フォレスト の順)

   ※古いアプリが稼働している為、.Netへの影響懸念から2008R2以降への更新は断念

  ・SYSVOL複製機能をFRSからDFSRへ更新(下位ドメイン→上位ドメイン の順)

1-4.新下位DCサーバ(正副)のドメインコントローラ昇格

  ・念の為並行作業はせず、正の昇格完了後に副を昇格

 

2.DCサーバ副(BDC)の移行

2-1.既存下位DCサーバ副(subDC02)をDCから降格・シャットダウン

  ・dcpromoではなく、サーバーマネージャから役割の削除の流れで降格する

2-2.subDC02の情報を下位ドメイン上から削除

  ・Active Directoryユーザーとコンピュータ >Computers

  ・Active Directoryサイトとサービス >Servers

2-3.新下位DCサーバ副(subDCS2)のホスト名をsubDC02に変更

  ・netdom computername %COMPUTERNAME% /~~(enum add makeprimary remove)

2-4.新下位DCサーバ副(新subDC02)のネットワーク設定を変更

  ・IPアドレス、DNS、WINS

2-5.新subDC02にて、既存下位DCサーバ正(subDC01)からFSMOを転送

  ※サブドメインの為、スキーママスタ、ドメイン名前付けマスタはドメイン内に持たない

 

3.DCサーバ正(PDC)の移行

※基本的にBDCと同じ作業になります

3-1.subDC01をDCから降格・シャットダウン

3-2.subDC01の情報を下位ドメイン上から削除

3-3.新下位DCサーバ正(subDCS1)のホスト名をsubDC01に変更

3-4.新下位DCサーバ正(新subDC01)のネットワーク設定を変更

3-5.新subDC01にて、新subDC02からFSMOを転送

 

4.事後確認

4-1.NTPの同期状況確認

4-2.DNSの同期状況確認

4-3.ADクライアントからのドメインログオン確認

 ※実際には、作業の各ポイントで「ドメインログオン、SYSVOLの参照」での確認を実施しています。

 

次回以降で具体的な手順について記載したいと思います。

明日は移行後立会の為、次の休みにでも…

 

SQLserverで高コストクエリ調査 ~上位20件では足りない!全部見たい!~

DBサーバのCPU負荷が高騰する事が多く、よく調査を依頼されます。

 

いつもはパフォーマンスダッシュボードを見ています。

インスタンスの右クリックメニューから[レポート]>[標準レポート] です。

※SSMSのバージョン17.2以上、が要件です

https://docs.microsoft.com/ja-jp/sql/relational-databases/performance/performance-dashboard?view=sql-server-ver15

表示はバケるのですが、Excelにエクスポートすると解消されます。

右中段の「CPU」をクリックすると、高コストクエリの一覧が表示されます。

 

こちらも同じく文字バケております。

 

そして、こちらが先程のレポートをExcelにエクスポートしたものになります。

 

 

累積CPU時間でソートされているので、「1SQLがめっちゃくちゃ時間が掛かる」だけでなく

「一回の処理は短いけど超絶連続実行されている」ようなケースも挙がるみたいです。

 

いつもこのレポートをExcelで渡していたのですが、

「全体の状況を把握したい。レポートの各クエリが、全CPU時間に対して何%だったか調査できないか」

というリクエストを受けました。

レポートは上位20件の為、この累積時間が全体の1%なのか10%なのかもっとなのか、

対策によって全体のコストが何%削減されたのか、が知りたいという事でした。

 

で、色々調べてちょっと手を加えたのが下記。

SELECT query_stats.query_hash AS “Query Hash”,   
    SUM(query_stats.total_worker_time) AS “累積 CPU 時間”,  
    MIN(query_stats.statement_text) AS “クエリ”  
FROM   
    (SELECT QS.*,   
    SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,  
    ((CASE statement_end_offset   
        WHEN -1 THEN DATALENGTH(ST.text)  
        ELSE QS.statement_end_offset END   
            – QS.statement_start_offset)/2) + 1) AS statement_text  
     FROM sys.dm_exec_query_stats AS QS  
     CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats  
GROUP BY query_stats.query_hash  
ORDER BY 2 DESC;

 

これで、このSQL実行時点での全累積CPU時間が取れるようです。

参考にしたのは下記ページ
sys.dm_exec_query_stats (Transact-SQL)    
    A. TOP N クエリを確認する
https://docs.microsoft.com/ja-jp/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-query-stats-transact-sql?view=sql-server-ver15#a-finding-the-top-n-queries  ;  

 

 

対策した後はDBサーバのCPU使用率が激減しました。(平均使用率で30%程度)

その割合と、上記SQLで比較した減少率がほぼ同じだったので、大きく間違ってはいないと思います。

 

WSLで色々(1) Windows共有のマウント/SSHサーバ構築&TeraTermで接続

■Windowsの共有フォルダをマウントする

コマンド一発です

mount -t drvfs //ターゲットホスト/共有名 マウントポイント -o rw,username=ユーザ名,password=パスワード,iocharset=utf8

 

ちゃんと共有側の書き込み権限を設定しておかないと、パーミッションが777に見えても書き込めません。

 

 

■SSHサーバを立てる(&Win側からTeraTermで接続)

こちらはちょっと試行錯誤がありました。

1.起動を試す

/etc/init.d/ssh start

ホストキーがないとの事。keygenしてないし当然でした。

 

2.まずは設定ファイル確認

cat /etc/ssh/sshd_config | grep Host

全部コメント化されてました。とりあえずrsaだけコメント解除。

 

3.キー生成

sshd_configに定義されていた名前でキーを生成。

cd /etc/ssh
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ”

 

4.再度起動確認

/etc/ssh# /etc/init.d/ssh start

今度は起動しました。

 

5.TeraTermでクライアント側鍵生成

[設定]>[SSH鍵生成]

RSAで生成した場合、id_rsa,id_rsa.pub がTERATERMのインストールフォルダに生成されます

 

6.公開鍵をサーバに転送

FTPサーバは起動していなかったので、ファイルコピーで。

Windows側からWSLのパーティションを見る方法がすぐにわからなかったのですが、

WSL側からは各ドライブが/mntにマウントされている事がわかっていたので、

WSLからWindowsのファイルをとってくることに。

su – WSLユーザ
mkdir .ssh
cd .ssh
cp -p /mnt/ファイルパス ./

とってきたid_rsa.pubの中身を、忘れずにAuthorized_keysへ追記

cat id_rsa.pub >> authorized_keys

上書きにはくれぐれもご注意を。

 

7.TeraTermで公開鍵認証でログイン

鍵ファイルを指定してチャレンジ。無事にログイン出来ました。

 

 

sshd_config では以下の2つがデフォルトで無効になってました。

PasswordAuthentication
ChallengeResponseAuthentication

勿論これを変更すれば公開鍵以外の方法でもログインできます。

設定を変更したらサーバのrestartを忘れずに!

これを書いてるお前のことだぞ!