Blog Home  Home Feed your aggregator (RSS 2.0)  
LDAP://Yusufs.Directory.Blog/ - Friday, September 08, 2006
Wieviele Sprachen sprechen Sie? Ich spreche bloß eine: LDAP!
 
 Friday, September 08, 2006

Prinzipiell ist es möglich, die IP-Adresse eines Domänencontrollers (DC) zu ändern.

 

Allerdings gibt es ein paar Grundregeln, die zu beachten wären:

  1. Die IP-Adresse des DCs ist den Namensservern WINS und DNS bekannt
    bzw. eingetragen und steht ebenfalls im lokalen NetBIOS- und DNS-Cache eines jeden Mitgliedsservers sowie Clients drin.
    Deshalb ist es empfehlenswert, die Änderung der IP-Adresse nur in einer "ruhigen Minute" zu erledigen,
    idealerweise wenn die Clients nicht online sind.

  2. Nach der Änderung der IP-Adresse, sollte in den WINS- und DNS-Servern, der alte IP-Eintrag des DCs gelöscht und überprüft werden,
    ob sich der DC mit der neuen IP dort eingetragen hat. Dieses kann man durch die Befehle mit "NBTSTAT -RR" (für WINS) und "IPCONFIG /Registerdns" (für DNS)
    manuell anstoßen. Die DNS-Einträge aus der "_msdcs-Zone" lassen sich mit dem folgenden NLTEST-Befehl entfernen:
    Nltest /DSDEREGDNS:DC01.Domäne.TLD

  3. Falls der DC das DNS installiert hat, gilt es zu kontrollieren, ob von einer übergeordneten DNS-Zone eine Zonen Delegierung auf diesen
    DC/DNS-Server existiert. Wenn dies der Fall ist, so gilt es die IP-Adresse für diese Delegierung zu aktualisieren. 


  4. Anschließend gilt es, auf allen anderen Servern (Memberserver und DCs) manuell die lokalen Namenscaches zu löschen,
    damit diese Server erneut die Namensserver abfragen um die neue IP-Adresse des geänderten DCs zu erhalten:
    "NBTSTAT -R" für den NetBIOS - Namenscache (WINS).
    Achtung auf die Gross- und Kleinschreibung des Schalters !  
    "IPCONFIG /Flushdns" zum löschen des DNS-Namenscaches. Bei Arbeitsplätzen die rund um die Uhr laufen müssen, wäre dies auch notwendig.

Das ganze kann man sich auch ersparen, wenn die Systeme neu gestartet werden, denn dabei werden die lokalen Caches ebenfalls gelöscht.

Nach der IP-Adressänderung des DCs kann es kurzzeitig vorkommen, dass diverse Fehlermeldungen in den Ereignisprotokollen der Systeme
temporär auftreten, da die Systeme es nicht sofort "merken", dass sich die IP-Information des DCs geändert hat.

 

Dieses kann man aber vernachlässigen, denn das regelt sich von alleine in dem Moment, in dem die neue IP-Adresse überall bekannt ist.

Es wäre ebenfalls die gleiche Vorgehensweise, wenn ein Microsoft Exchange- oder Terminalserver darauf installiert wäre.
Ich möchte aber daran erinnern, dass Microsoft es nicht empfiehlt einen Exchange Server auf einem DC zu installieren.

Zum Schluss gilt es noch zu überprüfen, ob nicht die alte IP-Adresse vielleicht irgendwo manuell in die lokale Lmhosts- bzw. Hosts-Datei
eines Systems eingetragen wurde. Wenn dies der Fall sein sollte, muss das natürlich auch geändert werden.

 

 

Weitere Informationen:

The Internet Protocol (TCP/IP) Properties dialog box displays the default IP address settings after you manually configure a static IP address in Windows 2000 Server or in Windows Server 2003

Change the static IP address of a domain controller

 

Friday, September 08, 2006 3:04:13 PM (W. Europe Standard Time, UTC+01:00)  #      Administration | Networking  | 
 Thursday, September 07, 2006

Irgendwann muss auch der letzte Mohikaner gehen bzw. ausgetauscht werden. ;-)

Was ist alles zu beachten, wenn man den ersten und einzigsten Domänencontroller austauschen möchte/muss:

1. Zu allererst sollte ein aktuelles Backup vom System State sowie den Daten existieren.


2. In den TCP/IP Einstellungen des neuen Servers trägt man als ersten und einzigsten DNS-Server den bereits bestehenden DC ein. Erst wenn die AD-Replikation (bei einer AD-integrierten Forward Lookup Zone, kurz FLZ) nach dem Heraufstufen zwischen den beiden DCs stattgefunden hat, trägt man den neuen DC sich selbst als ersten DNS-Server in seinen TCP/IP-Einstellungen
ein bzw. Welcher DNS-Server sollte eingetragen werden ?.


3. Der neue Server ist als zusätzlicher DC der Domäne hinzuzufügen. Außerdem muss das DNS entweder vor oder nach dem Heraufstufen des DCs installiert werden. Das DNS muss aber lediglich installiert und nicht noch zusätzlich konfiguriert werden, da das DNS bereits auf dem ersten DC konfiguriert ist. Es ist darauf zu achten, dass auf dem ersten DC die FLZ AD-integriert gespeichert ist, denn nur dann werden die DNS-Informationen automatisch dank der AD-Replikation auf den neuen DC repliziert. Des Weiteren ist es nur bei einer AD-integrierten FLZ möglich, die Option "Nur sichere" Updates zuzulassen (was anzuraten ist).
Einen zusätzlichen DC in die Domäne hinzufügen


4. Falls der neue Server, der erste Windows Server 2003 R2 Domänencontroller werden soll, so muss vorher das ADPREP von der zweiten R2-CD ausgeführt
werden. Für weitere Details siehe: Schemaupdate beim Windows Server 2003 R2

Ist der neue Server der erste Windows Server 2008 DC, so muss das Schema wie folgt aktualisiert werden:
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Wenn es sich dagegen um den ersten Windows Server 2008 R2 DC handelt, so ist das Schema folgendermaßen zu aktualisieren:
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen


5. Danach müssen die 5 FSMO Rollen, samt den Infrastrukturmasterrollen der einzelnen Anwendungsverzeichnispartitionen (ab Windows Server 2003) auf den neuen DC verschoben werden:

- Schemamaster
- Domänennamenmaster
- RID-Master
- PDC-Emulator
- Infrastrukturmaster

Die FSMO-Rollen verschieben


6. Zusätzlich sollte der neue DC zum Global Catalog-Server (GC) deklariert werden. Dazu ist im Snap-In Active Directory-Standorte und -Dienste in den Eigenschaften
des NTDS-Settings Objekt, das sich unterhalb des neuen DC-Objekts befindet, der Haken bei "Globaler Katalog" zu setzen.
Globaler Katalog (Global Catalog - GC)


7. Bevor der alte DC mit DCPROMO aus der Domäne entfernt wird,
gilt es noch das EFS-Zertifikat zu sichern:
Was muss ich tun, um den ersten DC zu deinstallieren?


8. Falls der DC auch ein DHCP-Server wäre, ist es möglich, die DHCP-Datenbank vom "alten" DC zu exportieren und auf dem neuen zu importieren:
How to move a DHCP database from a computer that is running Windows NT Server 4.0, Windows 2000, or Windows Server 2003 to a computer that is running Windows Server 2003
Die DHCP-Konfiguration samt den Leases, kann man mit folgendem Befehl (unter Windows Server 2003) sichern:
"netsh dhcp server export C:\Dhcp.txt all".

Um die exportierte Datei einzuspielen, gilt es folgenden Befehl einzugeben:
"netsh dhcp server import C:\Dhcp.txt all".

Wird der DHCP-Server von einem Windows Server 2003 auf Windows Server 2008 verschoben, so gilt es den folgenden Artikel durchzuführen:
How to move a DHCP database from a computer that is running Windows Server 2003 to Windows Server 2008


9. Ein WINS-Server sollte auch heute noch in einer Domäne existieren.
Der WINS erleichtert einem das tägliche Leben und kostet nicht viel Arbeit:
Wie sollte WINS konfiguriert werden?


10. Falls der DC auch Freigaben zur Verfügung stellt, können diese ebenfalls exportiert und auf dem neuen DC importiert werden:
Start - Ausführen - Regedit - HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
Anschließend ist der Serverdienst neu zu starten.

... oder man benutzt das File Server Migration Toolkit (FSMT).
Mit diesem Tool werden die Daten samt Berechtigungen kopiert und die Freigaben automatisch wieder erstellt:
http://www.microsoft.com/downloads/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&DisplayLang=en

Das Whitepaper zum FSMT kann hier heruntergeladen werden.


11. Drucker können mit dem Print Migrator kopiert/verschoben werden:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9B9F2925-CBC9-44DA-B2C9-FFDBC46B0B17&displaylang=en


12. Danach gilt es noch die Anmeldeskripte anzupassen.



Die Daten können z.B. mit NTBACKUP gesichert und auf dem neuen DC wiederhergestellt werden. 
ROBOCOPY oder XCOPY /O würden ebenfalls funktionieren, sowie diverse andere Programme/Tools.
Komfortabel lassen sich die Dateien allerdings mit dem File Server Migration Toolkit (FSMT) oder RichCopy auf den neuen Server kopieren.
Mit beiden Tools bleiben die Berechtigungen erhalten.

Wenn alle Daten sowie Dienste vom "alten" DC auf den neuen DC übernommen wurden, muss der Domänencontroller mit DCPROMO
aus dem Active Directory entfernt werden, damit die DC-Informationen ordnungsgemäß aus den Metadaten des AD entfernt werden.
Entfernt man jedoch den DC nicht mit DCPROMO aus der Domäne, sondern schaltet diesen einfach aus und installiert z.B. das Betriebssystem neu, so müssen die DC-Informationen in mühseliger Handarbeit aus den Metadaten des AD entfernt werden. 
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen

Falls man jetzt noch möchte, dass der neue DC die IP-Adresse sowie den Computernamen des alten DCs erhält,
so kann man beides folgendermaßen durchführen: Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen?
Die IP - Adresse eines Domänencontrollers ändern
Anschließend ist ein Neustart des Servers fällig.


Es sei an dieser Stelle angemerkt das es ratsam ist in jeder Domäne mindestens zwei DCs zu installieren, um die Ausfallsicherheit im Falle eines DC-Crashs zu gewährleisten!


Eine weitere Alternative zeigt dieser Artikel:
How to move a Windows installation to different hardware


Weitere Informationen:
Über Backup und Restore
Migrating Windows Small Business Server 2003 to New Hardware
How to replace single domain controller in domain with a single domain controller?

Thursday, September 07, 2006 11:54:36 AM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Installation  | 
 Monday, September 04, 2006

Die aktuelle Ausgabe der Zeitschrift IT-Administrator 09/2006 hat das Schwerpunkt Storage.

 

Dort beschreibe ich den in Windows Server 2003 R2 hinzugekommenen Ressourcenmanager für Dateiserver (File Server Ressource Manager, FSRM). Mit dem FSRM ist es nun möglich, dass man Dateien wie MP3, MPG oder AVI oder was auch immer auf dem Server/SAN/NAS/DAS verbieten kann zu speichern.

 

Mit dieser nützlichen Erweiterung hat der Administrator nun die Möglichkeit, seinen Storage besser zu verwalten und zu kontrollieren, damit der Datenwuchs nicht mit unnötigen Dateien ins unermessliche wächst, was schliesslich ebenfalls per Backup gesichert werden muss.

 

Das ganze könnt Ihr auf den Seiten 39 bis 42 nachlesen.

http://www.it-administrator.de/artikel/16653.html

Ich wünsche viel Spass beim lesen.

 

 Yusuf

Monday, September 04, 2006 5:46:48 PM (W. Europe Standard Time, UTC+01:00)  #      Meine Artikel  | 
 Sunday, September 03, 2006

Microsoft wird mit dem Longhorn Server sowie Windows Vista, eine neue Kontrollmöglichkeit, für den Administrator auf den Markt bringen.
Bisher hatte der Administrator anhand der IP oder Benutzerinformation die Möglichkeit zu kontrollieren, wie und ob überhaupt ein Client Zugriff auf das Netzwerk erhält. Mit NAP ist es dem Administrator nun möglich, anhand seiner definierten Richtlinien wie z.B. ist der Firmen-Virenscanner installiert, hat er die aktuellste Virendefinition installiert, ist die Desktop - Firewall installiert oder ist der Client mit den aktuellen Sicherheitspatches installiert usw., zu kontrollieren, ob dieser Zugriff auf das Netzwerk erhält oder falls er eine Vorgabe nicht erfüllt, in einen quarantäne Bereich des Netzwerks verschoben wird, damit die nicht erfüllte Richtlinie - nachbearbeitet werden kann und somit der Client dann den Zugriff auf das Netzwerk erhält.  
 
In meinem aktuellen Artikel könnt Ihr alles weitere lesen:
NAP - Network Access Protection

Sunday, September 03, 2006 5:45:13 PM (W. Europe Standard Time, UTC+01:00)  #      Meine Artikel  | 
 Wednesday, August 23, 2006

Man könnte aus "statistischen" Gründen auf die Idee kommen, die Anmeldung der Anwender zu protokollieren.

 

Gleich vorweg: Dieses ist Mitbestimmungspflichtig und muss vom Betriebsrat genehmigt werden! 

 

Wenn man die Protokollierung über eine GPO regeln möchte, gilt es z.B. in der "Default Domain Controller Policy" die Überwachung von Anmeldungen zu aktivieren. Der Nachteil ist zum einen, dass einzelne Benutzer davon nicht ausgenommen werden können und zum anderen,
dass zum Auswerten alle Sicherheitsprotokolle der DCs durchsucht werden muss. Dieses kann man sich natürlich erleichtern.

 

Im folgenden Pfad kann man die Protokollierung von Anmeldungen aktivieren:  
Computerkonfiguration - Windows Einstellungen - Sicherheitseinstellungen - Lokale Richtlinien -  Überwachungsrichtlinien - <Anmeldeereignisse überwachen>

Dann kontrolliert man die Domänencontroller nach diesen Einträgen:
 
Ereignisquelle: Security
Kategorie: Kontoanmeldung
Ereigniskennung: 675 (diese Event-ID wird bei einer fehlgeschlagenen Anmeldung protokolliert, siehe Audit Account Logon Events)
In der Beschreibung der Eventeinträge findet sich dann die Client-IP.

Mit den Tools EventComb und BLAT, lassen sich die Einträge zumailen:
Verwalten von Ereignisprotokollen mit EventComb MT
Happy mailing Blat online

Das ganze lässt sich natürlich auch per Logonskript und Logoffskript regeln.  Hierbei kann man sogar die Abmeldung mitloggen:
Logon.cmd: echo logon %username% %computername% %date% %time% >> \\Server\Freigabe\Logon.txt
Logoff.cmd: echo logoff %username% %computername% %date% %time% >> \\Server\Freigabe\Logoff.txt

Anschließend gilt es die erstellten Batch-Dateien in die entsprechende Richtlinie zu verknüpfen:
Benutzerkonfiguration - Windows-Einstellungen - Skripts (Anmelden/Abmelden)



Weitere Informationen zu diesem Thema:
How to track users logon/logoff
Troubleshooting Kerberos Errors
Log Parser 2.2

Account Lockout and Management Tools

HOW TO: Audit Active Directory Objects in Windows 2000

 

Wednesday, August 23, 2006 3:19:09 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory  | 
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: