Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 281
  • Last Modified:

Terminal server and Active Directory replication issues

It's been a long and winding road to get where I am now sow I'll skip all that and get right to the current status. My client has a pair of W2000 servers. #1 contains SQL 2000, DNS, TS licensing server, DHCP and ADC. #2 contains Exchange 2000, DNS, and ADC. The also have a Terminal Server.
The AD replicas between #1 and #2 are not syncronized. I suspect the rest of the sysptoms I'm going to describe are related to this.

1. When login as Administrator, bring up DNS on #1 and attempt to manage #2 I get an "Access Denied" error. Going from #2 to #1 works OK. From the Terminal server if I bring up Computer Management and try to connect to #2 it says Access Denied. #1 comes up OK.
2. Periodically the log on #2 contains a 13508 FRS error.
3. Exchange System Attendant would not start until I changed it from System account to Administrator.
Exchange then worked except that no one had access to Public folders. Mid afternoon it stopped sending and recieving mail. I restarted the server and now the System Attendant will not start.
4. Every couple of hours the log has a "couldn't contact the global catalog" error.
5. All the logs are filled with 3034 errors.
6. Terminal server was giving a "can't find a licensing server" error. I added the registry value to point to it and that error went away. However, everytime a non-2000 client trys to connect it refuses and puts an "unable to issue a Terminal server license" error in the log.

I am going out tomorrow with the idea of demoting #1 and promoting it again to see if it will replicate. I am offerring 500 points for urgency and difficulty. My questions are:
Is it reasonable to think that all these problems stem from the AD inconsistancy?
Is the demote-promote idea to restablish replication also reasonble?
Is there any other problem that these symptoms would point to?
Is there a way to tell exchange to use the other DC as a global catalog?
1 Solution
Nirmal SharmaSolution ArchitectCommented:
What is your exact problem? Please explain in short.

Thank You.
Hi  scarpenter104,

Sounds like your AD replication has taken a beating and the DC's are out of sync, this may help:
Error Message "Target Principal Name is Incorrect" When Manually Replicating Data Between Domain Controllers

Demoting on of the DC's (the one without the FSMO roles) would help out. Let AD settled down (i.e. no event log errors appearing) for a day then promote the server again and check replication is working correctly. Exchange doesn't like being on the same server as a DC, but it will still work okay.

Exchange by default queries AD to find the GC servers, but if you want to manually repoint them then open ESM and find the server. Right click on it and in properties tabs you'll see the option for GC's used. pick the one you want.

scarpenter104Author Commented:
Unfortunately I was already at the customer site working when these messages came in so I was unable to respond to them. For future reader's information though, this is how the problem was solved:

After copying both AD drives to backup drives so I could experiment wildly without fear, I checked to make sure #2 was specified as a Global Catalog and it was. Even so I was seeing "unable to locate global catalog" errors in the log so I shut down both servers, booted #2 into DSREPAIR mode, ran NTDSUTIL and began running checks on the domain controller. Initial checks passed but eventually a test revealed an RPC Endpoint Mapper error. Since NTDSUTIL has no means to diagnose this further, rebooted and ran DCDIAG.
Initial DCDIAG results showed a multitude of errors, the most significant being the fact that SYSVOL was no longer being shared.
Followed MicroSoft guidelines (Q315457) on rebuilding the SYSVOL tree and got the SYSVOL mounted and the DC online.
According to DCDIAG,  "Builtin/Administrators did not have the "Access this computer from network" right." It appeared that AD was replicating, but the SYSVOLs were still not consistant.
Attempted to open Domain Poicy editor and it said that Administrator does not have the right to do so. It appeared at this point that we were stuck in a catch 22: The Administrator is missing a right but is also missing the right to give himself that right. Determined that this must be a result of errant policy settings and after determining that those policys are contained in the SYSVOL volume, decided to go back to the procedure for rebuilding the SYSVOL tree and rebuild a SYSVOL with no default policies. While setting up for this, created a new folder in SYSVOL which triggered a replication between the two SYSVOL volumes and surprisingly corrected the problem. Rights are restored and replication is now happening.
As suspected, as soon as AD started replicating properly, Exchange started up properly on normal accounts, the Terminal Server began issuing licenses, access problems went away, the clouds broke, the birds sang, and life is good.
Closed, 500 points refunded.
Community Support Moderator (Graveyard shift)

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now