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

Wie kann man den Namen der LAN-Verbindung umbenennen ?
Z.B. wenn man sich als Administrator anmeldet und mit einem rechts-klick auf das Icon der LAN-Verbindung klickt und den Punkt "umbennen" auswählt. Dazu braucht mal allerdings Admin-Rechte.
 
Geht das auch als ein normaler Benutzer ?
Die Antwort lautet - Ja es geht. Dazu gibt es schliesslich die Gruppenrichtlinien.
Benutzerkonfiguration - Administrative Vorlagen - Netzwerk - Netzwerkverbindungen - "Umbennen von LAN-Verbindungen zulassen".
Mit dieser aktivierten Policy kann der Benutzer die Verbindung umbenennen.
 
Gibt es auch eine Script basierte Möglichkeit ?
Auch hier lautet die Antwort - Ja, die gibt es.
Das Zauberwort lautet: NETSH
"netsh interface set interface /?"
Damit kann mit der Option "newname" und einer zusätzlichen Option der Name vergeben werden.
Bei der weiteren Option gilt es herauszufinden, welche am sinnvollsten wäre.
 
 
Yusuf

Sichern mit Images ist bei vielen sehr gern gesehen, da man sich damit "scheinbar" gegen einen Crash schützen kann (oder vor einer Änderung).

Was bei einem Client evtl. noch zutrifft, trifft bei einem DC, Exchange oder SQL ... etc. schon gar nicht zu.

Daher mein Appell an alle:

Bitte lasst die Finger von Images auf DCs und Systemen die mit transaktionalen Datenbanken arbeiten.

Warum kann man DCs nicht imagen?

Weil es sich bei der Active Directory-Datenbank um ein verteiltes Datenbanksystem handelt!

Nur bei einer Onlinesicherung, kann die Konsistenz der Datenbanken geprüft werden. Mit Images
sichert man womöglich wochenlang eine defekte Datenbank mit und steht im Disasterfall dann ohne Backup da.

Würde man diese aber online sichern, so würde das System die Inkonsistenz im Form einer Warnung/Fehlermeldung melden.

Was wäre zum Beispiel, wenn auf der Festplatte ein Bad Sector/Block existieren würde?

Eine Exchange oder SQL Datenbank kann ziemlich groß werden, daher ist es möglich, dass der Bad Block damit die Datenbank inkonsistent werden lässt.

Was bei einem Offline-Image nicht auffällt, würde stattdessen bei einer Online-Sicherung sehr wohl auffallen.

Windows bemerkt aufgrund der Differenz zwischen den während der Sicherung kalkulierten Prüfsummen und den beim ursprünglichen Schreiben kalkulierten Prüfsummen, daß hier ein Datenverlust seit der letzten erfolgreichen Onlinesicherung eingetreten ist.

Wird das Image online erstellt, dramatisiert sich das ganze noch mehr.

Was ist zum Beispiel, wenn eine Datei sich über Eintausend Sektoren verteilt und das Imaging-Programm sichert von Sektor 1 bis 1000.

Es ist gerade bei Sektor 250, da wird die Datei erneut im laufenden Betrieb beschrieben.

Das Imaging-Programm bekommt davon nichts mit. Somit wird dann Sektor 1-250 von der alten Version und 251 bis 1000 von der neuen Version ins Image geschrieben.

Dann kommt noch der Aspekt der Computerkontokennwörter hinzu.

Denn unter Windows NT wird standardmäßig das Computerkontokennwort alle 7 Tage und unter Windows 2000/XP/Vista alle 30 Tage geändert.
Wird nun ein älteres Image zurückgesichert, können sich die Clients nicht mehr an der Domäne anmelden. Denn bei der Erstellung

des Server-Images werden natürlich auch die Computerkontokennwörter mit gesichert.

Hier ist ein schöner Artikel, den sich jeder mal zu Herzen nehmen sollte (Stichwort: USN-Rollback):

Warum Images nicht als Datensicherung taugen

Dieser sollte auch nicht fehlen:

http://www.msexchangefaq.de/verschiedenes/imagebackup.htm

Ein USN-Rollback unter Windows 2000

Ein USN-Rollback unter Windows 2003

Weitere Informationen:
Zwei wichtige IDs eines DCs: DC GUID und InvocationId

Wenn man Probleme mit den Standard-Gruppenrichtlinien hat (unter Windows Server 2003), kann man einiges mit dem Befehl "DCGPOFIX" wieder reparieren.

Mit diesem Befehl werden die beiden GPOs "Default Domain Policy" sowie "Default Domain Controllers Policy" in ihren Ursprungszustand versetzt, sprich, in die "Werkseinstellung". Genauer, DCGPOFIX setzt die Berechtigungen innerhalb des AD zurück.

Existiert ein Exchange im Netzwerk, kann es (oder wird es) nach ausführen von DCGPOFIX Probleme mit Exchange geben.

Daher ist es notwendig das Exchangesetup mit /DOMAINPREP nach DCGPOFIX erneut aufzurufen.

Siehe dazu folgenden Artikel:

Führt man den Befehl auf einem Windows Server 2003 R2 Domänencontroller aus, kommt es zu folgender Fehlermeldung:

Stattdessen muss DCGPOFIX mit dem Parameter "ignoreschema" ausgeführt werden: dcgpofix.exe /ignoreschema.


Error message when you use the Dcgpofix.exe command-line tool in a Windows Server 2003 R2-based domain: "Active Directory schema version for this domain, and the version supported by this tool do not match"

Wenn man einen DNS-Server installiert, richtet man überlicherweise nach der Installation seine DNS-Zonen ein.

Natürlich nur, wenn es kein "only Cache DNS-Server" sein soll.

Klickt man mit rechts auf den Server im DNS Snap-In, kann man z.B. die Option "Neue Zone..." auswählen.

Danach wird man vom Assistenten gefragt, ob man eine Forward Lookup Zone oder eine Reverse Lookup Zone einrichten möchte.

Das ganze geht natürlich auch gezielter, in dem man direkt (mit rechts) auf die Container "Forward-Lookupzonen" um eine FLZ bzw. auf "Reverse-Lookupzonen" um eine RLZ einzurichten. 

Somit muss man zwei Wege gehen, um eine FLZ sowie RLZ für "eine" Zone einzurichten.

Das ganze geht auch in einem Vorgang.

Klickt man mit rechts auf den DNS-Server (im DNS-Snap-In) und wählt die Option "DNS-Server konfigurieren..." aus, kann man eine FLZ sowie RLZ gleichzeitig einrichten.