i was looking in dns this morning, and noticed under

- forestdnszones
- domaindnszones

i had one site (siteb), but (sitea), and (sitec) were missing. (those
are the three sites in active directory sites and services.

the symptom that had me look at this, is my users are not going to
their correct domain controllers. (i've checked ad sites & services),
and this is the only thing that i see that's incorrect.

a hand ...someone?

thanks a lot!

eric

Hi

does the sites exist in ADSS? Install support tools and run netdiag /fix,
or/and restart the netlogon service


--
I hope that the information above s you

Good Luck
Jorge Silva
MCSA
Systems Administrator

<eric.olson@gmail.com> wrote in message
news:1153928979.161595.313970@i42g2000cwa.googlegr oups.com...
>i was looking in dns this morning, and noticed under
>
> - forestdnszones
> - domaindnszones
>
> i had one site (siteb), but (sitea), and (sitec) were missing. (those
> are the three sites in active directory sites and services.
>
> the symptom that had me look at this, is my users are not going to
> their correct domain controllers. (i've checked ad sites & services),
> and this is the only thing that i see that's incorrect.
>
> a hand ...someone?
>
> thanks a lot!
>
> eric
>

In news:1153928979.161595.313970@i42g2000cwa.googlegr oups.com,
eric.olson@gmail.com <eric.olson@gmail.com> stated, which I commented on
below:
> i was looking in dns this morning, and noticed under
>
> - forestdnszones
> - domaindnszones
>
> i had one site (siteb), but (sitea), and (sitec) were missing. (those
> are the three sites in active directory sites and services.
>
> the symptom that had me look at this, is my users are not going to
> their correct domain controllers. (i've checked ad sites & services),
> and this is the only thing that i see that's incorrect.
>
> a hand ...someone?
>
> thanks a lot!
>
> eric

Sites under the ForestDnsZones and DomainDnsZones application containers? Do
you mean domains? ForestDnsZones should show all domains, however the
DomainDnsZones should only show what domains it's configured with zones that
are DomainDnsZones integrated.

As Jorge asked, do you have "Sites" configured with a respective IP subnet
object that is associated with their respective Sites?

For Site domain controller information and services they offer, do not look
in the application containers but rather in the SRV records. They are the
ones with the underscores in them: _msdcs, _sites, _tcp, and _udp. Look
under the _sites folder for services running port 389 (LDAP or the domain
controllers themselves, and 3268 GCs (Global Catalogs).

Under the _msdcs folder you will see a "gc" folder. That will indicate all
of your GCs in the forest. Is there a GC for each Site?

As long as Sites are configured properly with their respecitive IP subnet
object, and the querying client's IP matches one of them, and there's a GC
in the Site, it will use the services in that site. If not, or
misconfigured, it will use a random lookup.

If I misunderstood, can you be more specific as to *exactly* what you are
seeing under which folder in DNS and possibly any errors in the Event logs
of the DCs and of the clients? Also, let use know what DNS servers the
clients are using.

--
Ace
Innovative IT Concepts, Inc
Willow Grove, PA

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Directory Services
Microsoft Certified Trainer

Having difficulty reading or finding responses to your post?
Instead of the website you're using, I suggest to use OEx (Outlook Express
or any other newsreader), and configure a news account, pointing to
news.microsoft.com. This is a direct link to the Microsoft Public
Newsgroups. It is FREE and requires NO ISP's Usenet account. OEx allows you
to easily find, track threads, cross-post, sort by date, poster's name,
watched threads or subject.
It's easy:

How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

Infinite Diversities in Infinite Combinations
Assimilation Imminent. Resistance is Futile
"Very funny Scotty. Now, beam down my clothes."

The only constant in life is change...

_msdcs, _sites, and _tcp are all correct. they each list all the sites
(which are also seen in ad sites and services).

sitea = primary dns
siteb = secondary (would it be better to have a primary dns site in
each location, even though they're all in the same domain?)
sitec = secondary (would it be better to have a primary dns site in
each location, even though they're all in the same domain?)

'siteb' is listed in domaindnszones, however sitea and sitec aren't.

sitea users = point to sitea dns.
siteb users = point to siteb dns, and a secondary of sitea
sitec users = point to sitec dns, and a secondary of sitea

another thing i noticed (i have several users who have "permissions" to
change things) -- which i'm about to cut off -- is:

in ad sites and services, under subnets:

xxx.xxx.129.0/26
xxx.xxx.129.128/25
xxx.xxx.169.64/27
xxx.xxx.129.64/27
xxx.xxx.129.96/27
xxx.xxx.131.0/27
xxx.xxx.131.112/28
xxx.xxx.131.144/28
xxx.xxx.255.160/28
*i also have quite a few entries that are the same as the above but
with a bunch of jibberish at the end of the bitmask (for instance
{A)#%@#()%UBN&)!@B&P!b24ybdlabgysdgy82gb7628ls76d8 slds}. i think these
are either bad, or just incorrect, and have to be removed.*

from what i understood it needed to be xxx.xxx.xxx.0/{bitmask}

all of the xxx.xxx are the same. i just omitted the other octets so i'm
not publishing my ip addresses / ranges on the www.

i tried 'netdiag /fix' but it's not available in windows 2003....
unless i was doing something wrong (like not running 'netdiag /fix'
from the dns server in question).

thanks for all your guys!

Ace Fekay [MVP] wrote:
> In news:1153928979.161595.313970@i42g2000cwa.googlegr oups.com,
> eric.olson@gmail.com <eric.olson@gmail.com> stated, which I commented on
> below:
> > i was looking in dns this morning, and noticed under
> >
> > - forestdnszones
> > - domaindnszones
> >
> > i had one site (siteb), but (sitea), and (sitec) were missing. (those
> > are the three sites in active directory sites and services.
> >
> > the symptom that had me look at this, is my users are not going to
> > their correct domain controllers. (i've checked ad sites & services),
> > and this is the only thing that i see that's incorrect.
> >
> > a hand ...someone?
> >
> > thanks a lot!
> >
> > eric
>
> Sites under the ForestDnsZones and DomainDnsZones application containers? Do
> you mean domains? ForestDnsZones should show all domains, however the
> DomainDnsZones should only show what domains it's configured with zones that
> are DomainDnsZones integrated.
>
> As Jorge asked, do you have "Sites" configured with a respective IP subnet
> object that is associated with their respective Sites?
>
> For Site domain controller information and services they offer, do not look
> in the application containers but rather in the SRV records. They are the
> ones with the underscores in them: _msdcs, _sites, _tcp, and _udp. Look
> under the _sites folder for services running port 389 (LDAP or the domain
> controllers themselves, and 3268 GCs (Global Catalogs).
>
> Under the _msdcs folder you will see a "gc" folder. That will indicate all
> of your GCs in the forest. Is there a GC for each Site?
>
> As long as Sites are configured properly with their respecitive IP subnet
> object, and the querying client's IP matches one of them, and there's a GC
> in the Site, it will use the services in that site. If not, or
> misconfigured, it will use a random lookup.
>
> If I misunderstood, can you be more specific as to *exactly* what you are
> seeing under which folder in DNS and possibly any errors in the Event logs
> of the DCs and of the clients? Also, let use know what DNS servers the
> clients are using.
>
> --
> Ace
> Innovative IT Concepts, Inc
> Willow Grove, PA
>
> This posting is provided "AS-IS" with no warranties or guarantees and
> confers no rights.
>
> Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
> Microsoft MVP - Directory Services
> Microsoft Certified Trainer
>
> Having difficulty reading or finding responses to your post?
> Instead of the website you're using, I suggest to use OEx (Outlook Express
> or any other newsreader), and configure a news account, pointing to
> news.microsoft.com. This is a direct link to the Microsoft Public
> Newsgroups. It is FREE and requires NO ISP's Usenet account. OEx allows you
> to easily find, track threads, cross-post, sort by date, poster's name,
> watched threads or subject.
> It's easy:
>
> How to Configure OEx for Internet News
> http://support.microsoft.com/?id=171164
>
> Infinite Diversities in Infinite Combinations
> Assimilation Imminent. Resistance is Futile
> "Very funny Scotty. Now, beam down my clothes."
>
> The only constant in life is change...

In news:1154033464.502281.29530@i3g2000cwc.googlegrou ps.com,
eric.olson@gmail.com <eric.olson@gmail.com> stated, which I commented on
below:
> _msdcs, _sites, and _tcp are all correct. they each list all the sites
> (which are also seen in ad sites and services).
>
> sitea = primary dns
> siteb = secondary (would it be better to have a primary dns site in
> each location, even though they're all in the same domain?)
> sitec = secondary (would it be better to have a primary dns site in
> each location, even though they're all in the same domain?)
>
> 'siteb' is listed in domaindnszones, however sitea and sitec aren't.
>
> sitea users = point to sitea dns.
> siteb users = point to siteb dns, and a secondary of sitea
> sitec users = point to sitec dns, and a secondary of sitea
>
> another thing i noticed (i have several users who have "permissions"
> to change things) -- which i'm about to cut off -- is:
>
> in ad sites and services, under subnets:
>
> xxx.xxx.129.0/26
> xxx.xxx.129.128/25
> xxx.xxx.169.64/27
> xxx.xxx.129.64/27
> xxx.xxx.129.96/27
> xxx.xxx.131.0/27
> xxx.xxx.131.112/28
> xxx.xxx.131.144/28
> xxx.xxx.255.160/28
> *i also have quite a few entries that are the same as the above but
> with a bunch of jibberish at the end of the bitmask (for instance
> {A)#%@#()%UBN&)!@B&P!b24ybdlabgysdgy82gb7628ls76d8 slds}. i think these
> are either bad, or just incorrect, and have to be removed.*
>
> from what i understood it needed to be xxx.xxx.xxx.0/{bitmask}
>
> all of the xxx.xxx are the same. i just omitted the other octets so
> i'm not publishing my ip addresses / ranges on the www.
>
> i tried 'netdiag /fix' but it's not available in windows 2003....
> unless i was doing something wrong (like not running 'netdiag /fix'
> from the dns server in question).
>
> thanks for all your guys!

Those jibberish ones sound like duplicates or conflicts. Yes, delete them.

You mentioned Primary and Secondary DNS. I'm not sure if this is skewed
terminology or not. Do you mean Primary and Secondary zones? Are you saying
DNS is not installed and running on domain controllers in those Sites?

If DNS is installed on all domain controllers, and you have one domain, and
you select the zone to be AD integrated, then the zone will auto populate on
ALL DNS servers that are domain controllers. If you have multiple domains,
only the ones in the ForestDnsZones partition will populate on ALL DC/DNS
servers, but if any are in either the DomainNC (bottom button in zone
properties), or the in DomainDnsZones, (middle button), they will replicate
to only the DC/DNS in their own domain.

If the zone is AD INtegrated, and you attempt to create a Secondary zone of
one of these zones on another DC that is in the same replication scope
context, then it will create an error and it will auto remove the zone.

Does that make sense? Maybe a clarification please?

Thanks,
Ace

Site A = Primary Zone
Site B & C = Secondary Zone

DNS is not installed on all DC's. Its installed on all but one. I'd
rather stick with the typical DNS until we've switched over to AD
Integrated, then switch DNS to be AD Integrated as well.

We only have one domain.

Ace Fekay [MVP] wrote:
> In news:1154033464.502281.29530@i3g2000cwc.googlegrou ps.com,
> eric.olson@gmail.com <eric.olson@gmail.com> stated, which I commented on
> below:
> > _msdcs, _sites, and _tcp are all correct. they each list all the sites
> > (which are also seen in ad sites and services).
> >
> > sitea = primary dns
> > siteb = secondary (would it be better to have a primary dns site in
> > each location, even though they're all in the same domain?)
> > sitec = secondary (would it be better to have a primary dns site in
> > each location, even though they're all in the same domain?)
> >
> > 'siteb' is listed in domaindnszones, however sitea and sitec aren't.
> >
> > sitea users = point to sitea dns.
> > siteb users = point to siteb dns, and a secondary of sitea
> > sitec users = point to sitec dns, and a secondary of sitea
> >
> > another thing i noticed (i have several users who have "permissions"
> > to change things) -- which i'm about to cut off -- is:
> >
> > in ad sites and services, under subnets:
> >
> > xxx.xxx.129.0/26
> > xxx.xxx.129.128/25
> > xxx.xxx.169.64/27
> > xxx.xxx.129.64/27
> > xxx.xxx.129.96/27
> > xxx.xxx.131.0/27
> > xxx.xxx.131.112/28
> > xxx.xxx.131.144/28
> > xxx.xxx.255.160/28
> > *i also have quite a few entries that are the same as the above but
> > with a bunch of jibberish at the end of the bitmask (for instance
> > {A)#%@#()%UBN&)!@B&P!b24ybdlabgysdgy82gb7628ls76d8 slds}. i think these
> > are either bad, or just incorrect, and have to be removed.*
> >
> > from what i understood it needed to be xxx.xxx.xxx.0/{bitmask}
> >
> > all of the xxx.xxx are the same. i just omitted the other octets so
> > i'm not publishing my ip addresses / ranges on the www.
> >
> > i tried 'netdiag /fix' but it's not available in windows 2003....
> > unless i was doing something wrong (like not running 'netdiag /fix'
> > from the dns server in question).
> >
> > thanks for all your guys!
>
> Those jibberish ones sound like duplicates or conflicts. Yes, delete them.
>
> You mentioned Primary and Secondary DNS. I'm not sure if this is skewed
> terminology or not. Do you mean Primary and Secondary zones? Are you saying
> DNS is not installed and running on domain controllers in those Sites?
>
> If DNS is installed on all domain controllers, and you have one domain, and
> you select the zone to be AD integrated, then the zone will auto populate on
> ALL DNS servers that are domain controllers. If you have multiple domains,
> only the ones in the ForestDnsZones partition will populate on ALL DC/DNS
> servers, but if any are in either the DomainNC (bottom button in zone
> properties), or the in DomainDnsZones, (middle button), they will replicate
> to only the DC/DNS in their own domain.
>
> If the zone is AD INtegrated, and you attempt to create a Secondary zone of
> one of these zones on another DC that is in the same replication scope
> context, then it will create an error and it will auto remove the zone.
>
> Does that make sense? Maybe a clarification please?
>
> Thanks,
> Ace

In news:1154208517.242283.217360@p79g2000cwp.googlegr oups.com,
eric.olson@gmail.com <eric.olson@gmail.com> stated, which I commented on
below:
> Site A = Primary Zone
> Site B & C = Secondary Zone
>
> DNS is not installed on all DC's. Its installed on all but one. I'd
> rather stick with the typical DNS until we've switched over to AD
> Integrated, then switch DNS to be AD Integrated as well.
>
> We only have one domain.

I see. If the zone was AD integrated, it acts as a primary zone on any DC
that it's hosted on.

Getting back to your original question, because the zone is not AD
Integrated in any of the application partitions, you shouldn't find any info
in the app partitions. The only thing I can think of about users not logging
on to their respective Site DCs (and the app partitions don't have anything
to do with this), is that your Sites configuration are not configured
properly.

By the way, curious, how did you determine that the clients are not using
their respective Site DCs? On the client machine, did you run an "echo
%logonserver%" ? If not, how did you determine this?

Remember, when configuring a site, you would create a Site, then create a
subnet object that reflects the subnet of that site (such as
192.168.10.0/24) and associate it with the site. Once you've done that, you
can then force the netlogon service to register the new info into the DNS
SRV records to reflect the new configuration, or just let it happen
automatically. Make sure there's a GC in each Site too.

Here's more info on managing Sites and controlling logon.

Managing Sites:
http://www.microsoft.com/technet/pro...1/adogd06.mspx

306602 - How to Optimize the Location of a DC or GC That Resides Outside of
a Client's Site [Includes info LdapIpAddress and GcIpAddress]:
http://support.microsoft.com/?id=306602

Ace

Actually, we used "set L" ...same difference. In either instance, it
returned the same thing. One of the issues we were having, is a user,
or a Exchange Server not "choosing" the correct DC/GC in their
respective site(s). Each site has a DC/GC, and some sites have multiple
DC's.

I think I'll follow the instructions in Hub-and-Spoke Technology, as
this will probably alieviate any client -> server connections.

We're fixing the broken connections in AD Sites & Services today. We'll
see how that works out.


Ace Fekay [MVP] wrote:
> In news:1154208517.242283.217360@p79g2000cwp.googlegr oups.com,
> eric.olson@gmail.com <eric.olson@gmail.com> stated, which I commented on
> below:
> > Site A = Primary Zone
> > Site B & C = Secondary Zone
> >
> > DNS is not installed on all DC's. Its installed on all but one. I'd
> > rather stick with the typical DNS until we've switched over to AD
> > Integrated, then switch DNS to be AD Integrated as well.
> >
> > We only have one domain.
>
> I see. If the zone was AD integrated, it acts as a primary zone on any DC
> that it's hosted on.
>
> Getting back to your original question, because the zone is not AD
> Integrated in any of the application partitions, you shouldn't find any info
> in the app partitions. The only thing I can think of about users not logging
> on to their respective Site DCs (and the app partitions don't have anything
> to do with this), is that your Sites configuration are not configured
> properly.
>
> By the way, curious, how did you determine that the clients are not using
> their respective Site DCs? On the client machine, did you run an "echo
> %logonserver%" ? If not, how did you determine this?
>
> Remember, when configuring a site, you would create a Site, then create a
> subnet object that reflects the subnet of that site (such as
> 192.168.10.0/24) and associate it with the site. Once you've done that, you
> can then force the netlogon service to register the new info into the DNS
> SRV records to reflect the new configuration, or just let it happen
> automatically. Make sure there's a GC in each Site too.
>
> Here's more info on managing Sites and controlling logon.
>
> Managing Sites:
> http://www.microsoft.com/technet/pro...1/adogd06.mspx
>
> 306602 - How to Optimize the Location of a DC or GC That Resides Outside of
> a Client's Site [Includes info LdapIpAddress and GcIpAddress]:
> http://support.microsoft.com/?id=306602
>
> Ace

<eric.olson@gmail.com> wrote in message
news:1154355499.569293.264210@i3g2000cwc.googlegro ups.com...
> Actually, we used "set L" ...same difference. In either instance, it
> returned the same thing. One of the issues we were having, is a user,
> or a Exchange Server not "choosing" the correct DC/GC in their
> respective site(s). Each site has a DC/GC, and some sites have multiple
> DC's.
>
> I think I'll follow the instructions in Hub-and-Spoke Technology, as
> this will probably alieviate any client -> server connections.
>
> We're fixing the broken connections in AD Sites & Services today. We'll
> see how that works out.

Maybe the 'broken' connections is what's causing it all. Hub and spoke or
mesh wouldn't really make a difference with logon authentication traffic,
but would affect replication traffic.

Ace

actually, it ended up being a misconfigured router by another entity.
its been resolved so far (at least as far as i can tell / test).

Ace Fekay [MVP] wrote:
> <eric.olson@gmail.com> wrote in message
> news:1154355499.569293.264210@i3g2000cwc.googlegro ups.com...
> > Actually, we used "set L" ...same difference. In either instance, it
> > returned the same thing. One of the issues we were having, is a user,
> > or a Exchange Server not "choosing" the correct DC/GC in their
> > respective site(s). Each site has a DC/GC, and some sites have multiple
> > DC's.
> >
> > I think I'll follow the instructions in Hub-and-Spoke Technology, as
> > this will probably alieviate any client -> server connections.
> >
> > We're fixing the broken connections in AD Sites & Services today. We'll
> > see how that works out.
>
> Maybe the 'broken' connections is what's causing it all. Hub and spoke or
> mesh wouldn't really make a difference with logon authentication traffic,
> but would affect replication traffic.
>
> Ace

In news:1154711935.091260.144450@s13g2000cwa.googlegr oups.com,
eric.olson@gmail.com <eric.olson@gmail.com> stated, which I commented on
below:
> actually, it ended up being a misconfigured router by another entity.
> its been resolved so far (at least as far as i can tell / test).

That could do it. Glad you found it (hope).

:-)

Ace