Login Script Replication Quandry

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Jeff M - 28 Jul 2005 21:03 GMT

Little confused on how to get the scripts in my sysvol directory to replicate
to 3 other 2000 servers in my domain? It is a simple kix script that just
seems to be stubborn and won't copy down to the other boxes. FRS service is
running, DFS service is running but no dfs roots defined and under AD sites
and services there appear to be links or relationships between the 4 servers.
What am I missing?]

Thanks

Reply to this Message

Paul Williams [MVP] - 28 Jul 2005 22:13 GMT

Firstly, verify replication is taking place with REPLMON or REPADMIN. Then
check the FRS event logs on each DC. Come back to us with any errors/
warnings/ suspicions.

Signature

Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

Reply to this Message

Ulf B. Simon-Weidner [MVP] - 29 Jul 2005 08:32 GMT

> Little confused on how to get the scripts in my sysvol directory to replicate
> to 3 other 2000 servers in my domain? It is a simple kix script that just
> seems to be stubborn and won't copy down to the other boxes. FRS service is
> running, DFS service is running but no dfs roots defined and under AD sites
> and services there appear to be links or relationships between the 4 servers.
> What am I missing?]

Hi Jeff,

Where did you put the script and what is the path? If you are assigning
the script via GPOs, you can open up the GPO in the Group Policy Editor,
go to the Logon-Script GPO, in the properties click browse and drag and
drop your script in the directory which is opening. This makes sure the
script is in the right directory underneath the specific GPO in your
sysvol-dfs-share.

If you are assigning the script via the properties of the user, then
make sure you can see the script when you browse to your
\\domain.com\netlogon -share. If it's not in there, put it in underneath
your sysvol-directory in the scripts folder (which is shared as
netlogon) - you won't be able to drag and drop it in the netlogon-share
since this is read only.

Then verify that the script appears in the same location on other DCs.
This should work.

--
Gruesse - Sincerely,

Ulf B. Simon-Weidner

MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz
Weblog: http://msmvps.org/UlfBSimonWeidner
Website: http://www.windowsserverfaq.org

Reply to this Message

Jeff M - 29 Jul 2005 14:17 GMT

Presently, we are assigning the login script via the properties of the user.
I have checked and the script is located in the proper place and also was
manually copied to the other scripts folders on the 3 other DC's. Using
group policy for this is on our "to do" list, but for now if I make a change
in the login script on one controller will that changed script get
automatically replicated and copied down to the other 3 DC's or will I need
to manually copy it each time?

> > Little confused on how to get the scripts in my sysvol directory to replicate
> > to 3 other 2000 servers in my domain? It is a simple kix script that just
[quoted text clipped - 30 lines]
> Weblog: http://msmvps.org/UlfBSimonWeidner
> Website: http://www.windowsserverfaq.org

Reply to this Message

Ulf B. Simon-Weidner [MVP] - 29 Jul 2005 14:40 GMT

> Presently, we are assigning the login script via the properties of the user.
> I have checked and the script is located in the proper place and also was
[quoted text clipped - 3 lines]
> automatically replicated and copied down to the other 3 DC's or will I need
> to manually copy it each time?

As long as the script is in the \\domain.com\netlogon share and the file
replication is running correctly (it'll say in your eventlog otherwise)
then the script will be synced automatically, you only need to change it
on one server.

--
Gruesse - Sincerely,

Ulf B. Simon-Weidner

MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz
Weblog: http://msmvps.org/UlfBSimonWeidner
Website: http://www.windowsserverfaq.org

Reply to this Message

Jeff M - 29 Jul 2005 15:29 GMT

I will keep an eye on the file repliction. Thanks again for the guidance.
It is great to have a place to get a sanity check to see if where you are
standing is correct.

> > Presently, we are assigning the login script via the properties of the user.
> > I have checked and the script is located in the proper place and also was
[quoted text clipped - 17 lines]
> Weblog: http://msmvps.org/UlfBSimonWeidner
> Website: http://www.windowsserverfaq.org

Reply to this Message

Paul Williams [MVP] - 29 Jul 2005 16:05 GMT

I posted this on the 28th, but it hasn't shown up. I'll post it again, as
it kind of goes on the end of what Ulf said to do...

[Thursday's post]
Firstly, verify replication is taking place with REPLMON or REPADMIN. Then
check the FRS event logs on each DC. Come back to us with any errors/
warnings/ suspicions.

[New]
If your AD is replicating but SYSVOL isn't, it's usually down to a
JRNL_WRAP_ERROR or something similar.

Signature

Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

Reply to this Message

Jeff M - 29 Jul 2005 16:08 GMT

Paul, when I went to check the file replication
service it pointed me to this error:
The File Replication Service has detected that the replica set "DOMAIN
SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.

Replica set name is : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replica root path is : "c:\winnt\sysvol\domain"
Replica root volume is : "\\.\C:"
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to
read from the NTFS USN journal is not found. This can occur because of one
of the following reasons.

[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can
truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long
time.
[5] File Replication Service could not keep up with the rate of Disk IO
activity on "\\.\C:".
Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1
will cause the following recovery steps to be taken to automatically recover
from this error state.
[1] At the first poll, which will occur in 5 minutes, this computer will be
deleted from the replica set. If you do not want to wait 5 minutes, then run
"net stop ntfrs" followed by "net start ntfrs" to restart the File
Replication Service.
[2] At the poll following the deletion this computer will be re-added to
the replica set. The re-addition will trigger a full tree sync for the
replica set.

WARNING: During the recovery process data in the replica tree may be
unavailable. You should reset the registry parameter described above to 0 to
prevent automatic recovery from making the data unexpectedly unavailable if
this error condition occurs again.

To change this registry parameter, run regedit.

Click on Start, Run and type regedit.

Expand HKEY_LOCAL_MACHINE.
Click down the key path:
"System\CurrentControlSet\Services\NtFrs\Parameters"
Double click on the value name
"Enable Journal Wrap Automatic Restore"
and update the value.

If the value name is not present you may add it with the New->DWORD Value
function under the Edit Menu item. Type the value name exactly as shown
above.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

My question is, by enabling the registry key for "enable journal wrap
automatic restore" is there any risks to this server being blown up? This
key presently does not exist? Should I enable this or is there something else
I should do?

> I posted this on the 28th, but it hasn't shown up. I'll post it again, as
> it kind of goes on the end of what Ulf said to do...
[quoted text clipped - 7 lines]
> If your AD is replicating but SYSVOL isn't, it's usually down to a
> JRNL_WRAP_ERROR or something similar.

Reply to this Message

Paul Williams [MVP] - 29 Jul 2005 17:12 GMT

> My question is, by enabling the registry key for "enable journal wrap
> automatic restore" is there any risks to this server being blown up? This
> key presently does not exist? Should I enable this or is there something
> else I should do?

The server won't blow up, but that key is no longer the recommendation
(although it obviously works). You should stop NtFrs, set the BurFlags to
D2, and then start NtFrs.

Here's the Key:

HKLM\ SYSTEM\ CurrentControlSet\ Services\ NtFrs\ Parameters\
Backup/Restore\ Process at Startup
BurFlags

You do this on the dodgy DC; not on the others.

Signature

Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

Reply to this Message

Jeff M - 29 Jul 2005 17:29 GMT

Ok, presently the BurFlags is set to REG_DWORD 0, hex, when you say set it to
"D2" are you talking about just changing the value in the field to 2 or
actually D2? just want to be sure

> > My question is, by enabling the registry key for "enable journal wrap
> > automatic restore" is there any risks to this server being blown up? This
[quoted text clipped - 12 lines]
>
> You do this on the dodgy DC; not on the others.

Reply to this Message

Jeff M - 29 Jul 2005 19:13 GMT

found it, changed it and I think it fixed the problem, going to validate it
now.

Thanks to you and Ulf for all of your help and time!

> Ok, presently the BurFlags is set to REG_DWORD 0, hex, when you say set it to
> "D2" are you talking about just changing the value in the field to 2 or
[quoted text clipped - 16 lines]
> >
> > You do this on the dodgy DC; not on the others.

Reply to this Message

Paul Williams [MVP] - 31 Jul 2005 23:26 GMT

No problem! And yes, it was actually D2 ;-)

Signature

Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net

Reply to this Message

Jeff M - 29 Jul 2005 15:58 GMT

Ulf, one last question for you. When I went to check the file replication
service it pointed me to this error:
The File Replication Service has detected that the replica set "DOMAIN
SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.

Replica set name is : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replica root path is : "c:\winnt\sysvol\domain"
Replica root volume is : "\\.\C:"
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to
read from the NTFS USN journal is not found. This can occur because of one
of the following reasons.

[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can
truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long
time.
[5] File Replication Service could not keep up with the rate of Disk IO
activity on "\\.\C:".
Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1
will cause the following recovery steps to be taken to automatically recover
from this error state.
[1] At the first poll, which will occur in 5 minutes, this computer will be
deleted from the replica set. If you do not want to wait 5 minutes, then run
"net stop ntfrs" followed by "net start ntfrs" to restart the File
Replication Service.
[2] At the poll following the deletion this computer will be re-added to
the replica set. The re-addition will trigger a full tree sync for the
replica set.

WARNING: During the recovery process data in the replica tree may be
unavailable. You should reset the registry parameter described above to 0 to
prevent automatic recovery from making the data unexpectedly unavailable if
this error condition occurs again.

To change this registry parameter, run regedit.

Click on Start, Run and type regedit.

Expand HKEY_LOCAL_MACHINE.
Click down the key path:
"System\CurrentControlSet\Services\NtFrs\Parameters"
Double click on the value name
"Enable Journal Wrap Automatic Restore"
and update the value.

If the value name is not present you may add it with the New->DWORD Value
function under the Edit Menu item. Type the value name exactly as shown
above.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

My question is, by enabling the registry key for "enable journal wrap
automatic restore" is there any risks to this server being blown up? This
key presently does not exist? Should I enable this or is there something else
I should do?

Thanks again

Reply to this Message