Junction Point missing

  • Thread starter Thread starter riel-edv
  • Start date Start date
R

riel-edv

FRSDIAG reports the following:
Checking for minimum FRS version requirement ... passed
Checking for errors/warnings in ntfrsutl ds ... passed
Checking for Replica Set configuration triggers... passed
Checking for suspicious file Backlog size... passed
Checking Overall Disk Space and SYSVOL structure (note: integrity is
Click to expand...
not >checked)...
ERROR: Junction Point missing on "h:\windows\sysvol\sysvol"
ERROR: Junction Point missing on "h:\windows\sysvol\staging areas"
......... failed 2
Checking for suspicious inlog entries ... passed
Checking for suspicious outlog entries ... passed
Checking for appropriate staging area size ... passed
Checking NtFrs Service (and dependent services) state...passed
Checking NtFrs related Registry Keys for possible problems...passed
Checking Repadmin Showreps for errors...passed

Final Result = failed with 2 error(s)
Click to expand...

How can I restore these junction points?




Regards Jurgen
 
riel-edv said:
FRSDIAG reports the following:
ERROR: Junction Point missing on "h:\windows\sysvol\sysvol"
ERROR: Junction Point missing on "h:\windows\sysvol\staging areas"

How can I restore these junction points?
Click to expand...
Hi,
you can test/restore the junction points with LINKD.exe from the
resource kit.
We have these two errors too :-) so I believe this is a bug in FRSDIAG.
 
Hallo Juergen,
it looks like that, if you have the same errors.
I already fixed the junction points using
"linkd c:\winnt\sysvol\sysvol\<fully qualified domain name>
c:\winnt\sysvol\domain"
but believed this wa not enough.
DO you think, this is all I had to repair?
If not, what is the coorect syntax to fix the staging areas junction point?
Danke
Juergen Riel
 
This is how your structure should look:

C:\winnt\sysvol
\Domain
- the actual data is here
\Staging
Domain
- the staging data is here

\Staging areas
\Domainname.com (points back to
c:\winnt\sysvol\staging\domain)
Linkd domainname.com
c:\winnt\sysvol\staging\domain

\Sysvol
\Domainname.com (points back to
c:\winnt\sysvol\domain)
Linkd domainname.com
c:\winnt\sysvol\domain

David Pharr, (e-mail address removed)

This posting is provided "AS IS" with no warranties, and confers no rights.
 
I had some similar problems over the past few weeks which I've been trying
every-which-way to analyze and resolve.

After all was said-and-done, the method I used to resolve the corruption
with the FRS system and the SYSVOL folders was, and this is on a network
with three DCs running AD, to demote and then re-promote each DC, one at a
time--this rebuilt the SYSVOL and NETLOGON folder structures (I made sure I
had at least one server running DNS and a GC at all times).

Then after each DC was demoted/re-promoted, I performed the BURFLAG
procedure from the DC that I know had "good" profile data, to the second of
three DCs (note that I kept the FRS service stopped on the third DC while I
was doing the BURFLAG restore routine with the second DC). Then, after the
"good" DC replicated to the second DC I stopped the FRS service on the
second DC. Now, I went back to the "good" DC, stopped its FRS service, set
its BURFLAG again to D4, set the last of three DCs to a BURFLAG of D2,
started the FRS service on the "good" DC, then started the FRS service on
the last (third) DC. This caused the "good" DC to replicate again, this time
to the third (last) DC. Then, I restarted the FRS on the second DC. After
all this was done my FRS SYSVOLs were in synch with the DSs (as shown in the
Active Directory Replication Monitor tool), replication of test files in
both the scripts folder (for NT-type policies) and the SYSVOL folder (for
GPOs) worked great between each of the DCs, and all was well.

I hope this makes some sense. If not, let me know and I can spell it out in
a more procedural format. Also, if any other readers see anything that I
might have overlooked, or some pitfalls to my process, please don't hesitate
to chime in. Why and how my FRS became corrupted I am not sure. My network
is a relatively small test network and we've got lots of cooks involved. So,
my guess is that someone may have done something they should not have, but
that's water under the bridge and I'm happy because after days of
researching this problem, and pulling out my hair, I've finally got things
working the way they should.

Regards,

Richard Huelbig
 
Richard said:
that's water under the bridge and I'm happy because after days of
researching this problem, and pulling out my hair, I've finally got things
working the way they should.
Click to expand...

Hi,
did you try FRSDIAG?
 
Juergen,


Yes, I tried FRSDIAG, DCDIAG, SONAR, and several other tools. FRSDIAG did
point to the missing junction points (before I re-promoted the DCs), and it
also listed other errors found in the ntfrs*.log files. However, the
research I did on the errors listed in the ntfrs*.log files did not yield
anything related to my network. In other words, when I ran through the
TechNet articles related to the errors in the log files, I was not able to
find any of the suspected causes (listed in the TechNet articles) for the
errors, on my DCs. This is half the reason why I was becoming so frustrated.
So, since I do have control over my network, and I only have a very few
policies installed, I decided that if I demoted/promoted the DCs, I could at
least be certain that the SYSVOL structure was correct. Then, if I still
continued to have problems I could troubleshoot from a "known, good base".
Does this make sense?

Regards,

Richard Huelbig
 
The steps you outlined make perfect sense.

If you have a known good Sysvol folder, you can simply stop FRS on all DCs,
set D4 on the known good copy, start FRS on that one and then set D2 on
each of the remaining copies. Fixing each DC one at a time is a good
approach. Burflags D4 tells the other DCs that this copy if the
authoritative one and D2 tells the DC to pull from another DC. The steps
you performed are basically those outlined in the following article (in
your case you had a good set of policies and didn't have to recreate them
from scratch):

315457 How to Rebuild SYSVOL and Its Content in a Domain
http://support.microsoft.com/?id=315457


Note: I should point out that in my earlier post the linkd commands are
not present in the folder structure. If the structure was not linked at
that point and you ran the listed linkd command in that folder it would
create a link to the correct location.

--------------------
| Reply-To: "Richard Huelbig" <[email protected]>
| From: "Richard Huelbig" <[email protected]>
| Newsgroups: microsoft.public.win2000.active_directory
| References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
| Subject: Re: Junction Point missing
| Lines: 22
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <[email protected]>
| Date: Tue, 11 Nov 2003 13:04:32 GMT
| NNTP-Posting-Host: 67.82.78.192
| X-Complaints-To: (e-mail address removed)
| X-Trace: news4.srv.hcvlny.cv.net 1068555872 67.82.78.192 (Tue, 11 Nov
2003 08:04:32 EST)
| NNTP-Posting-Date: Tue, 11 Nov 2003 08:04:32 EST
| Organization: Optimum Online
| Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!news-out.cwix.com!newsfeed.cwix.co
m!prodigy.com!newsfeed.telusplanet.net!newsfeed.telus.net!news3.optonline.ne
t!news4.srv.hcvlny.cv.net.POSTED!not-for-mail
| Xref: cpmsftngxa06.phx.gbl microsoft.public.win2000.active_directory:55812
| X-Tomcat-NG: microsoft.public.win2000.active_directory
|
| Juergen,
|
|
| Yes, I tried FRSDIAG, DCDIAG, SONAR, and several other tools. FRSDIAG did
| point to the missing junction points (before I re-promoted the DCs), and
it
| also listed other errors found in the ntfrs*.log files. However, the
| research I did on the errors listed in the ntfrs*.log files did not yield
| anything related to my network. In other words, when I ran through the
| TechNet articles related to the errors in the log files, I was not able to
| find any of the suspected causes (listed in the TechNet articles) for the
| errors, on my DCs. This is half the reason why I was becoming so
frustrated.
| So, since I do have control over my network, and I only have a very few
| policies installed, I decided that if I demoted/promoted the DCs, I could
at
| least be certain that the SYSVOL structure was correct. Then, if I still
| continued to have problems I could troubleshoot from a "known, good base".
| Does this make sense?
|
| Regards,
|
| Richard Huelbig
|
|
|

David Pharr, (e-mail address removed)

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top