Innledning

Active Directory har ikke forandret seg så mye i løpet av årene. Siden den først ble introdusert i 2000, har begrepene rundt organisering av Active Directory ikke endret. Det er fortsatt organisatoriske enheter (OUS) i Active Directory struktur som brukes til å hjelpe administratorer .... administrere. Det har kommet til min oppmerksomhet at mange organisasjoner bestemmer seg for å gjøre utslett beslutninger for sin OU design for å forsøke effektivitet, brukervennlighet, enkel administrasjon, og anvendelse av erfaringene. Jeg er den første til å innrømme at noen forslag av Microsoft og Microsoft-evangelistene ikke treffer mark hver gang, men i noen tilfeller finner jeg at de er perfekte, og vil forbli slik inntil teknologien endres for å bevise det galt. Dette er tilfellet med å bruke organisasjonsenheter innen Active Directory i den grad for hva de er laget for, og hvordan de best utnyttes.


Hva er en OU?
< P> En OU er et Active Directory-objekt som brukes til å organisere andre objekter som er opprettet og som finnes i Active Directory infrastruktur. Organisasjonsenheter er unike fra containere, som er en annen type organisasjons objekt som er inneholdt i Active Directory. OUene avvike fra Containere først og fremst fordi en OU kan ha et gruppepolicyobjekt (GPO) knyttet til det, hvor en Container kan ikke. Dette høres kanskje ikke så viktig, men det er det viktigste.

organisasjonsenheter i hovedsak skal brukes til å organisere følgende objekter:

Brukerkontoer
• konsernregnskapet
• Datamaskiner
  

  Ja, OUS også brukes til å organisere delte mapper og skrivere, men kontroll av disse objektene innen en OU er ikke alt som vanlig eller nyttig for den saks skyld.
  
  OU Defaults
  

  Når Active Directory er installert for første gang er det bare én OU. Standard Domain Controllers OU er den eneste OU som kommer som standard. Dette OU er utformet for å inneholde og administrere domenekontrollere for domenet. Domeneadministratoren kan opprette et ubegrenset antall organisasjonsenheter for domenet over tid, men for mange organisasjonsenheter kan bli tungvint og forårsake administrative spørsmål.
  
  grunner til å opprette en OU: Grunn # 1
  

  Den første grunnen til å opprette en OU er for å administrere stedene. Objektene som kan administreres inkludere brukerkontoer og konsernregnskap. Det er svært lite som kan styres for en datamaskin eller server i en OU, må denne forvaltningen gjøres på selve serveren. Eksempler på ledelse som kan gis i løpet av brukerkontoer og konsernregnskap omfatter:
  

  
  Brukere - Creation, sletting, modifisering av brukeregenskaper
  Grupper - Creation, sletting, modifikasjon av gruppemedlemskap
  
  

  Når en OU brukes til å gi administrative rettigheter over et objekt som finnes med det, dette kalles delegasjon. Det er en delegasjon veiviser for hver OU, vist i figur 1, samt en administrator kan endre tillatelser på OU direkte. Dette siste alternativet er veldig vanskelig, så er det ca 15 000 individuelle tillater tillatelser for hver OU.
  

  
  

  
  Figur 1:. Delegation Wizard for en OU
  
  Grunner til å opprette en OU: Grunn # 2
  

  Den andre grunnen til å opprette en OU er å distribuere GPO innstillinger. Når en GPO er knyttet til en OU, innstillingene innenfor GPO gjelder bare for objektene i at OU og barn organisasjonsenheter til at OU. Dette gir enkel og effektiv utrulling av GPO innstillinger til bare de brukere og datamaskiner som trenger innstillingene.
  

  GPOer kan knyttes til domenet og Active Directory-områder, men det er vanskeligere å administrere og konfigurere GPOer utplassert på disse stedene i Active Directory. For effektiviteten av GPO management, distribusjon og feilsøking, er det foreslått å utforme organisasjonsenheter for utplassering av GPOer.
  
  Designing OU Structure
  

  Når det gjelder tid til å designe OU struktur, mange spørsmål og diskusjoner må skje. Det er langt bedre å designe OU design før gjennomføring av generelle Active Directory infrastruktur, sammenlignet med etter Active Directory er oppe og går i produksjon. Altfor ofte selskaper føler det er lettere å "redesigne" Active Directory "igjen" enn å gjøre det riktig første gang.
  

  Ting å vurdere når du utformer OU struktur inkluderer:
  

  • Hvem vil være involvert i administrasjon av brukere, grupper og datamaskiner?
  • Vil alle som er ansvarlig for å administrere brukere, grupper og datamaskiner være i kontroll over alle objekter, eller bare en del av gjenstandene?
  • Hvilke brukerkontoer må ha de samme innstillingene og hvilke brukerkontoer må ha forskjellige innstillinger?
    O Disse innstillingene må være kategorisert i kategorier som gir mening for organisasjonen. Kategorier kan omfatte: drive kartlegginger, skriver kartlegginger, sikkerhetskonfigurasjoner, IE-innstillinger, programinnstillinger, osv
  • Hvilke datamaskinkontoer må ha de samme innstillingene og hvilke datakontoer må ha forskjellige innstillinger?
    O Du bør bryte opp servere fra stasjonære før du vurderer disse alternativene
    o Skrivebords kategorier kan omfatte:. IT, ledere, utviklere, finans, HR, HelpDesk, etc.
    o Server kategorier kan omfatte: DC, SQL, Web, intranett, finans, HR, etc.
    
    Hvor mange organisasjonsenheter?
    

    Jeg får dette spørsmålet ofte når de vurderer Active Directory design. Det er ikke noe klart svar. Svaret ligger i dine overordnede mål for Active Directory og hvordan du skal klare delegasjonen og GPO distribusjon. Det er egentlig tre regler for design, som din organisasjon kan utvikle for OU design on

    1. For få organisasjonsenheter -. Dette er et design som kommer til å føre til mye overhead med konfigurasjoner. Hvis det er for få organisasjonsenheter delegasjonen modellen vil være svært vanskelig å administrere, som alle brukere og grupper er i samme OU. I samme lys, vil GPO ledelse må skje innenfor sikkerhetsfiltrering som er tilgjengelig for hver GPO. Denne type behandling er svært vanskelig å distribuere og enda vanskeligere å feilsøke. For ikke å nevne at forvalte GPOer denne måten vil føre til ekstra overhead på GPO søknaden.
    2. For mange organisasjonsenheter - er dette et design som er typisk et resultat av dårlig planlegging og for mange administratorer. Hvis du går med design filosofi om det bare er to grunner for en OU, så kan du bli klar over dette design. Imidlertid, når den OU struktur benyttes for logisk plassering av gjenstander og dimensjonering, da den kan komme ut av kontroll svært raskt.
    3. Akkurat nok organisasjonsenheter - det er her din organisasjon trenger å falle med OU design. Jeg foreslår at du faller på "for få organisasjonsenheter" side først, som å fjerne organisasjonsenheter kan være vanskelig.
       
       Sammendrag
       

       organisasjonsenheter for Active Directory-designen er viktig. Hvis de ikke blir brukt, vil ledelsen, effektivitet og feilsøking av problemer som kan oppstå være vanskeligere. På motsatt side av spekteret, hvis for mange organisasjonsenheter er gjennomført, vil de samme problemene oppstår med ledelsen, effektivitet og feilsøking. Derfor faller et sted i mellom er nøkkelen for din OU design. Prøv å ikke over tror design, snarere logisk vurdere hvordan du ønsker å delegere og hvordan du ønsker å distribuere GPOer. Ikke "glem at noen GPO innstillinger (gruppepolicyinnstillinger og andre GP utvidelser) gir mulighet for å knytte GPOer høye i strukturen og fortsatt få effektiviteten av GPO søknaden.
       

       
       
       
       Previous:TrenchTales (Del 6) - Tastatur Conundrums
       Next Page:TrenchTales (del 5) - Logon Banners