Hi, even voor de zekerheid. Stel je hebt één domain controller die ook DNS server is. Op de Terminal server staat als primary DNS het IP adres van de DC. Op de DC zelf staat echter als primary DNS 127.0.0.1 Dat lijkt goed te werken maar hoe stellen jullie dit meestal in? Ik zet zelf vaak het echte IP adres erin van de server zelf en niet het lookback adres. Zou het kunnen dat je vage problemen krijgt op het netwerk als dit niet goed staat? Zou het kunnen dat de Terminal server een dns query doet bij de DC en de DC dit vervolgens aan zichzelf vraagt via 127.0.0.1? Gaat dat dan wel goed? Ik zit namelijk met een issue dat de Terminal elke paar dagen ineens aangeeft de DNS niet te kunnen bereiken waardoor sommige group policys niet goed door lijken te komen
Zie dit document: https://support.microsoft...dows-2000-server-and-in-w
Maar ik denk niet dat dit met je probleem te maken heeft. Of je nu het primaire IP-adres van de DC of 127.0.0.1 instelt als DNS-server op de adapter van de DC maakt verder weinig uit.
Maar ik denk niet dat dit met je probleem te maken heeft. Of je nu het primaire IP-adres van de DC of 127.0.0.1 instelt als DNS-server op de adapter van de DC maakt verder weinig uit.
DNS heeft toch root-hints; dan is het logisch dat de DNS-server het raadpleegt op localhost?
Ik zie alleen niet waarom GPO's fout lopen op DNS? Intern DNS-verkeer is aanzienlijk "makkelijker" dan extern DNS-verkeer en zolang jouw GPO's niets doen met public FQDN's, zou ik je adviseren even een volledige DCDIAG te draaien en AGPM Logging aan te zwengelen (mits je forest level dit toelaat).
Ik zie alleen niet waarom GPO's fout lopen op DNS? Intern DNS-verkeer is aanzienlijk "makkelijker" dan extern DNS-verkeer en zolang jouw GPO's niets doen met public FQDN's, zou ik je adviseren even een volledige DCDIAG te draaien en AGPM Logging aan te zwengelen (mits je forest level dit toelaat).
Mijn advertenties!!! | Mijn antwoorden zijn vaak niet snowflake-proof
Thanks, ik heb even gekeken in de DNS instellingen daar staat bij de eigenschappen bij Interfaces alleen het IP adres van de DC zelf 172.16.0.2 de 127.0.0.1 staat daar niet bij in dat lijstje. Ik neem aan dat dit zo hoort, ik kan me niet herinneren dat dit verkeerd is.
Goed idee, die diag gaan we maar eens doen. Wel is het zo dat als de terminal server een herstart krijgt dat alles weer werkt voor een dag of 4, daarna krijgen gebruikers tijdens het inloggen hun netwerkschijven niet meer mee via GPO, dan krijg je ook in het logboek weer dns timeouts. De boel draait al 3 jaar zonder problemen tot nu eigenlijk zonder dat er ooit instellingen zijn aangepast.MAX3400 schreef op woensdag 13 september 2017 @ 14:11:
DNS heeft toch root-hints; dan is het logisch dat de DNS-server het raadpleegt op localhost?
Ik zie alleen niet waarom GPO's fout lopen op DNS? Intern DNS-verkeer is aanzienlijk "makkelijker" dan extern DNS-verkeer en zolang jouw GPO's niets doen met public FQDN's, zou ik je adviseren even een volledige DCDIAG te draaien en AGPM Logging aan te zwengelen (mits je forest level dit toelaat).
Ik krijg nu net te horen dat één van de gebruikers al ingelogd was. Een zwart scherm kreeg en daarna weer terug kwam in de terminal sessie zonder netwerkmapping en zonder desktop icoontjes (redirected folders). Dat klinkt mij toch meer als een netwerkprobleem en niet zozeer alleen DNS. Alles draait trouwens op één hyper-v host
Je hebt op de Terminal Server niet een secundaire DNS-server ingesteld?
De terminal heeft één dns ingesteld en dat is de DC. Ik zie nu op hetzelfde tijdstip als wanneer het mis ging dit staan in het logboek van een andere server, de lokale Exchange server.
Event 5719 NETLOGON
This computer was not able to set up a secure session with a domain controller in domain "klantnaam" 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.
ADDITIONAL INFO
If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.
Event 5719 NETLOGON
This computer was not able to set up a secure session with a domain controller in domain "klantnaam" 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.
ADDITIONAL INFO
If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.
Wordt het niet eens tijd om namen en rugnummers te noemen? Of draai je nog Windows 2003? Hoe zit het met je recente updates/hotfixes? Gebruik je SCOM? Wat is de performance van de DC?
Mijn advertenties!!! | Mijn antwoorden zijn vaak niet snowflake-proof
Misschien eerst alle servers maar eens volledig updaten en het hele zooitje allemaal herstarten.MAX3400 schreef op woensdag 13 september 2017 @ 14:50:
Wordt het niet eens tijd om namen en rugnummers te noemen? Of draai je nog Windows 2003? Hoe zit het met je recente updates/hotfixes? Gebruik je SCOM? Wat is de performance van de DC?
1 hyper-v host met 2012R2. 3 VM's , allemaal Server 2012R2 draaien op diezelfde host. De meldingen dat het domein niet kan worden gevonden en er geen logonservers zijn gaan terug tot juni 2017 en gebeurt 1 a 2 keer per week. De servers worden niet actief gemonitord maar kunnen altijd remote worden overgenomen.
Het probleem lijkt nu te zitten in het feit dat als gebruikers afmelden van de terminal server dat de gebruikerssessie en de bestanden open blijven staan op de DC / file server. Als je opnieuw inlogt zijn je bestanden nog gelocked ofzo. Enige wat helpt is alles herstarten maarja, dat wil je niet elke dag hoeven doen
Verwijderd
Leer je users dat ze hun Office bestanden etc. even netjes opslaan. Of forceer een logoff na x uur (zou ik zelf overigens nooit doen, maar is mogelijk).metallicelmo schreef op woensdag 13 september 2017 @ 15:44:
Het probleem lijkt nu te zitten in het feit dat als gebruikers afmelden van de terminal server dat de gebruikerssessie en de bestanden open blijven staan op de DC / file server. Als je opnieuw inlogt zijn je bestanden nog gelocked ofzo. Enige wat helpt is alles herstarten maarja, dat wil je niet elke dag hoeven doen
Maar dat is wel iets heel anders dan hetgeen je vraagt in je startpost.
Behalve dat wanneer je NIC IP niet actief is (kabel er uit o.i.d.) je dan ook geen resolving meer hebt. Dat kan met 127.0.0.1 niet gebeuren.Jazzy schreef op woensdag 13 september 2017 @ 14:11:
Of je nu het primaire IP-adres van de DC of 127.0.0.1 instelt als DNS-server op de adapter van de DC maakt verder weinig uit.
Of het ook wat uitmaakt qua load kan ik nergens vinden, denk dat de stack van windows zelf slim genoeg is om dat niet via de NIC te laten lopen.
Duct tape can't fix stupid, but it can muffle the sound.
ik zag dus net in Computer Beheer op de dc/fileserver van diverse users wel 5 sessies open staan, als ze allemaal netjes uitloggen en op de terminal is er niemand meer ingelogd dan zie je na 15 minuten nog steeds alle sessies en bestanden open staan op de dc/file server. Gebruikers kunnen dan niet inloggen omdat de files al in gebruik zijn door een ander sessie id ofzo. Heel vaag, herstart van de terminal lijkt dan te helpen. Dat heb ik nu net weer moeten doen, kreeg net een telefoontje. Tevens de terminal server meer geheugen en schijfruimte geven. Was 7 gb vrije ruimte, nu 20 gb vrij. van 10GB naar 12GB RAM. kon niet meergeheugen uitdelen helaas. Het zijn 11 users
[ Voor 14% gewijzigd door metallicelmo op 13-09-2017 16:06 ]
Pagina: 1