can't get logon scripts to replicate


i have two domain controllers.

i want the logon scripts to replicate from one to the other,
server1 d:\winnt\sysvol\sysvol\\scripts
server2 c:\winnt\sysvol\sysvol\\scripts

How do i go about getting this to work?

Who is Participating?
Well, one option you can try that shouldn't take too much time is to use DCPROMO and demote one of the servers (whichever one WASN'T the first server for your domain) back to a normal server then promote it back up again.

I'm going to presume Server1 was the first server in your domain and that Server1 and Server2 are your only domain controllers in the domain, tree, and forest.  Please adjust accordingly if that's not so.  You'll probably want to do most of this work after hours.  

If you've transferred any FSMO roles ("Operations Masters") from Server1 to Server2, you'll need to transfer them back to Server1.  FSMO roles are: Schema Master, PDC Emulator, etc.  I THINK DCPromo will warn you and allow you to transfer them as part of the DCPromo operation -- but let's not take chances.

Make sure Server1 is running DNS, WINS, DHCP, DFS, and any other critical services.

Make sure Server1 is configured with the primary internal DNS domain (,, or whatever) being an Active Directory integrated domain.

Make sure Server1 has (the loopback address) as the ONLY DNS server it uses and set all connections to NOT register themselves in DNS (DC's do this automatically as part of AD/DNS integration and making it happen again causes boot time to be excessively long).  If it won't let you set it to, try leaving it blank and/or using the static address.  If multi-homed, use the internal address and make sure your binding order has the internal adapter first for everything.

Go to to make sure you have all the latest patches applied to Server1.

Go to AD Sites & Services and remove all connections you manually configured.  AD should create them automatically as part of the following process.

Run DCPromo on Server2 to demote Server2 to a member server.  Then shut it down and turn it off.

Reboot Server1.

Wait until Server1 is back up for 10 minutes or so (or check the event logs to make sure it's done with all the integrity checks & such) then boot Server2 back up.

Check that DNS settings on Server2 are identical to Server1 and that the DNS Service is installed -- this includes NOT having the machine register itself.  The only exception to this is that the primary DNS server for Server2 should be set to Server1 at this moment (once Server2 is up and running on its own as a DC and replicating successfully with Server1, you should change it to use same as Server1).

Go to WindowsUpdate to make sure Server2 is running all the latest patches.

DCPromo Server2 and promote it as an additional DC in the existing domain.

Configure DNS on Server2 to host the AD-integrated internal DNS zone also.

Go to WindowsUpdate a last time on Server2 to make sure there are no DC-specific patches you didn't pick up before you DCPromoed (3 steps ago).

Reboot Server2.  Check site replication.  If replication connections aren't there, check topology.  If they are, tell them to "replicate now".  Check the logs.  If something is still failing, reboot Server 1 and try again.

NOTE: If you have a LARGE domain or a slow network; please make sure you allow time for AD Replication in all these steps.

Good luck!

Do you have a thrust between these two domains ?

ccaathlAuthor Commented:
sorry, two domain controllers on the same domain

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

your file replication service is not working.

Does the NETLOGON share exist on each server?

Also you might want to read

"How to Troubleshoot FRS and DFS [Q272279]"
"SYSVOL Directory Is Slow to Synchronize [Q250545]"
"Replicating Logon Scripts and the Directory Replicator Service [Q271650]"

ccaathlAuthor Commented:
yes, NETLOGON exists on server1 as

and on server2 as

I was under the impression that simply by putting objects into the SYSVOL folder replication would happen automatically. Is this not the case?

I have also stopped and re-started the File Replication Service and it made no difference
you copy the source files to c:\WINNT\SYSVOL\domain\scripts NOT C:\WINNT\SYSVOL\sysvol\<DOMAIN.DOMAIN>\scripts
ccaathlAuthor Commented:
i created a file on server1 in c:\WINNT\SYSVOL\domain\scripts  and it copied it to server 1 C:\WINNT\SYSVOL\sysvol\<DOMAIN.DOMAIN>\scripts

nothing copied to server2 at all.

so now i'm completely lost.

also, it is the start of a long weekend here in the UK and so I won't be able to check until 9am BST on Tuesday.

Hope there's still help out there when that time comes!
And thanks for all the help so far of course.
sometime "time" fixes replication in Windows 2000.  I bet it will work on Tuesday.  Have a nice weekend!
As a validation test, I'd reboot both servers (not at the same time) and see if that clears the problem.

If not, check your replication connections and schedule under Active Directory Sites and Services -- Sites, Default-First-Site-Name, Servers, Server1, NTDS Settings:  there should be a connection to Server2.  Likewise, Server2's NTDS Settings should have a connection to Server1.  If one of those isn't true, run "Check Replication Topology" under the "All Tasks" option.  If both do exist, make sure the schedule for both is configured (set it to all times, 4 times per hour while troubleshooting).

I'm almost positive SYSVOL replication is controlled as part of the AD replication process.

In my experience, when you copy a file to \\server\sysvol\domainname.ext\scripts or locally to c:\winnt\sysvol\domain\scripts on the DC both of those replicate correctly.  I don't know about locally to c:\winnt\sysvol\sysvol\domainname.ext\scripts.

Last note:  check c:\winnt\debug\NtFrs_0001.log and all other NtFrs_xxxx.log files to see if there are any errors being logged that might clue you in about the source of the problem.
from Server1 Ping Server2 and from Server2 ping Server1.  Please confirm if it is resolving the FQN DNS name correctly from both server, i.e the ping replies with "
server1.domain.domain" and "server2.domain.domain"  The suffix should be the same.  Disjointed domain names in AD are quite common and will cause repliction to stop.

ccaathlAuthor Commented:

Greg: I created the connections since they weren't there and it has made no difference - reboots and all. The log files contain no obvious errors.

Darren: I tried the ping and it turns out Server2 pinging 1 will resolve the full name ( while Server1 pinging 2 only displays the server2 name.
Where can I rectify this. I have tried ading extra DNS references but it makes no difference.

Many thanks,
ccaathlAuthor Commented:
thanks for that, i see what you're getting at

however, i follow your steps to where i start to demote server2. After putting in the password the process fails with this message:

The operation failed because:
The Directory Service failed to replicate off the changes made locally.
"The DSA operation is unable to proceed because of a DNS lookup failure".

I then tried by making the DNS server itself ( and by removing forwarders within DNS.
Still no success though.

Thanks again for the suggestions though.
when you look at the Network Identication properties on SERVER2 what do you see?

Does it show "SERVER2.DOMAIN.DOMAIN" or "SERVER2" as the full computer name...or is it something else?

Set both Server1 and Server2 to use Server1 as the primary DNS server.  Open your domain in the DNS Manager on Server1 and alter the SOA record so that the zone version number is dramatically higher than what it is now (like add 1000 to the version number) and make sure server1 is set as the SOA server.  Make sure the DNS service is running on Server1.  Stop and disable the DNS service on Server2.  Restart the DNSCache (DNS Client) service on both servers.  Then retry demotion.
ccaathlAuthor Commented:
Greg, your last comment didn't work. I take it you meant the Start of Authority within the properties?
I incremented the Serial Number because I could find no Zone Version Number. This is the value you increase using the Increment button?

I checked the Network ID and both machines are

Thanks, Tom
Yes, I'm sorry, the SOA record is the "Start Of Authority" record and it's "Serial Number" in the dialog.  Event logs will refer to it as the zone version number, however.  The terms are synonymous.

After all that, it still didn't work... are these two servers on the same subnet?  Could one of them have an incorrect subnet mask?  Did you try running an "ipconfig /all" at the command prompt for each machine and checking to see if everything matched up between the two machines?  Is either machine multi-homed (has more than one network card)?

Changing tacts:  Make sure both machines have "" as the "DNS suffix for this connection" on the DNS tab of the TCPIP properties for the primary (internal network) network card.  Set "Append these DNS Suffixes" to have "" as the first appendix in the list.  On Server2, set the primary DNS server to Server1 and CHECK both the "Register this connection's addresses in DNS" and "Use this connection's DNS suffix in DNS registration".  Reboot Server2.

Look at DNS for your zone and verify that both servers are running the same version number after Server2 reboots (or verify that DNS is disabled on Server2).

Check to see that both machines have Host (A) records in your zone.

Check that both servers have alias records under the _msdcs folder.

Check that both have _kerberos and _ldap entries under both the "_msdcs/dc/_sites/Default-First-Site-Name/_tcp" and "_msdcs/dc/_tcp" folders.

Make sure there are _ldap entries under the "_msdcs/domains/(GUID here)/_tcp" folder.

Make sure Server1 has a _ldap entry under the "_msdcs/gc/_sites/Default-First-Site-Name/_tcp" and "_msdcs/gc/_tcp" folders and that Server2 does NOT.  If Server1 doesn't, go to AD Sites & Services, Sites, Default-First-Site-Name, Servers, SERVER1, right-click NTDS settings and select "properties", CHECK "Global Catalog".  If Server2 DOES have an entries there, go to SERVER2's NTDS properties and UNCHECK "Global Catalog".

Check to make sure both machines have entries under "_sites/Default-First-Site-Name/_tcp" and "_tcp" for _ldap and _kerberos and that Server1 has a _gc entry.  Both machines should also have _kpasswd entries under "_tcp" and _kpasswd and _kerberos entries under "_udp"

Don't try to add records manually at this point -- just verify that those records are there.  If they aren't, they should give us a clue as to what is going on.
ccaathlAuthor Commented:
My God It's Working!
I managed to get AD to uninstall and then DCPROMOed it back up.

The reason it wasn't leting itself be demoted was because I still had DNS Server running as a service.

So now that it has been demoted and promoted it is replicating fine.

I'll be sure to use a combination of your other suggestions Greg to fine tune the two servers before they go live. Now all I've got to do is get Exchange 2000 working on it! Watch this space for more cries for help!

Cheers for all the helpful suggestions!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.