[2003 Sites en Services] Aanmelding binnen Site

[Verwijderd]

We zijn al een tijd bezig om het volgende probleem te tackelen: werkstations melden aan op servers buiten hun sites of subnet.

Dit is onze situatie:

Één Domein, meerdere Sites.

Voorbeeld 8 sites.

Site A 10.1.0.0/22
Site B 10.1.100.0/22
Site C 10.1.110.0/22
Site D 10.1.125.0/22
Site E 10.1.140.0/22
Site F 10.1.165.0/22
Site G 10.1.185.0/22
Site H 10.1.200.0/22

Alle sites zijn gekoppeld d.m.v. VPN-verbindingen en sites kunnen elkaar zien/pingen. Al het verkeer word gerouteerd en DNS zorgt voor domeinbrede resolutie.

In Site A staan onze PDC (Server2003 R2 SP2), Exchange (2003 Ent.) en enkele file- en webservers. De PDC is ook de forward server voor DNS voor de BDC’s op de locaties. De Exchange Server is ook DC.
Het is niet de bedoeling dat cliënts aanmelden binnen deze site.

In Site B t/m H staat steeds één BDC welke ook de fileserver en DNS-server zijn voor die locatie. De replicatie van AD en DNS werkt tussen de locatie en Site A. Een gebruiker aangemaakt in Site G is zichtbaar in Site A en vice versa.



Volgens de documentatie van Microsoft wordt de aanmelding bepaald door de door in de DNS opgegeven gegevens, de zogenaamde SRV-records. Hier staan in de _ldap-records opgegeven welke servers domeincontrollers zijn. Nu zou het, volgens diezelfde literatuur, zo moeten zijn dat een cliënt altijd binnen zijn eigen subnet probeert een DC aan te spreken. Dit gebeurt echter niet.
Een cliënt met de volgende IP gegevens:

IP 10.1.185.0
Subnet 255.255.252.0
Gateway 10.1.185.1
Dns 10.1.185.10

meldt rustig aan in Site A (10.1.0.0/22)

Door via Start > Uitvoeren > %logonserver% in te typen op het werkstation wordt keurig onze Exchange Server geresolved, terwijl die IP gegevens zijn van Site G, en onze Exchange Server staat in Site A.

Bepaalde, voor die locatie ‘ongewenste’ DNS-records zou je wel kunnen wissen op iedere locatieserver, maar aangezien DNS in de AD geïntegreerd is, zal dit door de replicatie hersteld worden. En zo hoort het ook.
Hoe kunnen wij cliënts forceren aan te melden op de DC van hun eigen site, zonder aanpassingen (registry hacks e.d.) op de cliënts te doen?

[Rolfie]

Hoe zit het met je Global Catalog's?

[Verwijderd]

De enige Global Catalog server in de organisatie is de Exchange Server, die staat in Site A.

[Rolfie]

Is daar een speciale redenen voor? Ik weet niet hoe groot je sites zijn, maar als het kan dan zou ik meestel ook een GC op een site neer zetten.

heb je de mogelijkheid om er 1 een GC te maken en te testen?

Gebuik anders eens "How to enable user environment debug logging in retail builds of Windows" om te kijken waarom die naar de andere site gaat.

Je kan eventueel ook het geforceerd doen, zoals je vroeg in je topic, maar ik zou eerst kijken waarom die het doet. Finding a Domain Controller in the Closest Site

[ Voor 57% gewijzigd door Rolfie op 21-05-2007 22:07 ]

[Jazzy]

Hoe heb je de sites aangemaakt en er een subnet aan gekoppeld? Het lijkt er op dat er iets niet goed is gegaan bij de configuratie.

[sanfranjake]

Heb je Universal group membership caching aan staan voor de sites? En wat is precies de reden dat de domaincontrollers (Active Directory kent geen pdc/bdc zoals nt4) geen global catalog zijn op de andere locaties?
Ook al eens gedacht aan AD integrated DNS?
Staan sites in je AD sites and services precies zo ingesteld als in je tekening?

[ Voor 8% gewijzigd door sanfranjake op 21-05-2007 23:51 ]

[Verwijderd]

sanfranjake schreef op maandag 21 mei 2007 @ 23:50:
Heb je Universal group membership caching aan staan voor de sites? En wat is precies de reden dat de domaincontrollers (Active Directory kent geen pdc/bdc zoals nt4) geen global catalog zijn op de andere locaties?
Ook al eens gedacht aan AD integrated DNS?
Staan sites in je AD sites and services precies zo ingesteld als in je tekening?

<- Collega van Eddie...
Binnen een Windows2003 domeinstructuur worden nog steeds de termen PDC en BDC gebruikt. Klik maar eens op eigenschappen van een server. De PDC is gewoon de eerste DC in je domein (tijdens promovering). Alhoewel er geen sprake meer is van de termen primaire en secundaire DC's, is nog wel degelijk sprake van een hiërarchie. Maar we dwalen af.

DNS is hier al geintegreerd in de AD.

Per Site is een subnet en een server (DC) toegekend. Op de 'hoofdsite' (Site A) staan twee servers in S&S, de eerste DC en de Mail (GC). De rest zijn memberserver en staan niet in S&S omdat deze geen AD of GC huisvesten.

[Jazzy]

Ik wil niet doorzeuren maar dat is gewoon niet waar wat je zegt. De enige keer dat die term ter sprake komt is bij 1 van de 5 FSMO-rollen, namelijk die van PDC-emulator. Die rol zit er in voor backwards compatibility en kun je bovendien onderbrengen op welke server je maar wil. Meer info lees je hiero: http://www.microsoft.com/...a0590bd948e.mspx?mfr=true

Per Site is een subnet en een server (DC) toegekend. Op de 'hoofdsite' (Site A) staan twee servers in S&S, de eerste DC en de Mail (GC). De rest zijn memberserver en staan niet in S&S omdat deze geen AD of GC huisvesten.

Daar heb je de oorzaak van je probleem. Als de server geen domaincontroller is dan kan de client er ook niet op aanmelden, je zult deze servers DC moeten maken en in de juiste site moeten zetten.

Oh, verkeerd gelezen.

[ Voor 4% gewijzigd door Jazzy op 22-05-2007 11:49 ]

[Verwijderd]

Zoals gezegd, we dwalen af. Het PDC/BDC-verhaal was alleen om aan te geven dat de eerste DC in het domein op site A staat. Dat de termen afkomstig zijn uit het NT4-tijdperk en dat de rollen en functies daardoor verschillen met DC's in een 2003 domein, is volkomen irrelevant en leidt af van het probleem wat we proberen op te lossen.

[sanfranjake]

Verwijderd schreef op dinsdag 22 mei 2007 @ 13:00:
Zoals gezegd, we dwalen af. Het PDC/BDC-verhaal was alleen om aan te geven dat de eerste DC in het domein op site A staat. Dat de termen afkomstig zijn uit het NT4-tijdperk en dat de rollen en functies daardoor verschillen met DC's in een 2003 domein, is volkomen irrelevant en leidt af van het probleem wat we proberen op te lossen.

Juist als je de topologie/materie niet begrijpt, wat ik vermoed omdat consequent verkeerde termen gebruikt worden, dan krijg je dit soort problemen. Dus wees duidelijk in al je info, zet nog eens duidelijk alle domaincontrollers op een rij. Laten we de discussie over de verschillen tussen NT4 en Active Directory verder rusten, zolang we ze maar niet door elkaar blijven gooien wat voor ontzettend veel verwarring zorgt

[Verwijderd]

Ik zou jullie volledig gelijk willen geven, maar een der laatste opmerkingen schiet me toch even in het verkeerde keelgat, namelijk dat we de materie niet zouden doorgronden. Dat is me nogal een aanname die me gebasseerd lijkt op het slecht lezen van het gegevene en met name onze motivatie voor het gebruik van die termen.

Maar ok, vergeet alsjeblieft die termen. Opnieuw de situatie:

Hoofdsite

• Een hoofdsite (Site A) met eigen subnet en twee servers die domeincontrollers zijn.
• Eén server is forward DNS voor de overige DC's.
• De andere is de Exchange mailserver en huist tevens de GC.
• Er bevinden zich géén clients in deze site.
• Er is geen DHCP-server in deze site.

Locatie Sites (nu 8, uiteindelijk 20)

• Meerdere gelijkwaardige sites (op tekening Site B t/m G) met eigen subnet en domeincontroller.
• Er is geen GC op de locatie DC's.
• DC is tevens DNS- en DHCP-server voor die site.

• De locaties zijn verbonden d.m.v VPN's
• Alle servers zijn Windows 2003 R2 SP1
• Alle clients zijn Windows XP SP2
• Clients krijgen hun DHCP-gegevens van de locale DC, dit werkt ook.
• DNS is geintegreerd in AD. DC's op locatie forwarden naar de DC op Site A.
• S&S is ingesteld, alle sites hebben een subnet toegewezen gekregen en de juiste server is aan iedere site toegekend.
• S&S. De Inter-site transports staan default, oftewel IP is ingevuld, alle locaties staan in de lijst van gekoppelde sites.
• S&S. SMTP is niet ingericht.
• S&S. Servers zijn geen bruggehoofd voor inter-site transport.
• S&S. NTDS settings zijn automatisch gegenereerd en maken verbinding met de eerste DC op site A.
• Replicatie van AD, DNS en DFS is ingesteld en werkt feilloos.

Het enige probleem wat we ondervinden is dat clients aanmelden, over de VPN, in andere subnetten, bij domeincontrollers op andere locaties of op de hoofdlocatie.
Ze krijgen dus wel netjes een IP van de locale server, maar melden er niet aan.

[Verwijderd]

Rolfie schreef op maandag 21 mei 2007 @ 22:01:
Is daar een speciale redenen voor? Ik weet niet hoe groot je sites zijn, maar als het kan dan zou ik meestel ook een GC op een site neer zetten.

heb je de mogelijkheid om er 1 een GC te maken en te testen?

Gebuik anders eens "How to enable user environment debug logging in retail builds of Windows" om te kijken waarom die naar de andere site gaat.

Je kan eventueel ook het geforceerd doen, zoals je vroeg in je topic, maar ik zou eerst kijken waarom die het doet. Finding a Domain Controller in the Closest Site

Ik keek helemaal over je post heen, sorry. We hebben enkele DC's GC's laten hosten, maar dit had geen effect op het aanmelden van de clients, helaas.
We hebben er ooit voor gekozen om geen GC te laten hosten op locatie om bandbreedte te besparen op de WAN-lijnen i.v.m. replicatie ervan. Maar tests hebben uitgewezen dat het nauwelijks meetbaar is. De keuze is dus nu, gezien bandbreedtegebruik, redelijk arbitrair. GC kan wat ons betreft dus inderdaad overal aan worden gezet, maar het sorteert helaas geen resultaat gezien het aanmeldprobleem.
Ik kom nog terug op je andere suggesties.

[sanfranjake]

Sorry, mijn aannames waren wat voorbarig en inderdaad gebaseerd op de onduidelijke informatie..
Misschien zou je in inderdaad de userenv.log kunnen kijken of je daar nog iets ziet. Misschien komt er een timeout van de GC waardoor alles langer duurt oid.
Anders is How Domain Controllers Are Located in Windows ook een goeie, misschien waren jullie die al tegengekomen.
In de topicstart wordt aangegeven dat de eerste dc Windows 2003 R2 is. Zijn alle andere domaincontrollers dat ook? Of zijn die SP1 met/zonder R2?
Misschien zou je eens naar het GC gedeelte van How to optimize the location of a domain controller or global catalog that resides outside of a client's site kunnen kijken.

[Verwijderd]

Het eerste artikel wat je noemt kende ik inderdaad al. Het geeft wel een mogelijke oplossing voor het probleem, namelijk de SRV-records binnen DNS, maar dit kan in een AD-geintergreerde DNS zoals bij ons niet. Het tweede artikel daarentegen geeft daar weer wat opties voor, namelijk het uitsluiten van replicatie voor specifieke DNS-entries. Ik duik erin.

Alle servers binnen het domein zijn Windows Server 2003 R2 Enterprise SP2.

[Jazzy]

We hebben er ooit voor gekozen om geen GC te laten hosten op locatie om bandbreedte te besparen op de WAN-lijnen i.v.m. replicatie ervan. Maar tests hebben uitgewezen dat het nauwelijks meetbaar is. De keuze is dus nu, gezien bandbreedtegebruik, redelijk arbitrair. GC kan wat ons betreft dus inderdaad overal aan worden gezet, maar het sorteert helaas geen resultaat gezien het aanmeldprobleem.

Het is juist andersom, met name als je clients van zaken als Outlook/Exchange gebruiken bespaar je juist op banbreedte als je op iedere site een GC hebt. Af en toe replicatie weegt niet op tegen het veelvuldig raadplegen van een GC door je clients.

Ik weet niet hoe urgent dit voor jullie is maar ik heb de indruk dat het al een tijdje sleept en er al de nodige uurtjes in zijn gaan zitten. Je zou kunnen overwegen om het aan te kaarten bij Microsoft PSS. Dat kost je zo'n 300 euro maar ik vermoed dat ze het probleem snel boven zullen hebben.

Sorry dat ik je verder niet kan helpen.

[Question Mark]

Controleer op een client eens de waarde van de registry-key DynamicSiteName eens.

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName

Deze key wordt normaal gesproken gevuld door de Netlogon service (die deze waarde middels de DsGetDcName Api bepaalt), en zou de lokale site voor de client moeten bevatten.

Staat hier niet de goede site in (en die kans is aardig groot aangezien de client zich aanmeld in een verkeerde site), wis dan de waarde van deze key eens en reboot eens (en controleer de waarde van deze key dan nogmaals).

[Verwijderd]

Jazzy schreef op dinsdag 22 mei 2007 @ 18:20:
[...]
Het is juist andersom, met name als je clients van zaken als Outlook/Exchange gebruiken bespaar je juist op banbreedte als je op iedere site een GC hebt. Af en toe replicatie weegt niet op tegen het veelvuldig raadplegen van een GC door je clients.

Ik weet niet hoe urgent dit voor jullie is maar ik heb de indruk dat het al een tijdje sleept en er al de nodige uurtjes in zijn gaan zitten. Je zou kunnen overwegen om het aan te kaarten bij Microsoft PSS. Dat kost je zo'n 300 euro maar ik vermoed dat ze het probleem snel boven zullen hebben.

Sorry dat ik je verder niet kan helpen.

Je hebt volledig gelijk, maar dat was nu juist de reden voor onze keuze, we stellen namelijk alleen de OWA van Exchange ter beschikking aan de clients. Geen Outlook dus. OWA(IIS) kijkt dus in de GC op hetzelfde systeem.
Maar ons is opgevallen dat de replicatie tussen de DC's wel meevalt, dus zou het inderdaad een optie zijn om een GC op iedere locatie te hosten.

Alles is altijd urgent, dat weet je toch De sites zijn nog niet operationeel, uiteraard niet, we gaan niet uitrollen voordat alle problemen zijn opgelost en iedere test is gedaan. Maar de uitrol schuift wel steeds verder op met dergelijke onvoorspelbaarheden.
We zouden er best externe hulp bij willen roepen, maar ieder bedrijf en iedere expert die we raadplegen bevestigen onze keuzes bij het ontwerp van dit netwerk. Ik ben bang dat we iets vreselijk kleins over het hoofd zien.

Question Mark schreef op dinsdag 22 mei 2007 @ 19:02:
Controleer op een client eens de waarde van de registry-key DynamicSiteName eens.

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName

Deze key wordt normaal gesproken gevuld door de Netlogon service (die deze waarde middels de DsGetDcName Api bepaalt), en zou de lokale site voor de client moeten bevatten.

Staat hier niet de goede site in (en die kans is aardig groot aangezien de client zich aanmeld in een verkeerde site), wis dan de waarde van deze key eens en reboot eens (en controleer de waarde van deze key dan nogmaals).

Dit kwam ik eerder tegen. Het probleem hiermee is, is dat we ten allertijden willen voorkomen dat we werkstations moeten aanpassen aan de site waar ze in zitten. Dit komt niet alleen omdat we met uitwisselbare images voor de werkstations werken, maar ook omdat laptops overal moeten kunnen aanmelden.
Ik neem het in ieder geval mee in de documentatie voor eventuele worst case scenarios oplossingen.

[Question Mark]

Verwijderd schreef op dinsdag 22 mei 2007 @ 20:07:
[...]Dit komt niet alleen omdat we met uitwisselbare images voor de werkstations werken, maar ook omdat laptops overal moeten kunnen aanmelden.

Kan het niet zo zijn dat deze entry gevuld is in je "master-image", meegenomen wordt in de "kloon" en daardoor niet goed meer werkt. (security settings op de key wel in orde?)

Als je de waarde dus wist, zou deze na een reboot automatisch weer gevuld moeten worden met de juiste waarde (de lokale site van de client). Na weer een reboot wordt de waarde opnieuw bepaald, enzovoort. Het is een dynamische entry die na elke reboot opnieuw bepaald wordt.

Als je de sitename hard in wilt stellen, zoals ik begrijp uit je post (als laatste redmiddel), dan heb je de registry-entry "SiteName" nodig, niet "DynamicSiteName".

Zie verder ook deze thread in een ander forum, met hetzelfde probleem, wat ook door het wissen van de waarde van de key "DynamicSiteName" opgelost is.

Verder hier nog een leuk artikel van Mark Minasi (held ) met daarin een gedeelte over hoe handmatig middels NSLookup de DNS-records te controleren zijn, die gebruikt worden voor het bepalen van de juiste site en DC.

Draai voor de gein ook eens het commando "nltest /dsgetsite" op een client. De output zou de lokale site van de client moeten zijn. Om opnieuw de client een discovery te laten doen kun je "nltest /sc_reset:domain-name\local-dc" gebruiken. Hiermee kun je in ieder geval iets sneller troubleshooten en testen.

Verwijderd schreef op dinsdag 22 mei 2007 @ 09:50:
[...]Per Site is een subnet en een server (DC) toegekend.

De DC's zijn handmatig naar de betreffende site gemoved of hebben deze zelf de voor hun juiste site 'ontdekt' ?

[Jazzy]

Verwijderd schreef op dinsdag 22 mei 2007 @ 20:07:
We zouden er best externe hulp bij willen roepen, maar ieder bedrijf en iedere expert die we raadplegen bevestigen onze keuzes bij het ontwerp van dit netwerk. Ik ben bang dat we iets vreselijk kleins over het hoofd zien.

Het ontwerp ziet er ook prima uit, er zal in de uitvoering wat mis zijn gegaan.

[Verwijderd]

Question Mark schreef op dinsdag 22 mei 2007 @ 20:39:
[...]
Kan het niet zo zijn dat deze entry gevuld is in je "master-image", meegenomen wordt in de "kloon" en daardoor niet goed meer werkt. (security settings op de key wel in orde?)

Als je de waarde dus wist, zou deze na een reboot automatisch weer gevuld moeten worden met de juiste waarde (de lokale site van de client). Na weer een reboot wordt de waarde opnieuw bepaald, enzovoort. Het is een dynamische entry die na elke reboot opnieuw bepaald wordt.

Als je de sitename hard in wilt stellen, zoals ik begrijp uit je post (als laatste redmiddel), dan heb je de registry-entry "SiteName" nodig, niet "DynamicSiteName".

Ouch, hier heb je me mee. Ik had het blijkbaar niet goed gelezen. Wat jij bedoelt is een mooie testcase, welke gemakkelijk is uit te voeren.

Zie verder ook deze thread in een ander forum, met hetzelfde probleem, wat ook door het wissen van de waarde van de key "DynamicSiteName" opgelost is.

Verder hier nog een leuk artikel van Mark Minasi (held ) met daarin een gedeelte over hoe handmatig middels NSLookup de DNS-records te controleren zijn, die gebruikt worden voor het bepalen van de juiste site en DC.

Draai voor de gein ook eens het commando "nltest /dsgetsite" op een client. De output zou de lokale site van de client moeten zijn. Om opnieuw de client een discovery te laten doen kun je "nltest /sc_reset:domain-name\local-dc" gebruiken. Hiermee kun je in ieder geval iets sneller troubleshooten en testen.

Je geeft me hier een aantal mooie aanknopingspunten die op het eerste gezicht exact zijn waar we het moeten zoeken. Morgen, blijkbaar een grote dag, ga ik ermee aan de slag.

[...]
De DC's zijn handmatig naar de betreffende site gemoved of hebben deze zelf de voor hun juiste site 'ontdekt' ?

Bij de eerste sites ging de 'discovery' inderdaad vanzelf, maar na een aantal testcases wacht je dat niet meer af en is de server er handmatig in gemoved. Goeie vraag en je maakt me attent op iets waar ik niet meer aan gedacht had. Ik kan het aantal sites nog uitbreiden en wat testdozen erin hangen, alsmede een aantal bestaande sites afbreken en weer opbouwen, om te kijken hoe hun discovery verloopt. Ik moet wel zeggen dat ik er geen rare dingen van verwacht, maar gezien 'assumption the mother of all fuckups' is, (hè Ed) zal ik het zeker testen.

[Verwijderd]

Het kan zijn dat ik me vergis, maar volgens mij zijn de meeste subnets die in de OP staan ongeldig.

Met een 22 bits subnet kun je volgens mij alleen veelvouden van 4 als 3e octet hebben.

Site A 10.1.0.0/22
Site B 10.1.100.0/22
Site C 10.1.110.0/22 => 10.1.108.0/22
Site D 10.1.125.0/22 => 10.1.124.0/22
Site E 10.1.140.0/22
Site F 10.1.165.0/22 => 10.1.164.0/22
Site G 10.1.185.0/22 => 10.1.184.0/22
Site H 10.1.200.0/22

Als je probleem alleen bij de sites C, D, F en G optreedt zou het hiermee te maken kunnen hebben, omdat de clients en DC hun eigen subnet niet goed vinden en dan maar een andere pakken.

[ Voor 6% gewijzigd door Verwijderd op 23-05-2007 11:59 ]

[Verwijderd]

Question Mark schreef op dinsdag 22 mei 2007 @ 19:02:
Controleer op een client eens de waarde van de registry-key DynamicSiteName eens.

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName

Deze key wordt normaal gesproken gevuld door de Netlogon service (die deze waarde middels de DsGetDcName Api bepaalt), en zou de lokale site voor de client moeten bevatten.

Staat hier niet de goede site in (en die kans is aardig groot aangezien de client zich aanmeld in een verkeerde site), wis dan de waarde van deze key eens en reboot eens (en controleer de waarde van deze key dan nogmaals).

Dit klopt, waar de client op aanmeldt, wordt hier weergegeven. Als we dit wissen en we melden opnieuw aan, dan meldt de client zich weer net zo random aan als hiervoor. Die waarde vult zich dan ook met de naam van de site waar op dat moment is aangemeld en dit kan dus alles zijn. Dit geldt ook voor het totaal verwijderen van de key. Deze wordt gewoon weer aangemaakt met als waarde de sitenaam waar de aanmeldingsserver staat. De rechten op de key zijn dus correct.

Verwijderd schreef op woensdag 23 mei 2007 @ 11:25:
Het kan zijn dat ik me vergis, maar volgens mij zijn de meeste subnets die in de OP staan ongeldig.

Met een 22 bits subnet kun je volgens mij alleen veelvouden van 4 als 3e octet hebben.

Site A 10.1.0.0/22
Site B 10.1.100.0/22
Site C 10.1.110.0/22 => 10.1.108.0/22
Site D 10.1.125.0/22 => 10.1.124.0/22
Site E 10.1.140.0/22
Site F 10.1.165.0/22 => 10.1.164.0/22
Site G 10.1.185.0/22 => 10.1.184.0/22
Site H 10.1.200.0/22

Als je probleem alleen bij de sites C, D, F en G optreedt zou het hiermee te maken kunnen hebben, omdat de clients en DC hun eigen subnet niet goed vinden en dan maar een andere pakken.

Je hebt gelijk, de netwerken hebben een ander startpunt dan bijvoorbeeld 10.1.110.0, maar dit was ooit makkelijker te onthouden. In S&S, de routers, DHCP, DNS en dergelijke heeft het wel de correcte notatie. Het is alleen in deze post zo opgeschreven. Zoals je zult zien overlapt er niets en zijn er geen conflicten. We hadden net zo goed 10.1.111.212/22 kunnen zeggen. De "/22" creeert automatisch de juiste octetten, in dit geval 10.1.108.0 - 255.255.252.0.

[Verwijderd]

Verwijderd schreef op woensdag 23 mei 2007 @ 11:56:

Je hebt gelijk, de netwerken hebben een ander startpunt dan bijvoorbeeld 10.1.110.0, maar dit was ooit makkelijker te onthouden. In S&S, de routers, DHCP, DNS en dergelijke heeft het wel de correcte notatie. Het is alleen in deze post zo opgeschreven. Zoals je zult zien overlapt er niets en zijn er geen conflicten. We hadden net zo goed 10.1.111.212/22 kunnen zeggen. De "/22" creeert automatisch de juiste octetten, in dit geval 10.1.108.0 - 255.255.252.0.

Ok, dat kon ik natuurlijk niet aflezen aan de openingspost :-)

Nog een ding: Functioneren de DC's op de locaties ook als router/VPN endpoint?
Als ze multihomed zijn registreren ze standaard alle IP adressen in de DNS (ook die van de VPN) en hebben ze nog wel eens moeite met het vinden van hun subnet/site. Ook kan het dan voorkomen dat clients het goede subnet opzoeken, maar bij het resolven van het srv record naar een IP adres het verkeerde adres meekrijgen.

[Verwijderd]

Verwijderd schreef op woensdag 23 mei 2007 @ 12:14:
[...]
Ok, dat kon ik natuurlijk niet aflezen aan de openingspost :-)

Nog een ding: Functioneren de DC's op de locaties ook als router/VPN endpoint?
Als ze multihomed zijn registreren ze standaard alle IP adressen in de DNS (ook die van de VPN) en hebben ze nog wel eens moeite met het vinden van hun subnet/site. Ook kan het dan voorkomen dat clients het goede subnet opzoeken, maar bij het resolven van het srv record naar een IP adres het verkeerde adres meekrijgen.

Nee, de DC's zijn geen VPN-eindpunten. Voor het opbouwen van de VPN's en de routering gebruiken we Juniper Netscreens.

We hebben nu een situatie die werkend lijkt, maar toch bij mij wat twijfels naar voren brengt.
Er zijn nu GPO's per site gemaakt, waar in de Net Logon service Group Policy "Sites Covered by the Domain Controller Locator DNS SRV Records" opgegeven staat.

De twijfels zijn er omdat dit eigenlijk in de huidige setup niet nodig zou moeten zijn. Maar, zoals gezegd, lijkt het te werken in een test-setup met 6 sites.

[Verwijderd]

Het werkt dus nog steeds niet.
Om uit te sluiten dat we bij het opzetten van het bestaande domein een fout hebben gemaakt, hebben we een nieuwe situatie opgezet.

Het domein dat we nu test.lokaal (NETBIOS is TEST) noemen heeft de volgende servers:

Tdc01 (eerste domeincontroller voor een nieuw domein en GC)

Ip: 10.1.210.10
Subnet 255.255.255.0
GW 10.1.210.1
DNS 10.1.210.10

Tdc02 (extra domeincontroller voor bestaand domein)

Ip: 10.1.220.10
Subnet 255.255.255.0
GW 10.1.220.1
DNS 10.1.210.10

Tdc03 (extra domeincontroller voor bestaand domein)

Ip: 10.1.230.10
Subnet 255.255.255.0
GW 10.1.230.1
DNS 10.1.210.10

De server zijn verbonden met “Linksys Routers” en routeren volledig. Alle Dc’s kunnen elkaar zien en elkaar pingen op naam en IP.
Voorlopig is de enige DNS server in het domein Tdc01.

Voordat Tdc02 en Tdc03 zijn gepromoveerd c.q aangemeld zijn op het domein “TEST”, zijn op de Tdc01 de sites en subnetten gedefinieerd.

De “default first site” is hernoemd naar Test210
Een nieuwe site is gemaakt met de naam Test 220
Een nieuwe site is gemaakt met de naam Test 230

Hierna zijn subnetten aangemaakt en gekoppeld aan de sites

Subnet 10.1.0.210.0/24 is gekoppeld aan Test210
Subnet 10.1.0.220.0/24 is gekoppeld aan Test220
Subnet 10.1.0.230.0/24 is gekoppeld aan Test230

Hierna zijn Tdc02 en Tdc03 toegevoegd als extra domeincontroller voor een bestaand domein aan het domein “Test.Lokaal”.
Wat we nu waarnemen is dat binnen “Sites en Services” automatisch de domeincontroller zich nestelt in zijn eigen site. We hoeven nu niets handmatig te verplaatsen!

Nu hebben we de client lid gemaakt van het domein TEST. De client is op de router/switch aangesloten van Site “Test210” en krijgt via DHCP de volgende gegevens:

10.1.210.100
255.255.255.0
10.1.210.1
10.1.210.10

In Active Directory hebben we een aantal gebruikers aangemaakt.
Als we nu inloggen op de client, gaat de aanmelding razend snel zoals het hoort. Er zijn nog geen policy’s gedefinieerd.
Nu typen we bij Start > Uitvoeren het volgende commando:

%logonserver%

Gelijk wordt er geresolved naar de naam Tdc01

Als we nu de client aansluiten op de switch/router van Site “Test220” en we de IP gegevens hebben gecontroleerd, welke respectievelijk zijn:

10.1.220.100
255.255.255.0
10.1.220.1
10.1.210.10

en hierna aanmelden met dezelfde gebruiker die we hebben gebruikt voor het aanmelden op Site “Test210” is wederom de aanmelding razendsnel.
Als we nu het commando %logonserver% gebruiken, is nog steeds de logonserver Tdc01…
Als we de documentatie van Microsoft zouden moeten geloven, zou de client zich nu moeten aanmelden op een domeincontroller in zijn eigen site, dus Tdc02.

Verdere tests met andere gebruikersaccounts, en het overprikken van de client naar verschillende sites laat zien dat er steeds een willekeurige Dc wordt gekozen. En dat de MMC “Sites en Services” totaal geen invloed heeft op de aanmeldingserver voor de client.

Zijn de symptomen die wij waarnemen volledig in de lijn der verwachting, of moet toch echt de client de Dc van zijn site resolven.

[Verwijderd]

En weer een stapje verder.

Het lijkt erop dat de dynamische update van de SiteName voor een cliënt werkt. Echter, het duurt heel erg lang voordat de gebruiker die al reeds is aangemeld op die computer dit ook door heeft.

Wat nu lijkt te werken is het volgende:

Computer in Site A
Nieuwe Gebruiker aangemeld > Dc is die van Site A

Plug computer over naar Site B ( wacht op DHCP aanvraag )
Reboot Computer

Dezelfde gebruiker meldt nu aan > Dc is die van Site A
Meldt gebruiker af

Meldt diezelfde gebruiker weer aan > Dc is nu die van Site B

Onze conclusie:

Als eerste wordt het register voor het werkstation aangepast, en na een reboot, wordt deze actief.
Hierna meldt een gebruiker aan, en zijn bestaande profiel/register wordt geladen. Door af, en weer aan te melden, wordt zijn bestaande profiel gewijzigd, en neemt de waarde van de “LogonServer” over uit het register/profiel van de computer.

In alle testgevallen resulteert dit in hetzelfde, dus we hebben een werkbare situatie.
We veronderstellen dus wel dat het voor cliënts altijd mogelijk is om op een Dc aan te melden buiten hun site, en dat het dus alleen een registersleutel is die bepaald wie de Dc is voor een cliënt.
In onze optiek voert een cliënt, die totaal onwetend is van zijn omgeving, de volgende stappen uit:

1. DHCP aanvraag (hierin vindt de Pc zijn gegevens over WINS en DNS (wij gebruiken geen WINS)
2. De SRV records worden gevonden via DNS, maar de cliënt zijn “LogonServer” haalt hij “naar ons idee” hier niet vandaan.

Deze registersleutel zal worden bepaald door de “Net Logon Service” en niet door DNS? De cliënt zal dus voor zijn Dc/LogonServer de DNS-server niet raadplegen? Nogmaals, dit laatste is een veronderstelling.

Wat zal de juiste manier zijn (zonder op elke cliënt het register te wijzigen) een cliënt te forceren zich aan te melden bij de Dc van zijn Site? Of is deze er dan niet?

[Verwijderd]

Volgens wat ik overal kan lezen:

Het duurt idd een tijdje vooraleer de client blijkbaar volledig doorheeft dat hij in een andere site zit. Normaal gezien zal de client de key DynamicSiteName gebruiken om aan de DNS een domain controller te vragen die in zijn site zit.
Stel nu het volgende scenario: de Dell laptop heeft altijd in site Antwerpen aangelogd. Dus zijn DynamicSiteName key staat op "Antwerpen". De eigenaar van deze laptop gaat naar site Brussel. Wat er daar gebeurt is volgens mij het volgende:
- De client vraagt aan de DNS een DC die in de site Antwerpen staat, omdat de key zo nog staat ingesteld.
- De DC die de aanlogprocedure afhandelt voor de client, ziet aan het IP van de client dat hij niet meer in site Antwerpen zit, maar nu in site Brussel. De DC zal dit laten weten aan de client, en daarbij vermelden dat de client vanaf nu de DC in Brussel mag contacteren. (zie Microsoft Kb)
- De client heeft nu gehoord dat hij mag aanloggen op een DC uit Brussel, en contacteert alsnog een DC uit Brussel die nu de aanlogprocedure zal afhandelen.

Blijkbaar zit er vooral een vertraging op die laatste stap, namelijk het effectief gebruiken van de DC in de site waar de client zonet naartoe is gegaan. Naar ik mij goed kan herinneren, heb ik vroeger nochtans gelezen dat dat onmiddelijk zou moeten worden aangepast. Alleszins hadden ze hetzelfde probleem in de volgende thread (werd reeds aangehaald in deze thread)
Thread

Om te weten wanneer exact de client doorheeft dat hij in de nieuwe site moet aanloggen, kan je bij het testen toch best naar die registry key DynamicSiteName kijken. Wanneer die werd aangepast is het in orde....

Wat betreft je laatste veronderstelling
"Deze registersleutel zal worden bepaald door de “Net Logon Service” en niet door DNS? De cliënt zal dus voor zijn Dc/LogonServer de DNS-server niet raadplegen? Nogmaals, dit laatste is een veronderstelling."
Volgens mij zal net de "Net Logon Service" op zijn beurt DNS gebruiken om een domain controller te zoeken. Dat staat vrij duidelijk op deze technet site van microsoft.

Het lastige is dat dit allemaal niet gemakkelijk te testen is. Je moet al minstens 2 domain controllers opzetten met 2 sites (op zich niet zo veel werk) en daarna ook de routering in orde brengen. Dit laatste moet sowieso aangezien tussen verschillende subnetten (lees: sites) alleen maar kan gecommuniceerd worden via een router.

Als ik nog meer kan uitvissen, post ik het zeker en vast nog!

[ZeRoC00L]

Via deze site: http://www.mail-archive.c...tivedir.org/msg33309.html kwam ik bij MS het volgende artikel tegen: Description of the netmask ordering feature and the round robin feature in Windows Server 2003 DNS
Probeer dat eens.

[Tylen]

Verwijderd schreef op donderdag 14 juni 2007 @ 11:03:
En weer een stapje verder.

Het lijkt erop dat de dynamische update van de SiteName voor een cliënt werkt. Echter, het duurt heel erg lang voordat de gebruiker die al reeds is aangemeld op die computer dit ook door heeft.

Wat nu lijkt te werken is het volgende:

Computer in Site A
Nieuwe Gebruiker aangemeld > Dc is die van Site A

Plug computer over naar Site B ( wacht op DHCP aanvraag )
Reboot Computer

Dezelfde gebruiker meldt nu aan > Dc is die van Site A
Meldt gebruiker af

Meldt diezelfde gebruiker weer aan > Dc is nu die van Site B

Onze conclusie:

Als eerste wordt het register voor het werkstation aangepast, en na een reboot, wordt deze actief.
Hierna meldt een gebruiker aan, en zijn bestaande profiel/register wordt geladen. Door af, en weer aan te melden, wordt zijn bestaande profiel gewijzigd, en neemt de waarde van de “LogonServer” over uit het register/profiel van de computer.

In alle testgevallen resulteert dit in hetzelfde, dus we hebben een werkbare situatie.
We veronderstellen dus wel dat het voor cliënts altijd mogelijk is om op een Dc aan te melden buiten hun site, en dat het dus alleen een registersleutel is die bepaald wie de Dc is voor een cliënt.
In onze optiek voert een cliënt, die totaal onwetend is van zijn omgeving, de volgende stappen uit:

1. DHCP aanvraag (hierin vindt de Pc zijn gegevens over WINS en DNS (wij gebruiken geen WINS)
2. De SRV records worden gevonden via DNS, maar de cliënt zijn “LogonServer” haalt hij “naar ons idee” hier niet vandaan.

Deze registersleutel zal worden bepaald door de “Net Logon Service” en niet door DNS? De cliënt zal dus voor zijn Dc/LogonServer de DNS-server niet raadplegen? Nogmaals, dit laatste is een veronderstelling.

Wat zal de juiste manier zijn (zonder op elke cliënt het register te wijzigen) een cliënt te forceren zich aan te melden bij de Dc van zijn Site? Of is deze er dan niet?

De 2 domain controllers in Site B en Site C moeten wel Global Catalog servers worden.