NETLOGON.LOG NO_CLIENT_SITE from workstations from another forest!

I would like to know what is causing this: we have two forest with a trust
relationship between them, where all subnets from each domain are correctly
defined into each forest Sites & Subnets. The problem is, from only one
forest, we got a lot of NETLOGON 5807 events, where workstations & servers
from the other domain are looking for their subnet -- but cannot find them
since they are defined into their respective domain!

What's wrong? We cannot define those subnets since those domain controllers
are existing into another forest!!!

You need to define both forest's subnets in each forest so a client
connecting from an IP address in forest A gets a DC in the correct site
in forest B. Subnets can be defined in both forests.

Another option might be to code a supernet on each forest that has all
the other forest's subnets and assign them to a single site; that may or
may not work depending on the address ranges, etc.

Those sites will not have servers linked to them, since those servers are in
the other forest!

My question is more like "for what those workstations or servers are
searching their site from DCs in the other forest???"

Wrong DNS configuration? SRV record related?

If your clients are logging on in the other forest, then do you have a GC from ForestA in ForestB's subnet, and vice-versa?

I also assume DNS is setup with conditional forwarders from ForestA to ForestB and vice versa. This way when a client from ForestA is logging on while visting ForestB, they will be able to find their own domain resources, and there is no block in connectivity by firewalls, etc, through your VPN.

I also assume there are no ISP's DNS addresses on any machine or in DHCP's scope options, or this will cause undesirable effects. Another problem is if any of the domain controllers are multihomed. That is extremely problematic as well.

Additional check this one:
http://support.microsoft.com/kb/889031

We have workstations AND servers entry in those NETLOGON.LOG... and users are
not trying to log on into the other forest.

I double check ip settings from those servers and workstations, and they are
joined into the correct domain and their subnets are defined in the correct
forest, but we still have NO_CLIENT_SITE entry into other DC's forest...
what's wrong???

For what they are looking for their subnets/sites using DCs from another
forest???

I think you may have misunderstood me. If you setup a COnditional Forwarder
on your DNS servers to the other Forest, and they do the same, then when
your clients are at their location, they can find their own domain on your
side by querying the DNS servers at their location. The conditional
forwarder will send the request to your DNS servers and they will be able to
respond with the correct information.

Also, if you are debugging netlogon and it doesn't show a site at the other
forest, it's because it's not defined as part of your subnets. To satisfy
this, you could either:

1. Install a GC from your forest at their location.
2. Include their subnets as part of a Site in your location.

The conditional forwarders should work fine, but if you want the log to show
up correctly, I would install a GC at their location.

Each forest have conditional forwarding to the other forest DNS servers.

Adding subnets from the other forest could be done, but we can select only
current forest DCs, not from the other domain. How that can help in this
situation???

There is something wrong somewhere, those workstations (NETLOGON) should
look for their subnet ONLY on the domain where they are registrered/joined,
no?

Oh, I see what you're asking. Normally clients on one forest, don't log on
at the other forest location. When at the other location, they are using the
other forest's DNS servers, and those servers are sending the query through
the conditional forwarder to their own forest, however, I've never explored
this possibility as far as setting sites with another forest's subnet, so I
am not sure if the querying client will resolve for Site information through
a forwarder (conditional or not).

I would imagine the best way to handle that on your end, and this is
conjecture, is possibly to add the other forest's subnet as a subnet object,
and associate it with a site on your side. This way, after the query is
resolved, the client should get a site list from DNS and be able to handle
it. I would say give it a try.

If that doesn't work, I think the best thing is to forget the forwarder, and
I would suggest either to create stubs, or secondary zone transfers so no
forwarding occurs.