Active Directory -skeeman laajentaminen. Active Directory Schema -versio

AD DS:n skeema on joukko määritelmiä kaikille hakemiston objektityypeille ja niihin liittyville attribuuteille. Kaava määrittelee tavan, jolla AD DS:n on tallennettava ja määritettävä tietoja kaikista käyttäjistä, tietokoneista ja muista objekteista, jotta he voivat vakionäkymä koko AD DS -rakenteessa. Se on suojattu harkinnanvaraisten käyttöoikeusluetteloiden (DACL) avulla, ja se on vastuussa mahdollisten määritteiden tarjoamisesta jokaiselle AD DS:n objektille. Pohjimmiltaan skeema on itse hakemiston perusmääritelmä ja toimialueympäristön toiminnallisuuden perusta. Äärimmäistä varovaisuutta on noudatettava delegoitaessa skeeman hallintaoikeuksia valitulle ryhmälle järjestelmänvalvojia, koska skeemaan tehdyt muutokset vaikuttavat koko AD DS -ympäristöön.

Kaavioobjektit

AD DS -rakenteeseen tallennettuja elementtejä, kuten käyttäjiä, tulostimia, tietokoneita ja sivustoja, kutsutaan skeeman objekteiksi. Jokaisella tällaisella objektilla on oma attribuuttiluettelonsa, joka määrittelee sen ominaisuudet ja jota voidaan käyttää sen etsimiseen.

Kaavan laajennus

Yksi AD DS -suunnittelun tärkeimmistä eduista on kyky muokata ja laajentaa skeemaa suoraan sisältämään mukautettuja attribuutteja. Tyypillisesti attribuuttijoukon laajennus tapahtuu järjestelmän asennuksen aikana. Microsoft Exchange Palvelin, jossa mallia laajennetaan niin, että sen koko lähes kaksinkertaistuu. Kun suoritat päivityksen kohteesta Windows Server 2003 tai Windows Server 2008 AD Windows Server 2008 R2 AD DS, skeemaa myös laajennetaan, minkä seurauksena siihen lisätään Windows Server 2008 R2:lle ominaisia määritteitä. monet kolmannen osapuolen tuotteet tarjoavat myös omia tapoja laajentaa skeemaa, mikä antaa heille mahdollisuuden näyttää oman tyyppisiä tietoja luettelosta.

Kuten tiedät, mikään ei kestä ikuisesti, kaikki muuttuu, etenkin IT:n kaltaisella alalla. Kun infrastruktuuri on otettu käyttöön, se kehittyy, laajenee ja paranee jatkuvasti, ja tulee aika, jolloin sinun on lisättävä Active Directory -hakemistoosi toimialueen ohjain, jota hallitsee useampi kuin yksi henkilö. uudempi versio käyttöjärjestelmä.

Vaikuttaa siltä - mikä on ongelma? Mutta kuten käytäntö osoittaa, ongelmat syntyvät suurelta osin siitä syystä järjestelmänvalvojat hallitset vähän teoriaa ja ovat avoimesti hämmentyneitä tämä kysymys. Siksi on aika selvittää, mikä se on AD-suunnitelma ja miten se liittyy tapauksiimme.

AD piiri kutsutaan kuvaukseksi kaikista hakemistoobjekteista ja niiden attribuuteista. Pohjimmiltaan kaavio heijastaa perusrakenne hakemistoon ja on ensiarvoisen tärkeää sen asianmukaisen toiminnan kannalta.

Uudet käyttöjärjestelmän versiot sisältävät uusia objekteja ja attribuutteja, joten meidän on päivitettävä skeema, jotta ne toimisivat oikein toimialueen ohjauskoneina.

Se näyttää selvältä, mutta ei täysin, joten siirrytään yleisiin virheisiin ja väärinkäsityksiin.

Kaavan päivittäminen on tarpeen, jotta toimialueeseen voidaan sisällyttää tietokoneita, joissa on uudempi Windows-versio. Tämä ei ole totta, edes suurin osa uusimmat versiot Windows voi toimia melko menestyksekkäästi toimialueella Windowsin taso 2000 ilman skeeman päivitystä. Jos kuitenkin päivität järjestelmän, mitään pahaa ei tapahdu.

Jos haluat sisällyttää toimialueeseen uudempaa käyttöjärjestelmää käyttävän ohjaimen, sinun on päivitettävä toimialue (metsä). Tämä ei myöskään pidä paikkaansa, mutta toisin kuin edellinen tapaus, tämä toiminto tekee mahdottomaksi käyttää toimialueen ohjaimia, joiden käyttöjärjestelmä on alempi kuin sen toimintatila. Siksi sinun on virheen sattuessa palautettava AD-rakenne varmuuskopiosta.

Kiinnitämme huomionne myös metsän ja toimialueen toimintatapaan. Metsään sisältyvillä verkkotunnuksilla voi olla erilaisia tiloja työ, esimerkiksi yksi verkkotunnuksista voi toimia Windows-tila 2008 ja loput Windows 2003 -tilassa. Esimerkissämme metsän käyttötila ei voi olla korkeampi kuin Windows 2003.

Samanaikaisesti metsän matalampi toimintatapa ei estä millään tavalla lisäämästä käyttöä korkea tila toimialueella, sinun tarvitsee vain päivittää skeema.

Tutustuttuamme teoriaan siirrytään eteenpäin käytännön esimerkki. Oletetaan, että meillä on Windows 2000 -tason toimialue (mixed mode) - eniten matala taso AD - jonka alla on ohjain Windowsin ohjaus 2003, ja tavoitteenamme on luoda uusi ohjain epäonnistuneen ohjaimen tilalle.

Uudessa palvelimessa on Windows 2008 R2. Huomaa, että meillä ei ollut vaikeuksia ottaa käyttöön tästä palvelimesta olemassa olevaan verkkotunnukseen.

Meidän tapauksessamme kaikki roolit ovat samassa ohjaimessa, joten kopioimme kansion \support\adprep päällä kovalevy(tässä tapauksessa C:-aseman juureen) ja jatka metsäskeeman päivittämiseen. Toiminnon suorittaminen onnistuneesti edellyttää, että tilisi on sisällytettävä seuraaviin ryhmiin:

Kaavojen ylläpitäjät
Yritysjärjestelmänvalvojat
Sen verkkotunnuksen järjestelmänvalvojat, jossa skeeman omistaja sijaitsee

Päivitä metsäskeema suorittamalla komento:

C:\adprep\adprep /forestprep

Lue vakiovaroitus ja jatka napsauttamalla C, sitten Enter.

Kaavan päivitysprosessi alkaa. Kuten näet, sen versio muuttuu 30:stä (Windows 2003) 47:ään (Windows 2008 R2).

Kun olet päivittänyt metsäskeeman, sinun on päivitettävä toimialueen skeema. Ennen kuin teet tämän, varmista, että toimialue on käynnissä vähintään Windows 2000 -tilassa (natiivitila). Kuten muistamme, toimialueemme toimii sekatilassa, joten meidän tulisi vaihtaa toimialueen toimintatila ensisijaiseksi tai päivittää se Windows 2003:ksi. Koska tällä toimialueella ei ole Windows 2000 -käyttöjärjestelmää käyttäviä ohjaimia, olisi järkevintä päivittää toimialue. -tilassa.

Tämä toiminto tulee suorittaa verkkotunnuksen skeeman päivittämiseksi onnistuneesti Infrastruktuurin omistaja ja heillä on oikeuksia Verkkotunnuksen järjestelmänvalvoja. Suoritamme komennon:

C:\adprep\adprep /domainprep

Ja lue näytettävät tiedot huolellisesti. Kun päivität toimialueen skeemaa Windows 2000:sta tai Windows 2003:sta, sinun on muutettava käyttöoikeuksia tiedostojärjestelmä varten ryhmäkäytännöt. Tämä toiminto suoritetaan kerran ja tulevaisuudessa, esimerkiksi päivittämällä skeema vuoden 2008 tasolta tasolle 2008 R2, se on suoritettava. Päivitä ryhmäryhmän käyttöoikeudet kirjoittamalla komento:

C:\adprep\adprep /domainprep /gpprep

AD-versiot Windows 2008:n jälkeen ovat ottaneet käyttöön uudentyyppisen toimialueen ohjaimen: vain luku -toimialueen ohjaimen (RODC). Jos aiot ottaa tällaisen ohjaimen käyttöön, sinun on valmisteltava kaavio. Yleensä suosittelemme tämän toimenpiteen suorittamista riippumatta siitä, aiotko asentaa RODC:n lähitulevaisuudessa vai et.

Tämä toiminto voidaan suorittaa millä tahansa toimialueen ohjaimella, mutta sinun on oltava verkkotunnuksen jäsen Yritysjärjestelmänvalvojat Ja Nimeämisen mestari Ja Infrastruktuurin mestari on oltava saatavilla.

C:\adprep\adprep /rodcprep

Kuten näet, verkkotunnuksen skeeman päivittäminen, jos se on oikein suunniteltu, ei aiheuta vaikeuksia, mutta joka tapauksessa sinun tulee muistaa, että tämä on peruuttamaton toimenpide ja tarvittavat varmuuskopiot ovat käsillä.

On vaikea aliarvioida " Aktiiviset suunnitelmat Hakemisto" Active Directory -verkkoalueympäristöön rakennetuille verkoille. Tämä on AD-tekniikan perusta ja on erittäin tärkeää ymmärtää sen toiminnan periaatteet oikein. Useimmat järjestelmänvalvojat eivät kiinnitä järjestelmään riittävästi huomiota, koska he joutuvat harvoin käsittelemään sitä. Tässä artikkelissa kerron sinulle, mikä piiriversio on, miksi meidän on tiedettävä se ja mikä tärkeintä, kuinka sitä tarkastellaan nykyinen versio. Ensinnäkin muutama sana itse skeemasta, jokaisella Active Directoryssa luodulla objektilla, oli se sitten käyttäjä tai tietokone, on tiettyjä parametreja, joita kutsutaan attribuutteiksi. eniten yksinkertainen esimerkki voi toimia käyttäjäobjektin "Sukunimi"-attribuuttina. Kaava määrittää, mitä objekteja voimme luoda Active Directoryssa ja mitkä attribuutit niillä on Active Directory mahdollistaa useiden niiden perusteella rakennettujen toimialueohjainten käytön eri versioita Windows-käyttöjärjestelmä. Nimittäin - päällä Windows-pohjainen Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Koska nämä versiot julkaistiin eri vuosina ja jokaisessa uudessa versiossa on enemmän toimintoja kuin edellisessä, jokaisella käyttöjärjestelmällä on oma käsityksensä järjestelmästä. Siksi, kun lisäät uuden Windows Server 2008 -pohjaisen ohjaimen organisaatioon, jossa olemassa oleviin ohjaimiin rakennettu Windows Server 2003:lle, sinun oli suoritettava " Adprep". Olet siis päivittänyt organisaatiosi kaavion sille tasolle, jolla se toimii Windows Server 2008.

Kaavan päivitys suoritettiin ennen ensimmäistä asennusta Windowsin ohjain Server 2008:aa ja varsinaista uuden ohjaimen asennusta ei ehkä ole suoritettu. Jos olet vasta aloittamassa työskentelyä Active Directory -organisaation kanssa etkä tiedä, mitä toimintoja tehtiin ennen saapumistasi, ymmärtääksesi rakenteen täydellisyyden, sinun on tiedettävä, millä tasolla nykyisen organisaation Schema toimii.

Viestin sponsori

Kaikki uudet julkaisut, viime vuosien parhaat elokuvat. 5ic.ru:n parhaat suosikkielokuvat

Piirin mahdolliset versiot:

13 - Windows 2000 Server
30 - Windows Server 2003 RTM, Windows 2003 Service Pack 1:llä, Windows 2003 Service Pack 2:lla
31 - Windows Server 2003 R2
44 - Windows Server 2008 RTM

Vaikka kaikki organisaatiosi ohjaimet toimisivat Windows Server 2003 R2:lla ja piiriversiossa näkyy "44", sinun ei pitäisi olla yllättynyt, tämä tarkoittaa, että piiri on jo päivitetty Windows Server 2008 RTM -tasolle, mutta ohjain jostain syystä ei ollut syytä asentaa sitä.

Kaavan versiota voi tarkastella usealla eri tavalla. Yksinkertaisin tapa on käyttää DSQuery-apuohjelmaa. Tätä tarkoitusta varten sisään komentorivi sinun on syötettävä komento seuraavilla parametreilla:

"dsquery * cn=skeema,cn=määritykset,dc=domainname,dc=local -scope base -attr objectVersion"

Luonnollisesti osassa " dc= verkkotunnus dc= paikallinen" sinun on korvattava oma verkkotunnus. (Esimerkki: dc= Microsoft, dc= com )

Komennon antamisen tuloksena saadaan attribuutti " ObjectVersion", joka on piirin versionumero:

Riisi. 1 Kaavaversion hankkiminen DSQuery-apuohjelman kautta.

Toinen menetelmä on pidempi ja sisältää " ADSIEdit. msc“ . Jos haluat nähdä skeeman version, sinun on muodostettava yhteys Active Directory -skeemaosioon.

“CN=Schema,CN=Configuration,DC=domain,DC=paikallinen“

Ja etsi attribuutin arvo " objectVersion“.

Kuva 2 Kaavaversion hakeminen " ADSIEdit. msc“.

Kun tiedät järjestelmän version, voit aina sanoa luottavaisesti, tarvitseeko järjestelmää päivittää ja tarvittaessa mille tasolle.

On huomattava, että skeemapäivityksiä voidaan tehdä ohjelmisto integroitu tiiviisti Active Directoryyn. Kirkkain Microsoftin esimerkki Exchange-palvelin. Ja usein organisaatiosuunnittelussa Exchange-toteutus Palvelin, sinun on selvitettävä, onko skeema valmis? Ja jos on, mikä Exchange Serverin versio. Päällä nykyinen hetki Exchangesta on kolme versiota, jotka toimivat Active Directoryn kanssa, mutta skeeman muokkaamiseen on kuusi vaihtoehtoa.

Selvitä, onko Active Directory -mallia muutettu Exchange-palvelin mahdollinen attribuutilla " rangeUpper", joka kestää seuraavan arvot:

4397 - Exchange Server 2000 RTM
4406 - Exchange Server 2000 Service Pack 3:lla
6870 - Exchange Server 2003 RTM
6936 - Exchange Server 2003 Service Pack 3:lla
10628 - Exchange Server 2007
11116 – Exchange 2007 Service Pack 1:llä

Kuten näet, skeeman päivitys tapahtuu myös asennettaessa Exchange Server 2000/2003:n ja SP1 for Exchange 2007:n SP3-päivityssarja.

Näytä attribuutin arvo " rangeUpper" Voit käyttää DSQuery-apuohjelmaa:

"dsquery * CN=ms-Exch-Schema-Version-Pt, cn=skeema, cn=määritys, dc=verkkotunnus, dc=local -scope base -attr rangeUpper"

Riisi. 3 Attribuutin hankkiminen " rangeUpper" DSQuery-apuohjelman kautta.

Jos tämän komennon antamisen jälkeen palautetaan vastaus, joka osoittaa määritteen puuttumisen rangeUpper" voimme päätellä, että järjestelmää ei ole muutettu.

Kaavan päivitysprosessi on erittäin tärkeä kohta jokaiselle Aktiiviset organisaatiot Hakemisto, joten sinun tulee välttää tarpeettomia, perusteettomia toimia. Attribuuttien olemuksen ymmärtäminen " objectVersion"Ja « rangeUpper" antaa asiantuntijalle edun työskennellessään Active Directoryn kanssa tuntemattomassa organisaatiossa ja on myös apuväline ongelmien ratkaisemisessa.

Active Directoryn julkaisusta lähtien osa Windowsia Vuonna 2000 Microsoft toimitti käyttäjille Active Directoryn käyttöönoton perusskeeman määritelmän.

Active Directoryn® julkaisu merkitsi myös muutosta tavassa, jolla monet sovellukset kirjoitettiin ja toteutettiin Windowsissa®. Aiemmin sovellukset, kuten Microsoft® Exchange 5.5, rakennettiin omalla hakemistorakenteella. Active Directoryn käyttöönoton jälkeen monet sovellukset (Microsoftilta ja muilta yrityksiltä) ovat alkaneet hyödyntää tarjottua taustarakennetta sen sijaan, että olisivat luoneet oman skeemansa tyhjästä.

Aluksi käytettiin Active Directoryn tarjoamaa perusarkkitehtuuria, jota sitten laajennettiin tarpeen mukaan. Esimerkiksi Microsoft Exchange 2000 käytti Active Directorya viestintäjärjestelmien toteuttamiseen, mikä määritteli Microsoftin viestintäarkkitehtuurin tulevaisuuden.

Nykyään monet sovellukset, jotka on rakennettu toimimaan Active Directory -ympäristössä, luottavat sen perussuunnitteluun, ja monet sovellukset määrittelevät myös tarvittavat omia muutoksia järjestelmiä. Tätä varten tarvitset tietysti piirin, jota voidaan laajentaa, josta keskustellaan tässä artikkelissa. Lisäksi, koska monet sovellukset ovat riippuvaisia Active Directoryn taustalla olevista määritelmistä, taustalla olevan skeeman jatkuva vakaus on kriittistä. Koska useiden sovellusten on toimittava yhdessä samassa Active Directoryssa, yhteen sovellukseen tehtyjen muutosten ei pitäisi vaikuttaa muihin sovelluksiin.

Mikä on skeema?

Monille ihmisille Active Directory -skeema on hieman musta laatikko, ja ajatus itse skeeman muuttamisesta voi olla pelottava. Active Directory -skeeman laajentamista ei tietenkään tarvitse tehdä joka päivä, mutta jotkin sovellukset tai yritykset vaativat sitä. Siksi on erittäin tärkeää ymmärtää järjestelmän luonne ja sen koostumus, koska Active Directory on monille organisaatioille tärkeä voimavara, jonka epäonnistumisella virheellisen päivityksen vuoksi voi olla vakavia seurauksia.

Strategiana monet organisaatiot käyttävät Active Directory Lightweight Directory Services (ADLDS) -palveluita Windows Server® 2008:ssa (tai Active Directory Application Mode (ADAM) Windows Server 2003:ssa) vaihtoehtona testaukseen tai suorakäyttöön. mukautettuja määritelmiä skeema sen sijaan, että laajennat Active Directory -skeemaa.

Kaava on perusrakenne, joka tarjoaa muodon hakemistopalvelulle. Active Directory -skeema määrittää Active Directory Domain Services (ADDS) -palveluissa käytettävät attribuutit ja objektiluokat. Ydinskeema sisältää määritelmät monille tunnetuille luokille (kuten käyttäjälle, tietokoneelle ja organisaatioyksikölle) ja attribuuteille (kuten phoneNumber ja objectSID). Pääskeeman määrittelyssä olevia objekteja kutsutaan luokan 1 objekteiksi ja lisättäviä objekteja luokan 2 objekteiksi.

Active Directory -skeema sijaitsee säilössä, jonka määrittää polku cn=Schema, cn=Configuration,dc=X, missä X on Active Directory -metsän nimiavaruus. Muista, että Active Directory -metsä sisältää vain yhden skeeman; Muutosten tekeminen metsän skeeman määritelmään vaikuttaa kaikkiin kyseisen metsän toimialueisiin. Päällä riisi. 1 näyttää Active Directory -skeemaan lisättyjen luokkien ja määritteiden määrän Windows Serverin eri versioissa.

Luokkien ja attribuuttien lukumäärä

Päivitetään skeemaa kohteelle eri versioita Windows Server on toteutettu Adprep-apuohjelmalla. Päivitettäessä Windows Server 2003 R2:een skeeman versio päivitetään 31:een ja Windows Server 2008:aan päivitettäessä se päivitetään versioon 44.

Löydät versionumeron tarkistamalla ObjectVersion-attribuutin arvon kohdasta cn=Schema,cn=Configuration,dc=X Active Directoryssa käyttämällä työkalua, kuten ADSIEdit. Huomaa, että jotkin sovellukset, kuten Exchange Server, System Management Server(SMS) ja muut Active Directorysta riippuvaiset sovellukset voivat muuttaa skeemaa sovelluksen vaatimusten mukaan.

Peruskomponentit

Active Directory koostuu kahden tyyppisistä objekteista: classSchema (lyhennettynä luokka) ja attributeSchema (lyhennettynä attribuutti). Yleensä Active Directory -skeemalaajennusta harkitaan, jos organisaation on tallennettava tietoja tiettyihin määritteisiin, jotka eivät ole käytettävissä olemassa olevassa skeemassa. Hakemistoskeeman attribuutti luodaan määrittämällä attribuuttiSchema-objekti skeemasäilöön ja määrittämällä sitten uuden objektin vaaditut ominaisuudet.

Luettelo attribuuttiSchema-objektin ominaisuuksista ja tiedoista on osoitteessa go.microsoft.com/fwlink/?LinkId=110445. Kuten näet, objekteille voidaan määrittää attribuuttiskeema suuri määrä ominaisuuksia, joista osa vaaditaan.

Tavallisten attribuuttien lisäksi skeemassa on myös erikoisattribuutteja, joita kutsutaan linkitetyiksi määritteiksi, jotka toteutetaan pareittain määrittämällä eteenpäin ja taaksepäin linkit. Harkitse esimerkiksi ryhmäjäsenyyttä Active Directoryssa. Minkä tahansa ryhmän (esimerkiksi ContosoEmployees-ryhmän, jossa on jäsen John Doe) jäsenyysattribuutti on eteenpäin suuntautuva linkki ja jäsenobjektin vastaava memberOf-attribuutti on paluulinkki (joten kun jäsenen John Doen attribuuttia MemberOf kysytään, lasketaan ContosoEmployees-ryhmän erottuva nimi (DN).

Eteenpäin suuntautuva linkki toimii samalla tavalla kuin mikä tahansa muu attribuutti. Arvot voivat olla yksi- tai moniarvoisia (kuten jäsenyys-attribuutti, joka voi sisältää useita objekteja ryhmän jäseninä) ja ne tallennetaan hakemistoon pääobjektin mukana.

Toisaalta järjestelmä ylläpitää käänteisiä linkkejä tietojen eheyden varmistamiseksi. Kun paluulinkin attribuutin arvoa kysytään, tulos lasketaan kaikkien vastaavien lähtölinkin arvojen perusteella. Käänteiset linkit ovat aina epäselviä.

Kaikki ADDS:n objektiluokat määritellään skeemasäilön classSchema-objektilla. Luettelo attribuuteista, jotka ovat tärkeimpiä classSchema-objektin onnistuneelle määrittämiselle, on osoitteessa go.microsoft.com/fwlink/?LinkId=110445.

On olemassa kolmenlaisia luokkia, jotka voidaan määrittää: rakenteellinen, abstrakti ja hyödyllisyys. Luokkatyyppi määräytyy objectClassCategory-attribuutin arvon perusteella. (Neljäs luokka, joka tunnetaan nimellä 88, sisältää luokat, jotka on määritelty ennen vuoden 1993 X.500-standardeja. Tämä luokkatyyppi osoitetaan arvolla 0 objektiClassCategory-attribuutissa. Tämä tyyppi ei pitäisi enää määritellä.)

Tunnisteiden hankkiminen ja käyttö

Kaikkien hakemistossa olevien classSchema- ja attribuuttischema-objektien identiteetit määritetään käyttämällä vaadittuja objektitunnisteita (OID), classSchema-objekteille ohjaustunnusta ja attribuuttischema-objekteille attribuuttitunnusta. Nämä ovat ainutlaatuisia numeerisia arvoja, joita tietyt keskukset tarjoavat esineiden tunnistamiseksi. Numerointi on LDAP-protokollan (RFC 2251) määritelmän mukainen. Jotkut Active Directory -skeeman objektitunnisteet ovat Kansainvälisen standardointijärjestön (ISO) ja Microsoftin myöntämiä. Hakemiston objektitunnisteen on oltava yksilöllinen.

Objektin tunnus on numerosarja, esimerkiksi 1.2.840.113556.1.y.z, kuten kuvassa riisi. 2. Joten classSchema-käyttäjäobjektin tunnus on 1.2.840.113556.1.5.9.

Käyttäjäobjektin tunnus

Merkitys	Merkitys	Kuvaus
1	ISO	Määrittää juurikeskuksen.
2	ANSI	ISO:n määrittämä ryhmänimitys.
840	USA	Organisaation määrittämä maa-/aluekoodi.
113556	Microsoft	Organisaation nimitys maan/alueen mukaan.
1	Active Directory	Organisaation määrittämä (in tässä tapauksessa Microsoft).
Y	Objektityyppi	Numero edustaa erilaisia tyyppejä objekti (luokka), esimerkiksi classSchema tai attribuuttiskeema. Esimerkiksi 5 tarkoittaa objektin luokkaa.
Z	Esine	Numero, joka edustaa tiettyä kohdetta luokassa. Esimerkiksi käyttäjäluokalle voidaan antaa numero 9.

Kun organisaatio haluaa laajentaa skeemaa, se varmistaa, että objektin tunniste on yksilöllinen hankkimalla oman OID-juurinumeronsa, jota käytetään luomaan yksilölliset tunnisteet organisaation uusille attribuuteille ja objektiluokille. Kohteen tunnisteen juuren saa suoraan ISO:n kansallisesta rekisteröintitoimistosta (Yhdysvalloissa American National Standards Institute (ANSI)).

Pääobjektin tunnuksen hankkimismenettely ja palvelumaksut löytyvät osoitteesta ansi.org. Muilla alueilla ota yhteyttä asianmukaiseen ISO-jäsenorganisaatioon, joka on lueteltu osoitteessa iso.org/iso/about/iso_members.htm.

Aiemmin organisaatiot saivat Microsoftilta objektitunnuksen lähettämällä viestin sähköposti osoitteessa [sähköposti suojattu]. Tämä kuitenkin johtaa nyt automaattiseen vastaukseen, jossa sinua pyydetään lataamaan ja suorittamaan VBScript osoitteesta go.microsoft.com/fwlink/?LinkId=110453.

Microsoftin myöntämille objektitunnisteille on määritetty numeeriset tunnisteavaruusnumerot Microsoft vastustaa: 1.2.840.113556.1.8000.x, missä x – ainutlaatuinen numero, määritetty organisaatiolle. Organisaatio voi erottaa nämä tunnisteet objektien tunnistamiseksi. Näin ollen voit käyttää 1.2.840.113556.1.8000.x.1.y uusille classSchema-objekteille ja 1.2.840.113556.1.8000.x.2.z attribuuttiskeema-objekteille (jossa x on organisaation yksilöllinen numero ja y ja z ovat numerot, joille on määritetty tietyt classSchema- ja attribuuttiskeema-objektit). On myös suositeltavaa, että käytät yksilöllistä organisaation etuliitettä erottaaksesi näiden objektien nimet.

Liittyvien attribuuttien määrittäminen

Paluulinkin attribuutin syntaksiarvon on oltava 2.5.5.1, joka on Object Syntax (DS-DN). Yleensä paluulinkin attribuutit lisätään luokan mayContain-arvoon, jolla on suurin abstraktio. Tämä varmistaa, että paluulinkin attribuutti voidaan lukea minkä tahansa luokan objekteista, koska sellaisia attribuutteja ei tallenneta objektiin, vaan ne lasketaan lähtölinkin arvojen perusteella.

Windows Server 2003 esitteli ominaisuuden, jonka avulla organisaatiot voivat linkittää kaksi objektia skeemassa: automaattinen luominen linkkitunnukset. Tämä toiminto varmistaa, että linkkitunnus luodaan automaattisesti uudelle linkitetylle attribuutille, jos attribuutin linkkitunnus on 1.2.840.113556.1.2.50. Vastaava paluulinkki luodaan asettamalla linkkitunnukseksi eteenpäin linkin attribuuttitunnus tai ldapDisplayName. Kaavavälimuisti on ladattava uudelleen eteenpäin linkin luomisen jälkeen ja ennen paluulinkin luomista. Muussa tapauksessa attribuuttia attribuuttiId tai ldapDisplayName ei löydy luotaessa takaisinlinkkiä. Kaavavälimuisti ladataan uudelleen pyynnöstä muutaman minuutin kuluttua skeeman muuttamisesta tai kun toimialueen ohjauskone käynnistetään uudelleen.

Jos käytössäsi on Windows 2000 Active Directory, sinun on pyydettävä linkkitunnuksia Microsoftilta lähettämällä sähköposti osoitteeseen [sähköposti suojattu]. Automaattinen vastaus sisältää seuraavan rivin: "Sähköpostit lähetetty osoitteeseen [sähköposti suojattu] käsitellään vain, jos ne liittyvät linkID-rekisteröintiin vanhoille ympäristöille." (Sähköpostit lähetetty osoitteeseen [sähköposti suojattu], käsitellään vain, jos ne liittyvät linkkitunnusten rekisteröintiin vanhoissa ympäristöissä.) Tätä varten sinun on sisällytettävä sähköpostiisi seuraavat tiedot: yrityksen nimi, nimi yhteyshenkilö, sähköpostiosoite, puhelinnumero, rekisteröity etuliite (tarvittaessa), rekisteröity kohdetunnus (tarvittaessa).

Voit aloittaa järjestelmän laajentamisen

Oletetaan, että päätät laajentaa Active Directory -malliasi. Ratkaisu voi sisältää käytön lopettamisen vaihtoehtoinen hakemisto toteutetaan ADLDS:llä (tai ADAMilla Windows Server 2003:ssa) sen jälkeen, kun on vahvistettu, että se ei täytä vaatimuksia. Seuraava vaihe on määrittää uudet attribuuttiSchema-objektit, jotka on lisättävä skeemaan; tämä määrittää kaikki tarvittavat arvot (kuten cn, ldapDisplayName jne.), jotka osoittavat nämä uudet objektit. Kun määrität objektille attribuuttiarvoja, hankit myös objektin tunnisteen Microsoftilta tai muulta lähteeltä. Edellä mainitut toiminnot on dokumentoitu liiketoimintavaatimuksina ja teknisinä eritelminä. Lisäksi on toteutettu kokeellinen laboratorioympäristö, joka simuloi Active Directoryn toimintaa ja on valmis testattavaksi.

Monet organisaatiot perustavat erityiskomiteoita hyväksymään tai hylkäämään tällaiset muutokset ja luomaan prosessin niiden toteuttamiseksi. Nämä tarkistukset ja tasapainot ovat kriittisiä, koska Active Directorya käytetään luotettavana tietolähteenä monissa organisaatioissa, ja sen ylläpitämisen tärkeyttä muutosten jälkeen ei voi liioitella.

Kun organisaatio päättää jatkaa projektia, on määriteltävä suunnitelmat projektin testaamiseksi ja toteuttamiseksi. Voit laajentaa malliasi lisäämällä uusia objekteja Active Directory Console Schema -laajennuksella Microsoftin hallinta(MMC) tai käyttämällä ohjelmallisia tai puoliohjelmallisia menetelmiä (esimerkiksi LDIFDE:tä LDIF-tiedostojen tuontiin tai CSVDE:tä tuontiin CSV-tiedostot; tai ADSI-liitäntöjen skriptien käyttäminen).

Riippumatta valitusta menetelmästä, tämä toiminto on suoritettava palvelimella, joka on liitetty FSMO (Flexible Single Master Operations) -skeeman päärooliin Active Directory -metsässä. Lisäksi, tili Kaavan päivittämiseen käytetty käyttäjä tarvitsee riittävät järjestelmänvalvojan oikeudet päivityksen suorittamiseen, joten se on sisällytettävä Schema Administrators -ryhmään. Lopuksi sinun on otettava käyttöön metsän skeeman päivitykset (oletusarvoisesti poissa käytöstä).

Ellei muutos ole yksinkertainen, se tulisi tehdä automaattisesti, jotta varmistetaan standardisointi testaus- ja toteutusvaiheiden välillä ja estetään manuaalisissa vaiheissa mahdollisesti ilmenevät virheet. Oletetaan, että päätät toteuttaa muutoksen käyttämällä LDIFDE-työkalua. Jos haluat asentaa päivitykset skeemaa laajennettaessa, sinun on lisättävä uusia määritteitä ja luokkia, lisättävä luokkiin uusia määritteitä ja suoritettava sitten välimuistin uudelleenlataus. Alla on esimerkkejä.

Attribuuttien lisääminen

Oletetaan, että Contoso-niminen organisaatio on lisättävä Aktiivinen palvelu Hakemistoattribuutti, joka määrittää kaikkien työntekijöiden kengän koon. IN metsä aktiivinen Hakemisto kaksi verkkotunnusta: contoso.com ja työntekijät.contoso.com. Kaikkien objektien, jotka on luotu käyttämällä käyttäjäluokan määritelmää, on sisällettävä myös tämä uusi attribuutti.

On tärkeää muistaa, että skeeman muutos vaikuttaa molempiin toimialueisiin, koska ne ovat samassa metsässä. Oletetaan, että saat Microsoftilta objektitunnuksen 1.2.840.113556.8000.9999, joka jakautuu 1.2.840.113556.8000.9999.1:een classSchemaa varten ja 1.2.840.113556.8000.99schemos'attribuutiksi. Nyt sinun on määritettävä kaikki tämän uuden objektin attribuuttiarvot, kuten kuvassa riisi. 3.

ContosoEmpShoe-attribuutin määrittäminen

Attribuutti	Merkitys	Huomautuksia
Cn	contosoEmpShoe
lDAPDisplayName	contosoEmpShoe
adminDisplayName	contosoEmpShoe
attribuutin syntaksi	2.5.5.12	Määrittää Unicode-merkkijonon.
oMSyntaksi	64	Määrittää Unicode-merkkijonon.
objektiluokka	alkuun, attribuuttiskeema
attribuuttitunnus	1.2.840.113556.8000.9999.2.1	Organisaation määrittelemä.
isSingleValued	TOTTA	Vain yksi kenkäkoon arvo tallennetaan.
etsi lippuja	1	Analyysi osoittaa, että tämä attribuutti on indeksoitava. Huom. Kuormitusanalyysi tehdään laboratorioympäristössä.
isMemberOfPartialAttributeSet	TOTTA	Tämän määritteen on oltava saatavilla yleisessä luettelossa.

Lisäksi, vaikka contosoEmpShoe-attribuutin pitäisi olla kaikkien käyttäjäluokan objekteina luotujen objektien käytettävissä, oletuskäyttäjäluokan määritelmää ei suositella muuttamaan. Sen sijaan sinun tulee määrittää apuluokka contosoUser, jonka mayContain-attribuutti on asetettu contosoEmpShoe-asetukseksi, kuten kohdassa riisi. 4. Sitten sinun on lisättävä contosoUser helper -luokalle määritetyt attribuutit käyttäjäluokkaan.

ContosoUser-luokan määrittäminen

Nyt kun analyysi on tehty ja arvot on määritetty, sinun on luotava LDIF-tiedosto, joka näyttää jotain koodilta riisi. 5. Voit kopioida koodin kohteeseen riisi. 5 Muistioon ja tallenna tiedosto nimellä contosoUser.ldif (sisältyy lataukseen osoitteessa technetmagazine.com).

LDIF-tiedosto skeeman laajennukselle

#Attribuutin määritelmä contosoEmpShoe dn:lle: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attribuuttiSchema cn: contosoEmpShoe attribuuttiID: 1.2.840.213:056.11.9 2.5.5.1 2 isSingleValued: TRUE adminDisplayName: contosoEmpShoe adminDescription: contosoEmpShoe oMSyntax: 64 searchFlags: 1 lDAPDisplayName: contosoEmpShoe systemOnly: FALSE dn: muutaUpdateN - ow: muuta skeemaa: CN=contosoUser,CN=Schema,CN=Configuration , DC =X changetype: ntdsschemaadd objectClass: top objectClass: classSchema cn: contosoUser governsID: 1.2.840.113556.1.8000.9999.1.1 mayContain: contosoEmpShoe rDNAttID: cn objectClass:dmintososerU Luokka: 3 lDA PDisplayName: contosoKäyttäjänimi: contosoUser systemOnly: FALSE dn : changetype: muokkaa lisää: schemaUpdateNow schemaUpdateNow: 1 - dn: CN=User,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify add: auxiliaryClass auxiliaryClass: auxiliaryClass auxiliaryClass: contosoUser: modifyda addN: changeow 1

Kun olet luonut LDIF-tiedoston, sinun on testattava toteutus perusteellisesti pilottilaboratorioympäristössä, tarkistettava päästä päähän -toimialueen ja metsän replikointi ja otettava käyttöön skeeman päivitykset metsässä. Sinun on nyt kirjauduttava sisään tilillä, jolla on Schema Administrator -oikeudet. Saatat joutua poistamaan lähtevän replikoinnin käytöstä skeema-masterissa (jossa muutokset tehdään) ja suorittamalla seuraavan komennon tuodaksesi LDIF-tiedoston:

Ldifde –i –f \contosoUser.ldif –b -k –j. –c "CN=schema,CN=Configuration,DC=X" #schemaNamingContext

Kun olet tehnyt muutokset, ota lähtevä replikointi käyttöön skeeman pääkoneessa ja varmista, että replikointi on valmis kaikille toimialueen ohjauskoneille.

Hengitä syvään - olet valmis! Olet määrittänyt skeemaan uuden attribuutin, joka liitetään objekteihin, jotka on luotu käyttämällä käyttäjäluokkaa (eli käyttäjätilejä).

Voit testata muutokset avaamalla Active Directory -käyttäjät ja -tietokoneet, muodostamalla yhteyden työntekijöiden.contoso.com-toimialueeseen, valitsemalla käyttäjien organisaatioyksikön ja luomalla uuden käyttäjätilin nimeltä ContosoTestUser. Avaa nyt adsiedit.msc-konsoli ja muodosta yhteys verkkotunnukseen dc=employees,dc=contoso,dc=com, laajenna Käyttäjät-alajaosto, hiiren oikealla napsautuksella Napsauta ContosoTestUser ja avaa sitten Ominaisuudet-sivu. Etsi contosoEmpShoe-attribuutti. Voit muuttaa tätä attribuuttia syöttääksesi arvon. Voit myös tarkistaa ja muuttaa määritteitä Ldp.exe-apuohjelman avulla.

Katsotaanpa nyt esimerkkiä kahden ominaisuuden määrittämisestä ja yhdistämisestä ja kuvitellaan, että Contoso-yritys on erittäin tärkeä työntekijöidensä kenkäkoon kannalta ja sen on seurattava yrityksen työntekijöiden kenkäkokoa mittaavien asiantuntijoiden vuotuista tuottavuutta. Vaikka tämä saattaa tuntua naurettavalta, oletetaan myös, että Contoson ei tarvitse seurata vain sitä, kuka on vastuussa työntekijöiden kenkäkokojen mittaamisesta, vaan myös työntekijöitä, joiden kenkäkoot mitattiin, ja heidän lukumääränsä. Tämä kaikki tehdään yhdellä määritteellä. (Vaikka saatat ajatella, että tietokantataulukot soveltuvat paremmin tällaisten tietojen tallentamiseen, tässä on tarkoitus yksinkertaisesti selittää, miten eteenpäin ja taaksepäin linkit toimivat.)

Tietenkin teet ensin analyysin, joka on samanlainen kuin edellisessä esimerkissä mainitsemani. Mutta nyt mennään eteenpäin ja luodaan LDIF-tiedostot (linkids1.ldif ja linkids2.ldif) kuvan osoittamalla tavalla. riisi. 6. Suoritamme sitten seuraavan komennon tuodaksesi LDIF-tiedostot:

LDIF-tiedostot eteenpäin ja taaksepäin linkeistä

#linkids1.ldif #Attribuutin määritelmä edelleenlähetyslinkin attribuutille dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attribuuttiSchema cn: ContosoShoeSizeTaker.0.9.9.8.56.0.9.8.9 .2. 2 LinkID: 1.2.840.113556.1.2.50 attribuuttiSyntaksi: 2.5.5.1 isSingleValued: TRUE adminDisplayName: ContosoShoeSizeTaker adminDescription: ContosoShoeSizeTaker oMSyntaxlDAS:.isoplayNameSyntax: ker systemOnly: FALSE d n: muutostyyppi: muokkaa lisää: schemaUpdateNow schemaUpdateNow: 1 - #Reload schema #linkids2.ldif #Attribuutin määrittely taaksepäin linkin attribuutille dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemaadd objectClass: top objectClass: attribuuttiSchema cn: ContosoShoeShoeSizes.5.1 attribuutti3:81.2 IDTakenBeSizes. 8000,99 99.2 .3 LinkID: 1.2.840.113556.8000.9999.2.2 attribuuttiSyntaksi: 2.5.5.1 isSingleVued: FALSE adminDisplayName: ContosoShoeSizesTakenByMe admin adminDescription: 1 - # Lisää ContosoShoeSizeTaker ja ContosoShoeSizesTakenByMe attribuutti MayContain luokassa #contosoUser dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify add: mayContain mayContainS:ContosoTakerContainS:ContosoTakerShoey changetype: muokkaa lisää: schemaUpdateNow schemaUpdateNow: 1 - #Add Backward Link Attribuutti kuten MayContain Top dn:ssä: CN=Top,CN=Schema,CN=Configuration,DC=X changetype: ntdsschemamodify add: mayContain mayContain: ContosoShoeSizesTakenByMe dn: changetypeUpdate Add: schemateN schemaow:UpdateN ldifde – i –f \linkedids.ldif –b -k –j. –c "CN=schema,CN=Configuration,DC=X" #schemaNamingContext

Nyt kun luot käyttäjäobjektin, siinä on myös ContosoShoeSizeTaker- ja ContosoShoeSizesTakenByMe-attribuutit. Kun luot käyttäjäobjektin esimerkiksi Johnille, ContosoShoeSizeTaker-attribuutti täytetään kengän koon mitanneen henkilön erottuvalla nimellä Frank. Jos siirryt nyt Frankin käyttäjäobjektin ominaisuuksiin ja kysyt ContosoShoeSizesTakenByMe-attribuuttia, tulos sisältää Frankin ja muiden, joiden kengänkoon Frank mittasi, erottuvan nimen. Asiamme loppuun saattamiseksi johto voisi palkita Frankin hänen käyttäjätilin ContosoShoeSizesTakenByMe-attribuutissa olevien erottuvien nimien lukumäärän perusteella.

Valvonta- ja tasapainojärjestelmä

Kriittistä päivitystä, kuten skeeman muutosta, ei voida suorittaa ilman arkkitehtonisten vaatimusten noudattamisen varmistamista. Active Directory käyttää näitä suojaus- ja johdonmukaisuustarkistuksia varmistaakseen, että muutokset eivät aiheuta epäjohdonmukaisuuksia tai muita ongelmia Active Directory -skeemaa laajennettaessa tai muutettaessa.

Ensinnäkin kunkin luokan governsID-arvon on oltava yksilöllinen skeemassa. Kun määritetään schemaClass-objektia, kaikkien systemMayContain-, mayContain-, systemMustContain- ja mustContain-luetteloissa määritettyjen attribuuttien on oltava jo olemassa. Samaan aikaan kaikkien listoissa subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors ja possSuperiors määriteltyjen luokkien on myös oltava jo olemassa.

Lisäksi systemAuxiliaryClass- ja auxiliaryClass-luetteloiden kaikkien luokkien objectClassCategory-attribuutin on oltava luokka 88 tai apuluokka. Samoin systemPossSuperiors- ja possSuperiors-luetteloiden kaikkien luokkien objectClassCategory-attribuutti on määritettävä luokaksi 88 tai rakenneluokiksi.

Eri luokkia määritettäessä abstraktit luokat voidaan johtaa vain muista abstrakteista luokista, apuluokkia ei voida johtaa rakenneluokista, eikä rakenneluokkia voida johtaa apuluokista. Lisäksi rDNAttID:ssä määritetyn attribuutin on oltava yksiselitteinen ja sillä on oltava Unicode-merkkijonosyntaksi.

Nämä ovat joitakin classSchema-objekteihin liittyviä sääntöjä. Entä attribuuttiskeema-objektien säännöt? Aivan kuten luokkien governsID-arvon, attribuutin ID-arvon on oltava yksilöllinen. Lisäksi mAPIID-arvon (jos sellainen on) on oltava yksilöllinen. Seuraavaksi, jos rangeLower ja rangeUpper ovat läsnä, rangeLower-arvon on oltava arvoa pienempi valikoimaYlä. AttribuuttiSyntax- ja oMSyntax-arvojen on vastattava toisiaan. Jos määritteen syntaksi on objektin syntaksi (oMSyntax =127), sillä on oltava oikea oMObjectClass. Jos linkkitunnus on olemassa, sen on oltava yksilöllinen. Lisäksi paluulinkillä on oltava vastaava eteenpäin linkki.

Entä jos tapahtui virhe?

Kun skeemaa on laajennettu ja siihen on lisätty uusia objekteja (luokkia ja attribuutteja), niitä ei voi poistaa. Luokat ja attribuutit voidaan kuitenkin poistaa käytöstä asettamalla skeemaobjektin attribuutti isDefunct TRUE arvot. Et voi deaktivoida skeemaobjekteja, jotka ovat osa Active Directoryn mukana tulevaa oletusskeemaa (luokan 1 objektit). Vain oletusskeemaan lisätyt objektit voidaan deaktivoida, ts. Luokan 2 objektit ja vasta sen jälkeen, kun on tarkistettu, että luokkaa ei käytetä minkään olemassa olevan tehokkaan luokan subClassOf-, auxiliaryClass- tai possSuperiors-luetteloissa.

Kun yrität poistaa minkä tahansa määritteen käytöstä, Active Directory tarkistaa, käytetäänkö sitä minkä tahansa olemassa olevan kelvollisen luokan mustContain- ja mayContain-luetteloissa. Poistetut objektit voidaan ottaa uudelleen käyttöön asettamalla isDefunct-attribuutti arvoon FALSE. Jos Active Directory on käynnissä Windows Server 2003 -tasolla, voit käyttää uudelleen käytöstä poistettujen objektien ldapDisplayName-, schemaIdGuid-, OID- ja mapiID-arvoja.

Johtopäätös.

Kun lisäät tai muutat kaavion luokka- tai attribuuttimäärityksiä, lisäät tai muutat myös vastaavaa classSchema- tai attribuuttiskeema-objektia. Tämä prosessi on samanlainen kuin minkä tahansa objektin lisääminen tai muuttaminen Active Directoryssa, paitsi että lisätarkastuksia että muutokset eivät aiheuta epäjohdonmukaisuutta eivätkä voi aiheuttaa ongelmia piirissä tulevaisuudessa.

Vaikka Active Directory -skeeman muuttaminen ei ole monimutkainen prosessi, on tärkeää ymmärtää skeeman rakenne ja näiden muutosten toteuttamisprosessi. Kaikki Active Directory -skeeman muutokset on suunniteltava huolellisesti ja suoritettava erittäin huolellisesti. On tärkeää määritellä liiketoiminnan vaatimukset ja tekniset tiedot uusille kohteille ja suorittaa kattavat testaukset. Koska muutoksilla voi olla merkittävä vaikutus, on suositeltavaa laajentaa Active Directory -skeemaa vain, kun se on ehdottoman välttämätöntä.

Kuten tiedät, mikään ei kestä ikuisesti, kaikki muuttuu, etenkin IT:n kaltaisella alalla. Kun infrastruktuuri on otettu käyttöön, se kehittyy, laajenee ja paranee jatkuvasti, ja tulee aika, jolloin sinun on lisättävä Active Directoryyn käyttöjärjestelmän uudempaa versiota käyttävä toimialueen ohjain.

Vaikuttaa siltä - mikä on ongelma? Mutta kuten käytäntö osoittaa, ongelmia syntyy, mikä johtuu suurelta osin siitä, että järjestelmänvalvojilla on vähän tietoa teoriasta ja he ovat suoraan sanottuna hämmentyneitä tässä asiassa. Siksi on aika selvittää, mikä se on AD-suunnitelma ja miten se liittyy tapauksiimme.

AD piiri kutsutaan kuvaukseksi kaikista hakemistoobjekteista ja niiden attribuuteista. Pohjimmiltaan skeema heijastaa hakemiston perusrakennetta ja on ensiarvoisen tärkeä sen asianmukaisen toiminnan kannalta.

Uudet käyttöjärjestelmän versiot sisältävät uusia objekteja ja attribuutteja, joten meidän on päivitettävä skeema, jotta ne toimisivat oikein toimialueen ohjauskoneina.

Se näyttää selvältä, mutta ei täysin, joten siirrytään yleisiin virheisiin ja väärinkäsityksiin.

Kaavan päivittäminen on tarpeen, jotta toimialueeseen voidaan sisällyttää tietokoneita, joissa on uudempi Windows-versio. Tämä ei pidä paikkaansa, edes viimeisimmät Windows-versiot voi toimia melko menestyksekkäästi Windows 2000 -tason toimialueella ilman skeeman päivittämistä. Jos kuitenkin päivität järjestelmän, mitään pahaa ei tapahdu.

Jos haluat sisällyttää toimialueeseen uudempaa käyttöjärjestelmää käyttävän ohjaimen, sinun on päivitettävä toimialue (metsä). Tämä ei myöskään pidä paikkaansa, mutta toisin kuin edellinen tapaus, tämä toiminto tekee mahdottomaksi käyttää toimialueen ohjaimia, joiden käyttöjärjestelmä on alempi kuin sen toimintatila. Siksi sinun on virheen sattuessa palautettava AD-rakenne varmuuskopiosta.

Kiinnitämme huomionne myös metsän ja toimialueen toimintatapaan. Metsään sisältyvillä verkkotunnuksilla voi olla erilaisia toimintatapoja, esimerkiksi yksi toimialueista voi toimia Windows 2008 -tilassa ja loput Windows 2003 -tilassa. Esimerkissämme metsän käyttötila ei voi olla korkeampi kuin Windows 2003.

Samanaikaisesti metsän alempi toimintatapa ei millään tavalla estä korkeamman toimintatavan käyttöä alueella, mikä riittää, että skeema päivitetään.

Tutustuttuamme teoriaan siirrytään käytännön esimerkkiin. Oletetaan, että meillä on Windows 2000 -tason toimialue (mixed mode) - AD:n alin taso - jossa on Windows 2003 -ohjain, ja tavoitteenamme on luoda uusi ohjain epäonnistuneen tilalle.

Uudessa palvelimessa on Windows 2008 R2. Huomaa, että meillä ei ollut vaikeuksia liittää tämä palvelin olemassa olevaan verkkotunnukseen.

Kuitenkin, kun yritämme lisätä uuden toimialueen ohjaimen, saamme virheilmoituksen:

Voit käynnistää onnistuneesti ohjaimen, joka ohjaa enemmän kuin uusi versio Käyttöjärjestelmä meidän on päivitettävä metsäskeema ja toimialueen skeema. Poikkeuksena on Windows Server 2012, joka päivittää skeeman itse, kun lisää uuden toimialueen ohjaimen.

Voit päivittää skeeman käyttämällä Adprep-apuohjelmaa, joka sijaitsee kansiossa \support\adprep asennuksen yhteydessä Windows-levy Palvelin. Windows Server 2008 R2:sta lähtien tämä apuohjelma on oletusarvoisesti 64-bittinen, jos sinun on käytettävä 32-bittistä versiota, sinun tulee suorittaa se adprep32.exe.

Metsäkaavion päivityksen suorittaminen tämä apuohjelma pitäisi käynnistää Järjestelmän omistaja, ja päivittää toimialueen skeema muotoon Infrastruktuurin omistaja. Käytä komentoa saadaksesi selville, millä ohjaimilla on tarvitsemamme FSMO-roolit:

Netdom-kysely FSMO

Windows 2008:ssa ja uudemmissa käyttöjärjestelmissä tämä apuohjelma on asennettu oletusarvoisesti, ja Windows 2003:ssa se on asennettava levyltä hakemistosta \tuki\työkalut

Tämän komennon tulos on luettelo kaikista FSMO:n roolit ja ohjaimet näillä rooleilla:

Meidän tapauksessamme kaikki roolit ovat samassa ohjaimessa, joten kopioimme kansion \support\adprep kiintolevylle (tässä tapauksessa C:-aseman juureen) ja jatka metsäskeeman päivittämistä. Toiminnon suorittaminen onnistuneesti edellyttää, että tilisi on sisällytettävä seuraaviin ryhmiin:

Kaavojen ylläpitäjät
Yritysjärjestelmänvalvojat
Sen verkkotunnuksen järjestelmänvalvojat, jossa skeeman omistaja sijaitsee