ADModify (siehe unseren Überblicksartikel) kann auch Exchange-Attribute im AD bearbeiten. Dieser Artikel gibt ein kurzes Beispiel. Achtung: Die Exchange-Attribute können mit ADModify nur dort bearbeitet werden, wo der ESM installiert ist!
Die Integration von MassStorage Device Treibern in eine Installationsquelle läuft folgendermaßen ab.
Die Erstellung einer bootfähigen CD setze ich voraus. Dieser Step-by-Step Guide beschreibt nur die Änderung der Quellen, da ein Setup auch unattended aus einem Netzwerkshare erfolgen kann.
Benutzer können Dateien löschen, auf die sie keinen Zugriff haben. Das ist das, was als Feature (!) dokumentiert ist, sich aber meist als Riesenproblem äußert. Dann gibt es noch undokumentierte Schwächen, die auch problematisch sind, z. B. können manche Dateien, auf die nur Leserecht
erteilt wurde, verändert werden.
… weiterlesen
Viele Administratoren benutzen gern csvde, da die Ausgangsdateien sich sehr schön mit einer Tabellenkalkulation wie Excel erzeugen lassen. Hier können insbesondere mittels verknüpfter Tabelleninhalte umfangreiche Userdaten einfach gepflegt werden. Problematisch dabei ist die Zeilenbegrenzung, die dabei schnell erreicht wird. Ich persönlich ziehe daher ldifde vor. Dieses Tool ist ebenso auf jedem Windows Domaincontroller zu finden und arbeitet nicht spalten-, sondern zeilenorientiert.
Es gibt seit Windows 2000 ein mitgeliefertes Tool zur Bearbeitung von AD-Daten von der Kommandozeile aus: ldifde.exe. Es arbeitet mit Datensätzen, die zeilenweise eingelesen werden. Datensätze sind durch Leerzeilen voneinander getrennt. Diese werden via LDAP in das Active Directory geparsed.
Um erweiterte Wartungsarbeiten am Active Directory wie Offlinedefragmentierung oder Wiederherstellung durchzuführen, muss dieses im Wiederherstellungsmodus gebootet werden. Grundsätzlich muss man dazu beim Booten die F8 Taste drücken und den Modus auswählen. Mit Windows 2003 kann das auch von entfernten Standorten durchgeführt werden. Dies erleichtert die Prozedur im Wiederherstellungsfall erheblich, weil man nicht direkt am Server stehen muss.
Für die meisten Drucker gibt es auf der Windows Server 2003-CD keinen entsprechenden Druckertreiber mehr für Windows NT 4.0. Somit muss man bei der Anbindung von NT-Clients entweder mit lokal installierten Treibern auf den Clients arbeiten oder man benötigt einen Treiber vom Hersteller.</ />
Microsoft empfiehlt den Einsatz von Point&Print-Treibern, die man für HP-Drucker z.B. auf der HP Website findet: http://www.hp.com/pond/pnp/index.html … weiterlesen
Die Betriebsmasterrollen (FSMO) sollten, wenn möglich, nur dann auf einen anderen DC übertragen werden, wenn sowohl der momentane Rolleninhaber als auch der neu zu belegende Server online sind. Sollte der ursprüngliche Rolleninhaber allerdings ausgefallen sein, so geht dies natürlich nicht. In diesem Falle sollte abgewogen werden:
Der erste Gedanke zielt an dieser Stelle meist in Richtung eines Cluster-Systems. Nachteile: Kosten und Komplexität. Wem das zu aufwändig ist, der lässt meist zwei DHCP-Server parallel laufen. Nachteil: Man kann keine Reservierungen vornehmen. Die Lösung, die hier vorgestellt werden wird, funktioniert als Standby-Server mit manueller Umschaltung.
Dazu nutzt man einen kleinen Batch, der mittels Task Scheduler auf dem Primär-DHCP-Server (Server 1) die DHCP-Datenbank via netsh auf ein Share des Backup-DHCP-Servers (Server 2) dumped. Danach 'leert' es den Backup-DHCP-Server und importiert mittels netsh den Dump vo Primär-Server auf den Backup-Server. Damit kann man zum Beispiel stündlich alle Konfigurationsinformationen und die aktuellen DHCP-Leases auf dem zweiten Server automatisiert kopieren.
Zusätzlich autorisiert man den DHCP-Server auf Server 2 nicht im AD. Dadurch läuft man nicht Gefahr, dass er im laufenden Betrieb anfängt, IPs zu verteilen. Im Disasterfall muß nur der Backup-DHCP (Server 2) im AD authorisiert und der primäre (Server 1) gleich deaktiviert sowie der Import-Job abgestellt werden.
Achtung: Der folgende Beispielcode funktioniert nur unter Windows Server 2003. In der netsh-Version von Windows 2000 fehlt die Option "export", die hier genutzt wird. Mit den Informationen aus http://support.microsoft.com/kb/325473/en-us sollte es aber möglich sein, ein analoges Verfahren aufzubauen.
In diesem Beispiel ist der IP-Bereich 172.16.0.0 DHCP-Scope, bei mehreren Scopes müssen alle Scopes in der dhcpimport.cmd analog gelöscht werden. Die erste Datei muß auf dem Server 2 im Ordner c:backup mit dem Namen dhcpimport.cmd hinterlegt werden:
REM dhcpimport.cmd
REM Abzulegen in c:\backup auf Server 2
@echo off
netsh dhcp server delete optionvalue 6
netsh dhcp server delete optionvalue 15
netsh dhcp server delete optionvalue 44
netsh dhcp server delete optionvalue 46
netsh dhcp server delete optionvalue 66
netsh dhcp server delete optionvalue 67
netsh dhcp server delete optionvalue 81
netsh dhcp server delete optionvalue 135
netsh dhcp server delete scope 172.16.0.0 DHCPFULLFORCE
netsh dhcp server import c:\backup\dhcpdump.txt all
Der Export wird als geplanter Task auf Server1 erstellt. Sinnvoll dafür ist die Verwendung eines eigenen Dienstkontos, damit bei Kennwortänderungen das Update nicht versehentlich sabotiert wird. Das eingesetzte Konto muss auf dem Zielserver über Administratorrechte verfügen, ist also mit einem sehr starken kennwort zu schützen. Das folgende Kommando muss dabei in einer Zeile als Job eingetragen werden:
cmd /c netsh dhcp server export \\server2\c$\backup\dhcpdump.txt all && psexec \\server2 c:\backup\dhcpimport.cmd
Das dafür notwendige Tools psexec.exe ist Bestandteil der pstools und kann als Freeware von sysinternals.com downgeloaded werden. Entpacken Sie das Tool am besten in den Windows-Ordner %WINDIR%.
Es ist erlaubt, unter den Bedingungen der GNU Free Documentation License dieses Dokument zu kopieren, zu verteilen und/oder zu verändern.
Wenn man sich mit Performance-Tuning und Server Scaling beschäftigt, dann stößt man früher oder später an die sogenannte 4 GB-Grenze. Das klassische Windows ist ein 32 Bit-System und damit lassen sich grundsätzlich maximal 4 GB Hauptspeicher sinnvoll nutzen. Überraschend für viele ist allerdings die Tatsache, dass eine Hauptspeicherausstattung von >3GB für herkömmliche Terminal Server nicht sinnvoll ist. Woher kommt diese Grenze?
Kategorie: 
Translate EN