domainname.local/sysvol verwijst naar verkeerde DC

[Cai]

Situatie
In Amsterdam een SBS 2008 DC in domein: domein.local genaamd server1 -192.168.2.3
In Eindhoven een Server2008R2 DC in domein: domein.local genaamd server2 -192.168.5.2

Eindhoven is in Amsterdam dmv domainprep/forestprep enz succesvol gejoined en gepromoveerd naar DC. Vervolgens is de Server2 verplaatst naar Eindhoven. Via een hardwarematige (Draytek) site-to-site VPN zien beide server nu elkaar.

De Clients in Amsterdam gebruiken de DHCP server van Server1 en dienen die te gebruiken als logonserver. Dit gaat goed (gecontroleerd door SET commando).

De policies deployen echter niet goed en het aanmelden duur +- 5 min. Na debuggen kwam ik op het volgende. Het werkstation kan policy XYX niet vinden. Deze is nog niet aangekomen in Eindhoven.

Aldoende dit debuggen blijkt het volgende.

Op windows 7 werkstations in Amsterdam verwijst domein.local\sysvol naar Server 1 -> Correct
Op windows XP werkstation in Amsterdam verwijst domein.local\sysvol naar Server 2 -> Incorrect, gevolg een hoop problemen ivm timeouts over VPN.

Op het windows XP station een nslookup gedaan naar domein.local en die resolved naar server1
Pingen naar server 1 gaat goed - 192.168.2.3

Echter \\domein.local\sysvol\ kom je uit op de inhoud van server 2

Vraag
Waar gaat het hier fout?

Hoho, wat heb je zelf al gedaan
Gegoogled, daar een hotfix gevonden van XP clients icm DFS, die naar de verkeerde server kijken. Geinstalleerd, maar gedrag blijft onveranderd.

SBS 2008 heeft geen WINS-server rol, daar kan ik weinig (volgens mij)m aanpassen.

Geen idee, in welke hoek ik moet zoeken.

[NightMare]

Heb je je sites goed gedefinieerd in AD Sites & Services? Dus netjes 2 aparte sites aanmaken incl juiste subnets (1 voor Ehv en 1 voor Ams!). Daarna zorgen dat de servers in de juiste sites staan....

[ Voor 5% gewijzigd door NightMare op 10-08-2010 14:01 ]

[Physics]

Dus als ik het een beetje begrijp, Server2 is de DC. Waarbij de clients inloggen op Server1.
Nu is het zo dat de policy's geladen worden uit Server2 die verbonden staat via VPN tunnel met Server1.

De workstations laden de policy's van Server2? via de VPN tunnel?

[Cai]

Beide Servers zijn een DC

De policy's worden geladen van server 1

[ Voor 46% gewijzigd door Cai op 10-08-2010 14:07 ]

[wasted247]

NightMare schreef op dinsdag 10 augustus 2010 @ 14:01:
Heb je je sites goed gedefinieerd in AD Sites & Services? Dus netjes 2 aparte sites aanmaken incl juiste subnets (1 voor Ehv en 1 voor Ams!). Daarna zorgen dat de servers in de juiste sites staan....

Dit dus, vrij essentieel in AD omgevingen met meerdere locaties / subnet's.

[Physics]

Je moet idd in server 1 in AD de sites& services instellen. Zowel Server 1 als Server 2. Daarbij ook de subnets aanmaken van zowel server 1 als 2. Aangeraden het ook automatisch met elkaar te laten synchroniseren.

AD kijkt nu in het rond omdat hij het bestaan van server 2 niet kent. Niet zolang je het in AD op server 1 aangemaakt hebt onder Sites&Services

[Cai]

De sites en subnets ingesteld.

Echter het probleem dat sommige werkstations naar de inhoud van server2 kijken waneer gebrowsed wordt naar \\domein.local\ is niet opgelost.

Hoe/met welk commanda kan ik resolven waar het werkstation de betreffende info vandaan haalt?

[sanfranjake]

1. Je kan wel een WINS-server op 2008 installeren. Dit is geen role, maar een feature.
2. Is in C:\Windows\Sysvol\Domain\Policies wel de inhoud van je policies te zien op de tweede dc?
3. Fouten in de evenlogs op beide dc's?
4. Is er in AD Sites and Services een automatisch-gegenereerd intersite-replicatiepad tussen de beide dc's?
5. Krijg je met repadmin /showrepl en eventueel na repadmin /syncall ook nog steedfs problemen (wacht wel even want afhankelijk van het aantal policies en de daarin aanwezige content kan het best een tijdje duren, zeker over een wan-link!)
6. Neem even aan dat je nu via NTFRS repliceert, of repliceer je via DFS-R? Zie dfsrmig /showmigrationstate voor info daarover.

[hans_lenze]

Cai schreef op dinsdag 10 augustus 2010 @ 17:12:
De sites en subnets ingesteld.

Echter het probleem dat sommige werkstations naar de inhoud van server2 kijken waneer gebrowsed wordt naar \\domein.local\ is niet opgelost.

Hoe/met welk commanda kan ik resolven waar het werkstation de betreffende info vandaan haalt?

Heb je ook in DNS gekeken of de wijzigingen daar ook zijn doorgevoerd? Ik heb slechte ervaringen met het achteraf veranderen van een IP adres van een DC. De helft van de forward lookup zones staat nog steeds niet lekker ingesteld. MS DNS geeft standaard het lokale subnet een hogere prioriteit bij het antwoorden van DNS requests (het lokale subnet van de client).

[chratnox]

nslookup kijkt niet naar AD, die kijkt puur naar DNS. In DNS zul je zien dat er een A record bestaat per DC met de naam domainname.local, wat in principe een round robin DNS situatie oplevert. Doordat AD DNS gebruik maakt van subnet priorization wordt altijd een bepaald A record teruggegeven wanneer de client in hetzelfde subnet zit als dit A-record voor geregistreerd is. Je kan wel verwachten dat indien er iets niet goed is in DNS (denk aan een IP adres blijven hangen ergens) dit mechanisme onderuit gaat.

Door een nslookup uit te voeren laat je je DNS client het A record voor het domein onthouden. Dit houdt in dat gedurende de TTL van het A-record je gebruik maakt van de ene DC, maar wanneer de TTL verlopen is en DNS zijn zaken gaat updaten, kan ie de andere DC benaderen wanneer je het weer probeert. Dit levert onverwachtte situaties op.

Mijn advies: Controleer of alles in DNS in orde is (denk dus ook aan je _msdcs zones etc, controleer of je DC hier goed in staat).

Zie ook:
http://msmvps.com/blogs/acefekay/archive/2010/05/29/dns-and-subnet-priortization-amp-dns-round-robin.aspx

[ Voor 50% gewijzigd door chratnox op 10-08-2010 22:04 . Reden: Completeren bericht ]

[Rolfie]

Hoe/met welk commanda kan ik resolven waar het werkstation de betreffende info vandaan haalt?

Enabling debug logging for the Net Logon service

Aan WINS zou ik zeker niet beginnen. Is ook totaal niet nodig.

het eerste waar ik aan denk ik Site and Services. Staan daar 2 sites geconfigueerd? En staan de domain Contollers in de goede Site? En repliceren ze met elkaar?
Hier gaat het waarschijnlijk ergens verkeerd.

[Parzival]

wat iedereen zegt.. sites en services.. het logon proces kijkt naar de _msdcs service records voor het domein. Het pingen van domein.local is heel iets anders, dan wordt er naar de DNS servers zelf gekeken.. en dat kan een willekeurig antwoord zijn.

Ga naar sites en services, maak 2 subnets aan (192.168.1.0/24 en 192.168.5.0/24) en die koppel je in eerste instantie aan de Default first site. Daarna een nieuwe site maken en daar die 192.168.5.0/24 aan hange en een koppeling maken tussen de twee sites (site link). Wachten tot replicatie is voltooid (repadmin <dc> /syncall AeD) en daarna de clients opnieuw opstarten. Op een client kun je daarna (als je support tools hebt) via NLTEST /DSGETSITE kijken of in de juiste site wordt gekeken.
Evt moet je ook de DC opnieuw opstarten (of netlogon proces).

WINS wordt niet gebruikt in >2003 en >XP systemen en gaat je dus ook niet helpen.