NTFRS taking Way too long to share sysvol

[Jake]

I got this warning message this morning after my DC got a
JRNL_WRAP_ERROR in the ntfrs. I followed the recovery
procedures listed in the event (changed the DWORD value
in "Enable Journal Wrap Automatic Restore" parameter to 1
and restarted NTFRS.
My question is how much longer do I have to wait for the
sysvol to become "shared". Is there anything I can do to
kick start this?

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13566
Date: 7/14/2004
Time: 10:47:51 AM
User: N/A
Computer: OZ
Description:
File Replication Service is scanning the data in the
system volume. Computer OZ cannot become a domain
controller until this process is complete. The system
volume will then be shared as SYSVOL.

To check for the SYSVOL share, at the command prompt,
type:
net share

When File Replication Service completes the scanning
process, the SYSVOL share will appear.

The initialization of the system volume can take some
time. The time is dependent on the amount of data in the
system volume.

 

[Nathan]

My question is how much longer do I have to wait for the

sysvol to become "shared". Is there anything I can do to
kick start this?

Sit back and wait. Really there are too many variables to
give a good guess here as to how long it will take. How
big is your AD Database? How fast is the server?

I'm not the AD expert, but I think this is one of the
unobtrusive processes. Meaning that it will not hog all
the CPU/RAM at once. If you can find the proc and bump
it's priority to "real time" you could force it to hog
more, but could degrade performance overall.

Let it go, do other things, and when you start work
tomorrow it should be done. If not, panic.

 

[Guest]

Dang! It is our only DC and other member servers are
dependant on it. There has to be a way to speed things
up.

 

[ptwilliams]

Forever!! ;-)

You need to set the Burflags value to 'D2' for an non-authorative restore
(which, if you've other working DCs, is what you want).

Like Nathan said, this'll depend on the size, topology, etc. but I wouldn't
expect it to take more that an hour unless you have a *huge* environment, or
this DC is the only DC at a remote site.

--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________


I got this warning message this morning after my DC got a
JRNL_WRAP_ERROR in the ntfrs. I followed the recovery
procedures listed in the event (changed the DWORD value
in "Enable Journal Wrap Automatic Restore" parameter to 1
and restarted NTFRS.
My question is how much longer do I have to wait for the
sysvol to become "shared". Is there anything I can do to
kick start this?

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13566
Date: 7/14/2004
Time: 10:47:51 AM
User: N/A
Computer: OZ
Description:
File Replication Service is scanning the data in the
system volume. Computer OZ cannot become a domain
controller until this process is complete. The system
volume will then be shared as SYSVOL.

To check for the SYSVOL share, at the command prompt,
type:
net share

When File Replication Service completes the scanning
process, the SYSVOL share will appear.

The initialization of the system volume can take some
time. The time is dependent on the amount of data in the
system volume.

 

[Jim Singh]

Journal is a log file that keeps track of the changes made to the ntfs5.0
volumes and this log file is of fixed size by default but can be increased
to 128mb by configuring the following registry key:

HKLM\System\Ccs\Services\Ntfrs\Parameters\ntfs journal size

It depends how big is the volume that its trying to update. You should not
stop the FRS service for longer period of time as it can cause in the
journal wrap errors. I dont think there is a way to kick start it but you
can check it at MS site.
-Jim

 

[ptwilliams]

Oh, only one DC?!? It's going to involve a little more work then ;-)

This may help as a start:
-- http://support.microsoft.com/?id=263532

And here's another article that may help:
-- http://www.jsiinc.com/SUBM/tip6100/rh6153.htm


I do hope you have a regular backup...


--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________


Dang! It is our only DC and other member servers are
dependant on it. There has to be a way to speed things
up.

 

[ptwilliams]

SP3 made it 128MB.
SP4 made it 512MB...

Also, older antivirus or poor network conditions can cause this; not just
Frs being stopped.

--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________


Journal is a log file that keeps track of the changes made to the ntfs5.0
volumes and this log file is of fixed size by default but can be increased
to 128mb by configuring the following registry key:

HKLM\System\Ccs\Services\Ntfrs\Parameters\ntfs journal size

It depends how big is the volume that its trying to update. You should not
stop the FRS service for longer period of time as it can cause in the
journal wrap errors. I dont think there is a way to kick start it but you
can check it at MS site.
-Jim

 

[Jake]

This is the only DC at my site. So can I do a non
authorative restore to get things moving?

 

[Guest]

That key does not exist in the registry

-----Original Message-----
Journal is a log file that keeps track of the changes made to the ntfs5.0
volumes and this log file is of fixed size by default but can be increased
to 128mb by configuring the following registry key:

HKLM\System\Ccs\Services\Ntfrs\Parameters\ntfs journal size

It depends how big is the volume that its trying to update. You should not
stop the FRS service for longer period of time as it can cause in the
journal wrap errors. I dont think there is a way to kick start it but you
can check it at MS site.
-Jim





.

 

[Jim Singh]

You have to add the following key "Ntfs Journal size in MB" of value
REG_DWORD, in the HKLM\System\Ccs\Services\Ntfrs\Parameters\. You can set
the sieze from 8mb to 128mb. The default recommended size is 32mb atleast.

-Jim

 

[Jake]

I spoke with Microsoft Support. Stopped NTFRS, copied
policies and scripts from the
\sysvol\sysvol\<domain>\preexisting folder to my desktop,
change the burflag value to D4, restarted NTFRS, and
copied the policies and scripts back into the domain
folder. PRoblem solved. YEEEEHHAAAA!

 

[ptwilliams]

My good man, that is old advice.

The current amount is 512MB. This is recommended; not anything less. This
doesn't require changing.

--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________


You have to add the following key "Ntfs Journal size in MB" of value
REG_DWORD, in the HKLM\System\Ccs\Services\Ntfrs\Parameters\. You can set
the sieze from 8mb to 128mb. The default recommended size is 32mb atleast.

-Jim

 

[ptwilliams]

As you now know, no. You'd need to perform an authorative restore.

--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________


This is the only DC at my site. So can I do a non
authorative restore to get things moving?

 

[ptwilliams]

Glad you got it sorted...

Well done. ;-)


--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________


I spoke with Microsoft Support. Stopped NTFRS, copied
policies and scripts from the
\sysvol\sysvol\<domain>\preexisting folder to my desktop,
change the burflag value to D4, restarted NTFRS, and
copied the policies and scripts back into the domain
folder. PRoblem solved. YEEEEHHAAAA!