can't get logon scripts to replicate

Hi,

Do you have a thrust between these two domains ?

Longbow

sorry, two domain controllers on the same domain

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]"

yes, NETLOGON exists on server1 as
d:\winnt\sysvol\sysvol\domain.company\scripts

and on server2 as
c:\winnt\sysvol\sysvol\domain.company\scripts

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

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.

Hi,

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 (server1.domain.company.com) 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,

hi,
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 (127.0.0.1) 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.

Hi,
Greg, your last comment didn't work. I take it you meant the Start of Authority within the domain.com 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 server1or2.domain.company.com

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 "domain.company.com" 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 "domain.company.com" 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 domain.company.com 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 domain.company.com 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.

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!