jensw_2000

Juhu! Die "Bauchgefühl-Richtung" stimmt. Mit einem weichen Zeilenumbruch (ASCII 10) wird die Nachricht versendet. Also mit <ALT+RETURN>.<ALT+RETURN> ... Das Gleiche mit Putty. Ich habe gerade mal den Wireshark Portable mitlaufen lassen. HEX: 0D 0A 2C 0D 0A (dez. 13 10 46 13 10 >> CR LF . CR LF) versendet die Nachricht nicht. HEX: 0A 2C 0A (dez. 10 46 10 >> LF . LF) versendet die Nachricht. Der Exchange erwartet also ein falsches CRLF ... Offenbar bleiben die ausgehenden Mails von den Kopierern und vom Backup Monitoring genau deshalb hängen. Das trace ich morgen nochmal mit, wenn der Kunde vor Ort ist. Jetzt bin ich aber noch ratloser. Wie kann man Das korrigieren? Nach 'sowas' googeln ist nahezu aussichtslos :schreck: Ist leider doch der falsche Ansatz.... Mit dem Zeilenumbruch hängt das Kernproblem nicht zusammen. SMTPDiagPro von Stefan Kittel versendet die Mail auch mit ". 0D0A" also CR LF. Ich mache wohl besser einen Vorort Termin und trace den SMTP Traffic von allen Kopierern per Wireshark. Die Backup Statusmail geht nicht raus, weil die Software fehlerhaft ist. Die sendet das SMTP Command "DDATA" anstatt "DATA" und wartet stur auf ein OK vom Exchange. Das OK kommt natürlich nicht. Der Exchange antwortet auf den falschen Befehl jedoch richtiger Weise mit "500 5.3.3 unrecognized command" ...

Greifbare Ideen habe ich auch schon länger nicht mehr. Von meinem Bauchgefühl her hat das Problem nichts mit AV, Security oder Netzwerk zu tun. Telnet nimmt soweit ja alle SMTP Kommandos an. Nur das <return>.<return> löst bei dieser Exchange Installation eben nicht das Versenden der Message aus. Der Punkt erscheint in der Telnet Commandline. Vielleicht doch eher ein Zeichensatzproblem. Das CRLF ist ja auf "deutsch" ASCII-13 + ASCII-10. Eventuell erwartet dieser Exchange aus irgendwelchen Gründen aber einen weichen Zeilenumbruch (nur ASCII-10) oder einen "Linux Zeilenumbruch" (nur ASCII-13) zum Absenden der Message (<return>.<return>). Der Server (Fujitsu Primergy RX300 S7) hängt über 2 geteamte Broadcom Karten im LAN (Teaming über das Windows Server 2012 R2 NIC Teaming). Der Kartentreiber bzw. das NIC Team wird beim Zugriff über 127.0.0.1 aber auch nicht verwendet, wenn ich das von meinen MCSE / MCNE Kursen damals noch richtig in Erinnerung habe. Falls meine grauen Zellen noch ein bisschen funktionieren läuft Loopback nur über OSI Layer 2-LLC. "Netzwerkkarte und -treiber" auf OSI Layer 2-MAC gibt's dort glaube ich nicht. Der MAC Layer wird in diesem Fall im TCP Stack emuliert. Außer dem Exchange Server läuft 'nichts weiter auf der Maschine'. Nur das Nötigste. Windows Server 2012 R2, Backup Agent, AV Client, Exchange 2013 mit CU12, Fujitsu Serverview Agent und Serverview RAID.

Der läuft klassisch auf Blech.

Moin Norbert, ja, da antwortet wirklich der Exchange, s. Attachment. Sunny, danke dass Du dich mit einbringst. Aber sorry ... zählen wir eventuell ein bisschen Erbsen? :schreck: :D Also : Problem 1:1 reproduzierbar mit: > deaktiviertem AV Client > deinstalliertem AV Client > Telnet via Localhost IP > neu installiertem AV Client > wieder aktiviertem AV Client > neben dem AV Client gibt es keine andere Security Software auf dem Host CU12 habe ich gestern installiert. Das ändert leider auch nichts am Fehlerbild.

Hi, nein, da hängt ganz sicher keine AV Software oder etwas Vergleichbares zwischen. Ich kann das Problem direkt in der CMD auf dem Exchange mit aktiviertem und deaktiviertem AV Client nachstellen. Sogar über die Localhost IP. Port 25 hört nur die "MSExchangeFrontendTransport.exe" ab. KB3108023 ist noch nicht installiert. Das kann ich übers Wochenende nachholen. Der Exchange läuft noch mit CU11.

Ich würde da gerne nochmal nachfragen .... ;) Hat vielleicht jemand noch eine Idee, warum das <Return>.<Return> nicht angenommen wird? Ist das vielleicht ein Spracheinstellungsproblem auf dem Server? Vielleicht erwartet der einen anderen Zeilenumbruch als CRLF...

21 von 80 GB sind auf C: frei. Im Eventlog wird nichts geloggt, wenn ich die Mail per Telnet tippe und return.return tippe. Im SMTP log steht das komplette Protokoll vom HELO bis zum DATA. Das "Message queued for delivery" wird auch nicht geloggt. Stattdessen kommt irgendwann ein Timeout oder Cancel, je nachdem ob ich auf den Abbruch warte oder das Telnet Fenster hart beende. Hoops! Sorry. Falscher Server ;) Auf C: sind 196 von 280 GB frei Um das mal konkret zu zeigen hängt noch ein Screenshot dran.

Ja, der Trend Micro Worry Free Business Security Client. Der Problem tritt aber auch auf, wenn ich temporär alle Funktionen des AV Clients deaktiviere. Trend Micro WFBS haben wir auch bei vielen anderen Kunden im Einsatz. Dort kann ich Mails per Telnet versenden und es gibt keine vergleichbaren Probleme.

Moin, ich habe beim Exchange Server eines Kunden das Problem, dass einige SMTP Clients beim Senden von Emails 'hängen' und die Mails nie versendet werden. Bei einigen Kopierern klappt es tadellos, andere versenden keine Mails. Auch die eingesetzte Backup Software kann keine Statusmails über diesen Exchange SMTP versenden und hängt 5 Minuten beim Versenden einer Testmail. Um den Fehler einzugrenzen habe ich versucht, eine Testmail über Telnet zu versenden. Der Protokollablauf vom HELO bis zum DATA klappt problemlos. Nach dem DATA kommt wie erwartet die Antwort: "354 Start mail input; end with <CRLF>.<CRLF>" Jedoch wird das RETURN . RETURN nicht angenommen. Normalerweise kommt danach "OK. Message queued for delivery". Bei diesem Server kann ich RETURN . RETURN eingeben bis ich grün werde. Es werden lediglich Punkte in den Messagetext eingefügt (mit Zeilenumbruch). RETURN . RETURN führt aber nicht zum Versenden der Mail. Ich denke, dass die hängenden SMTP Clients ihre Mails auf die gleiche Art versenden und ebenfalls vor dem Problem stehen, dass nach dem RETURN . RETURN nicht das erwartete Statuscode "200 OK. Message queued for delivery" zurückkommt. Was hat dieser Exchange Server für ein Problem? So einen Effekt hatte ich bisher noch nie. Der Fehler ist direkt auf dem Exchange Server mit deaktiviertem Antivirus reproduzierbar. Es hängt dann nichts mehr dazwischen. Bei den Exchange 2013 Servern anderen Kunden funktioniert das tadellos. Da kann ich dieses Problem nicht reproduzieren. Gruß Jens

Hallo Daniel, ich habe mir jetzt einen USB Installationsstick erstellt und auf einem Windows 8.1 Referenz-PC den RAID Treiber per "DISM /Add-Driver .." in die WIM's auf dem USB Installationsmedium integriert. Das hat soweit geklappt. Wenn ich von USB boote und Diskpart aufrufe, dann werden mir alle Disks (incl. der RAID Disks) angezeigt. Der integrierte Treiber funktioniert also. Ich könnte das Windows Setup vom Stick starten, jedoch ohne Übernahme meines Windows 7 Profils und der Anwendungen. Das will ich nicht ... :shock:. Ich wäre Wochen damit beschäftigt meine Entwicklungsumgebungen wieder so einzurichten, dass ich produktiv weiterarbeiten könnte. Wenn ich das "gewünschte" Inplace Upgrade, aus Windows 7 heraus, von dem modifizierten USB Stick starte, dann habe ich exakt den gleichen Effekt wie vorher. Die Integration des RAID Treibers wird durch die "Inplace Upgrade Vorbereitung" vergessen und die RAID Disks sind nach dem Reboot ins Windows 8.1 Setup nicht mehr zu sehen. Das Inplace Upgrade greift beim Reboot auch nicht auf den USB Stick zurück. Daher nützt der hinzugefügte Treiber hier offenbar nicht viel. In der vom Setup präparierten Bootumgebung (Win PE) fehlt mein RAID Treiber in SYSTEM32\DRIVERS. Die RAID Laufwerke fehlen und das Setup kann nicht fortgesetzt werden ... Haben die Jungs aus Silicon Valley den Mann, der die "F6" Taste im Windows Setup programmiert hat in Rente geschickt? Im normalen Windows 8.1 Setup kann ich Storagetreiber bei Bedarf manuell nachladen. Dieser Mechanismus fehlt beim Inplace Upgrade. Wo legt das Setup, dass ich unter Windows 7 starte, die Boot.wim (bzw. die Setup "Bootumgebung") ab? Kann ich dort eventuell noch vor dem Start des zweiten Setup Abschnittes den RAID Treiber dazumogeln? Daniel, hast Du noch eine Idee? Google hilft mir nicht weiter und der MS Supporter, den ich hinzugezogen habe, ist leider auch ziemlich am Ende mit seinem Latein. PS: Schade, dass ihr keine Technet Events in Hamburg mehr macht. Das waren echt schöne Zeiten, als es noch echte Live-Events von euch gab. Die Webcasts gehen zur Not auch, sind aber definitiv kein adäquater Ersatz für Vorträge von Dir, Steffen Krause, Ralf Schnell u.v.a. ... Grüße Jens

Moin, das Windows 8.1 Inplace Upgrade macht mich fertig. Ich starte unter Windows 7 das 8.1er Setup und wähle die Option "nur persönliche Daten behalten" und lasse das Setup nach Updates suchen. Das Setup läuft dann ohne Warnungen bis 100% hoch und bootet den PC. Nach dem Neustart läuft der Rechner in das Windows Setup. Dort gibt es nach der Sprachauswahl gibt es nur die beiden Optionen "Problembehandlung" und "PC herunterfahren". Das Einzige das mir zum Installieren des Updates noch gerade so plausibel erscheint ist der Weg "Problembehandlung >> PC auffrischen". Das Setup bricht dort aber mit folgender Meldung ab: Ich habe dann tagelang die Bitlocker Verschlüsselung von allen meinen Laufwerken entfernt, die versteckte Startpartition auf 1 GB vergrößert, sichergestellt, dass es nur eine aktive Partition im System gibt, mein Windows 7 mit SFC /scannow überprüft, MSXML 6 neu installiert und bin jedem verdächtigen Log-Eintrag hinterhergegooglet. Nichts... Windows 8.1 Setup meint ich soll mein Laufwerk entsperren und es neu versuchen. In der Commandline, die man aus dem 8.1er Setup aufrufen kann habe ich nun festgestellt, dass der RAID Treiber meines Areca 1231 offensichtlich nicht geladen wurde. Der unter Windows 7 (x64) installierte Treiber ist signiert und aktuell. Diskpart > LIST DISK zeigt mir meine Windows 7 HDD (die an dem RAID Controller hängt) nicht an. BootRec /ScanOs läuft durch und findet keine Windows Installationen. Dummerweise finde ich im Windows 8.1 Setup keine Möglichkeit den RAID Controller Treiber nachzuladen. Boote ich den PC danach wieder, dann läuft das Rollback zum Glück sauber durch und mein Windows 7 ist wieder heile. Unter Windows 7 habe ich alle Laufwerke mit DISKPART > "ATT DIS" überprüft. Es gibt keine Laufwerke die "aktuell schreibgeschützt" oder "schreibgeschützt" sind. Chkdsk bringt ebenfalls keine Fehler. Kann mir jemand helfen oder muss ich den MS Support hinzuziehen? Wäre schade dafür einen Technet Freecall zu opfern, nur weil dieses 8.1er Setup derart missglückt ist ...

Bis alle Komponenten unserer Website Joomla 1.6 kompatibel sind ist die Site leider offline. Link entfernt von blub

Hallo, der AdsScripter funktioniert unter Server 2008 und 2008 R2. Dafür sind auch keine "Tricks" oder Änderungen in Doing nötig. Bei der Betriebssystem-Auswahl im AdsScripter wählt man einfach "WIN2003" aus und kann alle Felder wie gewont setzen. Ein Hinweis ggf. noch für Server 2008 R2. Das in 2008 R2 hinzugekommene Attribut "Objekt vor versehentlichem Löschen schützen", das beim manuellen erstellen von Objekten per Default aktiv ist, wird durch den AdsScripter nicht gesetzt. Benutzer, Gruppen und OUs, die durch den AdsScripter erstellt wurden, können also ohne weitere Aktionen per "Rechtsklick >> Löschen" gelöscht werden. Den "Löschschutz" kann man auf Wunsch später individuell per "AD Benutzer und Computer" auf den Objekten setzen. Grüße, Jens

Unter Win2003 gibt es eigentlich keine bekannten Probleme. Bist du so nett und schickst mit ein paar Informationen zu dem Problem an meine Support-Email (support@innovasoft.de)? Dann sehe ich mir das gerne mal an. Besonders interessant wären: - Screenshots von den AdsScripter Einstellungen - XLS - kurze Beschreibung der AD Struktur - Welche OUs und Gruppen existieren, welche soll der AdsScripter erzeugen ? - Schön wäre ein CScctipt Log (Script mit der CScript.exe starten und in Textdatei umleiten). MFG Jens

Hast du das Problem unter Windows Server 2008? Ist mir in diesem Fall schon mal zu Ohren gekommen ....