Probleem met AD DC/AD DS

[Jordverhagen]

Modbreak:

Knip. Werving is niet toegestaan, dus nee....

Mijn vraag
Ik heb voor mijn opleiding een server nodig die ik aan een werkstation verbind (windows 8 of 10)
ik heb vervolgend alles gedaan wat bekend is en voorheen wel gewerkt heeft.
heb een clean server 2012 r2 geinstalleerd en een clean windows 10.
ik heb een AD DS/DHCP/DNS aangemaakt en geconfigureerd volgend de volgende tutorial (just to be sure...)
[YouTube: https://www.youtube.com/watch?v=W4L6ydJplRs]

naderhand krijg ik de zelfde error die ik zelf al kreeg....



alles word in VMWARE 12.5 PRO gedaan.

Relevante software en hardware die ik gebruik
VMWARE 12.5 PRO
Intel core i7-3610QM @ 16GB DDR3
512GB SSD

VMWARE Windows 2012 R2 > 1Core 2CPU's > 4GB RAM > 60GB Main disk
VMWARE Windows 10 > 1Core 1CPU > 2GB RAM > 40GB Main disk

Wat ik al gevonden of geprobeerd heb
ik heb een AD DS/DHCP/DNS aangemaakt en geconfigureerd volgend de volgende tutorial (just to be sure...)
[YouTube: https://www.youtube.com/watch?v=W4L6ydJplRs]

naderhand krijg ik de zelfde error die ik zelf al kreeg....

Modbreak:

Knip. Werving is niet toegestaan, dus nee.... Dus ook niet hier plaatsen...

[ Voor 35% gewijzigd door F_J_K op 29-03-2017 15:59 . Reden: Werving verwijderd. ]

[BarrelFanatic6]

Heb je de server wel gepromoveerd tot DC via dcpromo?

[Jordverhagen]

BarrelFanatic6 schreef op woensdag 29 maart 2017 @ 14:50:
Heb je de server wel gepromoveerd tot DC via dcpromo?

Ja, uiteraard is dit al gedaan.

[BarrelFanatic6]

Kan je de server wel pingen op de client?

[PD2JK]

Lijkt op een DNS probleem, kun je de server pingen? (dus niet op IP basis maar op naam)

[.Maarten]

Zitten ze beide wel in het zelfde netwerk in VMware workstation?
Kun je beide pingen?

[Tommiiee]

Probeer het eens zonder '.local'

[Jordverhagen]

PD2JK schreef op woensdag 29 maart 2017 @ 14:52:
Lijkt op een DNS probleem, kun je de server pingen? (dus niet op IP basis maar op naam)

--- edit ga nu naam pingen.

[ Voor 5% gewijzigd door Jordverhagen op 29-03-2017 14:54 ]

[Jordverhagen]

.Maarten schreef op woensdag 29 maart 2017 @ 14:52:
Zitten ze beide wel in het zelfde netwerk in VMware workstation?
Kun je beide pingen?

[BarrelFanatic6]

En als je pingt op basis van naam? Dus niet op IP.

[PD2JK]

Nee

Doe eens:

ping jord_server

[Jordverhagen]

PD2JK schreef op woensdag 29 maart 2017 @ 14:54:
Nee

Doe eens:

ping jord_server

[.Maarten]

Dat ip is een extern adres. Die kun je dus altijd pingen omdat dat gewoon ergens op het internet is.

[Jordverhagen]

BarrelFanatic6 schreef op woensdag 29 maart 2017 @ 14:54:
En als je pingt op basis van naam? Dus niet op IP.

geen gehoor...

[PD2JK]

Stel een statische DNS in op je netwerkkaart van de client, DNS1 wordt dan het IP van je server.

[BarrelFanatic6]

Als je eens pingt naar de naam van de server, niet de naam van het domein?

[DukeBox]

Aan de ping tijden te zien ping je hoe dan ook geen lokaal adres. Wat is de reden dat je geen RFC 1918 range gebruikt ?

[.Maarten]

Welke ip adressen gebruik je trouwens?

[Jordverhagen]

PD2JK schreef op woensdag 29 maart 2017 @ 14:56:
Stel een statische DNS in op je netwerkkaart van de client, DNS1 wordt dan het IP van je server.

zowel als de server en client had ik 191.169.145.10 als static dns.

maar geen succes.

tevens is dit IP een gegeven. dus hiermee moeten we het doen (191.169.145.0 /24)

[Jordverhagen]

.Maarten schreef op woensdag 29 maart 2017 @ 14:57:
Welke ip adressen gebruik je trouwens?

tevens is dit IP een gegeven. dus hiermee moeten we het doen (191.169.145.0 /24)

[BarrelFanatic6]

Ping eens naar het interne IP van de server.

[Jordverhagen]

DukeBox schreef op woensdag 29 maart 2017 @ 14:57:
Aan de ping tijden te zien ping je hoe dan ook geen lokaal adres. Wat is de reden dat je geen RFC 1918 range gebruikt ?

wat bedoel je met rfc1918|?|

[Question Mark]

Geef eens de output van "ipconfig /all" van je client en je DC?

[Jordverhagen]

BarrelFanatic6 schreef op woensdag 29 maart 2017 @ 14:58:
Ping eens naar het interne IP van de server.

al geprobeerd maar daar staat static 191.169.145.10

[BarrelFanatic6]

Zit je client dan ook verbonden als intern netwerk via die NIC?

[Jordverhagen]

Question Mark schreef op woensdag 29 maart 2017 @ 14:59:
Geef eens de output van "ipconfig /all" van je client en je DC?

[Jordverhagen]

BarrelFanatic6 schreef op woensdag 29 maart 2017 @ 15:01:
Zit je client dan ook verbonden als intern netwerk via die NIC?

Modbreak:

Nee.....

[ Voor 19% gewijzigd door Question Mark op 29-03-2017 15:18 ]

[.Maarten]

Stel je netwerken in Workstation eens in dat ze beide hetzelfde gebruiken. En stel daarna de ipadressen eens statisch in in de 192.168.*.* range.

[BarrelFanatic6]

Het lijkt erop dat je client niet intern is verbonden met je server, wat ook de hoge ping kan verklaren. Ik heb geen ervaring met VMWare maar wellicht dat je de adapters anders moet instellen. (In VirtualBox heeft dit "Intern netwerk")

[DukeBox]

Jordverhagen schreef op woensdag 29 maart 2017 @ 14:59:
wat bedoel je met rfc1918|?|

Google stuk ? Wikipedia: RFC 1918

Zit er geen les materiaal bij die opleiding ? Zijn wel een beetje AD 101 dingen.

[ Voor 59% gewijzigd door DukeBox op 29-03-2017 15:06 ]

[Aapie]

nvm

[ Voor 122% gewijzigd door Aapie op 29-03-2017 15:18 ]

[Jordverhagen]

BarrelFanatic6 schreef op woensdag 29 maart 2017 @ 15:04:
Het lijkt erop dat je client niet intern is verbonden met je server, wat ook de hoge ping kan verklaren. Ik heb geen ervaring met VMWare maar wellicht dat je de adapters anders moet instellen. (In VirtualBox heeft dit "Intern netwerk")

in vmware is het gewoon een NIC zonder specifike naam.
waar zou de interene kaart op moeten staan? host-only / NAT/ briged? en de externe kaart?

[TFZ61]

.Maarten schreef op woensdag 29 maart 2017 @ 15:03:
Stel je netwerken in Workstation eens in dat ze beide hetzelfde gebruiken. En stel daarna de ipadressen eens statisch in in de 192.168.*.* range.

Inderdaad, ga naar settings van je virtuele machines, kijk hoe de netwerkkaarten zijn ingesteld in VMware.

[Jordverhagen]

DukeBox schreef op woensdag 29 maart 2017 @ 15:05:
[...]

Google stuk ? Wikipedia: RFC 1918

Zit er geen les materiaal bij die opleiding ? Zijn wel een beetje AD 101 dingen.

het lesboek heb ik al meerdere malen gevolgd. maar krijg dit probleem telkens.

[Tommiiee]

Jordverhagen schreef op woensdag 29 maart 2017 @ 15:06:
[...]


het lesboek heb ik al meerdere malen gevolgd. maar krijg dit probleem telkens.

Dan ligt het hoogstwaarschijnlijk inderdaad aan je VMware setup. Ik zou beide VM's op 'Host Only' NICs zetten en geen 2e netwerkkaart eraan hangen. Dan maar even geen internet. Kun je later alsnog toevoegen als dit werkt.

Edit: als je ze op host-only ze wel ff samen in het juiste VMnet hangen (dus allebei hetzelfde VMnet).

[ Voor 11% gewijzigd door Tommiiee op 29-03-2017 15:08 ]

[Jordverhagen]

Tommiiee schreef op woensdag 29 maart 2017 @ 15:07:
[...]

Dan ligt het hoogstwaarschijnlijk inderdaad aan je VMware setup. Ik zou beide VM's op 'Host Only' NICs zetten en geen 2e netwerkkaart eraan hangen. Dan maar even geen internet. Kun je later alsnog toevoegen als dit werkt.

Edit: als je ze op host-only ze wel ff samen in het juiste VMnet hangen (dus allebei hetzelfde VMnet).

DANK

[BarrelFanatic6]

Heet dus host-only in VMWare Heb ik ook weer wat geleerd.

[Jordverhagen]

Tommiiee schreef op woensdag 29 maart 2017 @ 15:07:
[...]

Dan ligt het hoogstwaarschijnlijk inderdaad aan je VMware setup. Ik zou beide VM's op 'Host Only' NICs zetten en geen 2e netwerkkaart eraan hangen. Dan maar even geen internet. Kun je later alsnog toevoegen als dit werkt.

Edit: als je ze op host-only ze wel ff samen in het juiste VMnet hangen (dus allebei hetzelfde VMnet).

tevens heb ik het probleem dat ik geen netwerk verbinding heb op de client.
punt 1 is waarschijnlijk om in de server een 2e nic te hangen die wel aan het netwerk verbonden is.

[BarrelFanatic6]

Dat is inderdaad de oplossing, daarna moet je ook de role voor routing installeren.

[Jordverhagen]

BarrelFanatic6 schreef op woensdag 29 maart 2017 @ 15:13:
Dat is inderdaad de oplossing, daarna moet je ook de role voor routing installeren.

NAT neem ik aan

we gebruiken andere termen

[BarrelFanatic6]

NAT in VMWare inderdaad, maar in je server zelf heb je nog je routing role nodig. (staat onder DirectAccess dacht ik)

[Jordverhagen]

BarrelFanatic6 schreef op woensdag 29 maart 2017 @ 15:15:
NAT in VMWare inderdaad, maar in je server zelf heb je nog je routing role nodig. (staat onder DirectAccess dacht ik)

valt onder NAT (gelukkig )

[BarrelFanatic6]

Ahh, de role heet dus Remote Access, is al even geleden dat ik het zelf gebruikt heb het configureren van de routing kom je zelf uit neem ik aan?

[Question Mark]

Een multi-homed Domain Controller is vragen om problemen.... Zeker als je nog niet voldoende kennis hebt van basiszaken...

[Jordverhagen]

BarrelFanatic6 schreef op woensdag 29 maart 2017 @ 15:19:
Ahh, de role heet dus Remote Access, is al even geleden dat ik het zelf gebruikt heb het configureren van de routing kom je zelf uit neem ik aan?

voor zover ik weet kom ik er wel uit. zo niet hoor je het

[HKLM_]

pagina 2 gemist

[ Voor 91% gewijzigd door HKLM_ op 29-03-2017 15:25 ]

[DukeBox]

Question Mark schreef op woensdag 29 maart 2017 @ 15:20:
Een multi-homed Domain Controller is vragen om problemen.... Zeker als je nog niet voldoende kennis hebt van basiszaken...

Met het unbinden van DNS aan je 'externe' NIC komt TS al een heel end.

[@r!k]

Question Mark schreef op woensdag 29 maart 2017 @ 15:20:
Een multi-homed Domain Controller is vragen om problemen.... Zeker als je nog niet voldoende kennis hebt van basiszaken...

Dat 191.x ip adres vind ik nog veel merkwaardiger. Waarom een publiek IP adres nemen voor de server en voor de client wel een uit de private range? Lijkt mij persoonlijk een typefout in de opdracht.

Even nslookup doen levert ook een ip adres uit zo te zien Brazillië op dan. Zeer merkwaardig.

[ Voor 9% gewijzigd door @r!k op 29-03-2017 15:27 ]

[Jordverhagen]

@r!k schreef op woensdag 29 maart 2017 @ 15:25:
[...]


Dat 191.x ip adres vind ik nog veel merkwaardiger. Waarom een publiek IP adres nemen voor de server en voor de client wel een uit de private range? Lijkt mij persoonlijk een typefout in de opdracht.

onderin staat <naam > 191.169.145.0 /24

[@r!k]

Jordverhagen schreef op woensdag 29 maart 2017 @ 15:27:
[...]


onderin staat <naam > 191.169.145.0 /24

[afbeelding]

Niet op je screenshot hoor.

Maar ook al staat het er, dat kan niet en is geen best practice tenzij je dat IP adres in bezit hebt en dat heb je niet.

[ Voor 19% gewijzigd door @r!k op 29-03-2017 15:30 ]

[Jordverhagen]

@r!k schreef op woensdag 29 maart 2017 @ 15:29:
[...]

Niet op je screenshot hoor.

onderin dit document staan alle leerlingen + IP

[ Voor 12% gewijzigd door Jordverhagen op 29-03-2017 15:31 ]

[BarrelFanatic6]

Een aparte range als je het mij vraagt.

[ Voor 67% gewijzigd door BarrelFanatic6 op 29-03-2017 15:32 ]

[@r!k]

Jordverhagen schreef op woensdag 29 maart 2017 @ 15:30:
[...]


onderin dit document staan alle leerlingen + IP


[afbeelding]

Bekijk je plaatje nog eens dan, want daar staat niks hoor, wel een ander ip adres die wel keurig in een private range valt.

Een nslookup op het adres dat je opgeeft komt echter hierop uit.

Name: 10.145.168.191.isp.timbrasil.com.br
Address: 191.168.145.10

<edit> Ah je hebt de lijst toegevoegd, simpele excel lijst. Ga er maar vanuit dat je leraar een tikfout gemaakt heeft. Die reeks kan gewoon echt niet, tenzij je alles prive houdt ga je het uiteindelijk wel werkend krijgen maar het is absoluut geen best practice om IP adressen van anderen te gebruiken. Ik zou mijn leraar eens een mailtje sturen als ik jou was.

[ Voor 26% gewijzigd door @r!k op 29-03-2017 15:34 ]

[Jordverhagen]

@r!k schreef op woensdag 29 maart 2017 @ 15:32:
[...]


Bekijk je plaatje nog eens dan, want daar staat niks hoor, wel een ander ip adres die wel keurig in een private range valt.

Een nslookup op het adres dat je opgeeft komt echter hierop uit.

Name: 10.145.168.191.isp.timbrasil.com.br
Address: 191.168.145.10

Modbreak:

En nogmaals.... dit is niet gewenst.... We lossen zaken met elkaar op het forum op, en niet via remote teamviewer. Houdt er ook rekening mee dat je werkt aan een schoolopdracht, en het de bedoeling is dat JIJ er van gaat leren.

Anderen jouw problemen op laten lossen is niet de bedoeling van schoolopdrachten.

[ Voor 25% gewijzigd door Question Mark op 29-03-2017 15:55 ]

[BarrelFanatic6]

Ik heb meer het gevoel dat die lijst 192.168 adressen moeten zijn in plaats van 191.169 adressen..

[@r!k]

Jordverhagen schreef op woensdag 29 maart 2017 @ 15:34:
[...]

zou je tijd hebben om via teamviewer mee te kijken? ik geloof dat ik ergens wat over het hoofd zie

Want? even een pc aan het internet hangen, nslookup openen in een command prompt en het ipadres dat je net opgaf intikken geeft dat terug als resultaat.

En nee, ik ga niet met je meekijken.

BarrelFanatic6 schreef op woensdag 29 maart 2017 @ 15:36:
Ik heb meer het gevoel dat die lijst 192.168 adressen moeten zijn in plaats van 191.169 adressen..

Ik ook.

[ Voor 21% gewijzigd door @r!k op 29-03-2017 15:38 ]

[Question Mark]

DukeBox schreef op woensdag 29 maart 2017 @ 15:24:
[...]

Met het unbinden van DNS aan je 'externe' NIC komt TS al een heel end.

Neup, de Netlogon service registreert nog steeds doodleuk alle ip-adressen van alle Nic's in DNS. Ongeacht of "register this connections addresses in DNS" enabled of disabled is...

Via de registry is dit te disablen, maar dat betekend dat handmatig de juiste (interne) srv en A-records in DNS opgevoerd moeten gaan worden. Niet onoverkomelijk overigens, mits je weet wat je moet doen...

[@r!k]

Question Mark schreef op woensdag 29 maart 2017 @ 15:53:
[...]

Neup, de Netlogon service registreert nog steeds doodleuk alle ip-adressen van alle Nic's in DNS. Ongeacht of "register this connections addresses in DNS" enabled of disabled is...

Via de registry is dit te disablen, maar dat betekend dat handmatig de juiste (interne) srv en A-records in DNS opgevoerd moeten gaan worden. Niet onoverkomelijk overigens, mits je weet wat je moet doen...

Bij 2008 R2 en 2012 zou dat geen probleem meer moeten zijn hoor. Heb er genoeg ingespoeld en toch echt niks in het register hoeven aan te passen. DNS server alleen laten luisteren op de productie NIC en ook alleen die NIC zichzelf laten registreren in DNS was voldoende.

[Question Mark]

Het gaat hier om een Domain Controller... Daar werkt het wel iets anders dan een standard member server. Zie ook onderstaand artikel van een MS trainer en MVP wat de issue (en oplossing) exact beschrijft:

http://blogs.msmvps.com/a...as-and-or-pppoe-adapters/

Multihomed DCs wiill cause numerous issues. The only exception to the rule are SBS servers, but that is a completely different topic which I will not address in this blog, but I can add that even the SBS gurus recommend to single-home it.

Het artikel beschrijft ook keurig de registry key die aangepast moet worden om de registratie door de Netlogon service te voorkomen, naast de andere zaken die uitgevoerd moeten worden.

[DukeBox]

Question Mark schreef op woensdag 29 maart 2017 @ 15:53:
Neup, de Netlogon service registreert nog steeds doodleuk alle ip-adressen van alle Nic's in DNS. Ongeacht of "register this connections addresses in DNS" enabled of disabled is...

Kan me niet herinneren dat ik daar ná 2003R2 nog last van heb gehad zolang binding en 'de NIC setting register in dns' maar correct staat.

[Question Mark]

Volgens mij speelt het nog steeds, zie ook onderstaand artikel nog:

Configuration for Multi NIC Domain Controller to Publish Single IP for Windows Server 2008 R2 & 2012

Hier staan dezelfde stappen in beschreven als het artikel wat ik al eerder aanhaalde.

Ik heb geen multihomed DC tot mijn beschikking, maar het zou fijn zijn als TS even de inhoud van de file "netlogon.dns" kan posten (%systemroot%\System32\Config). Daar staan exact de records in, die de netlogon service registreert in de DNS-server. Ik vermoed dat zonder aanpassingen daar alle know ip's in staan.

[ Voor 28% gewijzigd door Question Mark op 29-03-2017 19:03 ]

[@r!k]

Question Mark schreef op woensdag 29 maart 2017 @ 16:56:
Het gaat hier om een Domain Controller... Daar werkt het wel iets anders dan een standard member server. Zie ook onderstaand artikel van een MS trainer en MVP wat de issue (en oplossing) exact beschrijft:

http://blogs.msmvps.com/a...as-and-or-pppoe-adapters/


[...]


Het artikel beschrijft ook keurig de registry key die aangepast moet worden om de registratie door de Netlogon service te voorkomen, naast de andere zaken die uitgevoerd moeten worden.

Daar hebben we het wel over ja, domain controllers. Nogmaals sinds 2008 R2 en 2012 heb ik dit nooit hoeven doen. Ik heb het nog even voor je nagekeken (ik beheer meerdere multihomed DC's) en het enige dat we doen is de Binding order goed zetten, do not register this adapter in DNS aanvinken op de niet productie NIC, en de DNS server alleen laten luisteren op de Productie NIC/Ip adres(sen). Meer niet.

Met 2003 was het inderdaad een heel gedoe maar ik ben dit al jaren niet meer tegengekomen.

[DukeBox]

@r!k schreef op donderdag 30 maart 2017 @ 09:15:
Daar hebben we het wel over ja, domain controllers. Nogmaals sinds 2008 R2 en 2012 heb ik dit nooit hoeven doen.

Hier exact het zelfde, wat wel nog van belang is dat je sites en services correct staan (juiste ranges e.d.).

Heb regelmatig multihomed DC's gemanaged doordat er bijv. storage middels iSCSI aan hing of dat ding iets van routing/proxy deed.

[Question Mark]

@r!k schreef op donderdag 30 maart 2017 @ 09:15:
[...]
Ik heb het nog even voor je nagekeken (ik beheer meerdere multihomed DC's) en het enige dat we doen is de Binding order goed zetten, do not register this adapter in DNS aanvinken op de niet productie NIC, en de DNS server alleen laten luisteren op de Productie NIC/Ip adres(sen). Meer niet.

Intressant, kun je voor de zekerheid nog eens kijken in de netlogon.dns file?

[@r!k]

Question Mark schreef op donderdag 30 maart 2017 @ 11:35:
[...]

Intressant, kun je voor de zekerheid nog eens kijken in de netlogon.dns file?

Al gedaan, staat alleen de productie nic in.

[Question Mark]

Nice, thx.

Ik wist niet dat MS hier aanpassingen aan heeft doorgevoerd. Als je d'r online op gaat zoeken kom je nog steeds veel documentatie tegen waarin staat dat je eea nog steeds moet aanpassen.

[@r!k]

Question Mark schreef op donderdag 30 maart 2017 @ 12:59:
Nice, thx.

Ik wist niet dat MS hier aanpassingen aan heeft doorgevoerd. Als je d'r online op gaat zoeken kom je nog steeds veel documentatie tegen waarin staat dat je eea nog steeds moet aanpassen.

Ze voeren nog wel eens verbeteringen door. Net als bij een DR van Ad, als je een forest recovery doet in 2003 moet je de gegevens van de oude dc's verwijderen met ntdsutil en nog meer procedures, vanaf 2008 hoef je alleen maar het computer account te verwijderen en een extra vinkje aan te vinken. Scheelt zoveel tijd.

Disclaimer, de hele DR procedure is wel een stuk langer uiteraard maar op alleen al dit stuk hebben ze enorm verbetering geboekt.

[ Voor 9% gewijzigd door @r!k op 30-03-2017 20:28 ]

[DukeBox]

Question Mark schreef op donderdag 30 maart 2017 @ 12:59:
Ik wist niet dat MS hier aanpassingen aan heeft doorgevoerd. Als je d'r online op gaat zoeken kom je nog steeds veel documentatie tegen waarin staat dat je eea nog steeds moet aanpassen.

Omdat veel mensen ook niet weten dat het is opgelost en allemaal work-arounds gaan doen terwijl het nu eigenlijk werkt zoals het zou moeten werken.

[Question Mark]

Punt is dan ook dat de documentatie van MS niet op dit punt bijgewerkt wordt. Een probleem wat je tegenwoordig wel meer ziet overigens.

Ik heb gisteren serieus gezocht op Technet, en heb er géén officiele documentatie over kunnen vinden. Alleen nog "verouderde" docu, waarin staat dat er nog steeds handmatig zaken aangepast moeten gaan worden.

Als je vervolgens wél docu tegenkomt van een MS trainer en MVP, die verklaart dat het nog steeds niet opgelost is, en de workaround nog steeds moet worden toegepast ben je al snel geneigd de workaround toe te gaan passen.

Mooi dat het nu wel duidelijk is.