FRS: Invalid Parameter Errors

[James Palic]

I trust this is the correct ng... I can't seem to find a W2K3 specific ng for DFS.

We have a simple setup - two sites each with a W2K3 DC.

Back in February the SYSVOL stopped replicating. AD info
seems to be replicating just fine. DNS seems to be working. DCDIAG
doesn't report any issues. I can ping and nslookup the FQDN of each
DC as well as the domain name.

We have one other DFS directory that replicates between these two DC's
and it seems to replicate ok.

There are no errors in the event log. But I'm seeing in the
%systemroot%\debug\ntfrs_????.log files a series of entries that looks
like this for each file that is attempting to replicate:

=============================================
<StuExecuteInstall: 3036: 2271: S1: 12:03:08> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_FILE_NOT_FOUND

<ProcessOpenByIdStatus: 3036: 3010: S1: 12:03:09> ++ EB040000
00002BF0 Fid Open failed; NTStatus: STATUS_INVALID_PARAMETER

<FrsOpenSourceFileById: 3036: 3360: S0: 12:03:09> ++ ERROR -
NtCreateFile failed : NTStatus: STATUS_INVALID_PARAMETER

<StuOpenDestinationFile: 3036: 653: S0: 12:03:09> :: CoG
4def00c1, CxtG 4e1ae42a, FV 0, FID eb040000 00002bf0,
FN: Policies_NTFRS_038bdbf6, [FrsForceOpenId failed.
(ERROR_INVALID_PARAMETER)]

<StuExecuteInstall: 3036: 2271: S1: 12:03:09> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_FILE_NOT_FOUND

=============================================

The only error condition I'm seeing in SONAR is a long join cycle on
one of the DC's.

A week or so ago I did an authoritative restore by setting the
BURFLAGS to D4 on one box and D2 on the other and the inital
replication occurred ok. But changes since then don't replicate. I
tried the authoritative restore again but it didn't work this time.

I'd really like to figure out how to fix this without totally starting
over but I don't even know where to begin. Any thoughts?

Thanks.

Jim

[Jill Zoeller [MS]]

It sounds like there is something misconfigured somewhere that is causing
FRS to fail and you need to find and fix that problem. As you've discovered,
a D4/D2 does not fix FRS if the underlying problems still exist.

I recommend you install Ultrasound, a new FRS monitoring tool that is more
sophisticated than Sonar. Ultrasound can detect and report errors for FRS
and some basic errors for DNS/AD. The tool also includes a Help file that
has an FRS troubleshooter that is also used by PSS. The help file can walk
you through checking the FRS dependencies and identifying the root cause.

You can install Ultrasound and view details about other FRS tshooting tools
at
http://www.microsoft.com/windowsserver2003/technologies/fileandprint/file/dfs/tshootfrs.mspx.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Post by James Palic
I trust this is the correct ng... I can't seem to find a W2K3 specific ng for DFS.
We have a simple setup - two sites each with a W2K3 DC.
Back in February the SYSVOL stopped replicating. AD info
seems to be replicating just fine. DNS seems to be working. DCDIAG
doesn't report any issues. I can ping and nslookup the FQDN of each
DC as well as the domain name.
We have one other DFS directory that replicates between these two DC's
and it seems to replicate ok.
There are no errors in the event log. But I'm seeing in the
%systemroot%\debug\ntfrs_????.log files a series of entries that looks
=============================================
<StuExecuteInstall: 3036: 2271: S1: 12:03:08> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_FILE_NOT_FOUND
<ProcessOpenByIdStatus: 3036: 3010: S1: 12:03:09> ++ EB040000
00002BF0 Fid Open failed; NTStatus: STATUS_INVALID_PARAMETER
<FrsOpenSourceFileById: 3036: 3360: S0: 12:03:09> ++ ERROR -
NtCreateFile failed : NTStatus: STATUS_INVALID_PARAMETER
<StuOpenDestinationFile: 3036: 653: S0: 12:03:09> :: CoG
4def00c1, CxtG 4e1ae42a, FV 0, FID eb040000 00002bf0,
FN: Policies_NTFRS_038bdbf6, [FrsForceOpenId failed.
(ERROR_INVALID_PARAMETER)]
<StuExecuteInstall: 3036: 2271: S1: 12:03:09> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_FILE_NOT_FOUND
=============================================
The only error condition I'm seeing in SONAR is a long join cycle on
one of the DC's.
A week or so ago I did an authoritative restore by setting the
BURFLAGS to D4 on one box and D2 on the other and the inital
replication occurred ok. But changes since then don't replicate. I
tried the authoritative restore again but it didn't work this time.
I'd really like to figure out how to fix this without totally starting
over but I don't even know where to begin. Any thoughts?
Thanks.
Jim

[James Palic]

I do have Ultrasound installed although I don't consider myself a
sophisticated user. What I see in Ultrasound is that there are
sharing violations on all of the files in the Sysvol directory that
should be replicating. The state is reported as 13.

The Ultrasound help suggests that the sharing violation has to do with
another user or processing having the file open. When I use
Sysinternals procmon utility to look for processes having something to
do with SYSVOL I see only:

System c:\winnt\sysvol\sysvol
ntfrs c:\winnt\sysvol\domain\DO_NO_REMOVE_ntfrs_preinstall_directory
explorer c:\sysvol\domain

None of these match any of the files that are reporting sharing
violations. I think that the sharing violation is being reported as a
symptom but that the actual issue is something else - the question is
what else?

When I run netdiag, dcdiag, replmon, and topchk I see no errors.

Connstat reports:

Replica: DOMAIN SYSTEM VOLUME (SYSVOL SHARE)
(6480d1e2-5daf-43c2-b50ba9a810c60d29)
Member: TOMBSTONE ServiceState: 3 (ACTIVE)
OutLogSeqNum: 2943 OutlogCleanup: 2943 Delta: 0
Config Flags: Multimaster Primary Online
Root Path : c:\winnt\sysvol\domain
Staging Path: c:\winnt\sysvol\staging\domain
File Filter : *.tmp, *.bak, ~*
Dir Filter :

Partner I/O State Rev LastJoinTime
<Jrnl Cxtion> In Joined 0
WILMNT\BATH$ In Joined 8 Tue May 4, 2004
18:15:49
WILMNT\BATH$ Out Unjoined 8 Tue May 4, 2004
18:15:50

Send Cleanup Cos
OLog State Leadx Delta Trailx Delta LMT Out Last VVJoin
OLP_INACTIVE 2943 0 2943 0 0 0 Thu Apr 22, 2004
19:46:12

The Out connection from BATH was last VVJoin'ed on April 22. But
again this is probably a symptom generated because of the sharing
violations and not the root cause.

Can you offer any thoughts on where to look next?

Thanks.

Jim

Post by Jill Zoeller [MS]
It sounds like there is something misconfigured somewhere that is causing
FRS to fail and you need to find and fix that problem. As you've discovered,
a D4/D2 does not fix FRS if the underlying problems still exist.
I recommend you install Ultrasound, a new FRS monitoring tool that is more
sophisticated than Sonar. Ultrasound can detect and report errors for FRS
and some basic errors for DNS/AD. The tool also includes a Help file that
has an FRS troubleshooter that is also used by PSS. The help file can walk
you through checking the FRS dependencies and identifying the root cause.
You can install Ultrasound and view details about other FRS tshooting tools
at
http://www.microsoft.com/windowsserver2003/technologies/fileandprint/file/dfs/tshootfrs.mspx.

[Jill Zoeller [MS]]

We have a couple good KB articles on sharing violations, as well as a hotfix
that might help.

The articles are 822300 and 816493.

You might also try running FRSDiag to see if it reports anything. It's also
available at
http://www.microsoft.com/windowsserver2003/technologies/fileandprint/file/dfs/tshootfrs.mspx.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Post by James Palic
I do have Ultrasound installed although I don't consider myself a
sophisticated user. What I see in Ultrasound is that there are
sharing violations on all of the files in the Sysvol directory that
should be replicating. The state is reported as 13.
The Ultrasound help suggests that the sharing violation has to do with
another user or processing having the file open. When I use
Sysinternals procmon utility to look for processes having something to
System c:\winnt\sysvol\sysvol
ntfrs c:\winnt\sysvol\domain\DO_NO_REMOVE_ntfrs_preinstall_directory
explorer c:\sysvol\domain
None of these match any of the files that are reporting sharing
violations. I think that the sharing violation is being reported as a
symptom but that the actual issue is something else - the question is
what else?
When I run netdiag, dcdiag, replmon, and topchk I see no errors.
Replica: DOMAIN SYSTEM VOLUME (SYSVOL SHARE)
(6480d1e2-5daf-43c2-b50ba9a810c60d29)
Member: TOMBSTONE ServiceState: 3 (ACTIVE)
OutLogSeqNum: 2943 OutlogCleanup: 2943 Delta: 0
Config Flags: Multimaster Primary Online
Root Path : c:\winnt\sysvol\domain
Staging Path: c:\winnt\sysvol\staging\domain
File Filter : *.tmp, *.bak, ~*
Partner I/O State Rev LastJoinTime
<Jrnl Cxtion> In Joined 0
WILMNT\BATH$ In Joined 8 Tue May 4, 2004
18:15:49
WILMNT\BATH$ Out Unjoined 8 Tue May 4, 2004
18:15:50
Send Cleanup Cos
OLog State Leadx Delta Trailx Delta LMT Out Last VVJoin
OLP_INACTIVE 2943 0 2943 0 0 0 Thu Apr 22, 2004
19:46:12
The Out connection from BATH was last VVJoin'ed on April 22. But
again this is probably a symptom generated because of the sharing
violations and not the root cause.
Can you offer any thoughts on where to look next?
Thanks.
Jim

Post by Jill Zoeller [MS]
It sounds like there is something misconfigured somewhere that is causing
FRS to fail and you need to find and fix that problem. As you've discovered,
a D4/D2 does not fix FRS if the underlying problems still exist.
I recommend you install Ultrasound, a new FRS monitoring tool that is more
sophisticated than Sonar. Ultrasound can detect and report errors for FRS
and some basic errors for DNS/AD. The tool also includes a Help file that
has an FRS troubleshooter that is also used by PSS. The help file can walk
you through checking the FRS dependencies and identifying the root cause.
You can install Ultrasound and view details about other FRS tshooting tools
at

http://www.microsoft.com/windowsserver2003/technologies/fileandprint/file/dfs/tshootfrs.mspx.