29
Exchange 2010 verliert Verbindung zu DC-s
Hallo Community,
ich habe seit 1 Woche das Problem, dass der Mailserver (2010) nach einer gewissen Zeit immer die Verbindung zu seinen DC´s verliert und somit natürlich zum GC und dem Rest. Witziger Weise verbindet er sich nach ca 12 Stunden wieder mit den DC´s und läuft regulär. Das eventlog quillt über vor Fehlern, die aber alle im Zusammenhang mit den verloren DC´s und dem GC stehen.
Vor einer Woche wurden 2 Dinge am System geändert, zum einen ein neuer Kaspersky Agent installiert und zum anderen die DC´s angehoben.
nslookup - check - okay
telnet - check - okay
connector - check - okay
jemand ne Idee?
ich habe seit 1 Woche das Problem, dass der Mailserver (2010) nach einer gewissen Zeit immer die Verbindung zu seinen DC´s verliert und somit natürlich zum GC und dem Rest. Witziger Weise verbindet er sich nach ca 12 Stunden wieder mit den DC´s und läuft regulär. Das eventlog quillt über vor Fehlern, die aber alle im Zusammenhang mit den verloren DC´s und dem GC stehen.
Vor einer Woche wurden 2 Dinge am System geändert, zum einen ein neuer Kaspersky Agent installiert und zum anderen die DC´s angehoben.
nslookup - check - okay
telnet - check - okay
connector - check - okay
jemand ne Idee?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 345576
Url: https://administrator.de/contentid/345576
Ausgedruckt am: 23.11.2024 um 00:11 Uhr
29 Kommentare
Neuester Kommentar
Hi,
was heißt, er verliert die Verbindung zum DC? Hast Du da ne Eventlog-Meldung?
Kann da eine doppelte IP-Adresse im Spiel sein? Sind Server und Clients in verschiedenen Subnetzen?
Sind Echange Server und DC's in verschiedenen Subnetzen?
Wieviel DC's?
Wieviel DNS-Server? Welche/wieviel nutzt der Exchange davon?
Was sagen die Eventlogs auf den DC's? Haben die DC's möglicherweise ein Problem?
Haben DC's und/oder der Exchange mehrere Netzkarten?
E.
was heißt, er verliert die Verbindung zum DC? Hast Du da ne Eventlog-Meldung?
nslookup - check - okay
telnet - check - okay
connector - check - okay
Was auch immer Du da getestet hast. Es ist eh nur interessant, wenn Du es genau während des vermeintlichen Blackouts testest. Also: Was genau und wann hast Du da getestet.telnet - check - okay
connector - check - okay
Kann da eine doppelte IP-Adresse im Spiel sein? Sind Server und Clients in verschiedenen Subnetzen?
Sind Echange Server und DC's in verschiedenen Subnetzen?
Wieviel DC's?
Wieviel DNS-Server? Welche/wieviel nutzt der Exchange davon?
Was sagen die Eventlogs auf den DC's? Haben die DC's möglicherweise ein Problem?
Haben DC's und/oder der Exchange mehrere Netzkarten?
DC's angehoben
Also neue DC's ins Netz gebracht und die alten entfernt? Oder die alten neu installiert? Oder Inplace-Upgrade? Oder oder?E.
Die DC´s wurden von 2003 auf 2008R2 hochgestufft
sind alle im selben Netz am Standort
Keine doppelten IP´s vorhanden
sind 7 DC´s
2 DNS Server eingetragen / insgesamt 7
DC´s und Mailserver haben nur 1 aktive Netzwerkkarte
sind alle im selben Netz am Standort
Keine doppelten IP´s vorhanden
sind 7 DC´s
2 DNS Server eingetragen / insgesamt 7
DC´s und Mailserver haben nur 1 aktive Netzwerkkarte
Die DC´s wurden von 2003 auf 2008R2 hochgestufft
Nur die Funktionsebenen oder 2003'-Server durch 2008R2' ersetzt?sind alle im selben Netz am Standort
Ihr habt Bedarf für 7 DC's und die Clients und Server sind alle im selben Subnetz?! Wieviel Clients?Keine doppelten IP´s vorhanden
Was macht Dich da so sicher?sind 7 DC´s
Wieviele davon GC? Mehrere Domänen?2 DNS Server eingetragen / insgesamt 7
Und beide DNS-Server sind während eines Blackouts des Exchange Servers voll funktionstüchtig?
Nur die Funktionsebenen
ich meinte, sie befinden sich alle im selben subnet am jeweiligen Standort also z.B. Berlin hat 3 DC´s und die sind alle im selben subnet die anderen dc´s sind in den jeweiligen netzen des jeweiligen standortes. Ca. 200 Clients
es gibt keine ip Adresskonflikt Meldungen
jeder DC ist auch GC
nur 1 Domäne
beide DNS server sind während des "blackouts" voll funktionsfähig
Eventlogs auf den DC´s sind sauber
ich meinte, sie befinden sich alle im selben subnet am jeweiligen Standort also z.B. Berlin hat 3 DC´s und die sind alle im selben subnet die anderen dc´s sind in den jeweiligen netzen des jeweiligen standortes. Ca. 200 Clients
es gibt keine ip Adresskonflikt Meldungen
jeder DC ist auch GC
nur 1 Domäne
beide DNS server sind während des "blackouts" voll funktionsfähig
Eventlogs auf den DC´s sind sauber
es gibt keine ip Adresskonflikt Meldungen
Ich will nicht nerven, aber das hast Du überall geprüft:An den DC's, den DNS-Servern und den Exchange-Servern?
Aber Du hast leider meine erste Frage noch nicht beantwortet.
was heißt, er verliert die Verbindung zum DC? Hast Du da ne Eventlog-Meldung?
Ich weiß von unseren Exch2010 Servern, dass diese auch öfters mal durchgestartet werden müssen, wenn "deren" DC's z.B. zwecks Wartung "länger" offline sind. Also nicht bloß mal duchstarten sondern ein paar Minuten nicht verfügbar. Auch wenn diese DC's dann wieder online sind ändert das nichts. Man muss diese Exchange Server booten. Aussage unserers Esxchange Admins. Warum - keine Ahnung.
IP Konflikt kann ausgeschlossen werden, da alle betreffenden Stellen doppelt geprüft wurden.
Eventlog - Anwendung
###
Dienst MSExchangeMailSubmission. Ausnahme Microsoft.Exchange.Data.Directory.ADTransientException: Es konnte kein verfügbarer Domänencontroller gefunden werden.
bei Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(ConnectionType connectionType, ADObjectId domain, String serverName, Int32 port, NetworkCredential credential)
bei Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(ConnectionType connectionType)
bei Microsoft.Exchange.Data.Directory.ADSession.GetConnection(String preferredServer, Boolean isWriteOperation, Boolean isNotifyOperation, String optionalBaseDN, ADObjectId& rootId, ADScope scope)
bei Microsoft.Exchange.Data.Directory.ADSession.GetReadConnection(String preferredServer, String optionalBaseDN, ADObjectId& rootId, ADRawEntry scopeDeteriminingObject)
bei Microsoft.Exchange.Data.Directory.ADSession.Find(ADObjectId rootId, String optionalBaseDN, ADObjectId readId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults, IEnumerable`1 properties, CreateObjectDelegate objectCreator, CreateObjectsDelegate arrayCreator, Boolean includeDeletedObjects)
bei Microsoft.Exchange.Data.Directory.ADSession.Find(ADObjectId rootId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults, IEnumerable`1 properties, CreateObjectDelegate objectCtor, CreateObjectsDelegate arrayCtor)
bei Microsoft.Exchange.Data.Directory.ADSession.Find[TResult](ADObjectId rootId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults, IEnumerable`1 properties)
bei Microsoft.Exchange.Data.Directory.SystemConfiguration.ADSystemConfigurationSession.Find[TResult](ADObjectId rootId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults)
bei Microsoft.Exchange.Data.Directory.SystemConfiguration.ADSystemConfigurationSession.FindServerByFqdn(String serverFqdn)
bei Microsoft.Exchange.Data.Directory.SystemConfiguration.ADSystemConfigurationSession.FindLocalServer()
bei Microsoft.Exchange.Data.ApplicationLogic.PickerServerList.LoadFromAD(PickerServerList oldServers)
bei Microsoft.Exchange.Data.ApplicationLogic.ADConfigurationLoader`2.<>c__DisplayClass1.<ReadConfiguration>b__0()
bei Microsoft.Exchange.Data.Directory.ADNotificationAdapter.RunADOperation(ADOperation adOperation, Int32 retryCount)
bei Microsoft.Exchange.Data.Directory.ADNotificationAdapter.TryRunADOperation(ADOperation adOperation, Int32 retryCount) der Exchange-Topologieerkennung beim Ladeversuch der Topologieinformationen.
daraus resultiert ->
###
Prozess MAD.EXE (PID=7328). Keine Antwort von allen globalen Katalogservern in der Gesamtstruktur DC=xxx,DC=xxx:
Prozess STORE.EXE (PID=15052). Keine Antwort von allen verwendeten Domänencontrollerservern:
Prozess MSEXCHANGEADTOPOLOGY (PID=1408). Die Standortmonitor-API konnte nicht überprüfen den Standortnamens für diesen Exchange-Computer - Anruf=HrSearch Fehlercode=80040934. Überprüfen Sie, ob der Exchange-Server ordnungsgemäß beim DNS-Server registriert ist.
Prozess MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1408). Fehler bei der Topologieerkennung. Fehler: 0x80040952 (LDAP_LOCAL_ERROR (Client-side internal error or bad LDAP message)). Suchen Sie nach Informationen zum LDAP-Fehlercode (Lightweight Directory Access Protocol), der in der Ereignisbeschreibung angegeben ist. Verwenden Sie hierfür den Microsoft Knowledge Base-Artikel 218185, "Microsoft LDAP-Fehlercodes". Verwenden Sie die Informationen aus diesem Artikel, um mehr über die Ursache und Behebung dieses Fehlers zu erfahren. Testen Sie die Netzwerkverbindungen mit lokalen Domänencontrollern mithilfe der Befehlszeilentools 'Ping' oder 'PathPing'.
Eventlog - Anwendung
###
Dienst MSExchangeMailSubmission. Ausnahme Microsoft.Exchange.Data.Directory.ADTransientException: Es konnte kein verfügbarer Domänencontroller gefunden werden.
bei Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(ConnectionType connectionType, ADObjectId domain, String serverName, Int32 port, NetworkCredential credential)
bei Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(ConnectionType connectionType)
bei Microsoft.Exchange.Data.Directory.ADSession.GetConnection(String preferredServer, Boolean isWriteOperation, Boolean isNotifyOperation, String optionalBaseDN, ADObjectId& rootId, ADScope scope)
bei Microsoft.Exchange.Data.Directory.ADSession.GetReadConnection(String preferredServer, String optionalBaseDN, ADObjectId& rootId, ADRawEntry scopeDeteriminingObject)
bei Microsoft.Exchange.Data.Directory.ADSession.Find(ADObjectId rootId, String optionalBaseDN, ADObjectId readId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults, IEnumerable`1 properties, CreateObjectDelegate objectCreator, CreateObjectsDelegate arrayCreator, Boolean includeDeletedObjects)
bei Microsoft.Exchange.Data.Directory.ADSession.Find(ADObjectId rootId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults, IEnumerable`1 properties, CreateObjectDelegate objectCtor, CreateObjectsDelegate arrayCtor)
bei Microsoft.Exchange.Data.Directory.ADSession.Find[TResult](ADObjectId rootId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults, IEnumerable`1 properties)
bei Microsoft.Exchange.Data.Directory.SystemConfiguration.ADSystemConfigurationSession.Find[TResult](ADObjectId rootId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults)
bei Microsoft.Exchange.Data.Directory.SystemConfiguration.ADSystemConfigurationSession.FindServerByFqdn(String serverFqdn)
bei Microsoft.Exchange.Data.Directory.SystemConfiguration.ADSystemConfigurationSession.FindLocalServer()
bei Microsoft.Exchange.Data.ApplicationLogic.PickerServerList.LoadFromAD(PickerServerList oldServers)
bei Microsoft.Exchange.Data.ApplicationLogic.ADConfigurationLoader`2.<>c__DisplayClass1.<ReadConfiguration>b__0()
bei Microsoft.Exchange.Data.Directory.ADNotificationAdapter.RunADOperation(ADOperation adOperation, Int32 retryCount)
bei Microsoft.Exchange.Data.Directory.ADNotificationAdapter.TryRunADOperation(ADOperation adOperation, Int32 retryCount) der Exchange-Topologieerkennung beim Ladeversuch der Topologieinformationen.
daraus resultiert ->
###
Prozess MAD.EXE (PID=7328). Keine Antwort von allen globalen Katalogservern in der Gesamtstruktur DC=xxx,DC=xxx:
Prozess STORE.EXE (PID=15052). Keine Antwort von allen verwendeten Domänencontrollerservern:
Prozess MSEXCHANGEADTOPOLOGY (PID=1408). Die Standortmonitor-API konnte nicht überprüfen den Standortnamens für diesen Exchange-Computer - Anruf=HrSearch Fehlercode=80040934. Überprüfen Sie, ob der Exchange-Server ordnungsgemäß beim DNS-Server registriert ist.
Prozess MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1408). Fehler bei der Topologieerkennung. Fehler: 0x80040952 (LDAP_LOCAL_ERROR (Client-side internal error or bad LDAP message)). Suchen Sie nach Informationen zum LDAP-Fehlercode (Lightweight Directory Access Protocol), der in der Ereignisbeschreibung angegeben ist. Verwenden Sie hierfür den Microsoft Knowledge Base-Artikel 218185, "Microsoft LDAP-Fehlercodes". Verwenden Sie die Informationen aus diesem Artikel, um mehr über die Ursache und Behebung dieses Fehlers zu erfahren. Testen Sie die Netzwerkverbindungen mit lokalen Domänencontrollern mithilfe der Befehlszeilentools 'Ping' oder 'PathPing'.
Wenn das schon das Anwendungslog Deines EX ist, wie sieht denn dann das Systemlog aus?!
Mein letzter Kommentar ist irgendwie verloren gegangen ....?
Standort und Subnetze sind im AD abgebildet?
Falls nein:
Der Exchange steht zentral und/oder kann mit allen DC an allen Standorten direkt kommunizieren?
Standort und Subnetze sind im AD abgebildet?
Falls nein:
Der Exchange steht zentral und/oder kann mit allen DC an allen Standorten direkt kommunizieren?
Das Systemlog ist erstaunlich sauber im Vergleich zum Anwendungslog, lediglich Schannel 46/48
Standorte und subnets sind im AD abgebildet, Exchange kann mit allen DC´s direkt kommunizieren
Geht das ein bißchen genauer?!
"Schannel" hat was mit SSL/TLS zu tun. Das ist bestimmt ne Meldung im Kontext der Kommunikation mit den Clients.
Der Vollständigkeit wegen: Der Exchange Server hat alle aktuellen Updates?
Der Vollständigkeit wegen: Der Exchange Server hat alle aktuellen Updates?
Der einzige Fehler im Syslog ist:
Es wurde eine schwerwiegende Warnung empfangen: 46.
Es wurde eine schwerwiegende Warnung empfangen: 48.
beide von Schannel
die gab es aber auch schon bevor das Problem auftauchte.
Es wurde eine schwerwiegende Warnung empfangen: 46.
Es wurde eine schwerwiegende Warnung empfangen: 48.
beide von Schannel
die gab es aber auch schon bevor das Problem auftauchte.
Sowohl Exchange als auch der windows Server selber sind tages aktuell
OK, dann will ich Dich nicht weiter nerven. 
Wenn mir noch etwas einfallen sollte, dann melde ich mich ggf. hier. Bis dahin bin ich erstmal raus.
Wenn mir noch etwas einfallen sollte, dann melde ich mich ggf. hier. Bis dahin bin ich erstmal raus.
Also,
die Infos reichen leider nicht.
Was noch zu prüfen wäre:
AD-Replikation --> repadmin /showrepl auf allen Domänencontrollern
DCdiag auf allen Domänencontrollern
Am Exchange:
Deaktiviere Kaspersky!
Der gehört nicht auf einen EX!
In diesem Zuge, schau mal nach, ob die Firewall hochgefahren wurde; sowohl die Kaspersky als auch die Windows-interne.
Da Du nicht geschrieben hast, auf welchem OS der EX rennt hier noch ein Punkt:
Schau mal in die Netztopologie.
Speziell die Adaptereigenschaften und schau mal, was außer dem TCPIP-protokoll noch alles verwendet wird.
Du solltest ggf. TCPIPv6 ausschalten, falls es läuft.
Die neueren Mühlen präferieren es.
die Infos reichen leider nicht.
Was noch zu prüfen wäre:
AD-Replikation --> repadmin /showrepl auf allen Domänencontrollern
DCdiag auf allen Domänencontrollern
Am Exchange:
Deaktiviere Kaspersky!
Der gehört nicht auf einen EX!
In diesem Zuge, schau mal nach, ob die Firewall hochgefahren wurde; sowohl die Kaspersky als auch die Windows-interne.
Da Du nicht geschrieben hast, auf welchem OS der EX rennt hier noch ein Punkt:
Schau mal in die Netztopologie.
Speziell die Adaptereigenschaften und schau mal, was außer dem TCPIP-protokoll noch alles verwendet wird.
Du solltest ggf. TCPIPv6 ausschalten, falls es läuft.
Die neueren Mühlen präferieren es.
AD-replika läuft sauber auf allen DC´s durch
DCdiag alle test bestanden
Kaspersky habe ich vom exchange runtergeworfen
Firewalls beide i.O.
hatte TCPIPv6 deaktiviert, habs es dann zum testen aktiviert und anschließend wieder deaktiviert, da es nicht geholfen hatte
der 2010 exchange läuft auf einem 2008R2
DCdiag alle test bestanden
Kaspersky habe ich vom exchange runtergeworfen
Firewalls beide i.O.
hatte TCPIPv6 deaktiviert, habs es dann zum testen aktiviert und anschließend wieder deaktiviert, da es nicht geholfen hatte
der 2010 exchange läuft auf einem 2008R2
hatte TCPIPv6 deaktiviert, habs es dann zum testen aktiviert und anschließend wieder deaktiviert, da es nicht geholfen hatte
Wie jetzt? Du hast jetzt gerade solch eine Störung? Oder wie kannst Du jetzt so schnell beurteilen, dass die Aktivierung/Deaktivierung von IPv6 einen Unterschied macht? Wohl kaum, wenn nicht während der Störung getestet.
Moin,
Gruß,
Dani
hatte TCPIPv6 deaktiviert, habs es dann zum testen aktiviert und anschließend wieder deaktiviert, da es nicht geholfen hatte
dazu gibt es reichlich Lesestoff, zum Beispiel. Bitte auf allen DCs und Exchange-Servern IPv6 wieder aktivieren und anschließend nacheinander neustarten.Gruß,
Dani
Wie bereits anfangs erwähnt, besteht das Problem seit 1 Woche und ich hatte am Freitag IPv6 mal angemacht um zu schauen ob es daran liegt, lag es aber nicht und daher habe ich es heute wieder deaktiviert. Es trat in der Zeit von Freitag früh bis heute wieder täglich die Störung auf, daher tendiere ich dazu die IP Protokolle mal außen vor zu lassen.
Es scheint alles darauf hin zu deuten, dass der Kaspersky den Fehler verursacht hat, ich halte euch auf dem laufenden.
Es scheint alles darauf hin zu deuten, dass der Kaspersky den Fehler verursacht hat, ich halte euch auf dem laufenden.
Zitat von @Dani:
Moin,
Gruß,
Dani
Moin,
hatte TCPIPv6 deaktiviert, habs es dann zum testen aktiviert und anschließend wieder deaktiviert, da es nicht geholfen hatte
dazu gibt es reichlich Lesestoff, zum Beispiel. Bitte auf allen DCs und Exchange-Servern IPv6 wieder aktivieren und anschließend nacheinander neustarten.Gruß,
Dani
Ich will das, was Dani hier schreibt nicht als falsch abtun. Durchaus nicht.
Ich ergänze nur um folgenden Kommentar:
Es ist nicht immer so, wie es in den Büchern steht!
Ich habe selbst meine Infrastruktur auf Server 2008 R2 mit einem EX2010 auf rein IPv4 laufen.
Es läuft tadellos!
Ich habe selbst meine Infrastruktur auf Server 2008 R2 mit einem EX2010 auf rein IPv4 laufen.
Es läuft tadellos!
Kann ich bestätigen! Bei uns auch.Es läuft tadellos!
@beidermachtvongreyscull, @emeriks
wie immer gilt: Solange es funktioniert, interessiert es keinen. Haben wir in meinen Anfangszeiten bei meinem AG auch gemacht. Inzwischen gilt bei uns unternehmesweit sich an die Vorgaben der verschiedenen Hersteller zu halten. Vieles ist sehr komplex und eng miteinander verbunden, so dass gerne bei Beteiligung von mehreren Herstellern das Ping-Pong-Spiel beginnt oder es heißt "unsupported". Da sind viele Supports (Microsoft voran) inzwischen eiskalt und machen nicht mehr einmal eine Ausnahme.
Gruß,
Dani
wie immer gilt: Solange es funktioniert, interessiert es keinen. Haben wir in meinen Anfangszeiten bei meinem AG auch gemacht. Inzwischen gilt bei uns unternehmesweit sich an die Vorgaben der verschiedenen Hersteller zu halten. Vieles ist sehr komplex und eng miteinander verbunden, so dass gerne bei Beteiligung von mehreren Herstellern das Ping-Pong-Spiel beginnt oder es heißt "unsupported". Da sind viele Supports (Microsoft voran) inzwischen eiskalt und machen nicht mehr einmal eine Ausnahme.
Gruß,
Dani
@Dani
Da hast Du natürlich Recht. Mit Deinem letzten Kommentar hat nämlich jetzt der TO auch einen Grund, um es wieder einzsuchalten.
Ob es seinem Problem hilft, kann ich nicht sagen, aber was das Supportgedöns angeht, ja - das stimmt. Leider.
Gruß,
Andreas
Da hast Du natürlich Recht. Mit Deinem letzten Kommentar hat nämlich jetzt der TO auch einen Grund, um es wieder einzsuchalten.
Ob es seinem Problem hilft, kann ich nicht sagen, aber was das Supportgedöns angeht, ja - das stimmt. Leider.
Gruß,
Andreas
Das Problem wird immer schlimmer, er verliert nun nicht nur die Verbindung zu den DC´s sondern kann nicht mal mehr seine DB´s finden. Ich werde heute noch einen Tag investieren und wenn es zu keiner Lösung kommt, fackel ich die Kiste ab und setzt nen neuen auf ;(
fackel ich die Kiste ab und setzt nen neuen auf ;(
Ich denke Du meinst:- Einen zusätzlichen Server in derselbe Organisation installieren
- Postfächer verschieben
- SMTP-Transportweg auf den neuen Server anpassen
- nach ein paar Tagen/Wochen den alten Server deinstallieren
Also wenn da nix im Eventlog steht, dann empfehle ich Dir auch:
Zitat von @meanmachine:
Ich werde heute noch einen Tag investieren und wenn es zu keiner Lösung kommt, fackel ich die Kiste ab und setzt nen neuen auf ;(
Ich werde heute noch einen Tag investieren und wenn es zu keiner Lösung kommt, fackel ich die Kiste ab und setzt nen neuen auf ;(
Ich glaube ich muss den Titel ändern in DC´s verlieren Verbindung, jetzt ist nicht nur der Mailserver betroffen sondern auch andere Systeme die keinen DC mehr finden können. Komischer Weise immer in der Zeit von ca. 03.00 - 05.00 danach pendelt sich alles wieder ein.
Na wenn dem so ist, dann ist doch ein Netzwerkproblem an oberster Stelle zu vermuten. Wenn z.B. der DNS-Server in dieser Zeit nicht antwortet, dann geht auch kein Zugriff auf das AD.
