Ein Antivirusprogramm (Virenscanner) ist dafür da, um das System vor Schädlingen wie es Viren, Würmer und Trojanische Pferde darstellen, zu schützen.
Der Virenscanner spürt diese auf und löscht sie gegebenfalls.
Einen vollständigen Schutz vor Malware bietet ein Virenscanner hingegen nicht.

So hilfreich wie ein Virenscanner auch sein kann, so problematisch könnte der Echtzeitscanner (On-Access) werden.
Dieser agiert im Hintergrund als Systemdienst und scannt im Hintergrund alle Dateien, Programme und den Arbeitsspeicher.
Genau da liegt aber das Problem, denn der Virenscanner greift tief in das System ein und scannt auch Applikationen, die besser davor bewahrt wären.
Datenbanken wie sie z.B. auf einem Domänencontroller (NTDS.DIT) oder Exchange-Server existieren, können bei einem Echtzeitscan einen Schaden bekommen.

Damit dieses nicht passiert, bieten die meisten Virenscanner die Möglichkeit, diese Dateien in eine Art Ausschlussliste aufzunehmen.
Somit werden  die dort eingetragenen Dateien nicht vom Echtzeitscan überwacht.

Auf einem Domänencontroller sollten die Dateien die standardmäßig im Verzeichnis „%systemroot%\ntds“ gespeichert sind, ausgeschlossen werden.
Welche Dateien genau davon betroffen sind, kann man aus diesem Artikel entnehmen:
Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows

Die Dateien, die auf einem Exchange-Server vom Echtzeitscan verschont werden sollten, kann man hier entnehmen:
Recommendations for troubleshooting an Exchange Server computer with antivirus software installed
Exchange and antivirus software

Welche Virenscanner mit dem File Replication Service kompatibel sind, werden im folgenden Artikel aufgelistet:
Antivirus, backup, and disk optimization programs that are compatible with the File Replication Service

Wenn der DHCP-Server nicht startet, könnte es ebenfalls ein Indiz dafür sein, dass der Virenscanner die DHCP-Datenbank überwacht.
Dort sollte das Verzeichnis „%systemroot%\System32\DHCP“ vom Echtzeitscan verschont bleiben.
The DHCP service does not start when you start a Windows Server 2003-based computer

Die nachfolgende Beschreibung von NETDIAG erfolgt am Beispiel eines Windows Server 2003 R2.

Für die unterschiedlichen Windows Server Versionen gibt es spezifische Versionen von NETDIAG.

Die beschriebenen Ausgaben und Schalter von NETDIAG gelten aber auch für andere Server Versionen.

Standorte im Sinne des Active Directorys sind eine physikalische Komponente des Active Directorys.

Diese zu erstellen gehört zu einem sauberen Design einer Active Directory-Domäne dazu, falls Domänencontroller auch
in Aussenstellen platziert sind und z.B. die Notwendigkeit der Einflussnahme in Bezug auf die AD-Replikation besteht.

Ein AD-Standort kann dabei durchaus mehrere Domänen enthalten und eine einzige Domäne kann mehreren AD-Standorten angehören.

Durch das Erstellen von AD-Standorten wird die standortübergreifende (Inter-Site) Replikation planbar und der Verkehr auf den WAN-Verbindungen wird entlastet.

Mehr Informationen über Standorte, erhält man im folgenden Artikel:

Active Directory-Replikation

http://www.faq-o-matic.net/2006/04/26/active-directory-replikation/

Wie findet ein Client einen Domänencontroller an seinem Standort?

Wie so oft, spielt auch dabei die DNS-Namensauflösung eine große Rolle.

Die Voraussetzungen damit ein Client einen lokalen DC nutzt sind folgende:

• Im Snap-In "Active Directory-Standorte und -Dienste" müssen entsprechende Standorte erstellt sein
  
  
• Diesen Standorten muss das entsprechende IP-Subnetz bzw. Subnetze zugeordnet sein
  
  
• Die Server-Icons der jeweiligen Domänencontroller müssen sich in ihrem Active Directory Standort befinden.
  Falls es nicht der Fall ist, müssen diese dort an ihren richtigen Standort verschoben werden.
  
  Hinweis: Wenn ein DC an einen anderen Standort verschoben wurde, ist zwingend das DNS zu bereinigen.
  Dazu sind die SRV-Einträge des DCs, aus dem Pfad _tcp.<Name des Standorts>._sites.dc._msdcs.Domäne
  vom alten Standort zu entfernen.
  
  Siehe auch:
  Einen Domänencontroller an einen anderen Standort verschieben

Die Vorgehensweise wie ein Client einen DC findet, ist wie folgt:

• Der Client fragt im DNS nach, welche DCs es gibt.
  
  
• Falls der Client noch keine Standortinformationen hat, erhält er bei dem ersten Kontakt mit einem Domänencontroller
  von diesem die richtigen Informationen übermittelt, zu welchem Standort der Client gehört. Wenn ein Client dann erneut startet,
  versucht er über das DNS immer zuerst einen DC zu finden, der sich an seinem Standort befindet.
  
  
• Er erhält eine Liste aus der DNS-Antwort und geht diese durch, um einen DC zu finden der funktioniert und auch online ist.
  Dabei nimmt er bevorzugt einen DC aus seinem Standort. Die DNS-Abfrage die der Client in diesem Moment stellt, wäre: _ldap._tcp.<Standort>._sites.dc._msdcs.<Domäne>.
  
  
• Der Client setzt dann in seiner Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 
  den Eintrag DynamicSiteName mit dem Standort, an dem er sich befindet.
  
  
• Erst wenn der Client bei dieser Anfrage von einem DC aus seinem Standort keine Antwort erhält (wenn z.B. kein
  Domänencontroller an seinem Standort existiert) oder er noch keine Standortinformationen hat (z.B. nach einer Neuinstallation),
  fragt er mit einer zweiten Anfrage nach einem DC diesmal aus seiner Domäne nach. Die Abfrage lautet:
  _ldap._tcp.dc._msdcs.<Domäne>.
  
  Spätestens bei dieser Abfrage erhält der Client einen DC mitgeteilt.

Auf der Gegenseite geht der DC der die Anfrage eines Clients erhält wie folgt vor:

• Der Domänencontroller reicht die Clientanfrage an seinen NETLOGON-Prozess durch, der dann die Client-IP in seiner
  Subnet to Site Mapping Table nachsieht und dann das treffende Standort-Objekt heraussucht.
  
  
• Der Netlogon-Prozess des DCs übergibt an den DC die folgenden Infos:
  
  1. Den Namen des Standorts, in der sich der befragte Domänencontroller befindet.
  2. Den Standortnamen, in dem sich der Client befindet.
  3. Ein Flag das angezeigt wird, wenn sich der angefragte DC im gleichen Standort befindet (Bit gesetzt)
  oder ob der DC ausserhalb des Standortes ist (Bit nicht gesetzt).

Diese Informationen werden dann an den Client gesendet, der sich nun die Informationen wie folgt anschaut:

• Wenn sich der Domänencontroller an dem gleichen (oder nächstgelegenen) Standort befindet (gesetztes Bit),
  nimmt der Client bevorzugt diesen DC.
  
  
• Wenn sich kein DC an dem Standort des Clients befindet, entscheidet das Design in der
  MMC "Active Directory-Standorte und -Dienste", an welchem DC sich der Client authentifiziert.
  Der Client verwendet einen Domänencontroller der am nächsten zu seinem Standort ist.
  Dabei ist z.B. die Einstellung der Verbindungskosten entscheidend.
  
  
• Nachdem der Client einen DC ermittelt hat, wird dieser Eintrag des DCs zwischengespeichert.
  Falls sich der DC nicht an dem Standort des Clients oder an einem nicht günstigen Standort befinden sollte (Verbindungskosten),
  leert der Client nach 15 Minuten den Zwischenspeicher und verwirft somit den zwischengespeicherten DC.
  Der Client versucht dann erneut einen nächstgelegenen DC, idealerweise an seinem eigenen Standort zu finden.

Prinzipiell könnte man den Client zwingen, sich an einem vorgegebenen Standort zu authentifizieren.

Dazu muss im Registry-Pfad HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

der Eintrag SiteName erzeugt und als Wert der entsprechende Standort eingetragen werden.
Das wiederum hat aber den Nachteil, dass wenn der Client an einen anderen Standort verschoben werden sollte,

er sich versucht an seinem eingetragenen Standort zu authentifizieren.

Das führt dann zu einem langsamen Anmeldeverhalten.

Des Weiteren wird bei den Abfragen auch ein Auswahlverfahren angewendet.

Alle Domänencontroller sind, samt ihren SRV-Records, im DNS eingetragen und die jeweiligen Einträge enthalten eine Gewichtung sowie Priorität.

Der Domänencontroller, der mit seiner niedrigsten Zahl im Feld Priorität eingetragen ist (umso niedriger die Zahl, desto höher ist die Priorität),

wird vom Client als bevorzugter Domänencontroller genutzt. Existieren mehrere Domänencontroller mit der gleichen Priorität, entscheidet die Gewichtung.

Dabei gilt, je höher die Zahl (zwischen 1 und 65535), desto höher ist die Gewichtung und somit steht der Domänencontroller höher in

den Abfrageergebnissen die der Client geliefert bekommt.

Es können auch Standorte existieren, an denen kein Domänencontroller vor Ort besteht.

Hinweis: Standorte sollten auch dann erstellt werden, wenn kein Domänencontroller vor Ort existiert,

wenn z.B. mit standortabhängigen Richtlinien zu arbeiten ist.

Dann nimmt sich ein Domänencontroller aus einem anderen Standort, der dem Standort ohne Domänencontroller am nächsten ist

(anhand der Kosten der Standortverknüpfungen) dessen an und trägt sich im DNS als Domänencontroller für diesen Standort ein.

Dieses Verfahren nennt sich "Automatic Site Coverage" [1]. 

Es ist ebenso möglich einem bestimmten Domänencontroller mehrere Standorte zuzuweisen so dass dieser sich für mehrere Standorte im DNS einträgt.

Dazu fügt man unter Windows 2000 in der Registry des Domänencontrollers, unter dem folgenden Pfad:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

den Schlüssel "SiteCoverage" (REG_MULTI_SZ) hinzu und trägt als Wert dann den/die Standort(e) ein [2].

Unter Windows Server 2003 gibt es dafür eine Richtlinie:

Computerkonfiguration\Administrative Vorlagen\System\Netzwerkanmeldung\
Domänencontrollerlocator-DNS-Einträge\“Standorte, die durch DC-Locator-DNS-SRV-Einträge abgedeckt werden“

Die dort eingetragenen Standorte (jeweils getrennt durch ein Leerzeichen), werden vom NETLOGON-Dienst des Domänencontrollers im DNS registriert.

Neuerung ab Windows Vista und Windows Server 2008

Mit Vista und Windows Server 2008 wurde ein neues Feature (genauer eine Richtlinie) eingeführt, dass das Verhalten zum auffinden eines DCs verbessert.
Das Standardverhalten eines Clients und Mitgliedservers ist, dass zuerst im DNS nach einem DC am gleichen AD-Standort gesucht wird.
Schlägt dieser Versuch fehl, wird nach einem Zufallsprinzip ein DC aus der Domäne (von einem entfernten AD-Standort) ausgewählt,

der die Authentifizierung der Clients bzw. Mitgliedsserver durchführt.

Nun kann ab Vista und Windows Server 2008 die folgende Richtlinie aktiviert werden:
Computerkonfiguration\Administrative Vorlagen\System\Netzwerkanmeldung\Domänencontrollerlocator-DNS-Einträge\"Am nächstgelegenen Standort suchen"

Sites (Übersicht)
Sites and Subnets

How to optimize the location of a domain controller or global catalog that resides outside of a client's site

How Domain Controllers Are Located in Windows

How Domain Controllers Are Located in Windows XP

Replikation: Standorte & Standortverknüpfungsbrücken

Den Dateizugriff auf einem NTFS formatierten Datenträger kann man mit Windows-Boardmitteln überwachen.
Der Einsatz dieser Funktion sollte aber gut durchdacht sein, denn 

1. ist diese Einstellung vom Betriebsrat zu genehmigen bzw. ist Mitbestimmungspflichtig und
2. sollte man sich Gedanken darüber gemacht haben, was mit den gesammelten Informationen geschehen soll.

Findet diese Aufzeichnung statt, um längerfristige statistische Aussagen über das Zugriffsverhalten der Benutzer zu erlangen, so sollte die Protokollgröße vergrößert (in den Eigenschaften des jeweiligen Logs) oder die Protokolle des öfteren archiviert werden.

Die Überwachung sollte sich auf die (wenigen) wichtigsten Dateien/Ordner beschränken, denn es werden Rechenleistung sowie Speicherplatz beansprucht.

Im ersten Schritt gilt es, die folgende Richtlinie entweder auf Lokaler-, Standort-, Domänen- oder OU-Ebene zu aktivieren:

Computerkonfiguration\Windows-Einstellungen\

Sicherheitseinstellungen\Lokale Richtlinien\Überwachungsrichtlinie\Objektzugriffsversuche überwachen

Mit dieser Richtlinie, überwacht man die Ressourcenauslastung des Systems für Dateien, Verzeichnisse, Freigaben, Drucker und Active Directory Objekte.

Als zweiten Schritt gilt es, die Überwachungsebene (System Access Control List, SACL) für einzelne Ordner und Dateien festzulegen, damit eine genaue Überwachung des Zugriffs stattfinden kann. Dieses muss für jedes Objekt das überwacht werden soll, konfiguriert werden.

Zum konfigurieren der Datei- und Ordnerüberwachung geht man folgendermaßen vor:

• Im Kontextmenü der zu überwachenden Datei bzw. Ordner, wählt man die Option Eigenschaften aus
• Auf der Registerkarte Sicherheitseinstellungen gilt es auf Erweitert zu klicken
• Im Dialogfeld Erweiterte Sicherheitseinstellungen für <Dateiname/Ordnername> wählt man die Registerkarte Überwachung aus
  

• Soll an dieser Stelle die Vererbung der Überwachungseinstellungen eines übergeordneten Ordners aktiviert werden, so gilt es im Reiter Berechtigungen die Option Berechtigungen übergeordneter Objekte, sofern vererbbar, über alle untergeordneten Objekte verbreiten. Diese Objekte inklusive den hier definierten Einträgen mit einbeziehen zu aktivieren
   
• Ist es stattdessen gewünscht, die Einstellungen des aktuellen Ordners an die untergeordneten Dateien sowie Ordner zu vererben, so wählt man die Option Überwachungseinträge für alle untergeordneten Objekte durch die angezeigten Einträge, sofern anwendbar, ersetzen aus
   
• Im Listenfeld Überwachungseinträge können entweder der Benutzer, die Gruppe oder die Computer ausgewählt werden, deren Aktionen überwacht werden sollen
   
• Um einen bestimmten Benutzer, eine bestimmte Gruppe oder einen Computer auszuwählen, klickt man auf Hinzufügen… und wählt dann im darauf folgenden Dialogfeld Benutzer, Computer oder Gruppen wählen das entsprechende Objekt aus.
    

Anschließend wird das folgende Dialogfeld Überwachungseintrag für <Datei-/Ordnername> angezeigt. In der Dropdownliste Übernehmen für: kann die Überwachungseinstellung unter anderem für „Nur diesen Ordner“, „diesen Ordner, Unterordner und Dateien“, „Nur Dateien“ sowie weitere Kombinationen angewendet werden. Danach wählt man die erfolgreichen und/oder fehlgeschlagenen zu überwachenden Ereignisse aus und beendet die Auswahl-Fenster jeweils mit einem Klick auf OK:

Hinweis: Ausgeschlossen davon ist die Überwachung der Synchronisierung von Offlinedateien und -ordnern.

Möchte man unter Windows Server 2000, die beiden Richtlinien „Default Domain Controllers Policy“ sowie „Default Domain Policy“ in den Auslieferungszustand zurücksetzen, so kann man das mit dem „Windows 2000 Default Group Policy Restore Tool“ „RecreateDefPol.exe“ erledigen:

Windows 2000 Default Group Policy Restore Tool

Hinweis: Dieses Tool gilt nur für Windows Server 2000!

Unter Windows Server 2003 kann man die beiden Richtlinien folgendermaßen zurücksetzen:

DCGPOFIX auf einem DC/Exchange

Es ist auch möglich, die Richtlinien „händisch“ zurückzusetzen:

How to reset user rights in the Default Domain Controllers Group Policy object

How to reset security settings in the default Domain GPO in Windows 2000

How To Reset User Rights in the Default Domain Group Policy in Windows Server 2003

Falls ein Exchange Server im (Windows Server 2000 oder Windows Server 2003) Netzwerk existiert,
muss anschließend das Exchangesetup „setup.exe“ mit dem Schalter „/Domainprep“ von der Exchange Server CD ausgeführt werden:

Exchange Server permissions are removed by the RecreateDefPol.exe tool in Windows 2000 Server

The Dcgpofix tool does not restore security settings in the Default Domain Controller Policy to their original state

Einen Windows 2000/XP - Client, kann man ebenfalls von den angewendeten Richtlinien „befreien“.
Das geht, in dem alle Ordner sowie Unterschlüssel unter den folgenden Registry-Pfaden gelöscht werden:

- HKEY_CURRENT_USER\Software\Policies

- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies

- HKEY_LOCAL_MACHINE\SOFTWARE\Policies

- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies

Als nächstes navigiert man zu folgendem Verzeichnis: „%windir%\system32\GroupPolicy“.

Dort existieren (unter anderem) ein Ordner Namens "Machine" und ein Ordner "User".

In diesen beiden Ordnern, befindet sich jeweils die Datei "registry.pol", die es ebenfalls zu löschen gilt. 

Zu guter Letzt gilt es noch, die "user.pol" (%userprofile%\ntuser.pol) zu löschen, denn diese enthält die Verweise,
welche Einstellung aus welcher GPO kommt/kam. Anschließend ist ein Neustart fällig.

Möchte man, dass der Client erneut die Richtlinien von seiner Active Directory-Domäne bekommt, muss auf diesem ein „Gpupdate /Force“ ausgeführt werden, denn aufgrund der Policy-History (und der gpt.ini) die sich auf dem Client befindet, meint dieser, dass er immer noch mit den aktuellen Richtlinien ausgestattet ist und wird deshalb die Richtlinien, nicht von alleine übernehmen. Es sei denn, man würde die Policy-History löschen, dann würde es ebenfalls funktionieren.

Group Policy History Stored in Registry

Weitere Informationen:

Wiederherstellung der Default Richtlinien