anselmo80

Nein. 2 Verbindungen (oder sinds 3?) funktionieren auch ohne Terminalserver...

Falls du auf mich anspielst: NEIN, ich habs gelöst. Wir nutzen ja auch noch kein VPN. Das kommt dieses Jahr aber wahrscheinlich noch. Deswegen bin ich dir für den damaligen Tip dankbar und werde ihn auf jeden Fall vor der Umstellung installieren.

Das kann ich nicht bestätigen. Bei uns war der DC in der Außenstellen zunächst kein GC. Nachdem wir dies geändert hatten, ging der Traffic deutlich runter. Ich kann dir auch nur empfehlen den DC zum GC zu machen.

Wie ist denn das Scannen eingestellt? Den Reviewer-Mode würde ich beim Realtime-Scan nicht empfehlen...

Das kenne ich nur von eTrust Version 7 und 7.1 in Verbindung mit Exchange 5.5. Da liegt das Problem aber weniger an CA als bei MS, da angeblich die Mail-Schnittstellen nicht so offen waren, wie das bei 2003 anscheinend der Fall ist. Das Problem taucht bei Exchange 2003 und eTrust 7.1 auf jeden Fall nicht auf. Die Kollegen sind alle begeistert, wie schnell die Mails und die Informationen in den ÖO wieder lesbar sind. Exchange 2003 und Version 7 hatten wir nie im Einsatz. Im nächsten Monat werden wir die Version 8 einführen...

Wir haben die 7er Version nicht gleich nach der Einführung genutzt, sondern erst später. Da haben wir natürlich sofort die Updates mit installiert. Mit der 7er hatten wir nie Probleme. Stattdessen mit einer Vorgängerversion. Das wirft natürlich kein gutes Licht auf CA, wenn ein ähnlicher Fehler in zwei Produktversionne auftritt. Ich hoffe das CA für die Zukunft daraus gelernt hat...

@premus Wir haben eine Maintenance, von daher stehen uns die Updates sowieso zu. Wir bekommen die neuen Versionen dann zugeschickt (nachdem man diese angefordert hat). Ob ein Update von 7 auf 7.1 auch so möglich ist, weiß ich aus dem Kopf leider nicht... @Joe Die Probleme sind mir durchaus bekannt und waren auch verdammt ärgerlich. Für die Probs gab es übrigens ein Update. Dennoch ist so ein Sache unschön und gerade bei einem Serverprodukt hätte ich von CA mehr Tests erwartet, denn so was darf nicht passieren. Bei den neueren Versionen (7 aufwärts) hatten wir derartige Probleme nicht mehr...

Die 7.0er läuft auch auf 2003. Ich empfehle aber auch die Installation von 7.1. Wir hatten ein paar Probleme mit der 7er. Waren zwar nicht sonderlich tragisch, aber falsche Zeichen in den Log-Dateien und ähnliches können bei routinemäßigen Kontrollen schon sehr lästig sein. @Der Schwabe Für das SP2 müssen Ports in der integrierten Windows-Firewall freigeschaltet werden. Wenn du diese gar nicht nutzt läuft alles wie bisher. Ansonsten gibt es von CA ein Tool, welches die Aufgabe für dich übernimmt. Dazu kann dir HemLock aber sicherlich noch mehr sagen...

Bei uns tritt der Fehler auch auf. Es kommt wahrscheinlich von unseren Routern (Cisco). Der Wins-Server machen alle 40 Minuten einen "Rundruf" und es scheint so, als könnten die Router nicht auf die Anfrage antworten und dann wird der Fehler ins Log geschrieben...

Das sagt MS ja auch selber. Schaust du hier

Genau, dass ist auch der von APC gewollte Weg. Die Kosten für den Versand muss man selber tragen, aber APC übernimmt die Entsorgungskosten. Für weitere Infos einfach bei APC anrufen. Der Computer am anderen Ende bietet dir dann weitere Informationen über die Retoure an...

Zwar nicht der Artikel den ich damals gelesen habe, aber hier stehts auch drin Hier lesen Da steht nämlich: Das sollte deine Frage geklärt haben ;)

Ich bin mir nicht mehr ganz sicher, aber ich meine mal bei MS gelesen zu haben, dass der WTS das nämlich gar nicht kann. Man kann also theoretisch beliebig viele Lizenzen nutzen. In einem Nachsatz stand dann eben nur, dass es nicht erlaubt ist mehr zu nutzen als man gekauft hat.

Nutzen wir auch. Und wenn man keinen Exchange 5.5 mehr im Einsatz hat, ist dieser nur zu empfehlen...

Schade. @Velius Danke für den Link. Ich denke der kann bei Bedarf sehr sehr hilfreich sein.

Hallo! Ob dabei mit den anderen nichts passieren kann, kann ich leider nicht versichern. Von unserem Systemhaus habe ich erfahren, dass der Befehl "klist purge" mit Vorsicht eingesetzt werden sollte. Warum weiß ich aber nicht... Wenn du also keine Probleme bei der Replikation zwischen den DCs oder ähnliches feststellst, kannst du ja auch noch nach einer anderen Lösung suchen. Meine Schritte: Auf dem Server mit den Problemen 1. Kerberos Schlüsselverteilungscenter deaktivieren 2. Server neu starten 3. netdom /resetpwd /s:"PDC-EMULATOR" /ud: DOMÄNE\DOMÄNENADMIN /pd:* (groß geschriebenes ist entsprechend zu ersetzen) 4. Neu starten 5. Kerberos Schlüsselverteilungscenter Ob die Schritte 1 - 5 wirklich nötig sind weiß ich nicht. Das habe ich vorher im Rahmen eines anderen Lösungsversuchs probiert. Anschließend konnten sich die User aber wieder über die "normalen" Freigaben und nicht über die IP mit den Netz-Laufwerken verbinden. Hier die Schritte die nachher die Replikation wieder in Gang gebracht haben und alle Fehler in dcdiag beseitigt haben. Auf dem DC mit den Problemen... 6. Kerberos Schlüsselverteilungscenter beenden 7. In der Kommandozeile klist purge --> für jedes angegebene Ticket das Löschen bestätigen 8. Kerberos Schlüsselverteilungscenter 9. Server neu starten Nach kurzer Zeit sollte im Dateireplikations-Log folgender Eintrag erscheinen: Ereignistyp: Warnung Ereignisquelle: NtFrs Ereigniskategorie: Keine Ereigniskennung: 13509 Datum: 10.03.2006 Zeit: 15:43:38 Benutzer: Nicht zutreffend Computer: DC2 Beschreibung: Der Dateireplikationsdienst hat die Replikation von DC1 nach DC2 für c:\windows\sysvol\domain nach wiederholten Versuchen aktiviert. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp. Ich hoffe ich konnte dir damit helfen. Eine Garantie kann ich dir leider nicht geben, da ich mir selber nicht 100%ig über die Auswirkungen von klist purge im klaren bin.

Hallo! Zufällig mit den Uhrzeiten rumgespielt? Genau das gleiche ist mir letzte Woche passiert. Schau mal hier Ich habe es ohne den angegebenen Patch gelöst, da wir noch kein VPN nutzen. Wenn es bei dir ähnliche Probleme sind, kann ich dir meine genauere Vorgehensweise gerne noch mal schildern. Gruß, anselmo

Ich hatte bisher nie den Gedanken dieses Verhalten zu ändern, aber geärgert hat es mich auch immer. Werde es jetzt auch mal versuchen. Danke für den Beitrag.

Wenn ich dich richtig verstanden habe, meinst du den Cache von Outlook. Darin speichert Outlook die Empfänger denen du schon mal eine Mail geschickt hast, unabhängig von der Adresse dahinter. Bei einem neu installiertem Outlook sollte es also gar keine Vorschläge geben. Erst nach dem Versenden von Mails sollte Outlook dir nach und nach Vorschläge unterbreiten.

Es sind Standleitungen :D Ich werde mir den Patch dann doch noch mal anschauen. Danke für den Hinweis. Vor allem weil wir in Zukunft die Standleitungen wohl durch VPN-Leitungen ersetzen werden. Wobei ich immer noch glaube, dass das Problem eigentlich von der Umstellung des Datums herrührt. Zum einen entstanden die Probleme erst danach und zum anderen wiesen auch manche Fehlermeldungen darauf hin, dass die Authentifzierung nicht mehr funktioniert (habe ich den Kerberos 4 Fehler oben eigentlich geposted?). Deswegen denke ich, bin ich mit dem Löschen des Ticket Cache schon ganz gut gefahren.

Die Server haben alle SP1...

Hallo! Danke für die Antwort - und fürs Lesen des ganzen Texts :-). Ein VPN ist bei uns nicht dazwischen. Es sind ganz "normale" Verbindungen. Die Verbindung von Standort B zu A habe ich mittlerweile auch schon hinbekommen. Ich habe auf dem DC in Standort B den KDC gestoppt und anschließend mit klist purge den Ticket Cache geleert. Mit dem vorherigen zurücksetzen des Computerkontos hat das dann wohl gereicht. Zuerst kam die Meldung, dass er die Replikation des AD wieder aufnimmt und dann sah ich im Replmon die Verbindungen auch wieder als aktiv. Fehler gibt es auch keine mehr, was die beiden Server angeht. Jetzt werde ich gleiches noch mal für die Verbindung mit Standort C versuchen.

Hi! Muss man zu srvany nicht auch noch instsrv.exe verwenden? Ich meine da so was im Hinterkopf zu haben. Gruß, anselmo

Ereignistyp: Fehler Ereignisquelle: Kerberos Ereigniskategorie: Keine Ereigniskennung: 4 Datum: 10.03.2006 Zeit: 09:06:24 Benutzer: Nicht zutreffend Computer: DC Standort B Beschreibung: Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "host/DC Standort A.DOMÄNE" empfangen. Der verwendete Zielname war SMTPSVC/DC Standort A.DOMÄNE. Dies deutet darauf hin, dass das Kennwort, das zum Verschlüsseln des Kerberos-Diensttickets verwendet wurde, anders als das Kennwort auf dem Zielserver ist. Häufige Ursache hierfür sind identische Computerkontonamen im Zielbereich (DOMÄNE) und dem Clientbereich. Wenden Sie sich an den Systemadministrator. ------------------ Ereignistyp: Warnung Ereignisquelle: NTDS KCC Ereigniskategorie: Konsistenzprüfung Ereigniskennung: 1865 Datum: 10.03.2006 Zeit: 09:02:24 Benutzer: NT-AUTORITÄT\ANONYMOUS-ANMELDUNG Computer: DC Standort B Beschreibung: Die Konsistenzüberprüfung (KCC) konnte keine vollständige umfassende Struktur erstellen. Die folgende Liste einiger Standorte kann daher von dem lokalen Standort nicht erreicht werden. Standorte: CN=Kleve,CN=Sites,CN=Configuration,DC=DOMÄNE,DC=local CN=SITE A,CN=Sites,CN=Configuration,DC=DOMÄNE,DC=local ------------------- Ereignistyp: Fehler Ereignisquelle: NTDS KCC Ereigniskategorie: Konsistenzprüfung Ereigniskennung: 1311 Datum: 10.03.2006 Zeit: 09:02:24 Benutzer: NT-AUTORITÄT\ANONYMOUS-ANMELDUNG Computer: DC Standort B Beschreibung: Die Konsistenzprüfung hat Probleme mit der folgenden Verzeichnispartition ermittelt. Verzeichnispartition: CN=Configuration,DC=DOMÄNE,DC=local Es gibt für die Konsistenzprüfung nicht genügend Sitekonnektivitätsinformationen in Active Directory-Standorte und -Dienste, um eine umfassende Gesamtstrukturreplikationstopologie zu erstellen. Oder ein oder mehrere Domänencontroller mit dieser Verzeichnispartition ware nicht in der Lage, die Verzeichnispartitioninformationen zu replizieren. Dies liegt vermutlich an nicht zugreifbaren Domänencontrollern. Benutzeraktion Verwenden Sie Active Directory-Standorte und -Dienste, um eine der folgenden Maßnahmen durchzuführen: - Veröffentlichen Sie genügend Informationen über Standortkonnektivität, so dass die Konsistenzprüfung eine Route ermitteln kann, durch die die Verzeichnispartition diesen Standort erreichen kann. Diese Option wird empfohlen. - Fügen Sie zu einem Domänencontroller hinzu, der die Partition an diesem Standort enthält, ein ein Verbindungsobjekt von einem Domänencontroller hinzu, der die selbe Partition an einem anderen Standort enthält. Wenn keine dieser beiden Aufgaben von Active Directory-Dienste und -Standort den Problemzustand behebt, überprüfen Sie die bisher durch die Konsistenzprüfung protokollierten Ereignisse, die die nicht zugreifbaren Domänencontroller identifizieren. ---------------------- Ereignistyp: Warnung Ereignisquelle: NTDS KCC Ereigniskategorie: Konsistenzprüfung Ereigniskennung: 1566 Datum: 10.03.2006 Zeit: 09:02:24 Benutzer: NT-AUTORITÄT\ANONYMOUS-ANMELDUNG Computer: DC Standort B Beschreibung: Alle Domänencontroller am folgenden Standort, die die Verzeichnispartition über diesen Transport replizieren können, sind zurzeit nicht verfügbar. Standort: CN=SITE A,CN=Sites,CN=Configuration,DC=DOMÄNE,DC=local Verzeichnispartition: CN=Configuration,DC=DOMÄNE,DC=local Transport: CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=DOMÄNE,DC=local

Hallo zusammen! Ich habe folgendes (riesiges) Problem. Wir haben 3 Standorte. In jedem Standort steht ein Domänencontroller mit Windows Server 2003 inkl. einem Exchange 2003 Server (alles DCs einer Domäne). Am Dienstag ist in Standort A die Zeit nicht auf den 07.03.06 sondern aus Versehen auf den 03.07.06 gesetzt worden (ich weiß das man die Zeit nicht manuell synchronisieren sollte, aber unser Funkempfänger tuts zur Zeit nicht und da wollte ich es mal eben kurz per Hand tun). Seitdem besteht das Problem, dass die Standorte B und C nicht mehr mit Standort A replizieren können. Eine Anmeldung der Clients in Standort B und C schlug ebenfalls fehl. Probleme im Standort A gab es keine (hier ist auch der PDC-Emulator). Mit Netdom habe ich die Kennwörter der DCs in Standort A und B zurückgesetzt. Danach konnten sich die Clients wieder anmelden und auch Exchange startete und funktioniert dort wieder. Für die User ist somit wieder alles beim alten. Das Problem besteht nun in der Replikation der Server. In Standort B bekomme ich die im nächsten Beitrag angegebenen Fehlermeldungen im Eventlog. DNS-Namensauflösungen und so weiter funktionieren. Ich habe auch schon die Technet und EventID durchsucht, aber alle Hinweise (oft DNS-Probleme) treffen bei mir nicht zu, da die Einstellungen stimmen. Außerdem glaube ich, dass mein Ursprungsproblem eben mit der Änderung der Zeit zusammenhängt und dadurch die Passwörter mit denen die Server sich gegenseitig authentifizieren nicht mehr stimmen. Hat irgendjemand evtl. eine Idee, was man hier noch tun kann? VIelen Dank schon mal. Gruß, anselmo