きっかけはドメイン参加できないことから
ここ最近実は仮想版Isilon(Isilon SD Edge)を5回目の正直で組んでみました。用途としては
- SNS向けデータストアとしてのNFSストレージ
- VEEAMZIPで使用予定のCIFSストレージ
辺りを想定していて、NFSストレージの移行は完了して稼働中なんですが、CIFSストレージの構成を行う途中という状況でして、その際のドメイン参加をしようとしたときのこと。
割り当てRIDが払い出せない・・と言う理由でドメイン参加時にエラーが出たのであります。
その時、ドメインコントローラに何が起きたか？
我が家のActive Directory関連の構成概要図を以下の通り示しておきます。
FSMOは本番ドメインコントローラ(上図では本番DCと表記)に全て片寄せしています。
名前解決に関しては、外部向けはVerisign Public DNSを使用しています。
クライアントやサーバの名前解決はよほどの理由がない限りCacheDNSサーバで対応して貰うように構成しており、AD側で何かしら名前解決の問題が起きても、最低限インターネット向けの名前解決だけは出来るようにしています。
もちろん、各ドメインコントローラはマルチマスタレプリケーションで構成している状態で、ドメイン・フォレスト機能レベルはいずれもWindows Server 2012 R2です。
本番サイトと災対サイトは物理的な距離の離れたサイトなので、Active Directory側としてもサイト分割を行い、15分間隔でレプリケーションするように構成しています。
過去の記事でも述べていますが、この不具合が発生する前に実はストレージ障害が起きてしまい、吹き飛んだVMを復旧させたりと、それはそれで色々と苦労していました。
イベントログから見えたもの－災対サイト
ざっとログを眺めたところ、こんなログが継続的に出てました。
カテゴリ：警告
イベントID：1865
ソース：Microsoft-Windows-ActiveDirectory_DomainService
タスクカテゴリ：知識整合性チェッカー
"知識整合性チェッカー (KCC) は完全なスパン ツリー ネットワーク トポロジを形成できませんでした。このため、次の一覧のサイトはローカル サイトから到達できません。
サイト:
CN=Production-site,CN=Sites,CN=Configuration,DC=BLUECORE,DC=NET
どうやら継続的にエラーが出力されているようだと。レプリケーションがうまく出来てないようだ・・と言うことは分かりました。
ここで壮絶なやらかしをかます
本来、ここでやるべきだったのは
- FSMOを災対ドメインコントローラへ強制移行
- 自宅サイトドメインコントローラを降格（失敗しそうなら強制降格）
- 自宅サイトドメインコントローラを再昇格
と言う形で本番サイト側のLDAPデータを再構築することでした。が、何を間違えたのか、不幸にも最初にイベントログを災対サイト側ドメインコントローラで見てしまった私は、災対サイト側ドメインコントローラに障害が発生したと思い込んでしまい、これを強制降格させてしまったのです。しかも、まだ本番側のドメインコントローラログは全く見てない状態で。
いつものことながら、∑(ノ∀`*)ｱﾁｬｰ
はい、なんとその後から全くドメイン認証が通らなくなりました。あらゆるNASからバックアップデータが参照できなくなり、そもそもドメインコントローラのデータがバックアップ殆どしてなかった私はまさに大ピンチであります。
イベントログから見えたもの－本番サイト
まず、本番サイト側ドメインコントローラ(FSMO)にて
カテゴリ：情報
イベントID：1000
ソース：Microsoft-Windows-ActiveDirectory_DomainService
タスクカテゴリ：レプリケーション
Microsoft Active Directory ドメイン サービスのスタートアップが完了しました。バージョン 6.3.9600.19653
と言う起動完了イベントが発生したのち、以下のエラーイベントログが発行されていました。
カテゴリ：エラー
イベントID：2101
ソース：Microsoft-Windows-ActiveDirectory_DomainService
タスクカテゴリ：内部処理
Active Directory ドメイン サービス データベースは、サポートされていない復元方法を使って復元されました。
この状態が解決されない場合、Active Directory ドメイン サービスはユーザーをログオンさせることはできなくなります。
このため、Net Logon サービスは一時停止になりました。
ユーザー操作
詳細は、以前のイベント ログを参照してください。
カテゴリ：警告
イベントID:2092
ソース：Microsoft-Windows-ActiveDirectory_DomainService
タスクカテゴリ：レプリケーション
このサーバーは次の FSMO 役割の所有者ですが、有効ではないと判断されています。
このサーバーが再起動されて以来、FSMO を含むパーティションについて、このサーバー はどのパートナーとも正しくレプリケートが行われていません。
この状態が修正されるまで、FSMO 操作マスターへのアクセスを必要とする操作は失敗します。
FSMO 役割: CN=RID Manager$,CN=System,DC=BLUECORE,DC=NET
ユーザー操作:
1. 初期の同期はシステムが起動するときに、レプリケーションの前にシステムによって 行われる最初の動作です。
その初期の同期が失敗したために FSMO 役割が有効ではない と判断された可能性があります。
この処理についてはサポート技術情報 (KB) の記事 305476 によって説明されています。
2. このサーバーには 1 つ以上のレプリケーション パートナーがあり、これらのパートナーとのレプリケーションがすべて失敗しています。
コマンド repadmin /showrepl を 使うとレプリケーションのエラーを表示できます。
問題となっているエラーを修正して ください。
例として、IP 接続の問題、DNS 名前解決、またはセキュリティ認証などの問 題により正しいレプリケーションが妨げられている場合があります。
3. まれに、すべてのレプリケーション パートナーが (メンテナンスや障害回復などの ために) オフラインになることが予期される場合には、役割を強制して有効にできます。
これは http://support.microsoft.com のサポート技術情報 (KB) の記事 255504 および 324801 で提供されている手順に従って行うことができます。
次の操作に影響が出る場合があります:
スキーマ: このフォレストのスキーマをこれ以上変更できなくなります。
ドメイン名前付け: このフォレストで、これ以上ドメインを追加および削除できなくな ります。
PDC: グループ ポリシーの更新や、Active Directory ドメイン サービス以外の アカウントに対するパスワードのリセットなど、プライマリ ドメイン コントローラー の操作の実行がこれ以上できなくなります。
RID: 新しいユーザー アカウント、コンピューター アカウントまたはセキュリティ グルー プのセキュリティ識別子を新しく割り当てられなくなります。
インフラストラクチャ: ユニバーサル グループ メンバーシップなどのドメインを越えた 名前参照は、対象のオブジェクトが移動されたり名前が変更された場合に正しく更新さ れなくなります。"
早い話が
- FSMOのサーバ復旧方式がまずく、Active Directoryが正常な状態ではないと判断された
- そのためにNetlogonが一時停止した
- FSMOが正常ではないと判断され、そのためにRID Masterが機能せずにRIDが追加発行されなくなった
- RIDが枯渇した状態になり、Isilonがドメイン参加できなくなった
と言うことのようです。
FSMOのサーバ復旧方式というのは、実は本番系ドメインコントローラに数日前にトラブルが起き、他のノードにこのサーバを移行できない状況になっていたため、VMをクローニングして対処した・・・と言う出来事が起きていました。どうもサーバをクローニングさせ、それを立ち上げたのがまずかったようです。まぁ要はその日からと言うものコイツは全く災対側と同期できてなかったと言うことやね・・・・・・Orz
試したこと
再起動
単純にサーバを再起動しました。はい、残念ながら正常に立ち上がりはしませんでした。
Replication禁止属性の解除
どうやらサポートされない復旧をした場合に、対象のドメインコントローラには同期を禁止するフラグが立つようです。それを解除するコマンドを打ち込みました。
と、その前にまずは確認。
>repadmin /options sagara
Current DC Options: IS_GC DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
上記のようにINBOUND_REPLとOUTBOUND_REPLに対して「DISABLE」というフラグが立ってます。これを以下のコマンドで解除します。
repadmin /options sagara -DISABLE_INBOUND_REPL
repadmin /options sagara -DISABLE_OUTBOUND_REPL
で、再起動・・・しかし残念ながら現象は改善できませんでした。
Authoritative Restore
Authoritative Restoreは「権限あり復旧」を意味しており、現在のデータが正であるという処理をその時点のLDAPデータに対して行う手順です。これを行うことで現状のADデータが本番か出来るのではないか？と予想したと言うことで。
まずはActive Directory復旧モードで起動させた状態でコマンドプロンプトを起動し、以下の通りにコマンドを実行していきます。本来はこのコマンド実行前にWindows Server Backupやサードベンダー製バックアップソフトウェアのリストア処理が必要なんですが、事前にこのデータはバックアップできてないため、そのままの状態で実行をしました。
■ntdsutilを起動
> ntdsutil
ntdsutil:
■ntdsutilプロンプト上で、操作対象をNTDSに指定する
ntdsutil: activate instance ntds
■Authoritative Restoreメニューへ移動
ntdsutil: authoritative restore
■以下の通りリストアしていく
authoritative restore: restore subtree DC=BLUECORE,DC=NET
authoritative restore: restore subtree CN=Configuration,DC=BLUECORE,DC=NET
authoritative restore: restore subtree CN=Schema,CN=Configuration,DC=BLUECORE,DC=NET
authoritative restore: restore subtree DC=DomainDnsZones,DC=BLUECORE,DC=NET
authoritative restore: restore subtree DC=ForestDnsZones,DC=BLUECORE,DC=NET
■quitコマンドを連続実行してntdsutilを終了する
■サーバを再起動する
しかし・・・・・現象はふつーに再現してしまい、復旧には至れませんでした。
強制降格したドメインコントローラのクリーンナップ
もしかして強制降格したドメインコントローラのデータがゴミとして悪さをしてるのではないかと思ったので、ntdsutilを使用してドメインコントローラのデータをクリーンナップしました。
■ntdsutil起動
> ntdsutil
■metadata clenaupコマンドを実行
ntdsutil: metadata cleanup
■現在接続しているサーバから、災対ドメコンのデータを消す
metadata cleanup: remove selected server hitoyoshi
しかし、これも結局駄目で、repadmin /showreps コマンド実行時にエラー表示が見受けられなくなっただけでした。
結局執った手段：Netlogon強制起動
これ結構八方塞がりの状態になりまして、一時はどうしようかと思ったんですが、少し疑問がわいてきました。
もしかして、Netlogonって無理矢理動かせるんじゃないか？
実はNetlogonサービスの状態を見てみると、停止しているわけではなく、「一時停止」の状態になっているんですね。そしてその状態に限り、どうもアクションとして「再開」なるものが存在したのです。「再開」を選んでみるとおお、なんと普通に起動したではありませんか・・・・認証も普通に通ります。
その後の動作
このことを受け、取り敢えずまず行ったことは災対ドメインコントローラの再昇格でした。まだAD DSサーバコンポーネントは削除してなかったので、そのままウィザードを起動しまして、ドメインコントローラの再昇格を行いました。するとあら不思議、災対ドメインコントローラは何事もなかったかのように再昇格を果たしておりまして。
カテゴリ：情報
イベントID：2013
ソース：Microsoft-Windows-ActiveDirectory_DomainService
タスクカテゴリ：内部処理
Active Directory ドメイン サービスは、次の数のインデックスを初期化の処理の一部として再構築しています。
インデックスの数:
1
インデックス:
LCL_PHABVIEW_index00000411 +ATTb590468
情報
2014
Microsoft-Windows-ActiveDirectory_DomainService
内部処理
Active Directory ドメイン サービスは次の数のインデックスを正常に再構築しました。
インデックス:
1
カテゴリ：情報
イベントID：1394
ソース：Microsoft-Windows-ActiveDirectory_DomainService
タスクカテゴリ：内部処理
Active Directory ドメイン サービス データベースの更新を妨げていたすべての問題が解決しました。
Active Directory ドメイン データベースへの新規更新に成功しています。
Net Logon サービスが再開されました。
暫く時間をおくとレプリケーション用のチャネルも無事自動構成されたのであります。
また、災対ドメインコントローラに対しては再起動を行っても正常にNetlogonを起動できるようです。
その後FSMOの移動をしたところ、以下のように知識整合性チェッカーからも文句を言われなくなりました。
現在、このディレクトリ サービスは、サイト間トポロジ ジェネレーターで、このサイトのサイト間レプリケーション トポロジの生成と維持の責任を負っています。
SYSVOLが災対側にない
一難去ってまた一難・・・・と言う状況があり、今度はSYSVOL共有とNETLOGON共有が災対ドメインコントローラにないことが判明しました。今度はこれを何とかして修復しなければなりません。
取り敢えず同期状況をチェックしたのですが、特に問題はなさそうです。
>repadmin /showreps
DisasterControl-Site\HITOYOSHI
DSA オプション: IS_GC
サイト オプション: (none)
DSA オブジェクト GUID: 3ea9a961-ad38-46cc-95a1-e380e5096f65
DSA 起動 ID: e29ccc31-8f74-4074-9496-b2204c0cad2a
==== 入力方向の近隣サーバー======================================
DC=BLUECORE,DC=NET
Production-site\SAGARA (RPC 経由)
DSA オブジェクト GUID: a081bc9a-2e53-45d0-abce-8ba1e26dbcac
2020-05-24 18:38:24 の最後の試行は成功しました。
CN=Configuration,DC=BLUECORE,DC=NET
Production-site\SAGARA (RPC 経由)
DSA オブジェクト GUID: a081bc9a-2e53-45d0-abce-8ba1e26dbcac
2020-05-24 18:38:24 の最後の試行は成功しました。
CN=Schema,CN=Configuration,DC=BLUECORE,DC=NET
Production-site\SAGARA (RPC 経由)
DSA オブジェクト GUID: a081bc9a-2e53-45d0-abce-8ba1e26dbcac
2020-05-24 18:38:24 の最後の試行は成功しました。
DC=DomainDnsZones,DC=BLUECORE,DC=NET
Production-site\SAGARA (RPC 経由)
DSA オブジェクト GUID: a081bc9a-2e53-45d0-abce-8ba1e26dbcac
2020-05-24 18:38:24 の最後の試行は成功しました。
DC=ForestDnsZones,DC=BLUECORE,DC=NET
Production-site\SAGARA (RPC 経由)
DSA オブジェクト GUID: a081bc9a-2e53-45d0-abce-8ba1e26dbcac
2020-05-24 18:38:24 の最後の試行は成功しました。
>repadmin /showreps sagara
Production-site\SAGARA
DSA オプション: IS_GC
サイト オプション: (none)
DSA オブジェクト GUID: a081bc9a-2e53-45d0-abce-8ba1e26dbcac
DSA 起動 ID: 431356d9-4042-4c7e-8484-46256a8c8e15
==== 入力方向の近隣サーバー======================================
DC=BLUECORE,DC=NET
DisasterControl-Site\HITOYOSHI (RPC 経由)
DSA オブジェクト GUID: 3ea9a961-ad38-46cc-95a1-e380e5096f65
2020-05-24 18:32:52 の最後の試行は成功しました。
CN=Configuration,DC=BLUECORE,DC=NET
DisasterControl-Site\HITOYOSHI (RPC 経由)
DSA オブジェクト GUID: 3ea9a961-ad38-46cc-95a1-e380e5096f65
2020-05-24 18:32:52 の最後の試行は成功しました。
CN=Schema,CN=Configuration,DC=BLUECORE,DC=NET
DisasterControl-Site\HITOYOSHI (RPC 経由)
DSA オブジェクト GUID: 3ea9a961-ad38-46cc-95a1-e380e5096f65
2020-05-24 18:32:52 の最後の試行は成功しました。
DC=DomainDnsZones,DC=BLUECORE,DC=NET
DisasterControl-Site\HITOYOSHI (RPC 経由)
DSA オブジェクト GUID: 3ea9a961-ad38-46cc-95a1-e380e5096f65
2020-05-24 18:32:52 の最後の試行は成功しました。
DC=ForestDnsZones,DC=BLUECORE,DC=NET
DisasterControl-Site\HITOYOSHI (RPC 経由)
DSA オブジェクト GUID: 3ea9a961-ad38-46cc-95a1-e380e5096f65
2020-05-24 18:32:52 の最後の試行は成功しました。
しかし、SYSVOLフォルダは災対ドメインコントローラである「HITOYOSHI」には存在していません。
以下のサイトを参考に調査をすることにしました。
>For /f %i IN ('dsquery server -o rdn') do @echo%i && @(net view \\%i | find "SYSVOL") & echo
HITOYOSHI
ECHO は <ON> です。
SAGARA
SYSVOL Disk Logon server share
ECHO は <ON> です。
となると何が問題か？と言うことで調べると、以下コマンドを実行したときに原因が分かりまして。
>For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderi
nfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state
HITOYOSHI
ReplicatedFolderName ReplicationGroupName State
SYSVOL Share Domain System Volume 2
SAGARA
ReplicatedFolderName ReplicationGroupName State
SYSVOL Share Domain System Volume 2
各ドメインコントローラが示す「State=2」というのは、「初期同期待ち」であることを示しています。災対ドメインコントローラは昇格し直したばかりなので、特に問題はありません。ですが、本番ドメインコントローラがこのステータスを示しているのは全く話が別で、本来はこのステータスではまずいです。要は「どちらのドメインコントローラも初期同期待ちで、相手方からの発信を待ち続けている」という状態になっています。これは、サポートされない復旧をしたために、SYSVOLフォルダが「非Authoritativeで戻された状態」という認識をしていることが問題のように思えました。
なお、以下のように本番ドメインコントローラ側もイベントログを出力しており、問題あることが分かっています。
カテゴリ ：エラー
イベントID ：4612
ソース ：DFSR
タスクカテゴリ ：なし
HITOYOSHI.BLUECORE.NET とレプリケートされるまでまで初期同期状態のままです。サーバーが ドメイン コントローラーに昇格している場合、ドメイン コントローラーはこの問題が解決す るまでアドバタイズしません。これは特定のパートナーも初期同期状態であるか、 共有例外がサーバーあるいは同期パートナー内で発生した場合に発生する場合が あります。このイベントがファイル レプリケーション サービス (FRS) から DFS レプリ ケーションへの SYSVOL の移行により発生した場合は、発生した場合は、この問題 が解決されるまで変更はレプリケートされません。これは、サーバー上の SYSVOL フォルダーが他のドメイン コントローラーと同期ができなくなる原因となります。
追加情報:
レプリケート フォルダー名: SYSVOL Share
レプリケート フォルダー ID: 76A81284-ECF2-45AF-988B-5C5F5103FCBA
レプリケーション グループ名: Domain System Volume
レプリケーション グループ ID: 84172A5F-63AA-4ECB-872C-EEA144EDAA84
メンバー ID: 4064F570-67A9-419E-B4EC-286776B2BF14
これへの対策
SYSVOL同期が行えてない理由は恐らく「SYSVOLのAuthoritative Restoreが出来ていない」と言うことにあると考えたため、これの実行を行いました。
Windows Server 2003 R2の頃などでは、単純にSYSVOLデータを過去のバックアップデータで上書きコピーをすれば良いんですが、今のドメイン環境ではファイル同期の仕組みが昔ながらのFRS（ファイルレプリケーションサービス）からDFS-R(分散ファイルシステム/レプリケーション)にきりかえており、どうもやり方が少々異なるようです。そこで、以下のサイトを参考にしました。
- 一度本番ドメインコントローラを再起動し、ディレクトリサービス復旧モードで起動する
- Windows Server Backupを用いて、システム状態データを「-authsysvol」付で行う
- 通常モードで起動する
Windows Server Backupによるシステム状態データのリストア実行はコマンドプロンプトで以下のように実施します。
> wbadmin start systemstaterecovery -version=<Windows Server Backup でバックアップしたバージョン表記> -authsysvol
実行方法に関しては以下のサイトが参考になりました。
すると、本番ドメインコントローラのイベントログ出力が以下のように変わっていきます。(メッセージのみ)
まずは着信接続の確立。これは以前も出てました。
DFS レプリケーション サービスは、レプリケーション グループ Domain System Volume の パートナー SAGARA との着信接続を正常に確立しました。
追加情報:
接続に使用されたアドレス: SAGARA.BLUECORE.NET
接続 ID: 51A3C3BC-F4CB-45B8-8806-28F228E371CD
レプリケーション グループ ID: 82073254-C8AF-4BD1-9555-5FBBF812CF0F
変化があったのは以下です。実体のレプリケーションがDFS-Rによって行われていることが分かります。
DFS レプリケーション サービスは、ファイルが複数のサーバーで変更されていることを 検出しました。競合解決アルゴリズムを使用して、採用するファイルが決定され、 不採用となったファイルは、競合 (削除済み) フォルダーに移されました。
追加情報:
元のファイル パス: C:\Windows\SYSVOL\domain\scripts\networkdrive.bat
競合フォルダーでの新しい名前: networkdrive-{4724E522-FBB0-484A-8792-D21375514B68}-v482.bat
レプリケート フォルダーのルート: C:\Windows\SYSVOL\domain
ファイル ID: {6008A043-ECFA-4C80-99C9-D9C2578188CF}-v304
レプリケート フォルダー名: SYSVOL Share
レプリケート フォルダー ID: 76A81284-ECF2-45AF-988B-5C5F5103FCBA
レプリケーション グループ名: Domain System Volume
レプリケーション グループ ID: 82073254-C8AF-4BD1-9555-5FBBF812CF0F
メンバー ID: 049277D2-9C72-4B9B-A60B-A7CA7D2D5CCE
パートナー メンバー ID: 00000000-0000-0000-0000-000000000000
そうしたログがそれなりに出たのち、以下のログが出力され、正常化されたことが確認できました。
DFS レプリケーション サービスは、ローカル パス C:\Windows\SYSVOL\domain の SYSVOL レプリケート フォルダーの 初期化に成功しました。このメンバーは、パートナー SAGARA.BLUECORE.NET との SYSVOL の初期同期を完了して います。SYSVOL 共有をチェックするには、「net share」と入力してください。
追加情報:
レプリケート フォルダー名: SYSVOL Share
レプリケート フォルダー ID: 76A81284-ECF2-45AF-988B-5C5F5103FCBA
レプリケーション グループ名: Domain System Volume
レプリケーション グループ ID: 82073254-C8AF-4BD1-9555-5FBBF812CF0F
メンバー ID: 049277D2-9C72-4B9B-A60B-A7CA7D2D5CCE
同期パートナー: SAGARA.BLUECORE.NET
この時点でSYSVOLは無事見えるようになりました。また、初期同期でにらめっこしたものがどうなったかというのが以下です。
C:\Users\Administrator.BLUECORE>For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\rooｔ\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state
SAGARA
ReplicatedFolderName ReplicationGroupName State
SYSVOL Share Domain System Volume 4
HITOYOSHI
ReplicatedFolderName ReplicationGroupName State
SYSVOL Share Domain System Volume 4
「State=4」というのは「標準状態」であること、つまりは正常動作状態であることを意味しています。これでこの問題は無事復旧できたと言うことになります。グループポリシ管理コンソールで災対ドメインコントローラもちゃんと参照できるようになりました。
本番ドメインコントローラ再昇格
この状態でようやく本番ドメインコントローラが再昇格できるようになったわけですが、それでは以下の順序で本番ドメインコントローラの入れ直しを行います。
- 本番ドメインコントローラを強制降格する（データ不整合が残っているため、通常降格は不可でした）
- 災対ドメインコントローラ側でmetadata cleanup処理を実行する
- 本番ドメインコントローラを昇格する
実は本番ドメインコントローラを昇格する際、強制降格をさせたためにmetadata cleanupを忘れて慌てて行ったわけですが、昇格ウィザードがでる際に「再昇格を許容する」というオプションがついていることに気づきました。どうやら降格したドメインコントローラ情報が残っていることがウィザードのバレたようです。
つまりはもしかしたらmetadata cleanupいらないんじゃ？と言う考えもあったのですが、取り敢えず「再昇格を許容する」をONにした状態で再昇格を行いました。
その後本番ドメインコントローラを再起動し、イベントログを確認すると・・・・以下のようにレプリケーションも認証も正常動作する状態になったことが確認できました。
カテゴリ ：情報
イベントID ：1394
ソース ：ActiveDirectory_DomainService
Active Directory ドメイン サービス データベースの更新を妨げていたすべての問題が解決しました。
Active Directory ドメイン データベースへの新規更新に成功しています。
Net Logon サービスが再開されました。
カテゴリ ：情報
イベントID ：4604
ソース ：DFSR
タスクカテゴリ ：なし
DFS レプリケーション サービスは、ローカル パス C:\Windows\SYSVOL\domain の SYSVOL レプリケート フォルダーの 初期化に成功しました。このメンバーは、パートナー HITOYOSHI.BLUECORE.NET との SYSVOL の初期同期を完了して います。SYSVOL 共有をチェックするには、「net share」と入力してください。
追加情報:
レプリケート フォルダー名: SYSVOL Share
レプリケート フォルダー ID: 76A81284-ECF2-45AF-988B-5C5F5103FCBA
レプリケーション グループ名: Domain System Volume
レプリケーション グループ ID: 82073254-C8AF-4BD1-9555-5FBBF812CF0F
メンバー ID: 7A4E3478-B8B9-4AA4-AD4D-3C81EDF2846A
同期パートナー: HITOYOSHI.BLUECORE.NET
これだから自宅環境は面白い
ぶっちゃけ今回は最大の危機と言って良いぐらいのヤラカシをしたわけですが、どーしても仕事ではないと言うこともあり気軽に触れて派手にぶっ壊すというのが私には良くあります。いつも仕事ではもの凄く集中してトラブルが起きないように残心までしながら気を遣って・・・・・ってやってるのを、自宅だったらどーせ責任は私自身に対してだしーって考えるとちょっとそこまで緊張感を持たないというのはあります。
故にトラブルはごっついのが多いし「これアリエン」級のやらかしも多いです。ただ、それがあるからこそトラブルシュートの機会がたくさん芽生えるわけで、特に今回は相手がActive Directory・・しかもTechnet Plus期間を考慮すると実に15年稼働し続けたドメインであるが故、これがやられると取り返しがつかないのです。
だから意地でも復旧する必要があり、その中で古いままの知識が更新されたり、新たな理解が芽生えたり等収穫が多かった事例でもあったかなーと思います。長年動かし続ける環境というのは、どーしても組み上げて管理するのは人間ですから、必ずどっかで不整合が起きて、そして気づかず放置して大事件になるというリスクはあります。
そうしたときに、あらかじめ事故を体験しておくと、障害が起きても冷静で居られるし、考えるスピードも向上させることが出来る。だから自宅に検証環境くんで作っては壊しを繰り返すんだよなぁ・・・って思うと、それなりの投資になってるのかな－・・そうであって欲しいなーと感じる今日この頃です。
using WordPress and
Comments are closed