Namnet på den lokala domänen. Hur man inte namnger Active Directory-domäner

Namnet på den lokala domänen. Hur man inte namnger Active Directory-domäner

I sällsynta fall kan en domäntjänstadministratör ställas inför uppgiften att byta namn på den aktuella domänen. Orsakerna kan vara olika, men denna situation är fullt möjlig. Trots att denna uppgift inte kan kallas trivial, men ibland måste du ta itu med det, är det oerhört viktigt att göra allt rätt, för annars kan resultatet av händelser bli kritiskt farligt, upp till en helt icke-fungerande företagsinfrastruktur. Så senare i den här artikeln kommer du att lära dig om förutsättningarna för att utföra den här operationen, några begränsningar och hur du kan byta namn på din domän. Innan vi börjar ber vi dig att inte utföra dessa steg i en produktionsmiljö förrän du framgångsrikt har bytt namn på din testdomän i en labbmiljö. Låt oss börja.

Förutsättningar

Innan du börjar byta namn på din domän, se till att ta hänsyn till följande information:

  • Active Directory Forest funktionsnivå. Du kan bara utföra domänbyte-uppgifter om alla domäner i skogen kör minst Windows Server 2003 (det finns inga begränsningar i upplagan i det här fallet). Dessutom måste funktionsnivån höjas till minst Windows Server 2003-nivån. Windows nivå Server 2000, då blir nästa operation helt enkelt omöjlig;
  • Domänplats. Det kan finnas olika nivåer av domäner i en Active Directory-skog. Det vill säga, det kan antingen finnas en enda domän eller så kan skogen inkludera underordnade domäner. I händelse av att du ändrar platsen för domänkontrollanten i skogen måste du skapa en förtroenderelation;
  • DNS-zon. Redan innan du utför domänbyteoperationen måste du skapa en ny DNS-zon;
  • Administrativa meriter. För att utföra en domänbyteoperation måste du vara inloggad med ett administrativt konto som är medlem i gruppen Enterprise Admins;
  • Distributed File System (DFS) servrar. Om din företagsmiljö har DFS distribuerad eller roamingprofiler konfigurerade, observera att DFS rotservrar måste köra minst Windows Server 2000 Service Pack 3 eller senare operativsystem;
  • Inkompatibilitet med Microsoft Exchange-servrar. Det mest irriterande är att om en Microsoft Exchange Server 2003 Service Pack 1-e-postserver är utplacerad i din Active Directory-skog, kommer domänbytet att slutföras utan problem, men användarkontot under vilket domänbyteprocessen kommer att utföras vara medlem i gruppen Full Exchange Administrator. Mer och mer modern e-postservrar(inklusive Exchange Server 2016) är inkompatibla med domänbyteoperationer.

Observera också att du måste frysa alla pågående Active Directory-skogskonfigurationsåtgärder medan domänen byter namn. Med andra ord måste du se till att din skogskonfiguration inte ändras förrän domänbyteoperationen är helt slutförd ( detaljerad information se nedan för detaljer om hur du gör detta). Dessa operationer inkluderar: skapa eller ta bort domäner inom din Active Directory-skog, skapa eller ta bort programkatalogpartitioner, lägga till eller ta bort domänkontrollanter i skogen, skapa eller ta bort ett direkt etablerat förtroende och lägga till eller ta bort attribut som kommer att replikeras till den globala katalog.

För säkerhets skull skulle jag också råda dig att göra en fullständig säkerhetskopia av systemstatus på varje domänkontrollant i Active Directory-skogen. Om denna uppgift är klar kommer denna försiktighetsåtgärd definitivt inte att vara överflödig.

I händelse av att din infrastruktur uppfyller ovanstående krav och allt som krävs säkerhetskopior, kan du fortsätta med domänbytesprocessen.

Process för att byta namn på Active Directory-domän

Till att börja med, för att kontrollera det ursprungliga namnet på din domän, kan du öppna fönstret för systemegenskaper. Som du kan se i motsvarande illustration är mitt domännamn "Biopharmaceutic.local":

Ris. 1. Kontrollera det ursprungliga Active Directory-domännamnet

Nu bör du skapa en ny DNS-zon "biopharm.local" så att dina medlemsservrar och klienter kan ansluta sig till den nya utan problem efter det framgångsrika slutförandet av domänbytet. domän namn. För att göra detta, öppna DNS Manager» ( DNS Manager) och vara i " Framåtsökningszon» ( Framåtsökningszon) välj alternativet för att skapa en ny zon. I huvudsak skapas zonen som vanligt: ​​på den första sidan av guiden New Zone, läs den inledande informationen och fortsätt till den andra sidan. På sidan för zontyp väljer du den primära zonen ( Primär zon) och se till att alternativet att spara zonen i Active Directory är aktiverat. På sidan för zonreplikeringsområde lämnar du alternativet markerat som standard - " För alla DNS-servrar som körs på domänkontrollanter i denna domän: Biopharmaceutic.local» ( Till alla DNS-servrar som körs på domänkontrollanter i denna domän: Biopharmaceutic.local). På sidan med zonnamn bör du ange det nya domännamnet (biopharm.local), och på sidan för dynamisk uppdatering, lämna även alternativet " Tillåt endast säkra dynamiska uppdateringar (rekommenderas för Active Directory)» ( Tillåt endast säkra dynamiska uppdateringar (rekommenderas för Active Directory)), som är valt som standard. Du kan se flera steg för att skapa en ny zon nedan:

Ris. 2. Skapa en ny DNS-zoner

Nästa steg i domänbyte är att generera en beskrivning av skogens nuvarande tillstånd. Detta är faktiskt den första domänbyteoperationen som kommer att använda kommandoradsverktyget Rendom. Detta verktyg genererar en textbeskrivning av din nuvarande skogsstruktur som en XML-fil med namnet Domainlist.xml. Den här filen innehåller en lista över alla domänkatalogpartitioner samt programkatalogpartitioner som finns i din Active Directory-skog. Varje post för varje domän och programkatalogpartition är begränsad XML-taggar Och. Dessutom innehåller varje post data som inkluderar den globalt unika objektidentifieraren (GUID) för partitionens rotobjekt, DNS-namnet på domänen eller programkatalogen och NetBIOS-namnet för domänen.

För att skapa en sådan fil, öppna under lämpligt konto kommandorad och i den kör kommandot " slumpmässig /lista". Den genererade filen kommer att sparas i rotkatalogen konto din användare. Därefter måste du öppna den här filen med valfri textredigerare.

Inuti den här filen måste du ändra domännamnet i avsnittet som är avgränsat av taggar Och och NetBIOS-namnet inuti taggarna Och). Var noga med att notera att du inte får ändra GUID inuti motsvarande taggar.

I följande illustration kommer du att se processen för att utföra kommandot ovan, platsen för filen Domainlist.xml och ändringarna för den första delen av den här filen. I mitt fall kommer domännamnet i denna konfiguration att ändras 4 gånger:

Ris. 3. Generering och modifiering av filen Domainlist.xml

För att vara säker på att du har gjort de nödvändiga ändringarna i motsvarande fil kan du köra kommandot " random /showforest". Som du kan se i följande illustration har alla mina poster ändrats till "Bopharm":

Ris. 4. Se potentiella förändringar

När du kör följande kommando ( slumpmässig /uppladdning), översätter verktyget Rendom den nya skogsstrukturen som anges i den redigerade filen till en sekvens av som körs lokalt och på distans på varje domänkontrollant i skogen. Generellt sett kommer det här steget att göra ändringar i konfigurationskatalogsektionen i domännamnsguiden för att byta namn på Active Directory-domänen. Dessutom kommer en Dclist.xml-fil att genereras som används för att spåra framsteg och status för varje domänkontrollant i skogen för domänbyteoperationen. Förresten, vid denna tidpunkt fryser Rendom-verktyget din Active Directory-skog från att göra några ändringar i dess konfiguration. Processen för att utföra detta kommando ses nedan:

Ris. 5. Kör kommandot rendom /upload

Följande kommando körs för att kontrollera domänkontrollanternas beredskap innan domänbyteoperationen. Under detta steg måste du köra kommandot för förberedande kontroll på varje domänkontrollant i skogen. Detta för att säkerställa att Active Directory-databasen på varje domänkontrollant i skogen är i rätt tillstånd och redo att göra ändringar som gör att du kan byta namn på din domän. Kör därför kommandot " slumpmässigt /förbered", som det görs i följande illustration:

Ris. 6. Förbereder domänen för att döpa om

Det viktigaste ögonblicket. Utför kommandot " slumpmässig /kör". När detta kommando körs på domänen exekveras instruktioner för att byta namn på domänen. I huvudsak, just i detta ögonblick, kontaktas varje domänkontrollant i skogen individuellt, vilket får varje domänkontrollant att utföra instruktioner för att byta namn på domänen. När denna operation har slutförts kommer varje domänkontrollant att startas om. Se följande illustration för processen att byta namn på en domän:

Ris. 7. Process för domänbyte

Men det är inte allt. Även om din domän faktiskt redan har bytt namn, har du fortfarande uppgiften att fixa GPO:erna och deras referenser efter att domänbyte-operationen är klar. Ett kommandoradsverktyg används för att återställa GPO:er och GPO-länkar i varje omdöpt domän. gpfixup.exe. Du kan inte försumma denna procedur eftersom utan den, efter slutförandet av domänbyteoperationen i den nya skogen, grupppolicyer Jag kommer bara inte att fungera ordentligt. Observera att detta kommando måste köras en gång på varje omdöpt domän. Kör därför kommandot en gång gpfixup med parametrar /olddns:Biopharmaceutic.local(det gamla namnet på domänen du döpte om) och /newdns:Biopharm.local(det nya namnet på den omdöpta domänen) och sedan kommandot gpfixup med parametrar /oldnb:Biofarmaceutik Och /newnb:Biopharm(det gamla och nya NETBIOS-namnet på din domän). Denna procedur visas nedan:

Ris. 8. Åtgärda GPO

Det finns bara två kommandon kvar att utföra: kommandot " slumpmässigt / rent", som låter dig ta bort alla referenser till gamla domännamn i din Active Directory, samt kommandot " slumpmässigt /slut”, i själva verket frigör Active Directory-skogen från att göra ändringar i dess konfiguration. Du kan se processen för att utföra dessa kommandon i följande illustration:

Ris. 9. Fyll i bytet av Active Directory-domänen

För att ändringarna ska träda i kraft på medlemsservrarna och på slutklienterna måste du starta om deras datorer två gånger. Du måste dock byta namn på domänkontrollanterna manuellt. Som du kan se i följande illustration är mitt domänkontrollantnamn fortfarande detsamma.

Denna procedur är mycket mer komplicerad än att byta namn på en medlemsserver som är en vanlig medlem av en domän. För denna uppgift behöver vi verktyget " NETDOM", som börjar från Windows 2008är del av OS, och för Windows 2003 måste installera" Supportverktyg ".

Gör så här för att byta namn på en domänkontrollant:
1. Se först till att domänens funktionsnivå inte är lägre än Windows 2003 och leta efter behörigheter Domänadministratörer " ("Domänadministratörer ").
2. Öppna en förhöjd kommandotolk och lägg till ett extra namn för den styrenhet som vi ska byta namn på (i vårt exempel SRV-DC1-GAMMEL.TEST.LOKALT byta namn till SRV-DC1.TEST.LOKALT ):

NETDOM datornamn SRV-DC1-OLD.TEST.LOCAL /add:SRV-DC1.TEST.LOCAL


3. Använda redigeraren " ADSIEDIT.msc" se till att namnet läggs till korrekt. I editorn, hitta domänkontrollantobjektet och kontrollera värdet på egenskapen " msDS-AdditionalDnsHostName", som ska vara lika med" SRV-DC1.TEST.LOKALT ".


4. Nu måste du se till att den uppdaterade SPN attribut har replikerats helt till andra domänkontrollanter i skogen. Verktyget kommer att hjälpa oss med detta " READMIN" eller " REPLMON" För Windows 2003.


För att påskynda processen kan replikering tvingas fram i " DSSITE.msc". Klicka bara Högerklicka klicka på anslutningen och välj " Replikera nu".


5. Nu gör vi det nya namnet på domänkontrollanten till primärt:

NETDOM datornamn SRV-DC1-OLD.TEST.LOCAL /makeprimary:SRV-DC1.TEST.LOCAL


6. Vi överbelastar servern.
7. Återigen kontrollerar vi att den uppdaterade SPN attribut och poster i DNS lyckades replikera helt till andra domänkontrollanter och servrar DNS i skogen, och fastighetens värde" msDS-AdditionalDnsHostName" är nu lika med det gamla servernamnet.


När det är akut tidsbrist kan du tvinga fram replikering igen och överbelasta zoner DNS på andra kontroller om de visar det tidigare namnet på vår server.
8. Ta nu bort det gamla kontrollernamnet, som nu är valfritt:

NETDOM datornamn SRV-DC1.TEST.LOCAL /ta bort:SRV-DC1-OLD.TEST.LOCAL


9. Vi tvingar eller väntar på fullständig replikering, och till slut laddar vi om och kontrollerar framåt och bakåt domänzoner DNS för poster med det gamla namnet. Om vi ​​hittar några raderar vi eller korrigerar vid behov med ett nytt namn. Det är också värt att kontrollera värdet på attributet " msDS-AdditionalDnsHostName", som ska vara tom.

I slutet av proceduren, när ovanstående steg är slutförda, kontrollerar vi noggrant loggarna Active Directory på alla domänkontrollanter för fel och användning av " DCDIAG"vi ser till att skogen fungerar korrekt.

Året är 2015, internet har blivit utbrett, varje företag med självrespekt har sin egen hemsida sedan länge. Du behöver inte gå långt - även varje stadssjukhus har sina egna webbresurser. Men ändå har systemadministratörer inte lärt sig hur man skapar normala namn för sina domäner.

Kostnaden för en andranivådomän (till exempel bissquit.com) är lite över 500 rubel per år. Detta är väldigt lite även för vanliga medborgare, som du och jag, och det är bara slantar för företag, desto mer. Jag köpte min domän långt innan idén att starta den här bloggen dök upp. Det är bara bekvämt. Låt oss till och med ta fjärranslutning av rdp - Jag anger namnet på min domän istället för en tråkig ip-adress.

På Internet, som svar på begäran om "bästa praxis för aktiv katalogdomän", har nästan varje webbplats skrivit omfattande rekommendationer för att namnge AD-domäner och förklarat varför det bör göras på det sättet. Låt oss ta en närmare titt på vilka rekommendationer vi pratar om:

  • För att namnge en AD-domän, använd en underdomän till din organisations officiellt registrerade domän.

Du har rätt, bara ett råd. Detta är allt! Man kan prata mycket om detaljerna och små nyanser, men 80-90% av resonemanget kokar ner till ett enda råd, uttryckt ovan. Alla problem kommer från det faktum att en person vet att det är nödvändigt att göra detta, men inte förstår varför det är omöjligt eller det rekommenderas starkt att inte göra det annorlunda. Mer information från och med nu.

1. Varför kan du inte använda interna, externt olösliga namn som .local, .corp, .lan?

Burk. Mer som möjligt. De flesta av dem använder dem. Jag har exempel bland vänner som har 2000+ personer i organisationer och använder .local-domänen. Alla svårigheter börjar om du plötsligt behöver en riktig AD-domän. Detta kan hända när du använder hybridmolninstallationer (Exchange + Office365 är ett utmärkt exempel). “Varför inte bara byta namn på domänen, för med viss version AD är det fullt möjligt?” - du frågar. Ja, i princip är det möjligt, men du kommer att behöva möta svårigheterna med att migrera domänberoende tjänster. Bland dem finns samma Exchange och andra, men här räcker det mer än väl med en Exchange.

2. "OK, vi köper ett riktigt externt namn - my-company.com, vi kommer också att kalla AD-domänen" - inte heller ett alternativ. Det kommer att finnas tillståndsproblem med andra resurser som finns på my-company.com, såsom företagets webbplats. Och dessutom kommer dina DNS-servrar inte att vara auktoritativa för denna domän, även om de kommer att betrakta sig själva som sådana. Detta kommer också att orsaka problem.

Det finns andra överväganden för domännamn, bland dem att skapa en liknande riktig domän men i en annan toppdomän. Men det förefaller mig som att det inte är någon mening med att göra detta, eftersom en del av problemen fortfarande kvarstår, och det finns helt enkelt inga uppenbara fördelar jämfört med att använda domänen corp.my-company.com (namnet tas som ett exempel ).

För den som gillar att göra allt på sitt eget sätt kommer även nyligen problem med certifikat att läggas till, så det är ingen idé att använda interna namn nu.

Frågan om att välja ett domännamn vilar tekniskt sett på raden där du skriver namnet när du skapar AD-domänen och inget mer. Konsekvenserna som fel namnval kommer att medföra kommer dock att orsaka dig många problem i framtiden, och därför är det mycket viktigt att göra allt på ett kvalitativt sätt i planeringsstadiet. Återigen är det bra att läsa artiklar av erfarna administratörer

Igår fick vår studio ett brev från vår vanliga läsare Andrey, med frågan:

Jag tycker om att läsa din blogg, jag lärde mig mycket nyttigt för mig själv, jag ville veta din åsikt om domännamnet Active Directory, många skriver att det ska heta *organisation*.local, och någon skriver att det ska heta samma som domänen.

Låt oss ta en snabb titt på vad som är det bästa namnet att använda när du namnger en domän inom en organisation.

Som praxis visar, kan valet av ett domännamn förvirra även en erfaren systemadministratör. När du först startar verktyget dcpromo domännamnet kommer att genereras automatiskt och slumpmässigt, om domännamnet inte anpassas till nödvändiga regler redan i detta skede kommer det att bli svårare att ändra domännamnet i framtiden. Låt oss titta på alternativen i ordning efter deras popularitet.

1. Domän med namnet example.local

Ledaren för vår hitparad är ett domännamn som slutar på lokal. Det finns andra varianter på detta tema, till exempel testa, firma, fabrik, nn, loc, och så vidare. Nu kommer du inte ens ihåg var sådan kärlek kom ifrån; i alla sina böcker använder Microsoft alltid sitt eget namn på formen contoso.com där vi tydligt kan se format för domännamn. Men i nästan 10 år, domänen .lokal intog en ledande position. Situationen började plana ut med tillkomsten av tjänster som användes i deras arbete SSL-certifikat. Där användningen av domäner "inte bryr sig och så kommer det att göra" blir omöjligt. Se, anta att ditt företag använder internt Exchange-server, som behöver ett ssl-certifikat för att kryptera klientanslutningar. Enligt ditt scenario behöver du ett certifikat för att utföra denna uppgift extern CA, där du måste ange alla namn på servrarna som används för extern anslutning. Det verkar som om en sådan sak, vi skriver ner alla namn på servrarna och ansöker om utfärdande av certifikat, men det finns en sak. Med namnet på en sådan domän du kommer inte att kunna validera, eftersom domänen "bryr sig inte och så kommer den att göra" inte existerar och du kommer att få en mjuk vägran att försöka förklara för en extern certifieringsmyndighet att du behöver lägga in FQDN-namnet för en icke-existerande domän i SAN :

Det är inte möjligt, vi utfärdar endast certifikat för riktiga domännamn.

Men det finns ett problem till. Använda ett domännamn inte ägs av dig i ett domännamn kan leda till katastrofala konsekvenser. Föreställ dig situationen om zonen lokal kommer att vara offentliga. Som en zon com eller sv. Jag tycker inte att det är värt att fortsätta.

2. Domännamnet är detsamma som det externa domännamnet

Andraplatsen i vår hitparad. Trots att ett sådant scenario är mindre populärt har det fortfarande rätt till liv. Förutom det faktum att du inom en snar framtid fortfarande kommer att få en del besvär när du underhåller nätverket, är det inget annat som hotar dig. Huvudproblemet i det här scenariot är att du måste underhålla två DNS-servrar: inre och yttre. Under detta villkor kommer datorer i nätverket att använda den interna DNS-servern för namnupplösning, och datorer utanför företagets omkrets kommer att använda en extern. Anta att din domän har ett stolt namn exempel.com. I DMZ zon du har hemsida namngivna företag exempel.com. I scenariot som beskrivs ovan, datorer lokaliserade inuti organisationer kan inte komma åt det eftersom exempel.com är det för dem domän namn och när du anger den här adressen i webbläsaren kommer de att gå till domänkontrollant. Som jag noterade ovan, förutom besvär, kommer detta att leda till ingenting. Du kan alltid använda kryckor som omdirigerar dig till en extern webbplats, men acceptera att detta inte är ett nödvändigt dubbelarbete, eller använd ett webbplatsnamn som börjar med www eller utanför.

3. Ett ord domännamn

Kanske det mest felaktiga alternativet från ovan. Domäner på en nivå: Domän med en etikettär en domän som endast innehåller en komponent. Tydligen började de användas under NTs dagar, när Microsoft anammade den framgångsrika erfarenheten av Novell. Det hände så att jag till en början var administratör för FreeBSD och en stor flotta av NetWare-servrar från och med version 4.11, och på den tiden använde NetWare Bindery i sitt arbete, vilket bara är namnen domänschema på en nivå, som senare togs över av Microsoft.

bästa praxis

Det är dags att sammanfatta det. Vilket domännamn ska man använda? Endast en tredjenivådomän i den domän du äger. Använd inte andras vackrare domännamn :-). Du kan se ett exempel på en sådan domän nedan.

Vad är en domänkontrollant

Domänkontrollant tillhandahåller centraliserad hantering nätverksenheter, det vill säga domäner. Styrenheten lagrar all information från konton och inställningar för nätverksanvändare. Det här är säkerhetsinställningarna lokal politik och många andra. Detta är en sorts server som har full kontroll över ett specifikt nätverk eller nätverksgrupp. En domänkontrollant är en sorts uppsättning speciell programvara som kör olika Active Directory-tjänster. Regulatorerna kör vissa operativsystem som t.ex windows server 2003. Installationsguiden för Active Drive låter dig skapa domänkontrollanter.

I operationssalen Windows-system NT, som primär server, använder den primära domänkontrollanten. Andra servrar som används används som säkerhetskopieringskontroller. De viktigaste PDC-kontrollerna kan utföra olika uppgifter relaterade till medlemskap i användargrupp, skapa och ändra lösenord, lägga till användare och många andra. Därefter överförs data till ytterligare BDC-styrenheter.

Kan användas som domänkontrollant programvara Samba 4 om Unix-operativsystemet är installerat. Denna programvara stöder även andra operativsystem som Windows 2003, 2008, 2003 R2 och 2008 R2. Vart och ett av operativsystemen kan vid behov utökas beroende på specifika krav och parametrar.

Använda domänkontrollanter

Domänkontrollanter används av många organisationer som är värddatorer anslutna till varandra och till nätverket. Kontrollanter lagrar katalogdata och styr hur användare loggar in, loggar ut och interagerar med varandra.

Organisationer som använder en domänkontrollant måste bestämma hur många domänkontrollanter som ska användas, planera för dataarkivering, fysisk säkerhet, serveruppgraderingar och andra nödvändiga uppgifter.

Om ett företag eller en organisation är litet och det bara använder ett domännätverk, så räcker det med att använda två kontroller som kan ge hög stabilitet, feltolerans och en hög nivå av nätverkstillgänglighet. I nätverk som är uppdelade i en viss mängd platser, på var och en av dem är en styrenhet installerad, vilket gör det möjligt att uppnå nödvändig prestanda och tillförlitlighet. Genom att använda kontroller på varje sida kan användarinloggning göras mycket enklare och snabbare.

Nätverkstrafiken kan optimeras, för att göra detta måste du ställa in tiden för replikeringsuppdateringar när belastningen på nätverket är minimal. Att ställa in replikering kommer att avsevärt förenkla ditt arbete och göra det mer produktivt.

Du kan uppnå maximal prestanda i kontrollenhetens arbete om domänen är en global katalog, vilket gör att du kan fråga efter alla objekt med en viss vikt. Det är dock viktigt att komma ihåg att aktivering av en global katalog resulterar i en betydande ökning av replikeringstrafiken.

Värddomänkontrollanten lämnas bäst oaktiverad om mer än en domänkontrollant används. När du använder en domänkontrollant är det mycket viktigt att ta hand om säkerheten, eftersom den blir ganska tillgänglig för angripare som vill ta den data som behövs för att bedrägeri.

Överväganden för installation av ytterligare domänkontrollanter

För att uppnå högre tillförlitlighet i driften av de nödvändiga nätverkstjänster måste du installera ytterligare domänkontrollanter. Som ett resultat kan betydligt högre stabilitet, tillförlitlighet och driftsäkerhet uppnås. Nätverksprestandan i detta fall kommer att bli mycket högre, vilket är en mycket viktig parameter för organisationer som använder en domänkontrollant.

För att domänkontrollanten ska fungera korrekt måste en del förarbete göras. Det första du ska göra är att kontrollera TCP/IP-inställningarna, de måste vara korrekt inställda för servern. Det viktigaste är att kontrollera DNS-namn för mappningar.

För säkert arbete domänkontrollanten måste använda NTFS-filsystemet, vilket är säkrare än FAT 32-filsystem. NTFS-system, som kommer att innehålla systemvolymen. Åtkomst till DNS-servern från servern krävs också. DNS-tjänst installerad på denna eller en extra server som måste stödja resursposter.

För att korrekt konfigurera en domänkontrollant kan du använda konfigurationsguiden, som låter dig lägga till exekvering av specifika roller. För att göra detta måste du gå till administrationssektionen via kontrollpanelen. Du måste ange en domänkontrollant som serverroll.

Domänkontrollant idag är oumbärlig för nätverk och sajter som används av olika organisationer, institutioner och företag inom alla områden av mänsklig verksamhet. Tack vare honom säkerställs hög produktivitet i arbete och säkerhet, vilket i dator nätverkär av särskild betydelse. Rollen som en domänkontrollant är mycket viktig, eftersom den låter dig hantera domänområden byggda på datornätverk. Varje operativsystem har vissa nyanser relaterade till driften av domänkontrollanter, men principen och dess syfte är desamma överallt, så att hantera inställningarna är inte så svårt som det kan verka i början. Det är dock mycket viktigt att domänkontrollanter konfigureras av experter för att i slutändan uppnå hög prestanda och säkerhet under drift.