G
Guest
Background:
I'm working on a 2000 domain with 2 fully patched DC's--"DC1" and "DC2".
The first--DC1--is also the main file server. The second--DC2 runs DNS,
WINS, and DHCP. I want to demote DC1 (which no longer runs WINS or DNS) and
decommission it after transferring its files to the new hardware after I fix
the below problem and I can authenticate to the domain with DC1 turned off.
DNS is good on DC2. My goal is to get DC2 running properly as primary
AD/DC/GC etc.
Scenario:
The FSMO roles were transferred to DC2 and DC2 was set as a GC. A problem
was then discovered with FRS on DC1 (NtFrs event id 13568); in addition,
domain login request are not authenticated when DC1 is off. The SYSVOL on
DC2 is also not shared which adds credibility to FRS on DC1 not working
properly when DC2 was added as an additional DC. I believe the Journal Wrap
Error for the domain system volume to be due to the fact that the FRS service
was not running for a number of months (months ago). Since FRS has been
reset to run automatically, the system has undergone (I think) two service
packs.
I've researched the error (13568) and I have a few concerns. TechNet's AD
Ops Overview section titled "Troubleshooting FRS Event 13568"
(http://www.microsoft.com/technet/pr...ry/maintain/opsguide/part1/adogd11.mspx#E2BAC)
makes me wonder if performing a chkdsk might correct this situation. A
chkdsk has not been performed in a loooong time (~18 months). I'm going for
this one first, as this is the easiest but I doubt it will fix my FRS woes.
Second, MSKB 292438 states that enabling the journal wrap automatic restore
value (as outlined in the event error) should not be used post SP3 but it
doesn't say why. That article leads me to MSKB 290762 which goes into
authoritative and nonauthoritative restores which I have zero experience with
and I'm not certain which I might need or what would happen to these DC's in
their current state if or when FRS gets going. Right now SYSVOL on DC2 is
not shared and the Policies and scripts (w/sharing) directories (as on DC1)
are not present on (DC2).
My first consideration is the easiest--to perform a chkdsk. As stated, I do
not have any experience with authoritative and nonauthoritative restores and
I am not sure which I might need. Doing either on DC1 right now seems like a
bad idea considering DC2 holds the FSMO roles but cannot authenticate users
without DC1. Inbound connections to DC1 from DC2 seem fine. Also, the reg
entry for Replica Set Parent in
HKLM\System\CCS\Services\NTFRS\Parameters\SysVol Seeding\Domain System Volume
(SYSVOL share) is set to DC1.
DC1's days are numbered. It is going offline as soon as DC2 can function on
it's own (and DC1's files transferred to the new file server).
My "production" environment is one domain. I have another domain for
testing, etc, but nothing "production".
FRS is currently running (as viewed in Services) on DC1 but it is in a
Journal Wrap Error state.
DCDIAG on DC1: FRSSYSVOL passed but displays an error stating:
No record of File Replication System, SYSVOL started. The Active Directory
may be prevented from starting.
DCDIAG on DC2: ADVERTISING failed with the warning:
DsGetDcName retuned information for \\<DC1 FQDN>, when we were trying to
reach DC2. Server is not responding or is not considered suitable.
Here again, FRSSYSVOL passed but returned the same error as on DC1 with the
additional statement:
There are errors after the SYSVOL has been shared. The SYSVOL can prevent
the AD from starting.
Once I can get DC2 running like it should and DC1 is set out to pasture, I
plan to upgrade this DC and another new one to 2003 but that's down the road
a bit.
I'm certain file replication on DC1 is where my problem lies which has
subsequently prevented DC2 from becoming redundant for this domain.
TMM
I'm working on a 2000 domain with 2 fully patched DC's--"DC1" and "DC2".
The first--DC1--is also the main file server. The second--DC2 runs DNS,
WINS, and DHCP. I want to demote DC1 (which no longer runs WINS or DNS) and
decommission it after transferring its files to the new hardware after I fix
the below problem and I can authenticate to the domain with DC1 turned off.
DNS is good on DC2. My goal is to get DC2 running properly as primary
AD/DC/GC etc.
Scenario:
The FSMO roles were transferred to DC2 and DC2 was set as a GC. A problem
was then discovered with FRS on DC1 (NtFrs event id 13568); in addition,
domain login request are not authenticated when DC1 is off. The SYSVOL on
DC2 is also not shared which adds credibility to FRS on DC1 not working
properly when DC2 was added as an additional DC. I believe the Journal Wrap
Error for the domain system volume to be due to the fact that the FRS service
was not running for a number of months (months ago). Since FRS has been
reset to run automatically, the system has undergone (I think) two service
packs.
I've researched the error (13568) and I have a few concerns. TechNet's AD
Ops Overview section titled "Troubleshooting FRS Event 13568"
(http://www.microsoft.com/technet/pr...ry/maintain/opsguide/part1/adogd11.mspx#E2BAC)
makes me wonder if performing a chkdsk might correct this situation. A
chkdsk has not been performed in a loooong time (~18 months). I'm going for
this one first, as this is the easiest but I doubt it will fix my FRS woes.
Second, MSKB 292438 states that enabling the journal wrap automatic restore
value (as outlined in the event error) should not be used post SP3 but it
doesn't say why. That article leads me to MSKB 290762 which goes into
authoritative and nonauthoritative restores which I have zero experience with
and I'm not certain which I might need or what would happen to these DC's in
their current state if or when FRS gets going. Right now SYSVOL on DC2 is
not shared and the Policies and scripts (w/sharing) directories (as on DC1)
are not present on (DC2).
My first consideration is the easiest--to perform a chkdsk. As stated, I do
not have any experience with authoritative and nonauthoritative restores and
I am not sure which I might need. Doing either on DC1 right now seems like a
bad idea considering DC2 holds the FSMO roles but cannot authenticate users
without DC1. Inbound connections to DC1 from DC2 seem fine. Also, the reg
entry for Replica Set Parent in
HKLM\System\CCS\Services\NTFRS\Parameters\SysVol Seeding\Domain System Volume
(SYSVOL share) is set to DC1.
DC1's days are numbered. It is going offline as soon as DC2 can function on
it's own (and DC1's files transferred to the new file server).
My "production" environment is one domain. I have another domain for
testing, etc, but nothing "production".
FRS is currently running (as viewed in Services) on DC1 but it is in a
Journal Wrap Error state.
DCDIAG on DC1: FRSSYSVOL passed but displays an error stating:
No record of File Replication System, SYSVOL started. The Active Directory
may be prevented from starting.
DCDIAG on DC2: ADVERTISING failed with the warning:
DsGetDcName retuned information for \\<DC1 FQDN>, when we were trying to
reach DC2. Server is not responding or is not considered suitable.
Here again, FRSSYSVOL passed but returned the same error as on DC1 with the
additional statement:
There are errors after the SYSVOL has been shared. The SYSVOL can prevent
the AD from starting.
Once I can get DC2 running like it should and DC1 is set out to pasture, I
plan to upgrade this DC and another new one to 2003 but that's down the road
a bit.
I'm certain file replication on DC1 is where my problem lies which has
subsequently prevented DC2 from becoming redundant for this domain.
TMM