Beiträge von hati39

Es war der Virenscanner, von GData. Abstellen reichte nicht, deinstallieren musste sein.

Closed.

Ok, jetzt wird es lustig.
Ich bin gerade beim Kunden vor Ort und wir haben den alten Exchange Server neu gestartet. Beim Hochfahren wurden alle 57 Testmails, die wir seit gestern geschickt haben, zugestellt. Der Vorgang lässt sich reproduzieren.

Hallo Jean-Claude,

vielen Dank für die Antwort. Fangen wir mal oben an: der Wink mit dem Zaunpfahl! In der Tat ist der neue Exchange Server mit an Sicherheit grenzender Wahrscheinlichkeit nicht mir dem gleichen Account installiert worden. Wir haben Domäne und Exchange damals komplett in der Werkstatt aufgesetzt und fertig ausgeliefert. Installiert wurde daher mit dem Administrator. Später wurden dann weitere Administratoren eingerichtet, unter anderem der von mir benutzte für die neue Installation. Er hat zusätzlich noch das Recht, sich als Dienst anzumelden (es ist der von Veritas benutzte Account).
Was kann das denn für Auswirkungen haben und wie mache ich das ggf. rückgängig? Kann ich einfach den neuen Server deinstallieren und dann als Administrator neu installieren?

Die Server sind in der gleichen Routinggruppe.

Dann zu SMTP:
Ich hatte nur per Telnet ausprobiert, ob ich den SMTP Server überhaupt erreiche. Dies war der Fall. Nun habe ich wie beschrieben manuell eine Mail zugestellt. Die kommt auch an, obwohl ich zunächst Bedenken hatte, denn ich erhalte kein "Recipient OK" und auch kein "accepted for delivery", sondern ein "Queued mail for delivery". Hier die Ausgabe, aber wie gesagt: Die Mail kommt an. (Domäne ausgeXt)

220 st-exchange-07.xxx.DE Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959
ready at Thu, 15 Mar 2007 09:05:13 +0100
250 st-exchange-07.xxx.DE Hello [192.168.1.10]
250 2.1.0 dbagent@xxx.de....Sender OK
250 2.1.5 j.wieche@xxx.de
354 Enter mail, end with "." on a line by itself
250 2.6.0 <ST-EXCHANGE-0749AsD00000001@st-exchange-07.xxx.DE> Queued mail for
delivery
221 2.0.0 st-exchange-07.xxx.DE Service closing transmission channel

Nun zu BPA und Winroute:
An kritischen Problemen erhalte ich nur Nebensächlichkeiten, etwa dass die Datensicherung kritisch ist. Klar, läuft ja auch noch keine. Auffällig ist hingegen folgendes: An dem Standort gibt es 3 DCs, wovon 2 auch den global catalog führen. Nur bei einem der Server (einer der beiden global catalog Server, aber nicht der Schema-Master) findet sich in den Informationselementen die administrative Gruppe und die Routinggruppe. Bei den anderen beiden DCs findet sich hingegen kein Hinweis im AD auf Exchange. Das Schema habe ich aber natürlich erweitert und die Systemverwaltungstools sind auf allen drei Servern ebenfalls installiert.
Winroute findet die administrative Gruppe und listet dort auch die Routinggruppe, meldet aber, es seien keine Routinggruppen im AD zu finden. Das irritiert mich etwas.
Erwähnen sollte ich vielleicht noch, dass die Warteschlangen für den alten Server 'SMTP Gateway X.400 für den MTA' und den 'virtuellen Standardserver für den neuen Server', wo auch die Mails auflaufen, nicht mit einem grünen Kreis mit Haken versehen sind. Auf dem neuen Server hat die Warteschlage für das smtp-X.400 Gateway keinen Haken.

Ok, wir haben also ein Routingproblem. Was nun?

Ich habe die Frage bereits heute Morgen in der MS Community gestellt, aber bis auf den Hinweis, dass das Posting lang sei und ein paar Gegenfragen, die im dem langen Posting längst beantwortet sind, kam leider nichts. Es drängt aber, deshalb hier noch mal das lange Posting:

Wir stellen bei einem Kunden die Domäne von 2000 auf 2003 um und Exchange
ebenfalls von 2000 auf 2003. Alle DCs und sonstigen Server sind auf aktuellem
Stand, Exchange 2000 ebenfalls. Der neue Exchange 2003 Server auf einem
Windows 2003 Mitgliedsserver ist im Netz, forestprep und domainprep
durchgeführt, alle Tools wie dcgiag, netdiag, nsdiag liefern keine Fehler.
Die Installation ist einwandfrei gelaufen, die aktuellen Bereitstellungstools
wurden verwendet. Vorsichtshalber habe ich vorher die verstärkte
Sicherheitskonfiguration abgestellt, Firewall ist aus. Die Migration ist
lange und sorgfältig geplant, bis Ostern soll der neue Exchange Server seine
Arbeit aufgenommen haben und Ostern dann die Domäne selbst auf 2003 migriert
werden. Die Installation ist MS konform als swing Update durchgeführt worden,
exakt wie im TechNet, der einschlägigen Literatur, Internetquellen wie
msxfaq.de und Communities beschrieben. Der Exchange Server hatte bisher nur
interne Postfächer und öffentliche Ordner zu verwalten, es gab keine
Internetanbindung, keinerlei Connectoren oder Scripte, nur einen Server, eine
Routinggruppe, eine administrative Gruppe, nichts, was irgendwelche Probleme
hätte bereiten können. Trotzdem gibt es eins, das mir jetzt gerade den
Zeitplan gehörig durcheinander bringt:

Die test weise verschobenen Postfächer sind verfügbar, die Benutzer können
sich anmelden und Mails verschicken. Mails von Benutzern, die noch auf dem
Exchange 2000 Server residieren, können aber keine Mails an die Benutzer
schicken, deren Postfächer sich schon auf dem 2003 Server befinden. Die Mails
bleiben in der Warteschlange hängen, die Benutzer erhalten eine
Verzögerungsnachricht. Auch die öffentlichen Ordner lassen sich nicht
replizieren, ein neu angelegter Ordner auf dem 2003 Server erscheint aber
sofort auch bei 2000, wenn ich über den Systemmanager des 2003 Servers die
Replikation starte. PFmigrate habe ich bewusst noch nicht eingesetzt, weil ja
irgendwie die Kommunikation von 2000 nach 2003 gestört ist und ich nicht wer
was was für Seiteneffekte auslösen möchte.

Das Exchange Troubleshooting Tool stellt fest, dass die Mails in der
Warteschlange hängen bleiben. Schön. Das wusste ich, deshalb habe ich es ja
benutzt. Zwei Dinge irritieren mich:
Bevor das Troubleshooting Tool feststellt, dass die Mails in der
Warteschlange hängen bleiben, behauptet es, der GC könne den neuen Exchange
Server nicht anpingen. Das stimmt aber nicht. Ich erreiche nicht nur von
jedem DC, egal ob GC oder nicht, als auch von jedem anderen Computer im
Netzwerk beide Exchange Server über IP, über NETBIOS über RPC, egal, ich kann
auch ein Telnet auf den smtp Port machen, es gibt keinerlei DNS Probleme im
Netzwerk, beide Exchange Server, die drei DCs des Hauptstandortes und weitere
wichtige Server hängen zusammen an einem niegelnagelneuen Level 3 managebaren
Gigabit Switch, der wiederum über einen 8Gbit Trunk mit dem Switch Stack
verbunden ist, an dem die Clients hängen. Es ist keinerlei Firewall
dazwischen, keine Port Filter sind irgendwo aktiviert, nichts. Der hierfür
relevante Teil des Netzwerkes ist komplett neu aufgebaut worden und
fehlerfrei.

Die zweite Irritation liefert der System Manager des 2003 Servers. Obwohl
Betriebssystem und Exchange frisch nach Anleitung fehlerfrei installiert und
mit sämtlichen SPs und Patches versehen, stürzt der System Manager gnadenlos
ab, wenn ich irgendeine Hilfefunktion verwende. Sobald ich auf das
Fragezeichen oben rechts oder auf Hilfe klicke oder F1 drücke, stürzt er
gnadenlos ab. Eventlogs sind auf beiden Servern sauber, lediglich der
Exchange 2000 meldet eine Warnung, dass es zu Verzögerungen kommen kann, weil
die Mails ind er Warteschlange hängen. Äh, ja, ich weiss

Bitte um Anregungen, die über "was sagt denn nslookup" hinaus gehen.