[Astatine]

Where to begin....the main network has an IP range of 192.168.101.* and has been working fine with a number of DCs. The outgoing IT manager has setup a child domain called "training" for the training rooms for security purposes. These rooms use an IP range of 192.168.200.* and have two DCs. There is supposedly a trust relationship in place between the domains to allow the training staff to authenticate against the parent domain and yet, still get access to resources on the child domain. The trust is apparently one way to pretent students "hacking back up the tree".

For a start, there is...endless Warning entries in the Directory event log, with event ID of 1265, "Knowledge Consistancy". The description is below:

Quote:

The attempt to establish a replication link with parameters

Partition: CN=Configuration,DC=domain,DC=com,DC=au
Source DSA DN: CN=NTDS Settings,CN=114-IT14378,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=com,DC=au
Source DSA Address: ea1dc668-433f-47dc-9419-373ba2af0998._msdcs.domain.com.au
Inter-site Transport (if any):

failed with the following status:

The RPC server is unavailable.

The record data is the status code. This operation will be retried.

These will occur in blocks of about three in about 90 seconds, slightly different and then it will try again in about 15 minutes. So obviously something is amiss there.

In AD Domains and Trusts, Properties>Trusts lists the child domain in both boxes, as type Child with transitive set to Yes. If I select one, click Edit and then Verify, an error will appear "Windows cannot find a primary domain controller for the training.domain.com.au domain. Verify that the PDC is functioning and then try again." When viewing properties for the child domain, the General tab says "The Active Directory object could not be displayed. A referral was returned from the server." The Trusts tab returns no data.

Pinging training.domain.com.au on machines connecting to the parent domain returns an address in the 192.168.101.* range that times out. Also, pinging dc.training.domain.com.au (where DC is the name of either training room DCs). The IPs returned are in the 192.168.200.* range and are correct for the starting IP of each room's subnet. Using NET VIEW \\servername where servername is a DC in the training domain gives "Access is denied", even when logged in as an administrator on the parent domain. When attempting to manually map a drive letter to the server, the following error is returned:

Quote:

System error 1311 has occurred.

There are currently no logon servers available to service the logon request.

I think it's pretty obvious there's some sort of issues here but I literally don't know where to start. Any suggestions, help, etc? Thanks.

[AndyFair]

Take a look at this link from support.microsoft.com

Rgds
AndyF

[deguello]

I am not sure I really understand how the domain is setup. Trusts are not required between domains in the same forest. You can remove default rights to the domain but forest admin will still be able to access either if needed. That ID can can go reclaim rights taken from it. Trusts are established between separate forests in the NT4 sense of concept.

Generally speaking, I would suggest that start with general troubleshooting procedures for AD. First, verify that DNS is setup properly. Make sure it allows for dynamic updates and since your running an AD, integrate all critical zones into it. Just because you have a child domain entry in your DNS does not mean that you have performed a DCPROMO of your child domain. Was this actually ever done? If so, you should have an entry in your DNS forward zone, in the _msdcs section off the root of your primary zone. You should also have a DC entry in the _msdcs section of your child domain. There should also be a full compliment of global catalog, sites and services etc entries on EACH domain. So in other words you should see child domain entries in the DNS at both domain.com and child.domain.com.

domain.com
_msdcs
_gc
child
_msdcs
_gc

It really sounds to me like whoever set the domain up may not really understand the concept of a "child domain" from every aspect. I could be totally wrong here, but it will cost you for me to be sure. Since this is what I do for a living, I dont mind sharing and helping, but firm analysis on site would incur fees.

Hope this helps.

deg

[DS3Circuit]

http://www.eventid.net/display.asp?eventid=1265&source=

[Astatine]

Thanks for the starting points, guys. There's some weird things on how the child domain systems are setup (like the DCs having multiple IPs) and I'll have to get more details about it when I'm at work. If I can find out anymore, I'll post about it.

[Astatine]

Quote:

Generally speaking, I would suggest that start with general troubleshooting procedures for AD. First, verify that DNS is setup properly. Make sure it allows for dynamic updates and since your running an AD, integrate all critical zones into it. Just because you have a child domain entry in your DNS does not mean that you have performed a DCPROMO of your child domain. Was this actually ever done?

Not sure if that was done as I didn't setup the network.

Quote:

If so, you should have an entry in your DNS forward zone, in the _msdcs section off the root of your primary zone. You should also have a DC entry in the _msdcs section of your child domain. There should also be a full compliment of global catalog, sites and services etc entries on EACH domain. So in other words you should see child domain entries in the DNS at both domain.com and child.domain.com.

Under that section, there are Alias entries for each DC, with weird names like 8d987675-9043-421b-8482-904d145a3eb8. Under the child domain, there is only the dc and pdc folders in the _msdcs folder. There's no gc folder. Also, the gc folders are just that, "gc", not with the underscore at the start like in your example.

Quote:

It really sounds to me like whoever set the domain up may not really understand the concept of a "child domain" from every aspect. I could be totally wrong here, but it will cost you for me to be sure. Since this is what I do for a living, I dont mind sharing and helping, but firm analysis on site would incur fees.

Hope this helps.

deg

Understandable. The guy who set it up is insisting there shouldn't be any problems with it. I'll keep plugging away.

[Astatine]

Forgot to mention - all DCs and servers are running Windows 2000 server. Clients are a mix of 95, 98 and 2000. The domain is set to mixed mode. Is there any real reason not to switch to native mode?

[deguello]

I just spent an hour replying to your post and the session timed out when I hit submit and I lost it all. Can't get it back...... ;(

You can go native mode unless you have any NT4 DC's. I will readdress your issues when I get time.

In the mean time, check your sites and services for correct subnetting. Make sure that the subnets are actually assigned to correct sites.

Check that your child domain DC was actually promoted to a DC. Look for it in the AD MMC.

Let me know the results.

[Astatine]

Quote:

I just spent an hour replying to your post and the session timed out when I hit submit and I lost it all. Can't get it back...... ;(

Yeah, it happened to me before.

Quote:

In the mean time, check your sites and services for correct subnetting. Make sure that the subnets are actually assigned to correct sites.

In ADSS, there are two sites - Default-First-Site-Name and Conferencing. *All* the DCs are allocated there in the Default one. To me, this seems just a tad fishy and I had asked about creating extra sites in a previous topic. Under Subnets, there are a few - 192.168.101.0/24 (the head office range), 192.168.200.0/24 (training), 192.168.200.32/27 (training), 192.168.200.64/27 (training again) and 192.168.200.96/27 (training). When you go into Properties for each, the site it set to Default-First-Site-Name. There are missing subnets for the other offices (which use ranges such as 192.168.102, 103, etc but I think they use VPN so that might be why they're not there).

Quote:

Check that your child domain DC was actually promoted to a DC. Look for it in the AD MMC.

When looking at AD Users and Computers for the parent domain, no child domain DCs are listed.