AD Problem involving FRS

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
 
G

Guest

Hi TMM,

I was reading your post and could see scenario i am facing currently. I have
exactly same problem with journal wrap but in my case there was only one
windows 2000 server configured as DC. Second DC was removed long time ago but
was never demoted and/or removed from AD.
I can not recall when journal wrap problem appeared first but here i what i
did:


1. installed new 2000 server on other computer.
2. enabled in/out replication on first DC (one with journal wrap problem,
holder of fsmo roles and GC)
3. setup AD (dcpromo) on new server.
4. restarted and everything seems ok on the second DC.

I have ntfrs not starting problems when i reboot first DC but i can start it
manually and after that it seems that it works fine, no entries in event
viewer or anything what can point to the replication problem (journal wrap
problem is still there but AD is replicating good)

Due to the users and workload, i can not afford switching off first DC at
any time but i will wait until tonight where i will try to login to the DC
only when second DC is on and running.

Will post outcone in this thread to let you know.

I`m curious if you got anywhere with the approach you intended to do?

Thanks

Jeremija
 
G

Guest

Jeremija,

I have an identical hardwre server that I am setting up in my lab and i plan
to image and restore my primary DC--the one withthe problem--to my lab server
and mess with that one.

I suspect if you turn off your primary server, your users will not be able
to authenticate to the domain. Check to see if the sysvol is shared on your
secondary server. If not, then setting it up never completed fully as this
volumn gets shared when adding as a secondary DC to an existing domain.

Look into DCDIAG in the tools for Server 2000. It reveals a lot of info.
 
G

Guest

TMM,

I did some tests last night, first DC was off and logon and authentication
to the second dc was failing with error that "specified domain could not be
contacted".
I found out that as you said, sysvol was not shared so i did it through
registry

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
Changed SysvolReady data value from 0 to 1.

Also entered second DNS to point to second DC and worked like charm even
without restarting.

I am able to login now only to the second DC while first one is off and that
sounds good.

My idea is folloeing:
1. transfer FSMO roles to the second dc
2. make second DC global catalog
3. demote first domain controller (one with journal wrap problem)
4. install fresh win2000 server on that server
5. dcpromo it to the domain controller
6. transfer back FSMO roles
7. making it global catalog and leaving other DC to be global catalog as well

This sounds like reasonable and working scenario in order to fix journal
wrap errors, what do you think?

My colegue did restoration of problematic server (journal wrap problem)
image but on different hardware and as far as he told me he did not face JW
problem....

Thank you TMM

Jeremija
 
G

Guest

Jeremija,

All you did to get your sysvol shared was the registry edit? I think that
may be all I need to do as well, if that is the case. My 2nd DC is already
my FSMO and GC. Unless I heard otherwise from you, I'll try your regedit
this weekend with my primary DC offline.

Your 7 step plan sound solid to me

TMM
 
G

Guest

TMM,

exactly, all that was done to share SYSVOL in my case was registry edit

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
Changed SysvolReady data value from 0 to 1.

before editing do NET SHARE on the second DC and check if SYSVOL is appearing.

You can try following as well:
1. shutdown your second dc
2. unplug it from the network
3. start second dc
4. logon as domain admin
5. start AD users and cumputers MMC (in my case i could not see anything and
had errors opening it)
6. close AD users and computers MMC
7. do registry edit for SYSVOL share
8. start AD users and computers MMC again. (in my case, no errors after 7th
step and i could see all containers again.

Hope that helps TMM

Jeremija
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top