Innledning
jeg endte forrige artikkel i denne serien ved å snakke om noen av de enkelte testene du kan kjøre ved hjelp av Domain Controller Diagnostic Utility. Selv om jeg har snakket om ganske mange tester så langt, det er nok av flere tester du kan utføre. I denne artikkelen, jeg ønsker å fortsette der jeg slapp, og snakke om noen flere tester at Domain Controller Diagnostic Utility kan utføre.
Locator Sjekk
Locator Check er en av de viktigste testene du kan utføre ved hjelp DCDIAG. Som jeg er sikker på at du sikkert vet, tildeler Active Directory ulike Fleksibel seng Master Operations (FSMO) Roller visse domenekontrollere i skogen. De globale FSMO roller er opprinnelig tildelt den første domenekontroller i skogen. Det er også noen domene nivå FSMO roller som tildeles som standard til den første domenekontroller i hvert domene.
Locator Sjekk testen utfører tester for å være sikker på at serverne som er vert den globale FSMO roller er kjent, og at de servere kan være plassert. Enda viktigere, sjekker den for å sørge for at serverne hosting globale FSMO roller er å svare på forespørsler.
Utføre en locator sjekk er enkel. Alt du trenger å gjøre er å skrive inn følgende kommando:
DCDIAG /TEST: LocatorCheck
Selvfølgelig er dette bare den enkleste eksempel på hvordan du ville kjøre en locator sjekk test. Du har muligheten til å angi en bestemt domenekontroller og et sett med autentiseringsakkreditiver akkurat som du kan for noen annen test.
Intersite test
Avhengig av Active Directory topologi, kan Intersite testen også være en viktig en . Når du kjører Intersite test, utfører Domain Controller Diagnostic Utility en rekke tester for å se om det er noen problemer med brohoder som kan føre til Active Directory informasjon fra replikere tvers språk grenser.
Syntaks brukes for å kjøre intersite testen er nesten identisk med den som brukes for lokaliseringskontroll. Hvis du ønsker å utføre en intersite test, bare skriv denne kommandoen:
DCDIAG /Test: Intersite
KCCEvent Test
annen replikering relatert test er den KCCEvent test. Denne testen brukes til å sørge for at Kunnskaps Konsistens Checker (KCC) fungerer, og at det er å fullføre uten å produsere noen feil. Du kan kjøre KCCEvent test ved å skrive inn følgende kommando:
DCDIAG /Test: KCCEvent
KnowsofRoleHolders Test
Knows av rolleinnehavere testen sjekker for å se om Directory Service Agent vet hvilke servere er vertskap for ulike Fleksible Enkelt driftsovervåkeren roller. Hvis du bare ønsker å kjøre en rask test, så kan du gjøre det ved å skrive inn denne kommandoen:
DCDIAG /Test: KnowsOfRoleHolders
Selv om at testen vil vanligvis få jobben gjort, kan du noen ganger lurt å faktisk ønsker å sjekke for å se hvilke domenekontrollere at Directory Service Agent mener holder rollene. Hvis du ønsker å identifisere de enkelte servere, så må du kjøre denne hvile i verbose-modus. For å gjøre dette, skriver du denne kommandoen:
DCDIAG /Test: KnowsofRoleHolders /v
Machine konto Test
I et Active Directory-miljø, er servere og arbeidsstasjoner koblet til et domene. Denne prosessen med å bli en maskin til et domene fører til en maskinkonto skal opprettes. Som en brukerkonto, har en maskin konto et tilhørende passord og en rekke andre egenskaper som er designet for å identifisere den enkelte maskin. Hvis maskinen kontoen blir skadet eller faller ut av sync med Active Directory, da det tilsvarende maskinen ikke vil være i stand til å koble til domenet. Heldigvis er det en test som du kan bruke til å sjekke integriteten til en domenekontroller maskin konto. Du kan utføre denne testen ved å skrive inn følgende kommando:
DCDIAG /Test: MachineAccount
I alle de årene som Active Directory har eksistert, har jeg bare kjøre inn i noen få situasjoner der et problem med en maskin kontoen holdt en maskin fra å fungere korrekt. I de fleste av disse tilfellene ble problemet forårsaket av konto maskinens passord komme ut av synk med passordet for maskinen konto som er lagret i Active Directory databasen.
Hvis en maskin kontoen ikke har problemer selv, det er en par valgfrie brytere som du kan bruke til å løse problemet. En slik bryter er den /FixMachineAccount bryteren, som tilbakestiller regnskapet ulike flagg. Hvis dette ikke løser problemet, så kan du alltids prøve å gjenskape maskinen konto ved å bruke /RecreateMachineAccount bryteren.
Naming Context Security Descriptors Test
En av de mer obskure tester er en sjekk for å se om sikkerheten beskrivelsene på navne sammenhenger er riktige. Hvis sikkerhetsbeskrivelser er ugyldige, så replikering kan mislykkes. Du kan kjøre denne testen ved å skrive inn følgende kommando:
DCDIAG /Test: NCSecDesc
NetLogons, En lignende test relatert til replikering er NetLogons test. Den sjekker å se at replikering er ikke sviktende grunn av utilstrekkelige påloggingsrettigheter. Du kan kjøre denne testen ved å skrive inn følgende kommando:
DCDIAG /Test: NetLogons
gjenstander Replikerte Test
En annen viktig test relatert til replikering prosessen er Objekter Replikerte test. Denne testen er først og fremst brukes til å bekrefte at maskinen kontoer har kopiert over alle dine domenekontrollere, men det kan også brukes til å sjekke om andre typer objekter har kopiert også.
For å bruke denne testen, du er nødt til å vite det unike navnet (DN) for objektet som du vil teste. Hvis objektet som du leter opp er noe annet enn en maskin-konto, vil du også nødt til å vite objektets navngiving kontekst. Syntaksen for denne testen ser omtrent slik ut:
DCDIAG /Test: ObjectsReplicated /ObjectDN: < objekt unike navn > /N: < objektets navngiving kontekst >
Outbound sikre kanaler Test
Som maskinene som lagrer brukerpassord og diverse andre sikkerhetsinnstillinger, domenekontrollere er noen av de mest følsomme servere på et nettverk. Som sådan, har Microsoft konfigurert domenekontrollere for å kommunisere med hverandre over en sikker kanal når det er mulig. Dette forhindrer folk fra å bruke en pakke sniffer å stjele Active Directory informasjon som det replikerer fra en domenekontroller til en annen.
Per definisjon er en sikker kanal en godkjent Remote Procedure Call (RPC) forbindelse mellom to maskiner i et domene med en etablert sikkerhetskonteksten som brukes til signering og kryptering av RPC-pakker.
Det bør derfor ikke komme som noen overraskelse at Domain Controller Diagnostic Utility gir en test for å sjekke utgående sikre kanaler. Dette er en av de testene som ikke kjører som standard, så du blir nødt til å kjøre den manuelt hvis du ønsker å bruke den. Syntaksen ser slik ut:
DCDIAG /Test: OutboundSecureChannels /TestDomain: < dittdomene >
Normalt vil denne testen bare sjekke domenekontrollere innenfor gjeldende område. Du kan tvinge test for å sjekke eksterne sider ved å legge til /NoRestriction bryteren på prøve.
Konklusjon
I denne artikkelen har jeg snakket om flere av de testene du kan utføre mot domenekontrollere ved å bruke Domain Controller Diagnostic Utility. Tro det eller ei, vi er ikke ferdig ennå. Det er fortsatt flere flere tester som jeg ønsker å snakke om. I neste artikkel i serien, vil jeg bryte opp ting ved å snakke om de resterende testene.