Innledning
Det er flere måter du kan reise deg opp når du setter opp og konfigurerer Active Directory for organisasjonen. Feilkonfigurerte innstillinger, utilstrekkelige vedlikeholdsprosedyrer og andre feil kan føre til konsekvenser som kan variere fra dårlig ytelse til unsupportablility. Mitt mål i denne artikkelserien er å fremheve noen av de vanligste feilene som gjøres med å konfigurere, administrere og vedlikeholde Active Directory-miljøer som kjører støttede versjoner av Windows Server. Mange av innsikt og anbefalinger som jeg skal dele i disse artiklene har blitt innhentet fra kommunikasjon med ulike kolleger som er IT-administratorer eller konsulenter som arbeider i feltet. Noen av forslagene ble også bidratt med ulike eksperter jeg kjenner som jobber hos Microsoft Corporation.
Men det er viktig at du forstår at jeg bare tilby mine egne personlige forslag i disse artiklene her på WindowsNetworking.com og er ikke å gi noen "offisielle" veiledning om de sakene som diskuteres. For offentlige anbefalinger bør du alltid konsultere Microsoft TechNet eller artikler i Microsoft Knowledge Base eller noen andre Microsoft sikkerhet. Så vennligst ta alt i disse artiklene "som den er" uten garantier.
Bruke loopback adresse på domenekontrollere som kjører Windows Server 2008 og Windows Server 2008 R2
Den første utgaven vil vi undersøke er om det er en god ide eller ikke for en domenekontroller å ha tilbakekoblingsadressen konfigurert i sine DNS klientinnstillinger. Nærmere bestemt er det OK for en domenekontroller som også har DNS Server rollen installert på den for å ha adressen 127.0.0.1 i sin TCP /IP-innstillingene for enten den foretrukne (primær) eller alternativ (sekundær) DNS server? Eller bør du bruke den faktiske IP-adressen tilordnes til nettverkskortet på domenekontrolleren i stedet?
Hvis du søker TechNet for noen offisiell veiledning om denne saken, kan du føle deg litt forvirret etterpå. For eksempel, i dette innlegget laget i 2010 til Ask The Directory Services teamet blogge følgende spørsmål stilles:
Branch sider:
Primær DNS - en DNS-server i den sentrale (hub) site
Secondary DNS - en annen DNS server i samme gren nettstedet (eller en DNS-server i en annen gren stedet)
Tertiær DNS - den lokale serveren (enten ved hjelp av loopback eller faktiske adresse)
På den annen side, forteller en annen kollega som også har lignende lang erfaring med store AD distribusjoner meg at den riktige måten å gjøre det på er å konfigurere DNS på alle domenekontrollere (dvs. i både det sentrale området og avdelingskontorer) som dette:
Primær DNS - en DNS-server i det sentrale (hub) nettsted (men ikke den lokale DNS server)
Sekundær DNS - en annen DNS-server i det sentrale (hub) nettsted (men igjen ikke den lokale DNS server)
Tertiær DNS - en annen DNS-server i det sentrale (hub) nettsted (men igjen ikke lokal DNS server)
kvartær DNS for lokal server sentralt (hub) site - en annen DNS-server i det sentrale (hub) nettsted (men igjen ikke den lokale DNS server)
kvartær DNS for lokal server i grenen site - en annen DNS server i samme gren nettstedet
quinary DNS - den lokale serveren (enten ved hjelp av loopback eller faktiske adresse)
Uansett hvilken av disse ordningene du velger å følge, må du kanskje variere dem avhengig av tilkoblingsmuligheter, båndbredde og ventetid mellom de ulike områdene som er involvert. Husk også at du kan være i stand til å redusere latency problemer som kan påvirke DNS oppløsning ved å distribuere caching-bare navnetjenere og utnytte betinget videresending.
Testing mulig feilscenarier
Til slutt, uansett hvilken ordning du bruker for konfigurering av DNS-server innstillinger på domenekontrollere i Active Directory-miljø, kan det være lurt å også gjennomføre en test for å se hva som skjer hvis alle domenekontrollere i et område er plutselig stengt, enten grasiøst eller ved en brå strømbrudd. Jeg har faktisk hørt en rapport fra en organisasjon som hadde to domenekontrollere i deres sentrale området hvor hver domenekontroller pekte på den andre som sin foretrukne DNS-serveren og til seg selv som sin alternative DNS-server, og når begge domenekontrollere ble restartet på Samtidig etter å ha lapper brukt, Active Directory-tjenester av ingen av dem var i stand til å starte på nytt etterpå. Jeg er ikke sikker på hvorfor dette skulle skje, men jeg fortalte det gjorde. Så moralen i historien er, men du konfigurere DNS Client på domenekontrollere, sørg for å teste oppsettet grundig! Anmeldelser