Server 2008 AD Sites and Services / netlogon problemen

[ruderuud]

Mijn vraag:

Sommige windows7 clients geven Netlogon problemen.

Is het nodig om subnets te defineren in AD Sites and Services?

We hebben op dit moment van schijven een enkele site met 3 domain controllers, deze site hebben we in meerdere netwerk segmenten opgedeeld, waaronder 2 subnetten bedoeld voor kantoor automatisering.

1 van de 2 subnetts huizen wij windows servers, windows 7 clients, centos7 desktops en centos servers. De andere subnet hebben we enkel windows clients. Overige subnets dan die 2 vallen buiten mijn scope.

Deze subnets staan niet gedefineerd in Sites & services.....
mijn voorganger heeft dit niet gedaan of is zich er niet van bewust....??

Zijn de netlogon problemen hieraan gerelateerd?


Relevante software en hardware die ik gebruik:

windows server 2008 Active directory domain services


Wat ik al gevonden of geprobeerd heb:

DNS werkt prima, Repliceert elke 2 minuut.
AD domain controllers repliceren als een tierelier. lijkt mij ook geen issue.
http://anexinetisg.blogsp...nets-in-ad-sites-and.html

[Killah_Priest]

Ik configureer alleen de subnets in sites & services wanneer ik met meerdere sites te maken heb (dit zodat oa de "lokale" (RO)DC en met bv DFS de dichtstbijzijnde target gebruikt worden)

[redfoxert]

Heb je de clients zelf al eens bekeken alvorens je je AD topology misschien overhoop haalt terwijl dat helemaal niet nodig is?

[Brahiewahiewa]

ruderuud schreef op donderdag 14 april 2016 @ 12:10:
...Zijn de netlogon problemen hieraan gerelateerd?
...

Welke problemen? Je zou op z'n minst errormessages kunnen melden of gelogde events.
Op deze manier maak je je wel heel erg afhankelijk van onze kristallen bol

[ruderuud]

Inderdaad van een kristallen bol leer je geen bal... En meteen het AD topologie omgooien lijkt mij ook onnodig. vandaar mijn noodkreet:

Bijdeze de voorkomende event-meldingen:

########################
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="NETLOGON" />
<EventID Qualifiers="0">5719</EventID>

This computer was not able to set up a secure session with a domain controller in domain HIQ due to the following:
There are currently no logon servers available to service the logon request.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

########################

<Provider Name="Microsoft-Windows-TerminalServices-RemoteConnectionManager" Guid="{C76BAA63-AE81-421C-B425-340B4B24157F}" EventSourceName="TermService" />
<EventID Qualifiers="49152">1067</EventID>

The terminal server cannot register 'TERMSRV' Service Principal Name to be used for server authentication. The following error occured: The specified domain either does not exist or could not be contacted.

DNS staan naar mijn inziens goed:

preferred DNS: primaire dc
sec. : backup dc
tritair: andere dc
als laast: 8.8.8.8

Bedankt voor de reacties tot zover!

[bregweb]

Make sure that this computer is connected to the network.

Al gekeken naar deze tip van je machine? Even lokaal inloggen, kun je dan pingen?

Ben jij de portier die de rol van IT'er moet waarnemen nu de IT'er ziek is? Je geeft veel onnuttige info. DNS repliceert?

Heeft het ooit gewerkt en nu opeens niet, wat is er gewijzigd?

[ruderuud]

blijkbaar ben ik de portier

groeten

[akimosan]

Ik zie weer externe DNS opduiken in de configuratie. Big mistake bij AD topologie. Maakt niet uit of hij 1e, 2, 3e of 100e is. En waarom 3 DNS servers? Zijn je DC's (allemaal met DNS server role geïnstalleerd? ) zo vaak allemaal tegelijk offline?

[Duinkonijn]

Ik zou ook die Google dns weghalen en zorgen dat je kan resolven via je eigen dns servers(forwarder)

[ Voor 5% gewijzigd door Duinkonijn op 14-04-2016 21:56 ]

[bregweb]

ruderuud schreef op donderdag 14 april 2016 @ 16:29:
blijkbaar ben ik de portier

groeten

Wat ik zie is een vraag op bedrijfsniveau, zonder vermelding van eigen inspanning, met bijgeleverde info die niet erg ter zake doet. Verder is er kennelijk binnen jouw organisatie niemand aanwezig met voldoende IT-kennis om als sparring partner te fungeren en/of geen externe partij om advies aan te vragen.

Toch probeer ik je nog steeds te helpen, maar blijkbaar kies jij er voor om alleen mijn (misschien ongepaste) opmerking te lezen.

[Question Mark]

bregweb schreef op vrijdag 15 april 2016 @ 10:53:
[...]


Wat ik zie is een vraag op bedrijfsniveau, zonder vermelding van eigen inspanning, met bijgeleverde info die niet erg ter zake doet.

Daar ben ik het niet mee eens. TS heeft wel degelijk in zijn topicstart gemeld wat hij zelf geprobeerd heeft. Dat er meer zaken te testen of te controleren zijn, is voor een senior beheerder duidelijk. Maar... TS is misschien een starter in de IT wereld en heeft vanuit zijn kennis en blikveld misschien alles gedaan wat hij kon.

Verder is er kennelijk binnen jouw organisatie niemand aanwezig met voldoende IT-kennis om als sparring partner te fungeren en/of geen externe partij om advies aan te vragen.

Ja, so what? Dat is toch totaal niet relevant voor dit topic?

Toch probeer ik je nog steeds te helpen, maar blijkbaar kies jij er voor om alleen mijn (misschien ongepaste) opmerking te lezen.

En ook dat snap ik... Je geeft hier zelf al aan dat je opmerking ongepast is. Dan kun je verwachten dat je daar reacties op gaat krijgen.

Zullen we nu maar ontopic gaan?

Topicstarter: die Google DNS server mag inderdaad niet door clients gebruikt gaan worden. Interne AD clients mogen alleen maar de interne DNS-servers gebruiken, die de AD records hosten. De interne DNS servers moeten middels Forwarders regelen dat zij evt externe records voor de clients kunnen resolven.

[Muggie]

Het is nmm verstandig om al je subnets op te nemen in AD sites and services. Lost je probleem waarschijnlijk niet op maar het houdt je basis inrichting zo volledig mogelijk.

Geven je clients nic foutmeldingen? Heb dit fenomeen weleens gezien icm verouderde nic drivers.

[Linke Loe]

Muggie schreef op zaterdag 16 april 2016 @ 13:50:
Het is nmm verstandig om al je subnets op te nemen in AD sites and services. Lost je probleem waarschijnlijk niet op maar het houdt je basis inrichting zo volledig mogelijk.

Hmmm, ik zou alleen maar de subnets opnemen, waar je ook daadwerkelijk een domain controller hebt draaien.

[synoniem]

Als je op de betreffende clients kijkt hebben ze dan een bereikbare DNS/WINS server dus binnen hun subnet en/of gateway?

[Muggie]

Linke Loe schreef op zondag 17 april 2016 @ 00:58:
[...]

Hmmm, ik zou alleen maar de subnets opnemen, waar je ook daadwerkelijk een domain controller hebt draaien.

Bekijk je netlogon.log maar eens dan, daar staan alle clients die aanmelden en waarvan het subnet niet in adss staat.

[Brahiewahiewa]

ruderuud schreef op donderdag 14 april 2016 @ 16:07:
...DNS staan naar mijn inziens goed:

preferred DNS: primaire dc
sec. : backup dc
tritair: andere dc
als laast: 8.8.8.8

Om 't nog maar even te benadrukken: dit is dè oorzaak van je netlogon problemen.
Waarom is dit gedaan? Zijn er geen forwarders gedefinieerd op de DNS servers?

[Killah_Priest]

Brahiewahiewa schreef op zondag 17 april 2016 @ 12:54:
[...]

Om 't nog maar even te benadrukken: dit is dè oorzaak van je netlogon problemen.
Waarom is dit gedaan? Zijn er geen forwarders gedefinieerd op de DNS servers?

Vaak wordt dit ingesteld omdat veel mensen niet weten hoe DNS werkt mbt primare, secundaire (en meer) DNS servers ingesteld. Men denkt : als DNS server A niet bereikbaar is dan pas wordt B gequeried.

(even algemene info voor de onwetenden hier) :
Helaas is het zo : als A niet bereikbaar is of te laat reageert dan gaat ie over naar de volgende B (of C) : daar blijft ie vervolgens minstens 15 minuten op "plakken" (om het maar even in jip en janneke taal uit te leggen) waardoor alle queries hierheen gaan.

[Linke Loe]

Muggie schreef op zondag 17 april 2016 @ 09:44:
[...]


Bekijk je netlogon.log maar eens dan, daar staan alle clients die aanmelden en waarvan het subnet niet in adss staat.

Natuurlijk staan alle clients die zich aanmelden in de logfiles, maar dat betekent nog niet dat je voor ieder IP-subnet een vermelding moet hebben binnen ADSS. Hier maak je namelijk je AD sites in aan, waar je vervolgens de overeenkomende IP-subnets aan koppelt. Een AD-site is hierin wat anders dan een site als zijnde een fysieke lokatie. AD-sites maak je namelijk aan om het replicatieverkeer tussen je domain controllers te reguleren. Het zou dan een beetje onzinnig zijn, als je sites aanmaakt, waar geen domain controller draait. Uiteraard hoef je dan ook geen IP-subnet op te geven, waar je geen domain controller in hebt draaien. Dat zou een mooie bende worden als je, zoals in ons geval, zo'n 400 fysieke lokaties in 5 landen hebt...

[Question Mark]

Linke Loe schreef op zondag 17 april 2016 @ 20:53:
[...]
AD-sites maak je namelijk aan om het replicatieverkeer tussen je domain controllers te reguleren.

Neup, het zorgt er ook voor dat clients zich kunnen aanmelden bij de dichtsbijzijnde DC.

Het zou dan een beetje onzinnig zijn, als je sites aanmaakt, waar geen domain controller draait. Uiteraard hoef je dan ook geen IP-subnet op te geven, waar je geen domain controller in hebt draaien. Dat zou een mooie bende worden als je, zoals in ons geval, zo'n 400 fysieke lokaties in 5 landen hebt...

Ik zou me als ik jouw was even goed inlezen in wat Automatic Site Coverage doet, en dan eens goed nadenken of je dit wel of niet wilt.

Automatic Site Coverage
There is not necessarily a domain controller in every site. For various reasons, it is possible that no domain controller exists for a particular domain at the local site. By default, each domain controller checks all sites in the forest and then checks the replication cost matrix. A domain controller advertises itself (registers a site-related SRV record in DNS) in any site that does not have a domain controller for that domain and for which its site has the lowest-cost connections. This process ensures that every site has a domain controller that is defined by default for every domain in the forest, even if a site does not contain a domain controller for that domain. The domain controllers that are published in DNS are those from the closest site (as defined by the replication topology.

For example, given one domain and three sites, a domain controller for that domain might be located in two of the sites, but there might be no domain controller for the domain in the third site. Replication to the domain that does not have a domain controller in the third site might be too expensive in terms of cost or replication latency. To ensure that a domain controller can be located in the site closest to a client computer, if not the same site, Windows 2000 automatically attempts to register a domain controller in every site. The algorithm that is used to accomplish automatic site coverage determines how one site can "cover" another site when no domain controller exists in the second site.

In jullie omgeving kan een client dus gebruik gaan maken van een puur willekeurige DC die netwerktechnisch gezien niet de beste keuze zou zijn. Door het goed op orde hebben van je sites kun je dit nog sturen.

[col-dejong]

Wordt er gebruik gemaakt van virtualisatie / fysieke machines, staat de tijd van Windows / BIOS wel goed? Éénmaal een server gehad waarbij de BIOS tijd een uur achter stond, vSphere wel de goede tijd aangaf maar de guests hier problemen mee kregen. Uiteindelijk kregen clients ook bovenstaande NETLOGON melding.

[akimosan]

Ik denk dat de TS er even de brui aan heeft gegeven en het topic niet meer volgt.
Mogelijk omdat hij de eerste negatieve reacties in de trant van: "weet je wel wat je doet en heb je er al iemand bijgehaald.." een beetje beu was.
Gezien de DNS verwijzing naar 8.8.8.8 wijzen verschillende mensen hier dat aan als meest verdachte boosdoener.

[Muggie]

Linke Loe schreef op zondag 17 april 2016 @ 20:53:
[...]

Natuurlijk staan alle clients die zich aanmelden in de logfiles, ... knip ...

De clients waarvan het subnet niet bekend is staan in die logfiles, verder wat Question Mark zegt.

[Anoniem: 64486]

Maak je toevallig gebruik van een Layer 3 netwerk? Zo ja, dan is dit een bekend probleem. Patch: https://support.microsoft.com/en-us/kb/2459530 verhelpt deze problemen veelal. Dit heeft mij al in meerdere netwerken geholpen Als je deze toepast, dan wil je meestal ook hotfix: https://support.microsoft.com/en-us/kb/2673042 toepassen.