Stefan W

Du kannst es natürlich so machen. Hat natürlich den einen RIESENVORTEIL: Du hast alles selbst gemacht, kannst es sauber dokumentieren und weißt was wo wie wann gemacht wurde, und brauchst keine externe Firma mehr. Doch das große Aber: wenn du bei Exchange sehr wenig bis garkeine Erfahrung hast, wird dich durch die Downtime wahrscheinlich dein Chef mit Haut und Haaren fressen :) zu monstamanias Punkt D: Das sehe ich nicht so, ich glaube du lernst dabei mehr, als bei einer Migration - vorallem was Abhängigkeiten betrifft. Nur in einer Produktivumgebung soetwas zu machen erfordert sehr viel Mut und Zeit :) Wobei: Mut ist in dem Fall Risiko

sorry - hab ich wohl überlesen :)

Die GF weiß, dass die MA das tun? Bevor ich hier einen Finger rühre, würde ich das Thema mit der GF besprechen. Ich gehe davon aus, dass den MA aufgetragen wird, alle Daten auf einem Server zu speichern. Demnach würde ich ihm den PC neu aufsetzen, den Zugang für seine Programme schaffen (zB auf seinen lokalen Datenträger kopieren) und ihn alles selbst machen lassen.

Hi, evtl hilft dir das Aufbewahrungsrichtlinientag setzen - alle anderen Ordner im Postfach - Aufbewahrungszeig 0 Tage, bei Verfallszeit endgültig löschen Aufbewahrungsrichtlinie erstellen - Aufbewahrungsrichtlinientag auswählen, Postfach auswählen. Ob das mit den 0 Tagen funktioniert kann ich nicht sagen, wir haben einige Postfächer mit 7 Tagen konfiguriert, da funktioniert es prächtig. lg Stefan

was du testen könntest: deaktiviere in der msconfig - Dienste alle nicht-Microsoftdienste, unter Systemstart alles was nicht mit MS zu tun hat, weg. Wenn es dann geht, kannst du sukzessive die einzellnen Haken wieder setzen, bis es nicht mehr funktioniert. lg

Bei uns in der Firma war es leider üblich dass der Übergang zwischen Test zu produktivsystem natlos ging (die verschiedensten testserver - zB Sharepoint) Das führte zu einigen großen, und mehreren kleinen Problemen. Wenn du es in einer Testumgebung machst, und es klappt, mach das gleiche in der Produktivumgebung. Verlass dich nur nicht zu sehr auf deine Tests. Wie in einem anderen Beitrag auch NorbertFe schon gesagt hat: alles was in einer Testumgebung funktioniert, wirft in der Produktivumgebung Fehler :) lg

gratulation :)

Hi, Wir haben ein selbst geschriebenes Ticketsystem. Dort werden E-Mails zu diesem Thema angehängt. Mit SQL wird auf Outlook zugegriffen, nach ungelesenen Objekten mit einem String im Betreff gesucht, die Mail zum "Kunden" (der im Betreff mit Nummer steht) in der DB gespeichert, und die Mail als gelesen markiert. Ich kann mir vorstellen, dass dir das auch helfen kann. lg

Hi, hast du eventuell eine coexistenz von mehreren Visual Studio Versionen drauf? die machen bei uns Probleme mit RDP. Welche SW läuft am Rechner, abgesehen von Standardsoftware wie Office, Adobe Reader etc.? lg Stefan

Hi hast du Erfahrung mit SQL? damit kannst du zB aufs Outlook zugreifen und die Mails abarbeiten und in eine DB schreiben. lg

was? ich glaub ich habs nicht geschnallt :P

ok, danke für die Info. Herausnehmen kann ich dies erst, wenn ich nur mehr einen Exchangeserver habe (der 2003er läuft noch mit exakt einem Postfach - dem der GF, der hat gefühlte 20.000 Geräte die auf den neuen ActiveSync bzw Outlook Anywhere Pfad umgeändert werden müssen - dafür hat er keine Zeit :/)

Ich habe 2 empfangsconnectoren einmal name: Default Exchange01 fqdn: exchange01.intern.local name: Client Exchange01 fqdn: exchange.firma.com Am Default kann ich jedoch den FQDN nicht ändern, da ich hier noch die Berechtigung "Exchange Server" dürfen sich anmelden aktiv hab

hab gerade gemerkt, dass er irgendwie komisch antwortet. telnet exchange.extern.com 25 220*****... helo test 250 internerservername.local Hello [iP] sollte er, wenn ich im Client empfangsconnector und im sendeconnector den externen FQDN angegeben habe, nicht mit diesem antworten? lg

Danke, diese Antwort wollte ich hören :)

Das ist das was ich angesprochen habe - bei ausgehenden Mails den Header löschen :)) nur hatte ich es aus diesem Link Removing Exchange 2007/2010 Internal Headers · Tech Snippets

Ok, Wenn ich in einer Transportregel, aus dem Unternehmen ausgehend, den header entferne: Kann dies zu Problemen (zB als SPAM markiert zu werden) führen? Denn durch die Transportregel, wäre dann nur noch die MessageID die den internen Namen führt lg Stefan

Hi, Zum Beispiel, dass du deine Produktivumgebung, die du hast dann in einer nicht so abgesichterten "Testumgebung" hast. Zum Anderen ist es schon mehrfach passiert, dass man denkt auf der Testumgebung zu arbeiten, aber in wirklichkeit an der Produktivumgebung arbeitet - sieht ja gleich aus. Des Weiteren soll ja eine Physische Maschine virtualisiert werden. Was offline geschieht (oder redest du von einem online P2V?) was somit auch Downtime hervorruft. Aus dem Beitrag lese ich heraus, dass die Umgebung klein bis kleinst ist, und somit sehr leicht und schnell nachgebaut ist. lg

Hi da hab ich schon geschaut. Hab einen neuen Beitrag diesbezüglich erstellt. http://www.mcseboard.de/ms-exchange-forum-80/2010-mailheader-187799.html lg

DAs Problem liegt darin, dass die GF nicht wünscht, dass der interne Servernamen nach draußen geht lg

Korrektur: Zusammenfassung hat nur auf mich zugetroffen :)

Hallo Ich stehe vor dem Problem, dass im Mailheader einmal der richtige, und einmalder falsche FQDN wiedergegeben wird Delivered-To: extern.test@gmail.com Received: by 10.49.73.129 with SMTP id l1csp18763qev; Mon, 30 Jul 2012 23:08:56 -0700 (PDT) Received: by 10.180.87.232 with SMTP id bb8mr46313wib.0.1343714936123; Mon, 30 Jul 2012 23:08:56 -0700 (PDT) Return-Path: <prvs=45594B1C72=stefan@firma.com> Received: from [color="SeaGreen"]exchange.firma.com[/color] (exchange.firma.com. [105.143.91.138]) by mx.google.com with ESMTP id fj2si6214198wib.47.2012.07.30.23.08.55; Mon, 30 Jul 2012 23:08:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of prvs=45594B1C72=stefan@firma.com designates 105.143.91.138 as permitted sender) client-ip=105.143.91.138; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of prvs=45594B1C72=stefan@firma.com designates 105.143.91.138 as permitted sender) smtp.mail=prvs=45594B1C72=stefan@firma.com Received: from [color="Red"][b]EXCHANGE01.intern.firma.local[/b][/color] ([2002:ac64:6363::ac64:6363]) by EXCHANGE01.intern.firma.local ([2002:ac64:6363::ac64:6363]) with mapi id 14.02.0309.002; Tue, 31 Jul 2012 08:08:30 +0200 From: Stefan <stefan@Firma.com> To: Stefan <extern.test@gmail.com> Subject: test 124 Thread-Topic: test 124 Thread-Index: Ac1u4uJ2PqxJcd6mSVeqgieScCMW/g== Date: Tue, 31 Jul 2012 06:08:29 +0000 Message-ID: <223889B374F56B46951A8964679C1728010FB3@[color="Red"][b]EXCHANGE01.intern.firma.local[/b][/color]> IP Adressen wurden natürlich verändert, somit ist ein telnet smtp mit den Daten nicht möglich. auch bei Telnet verwendet er den internen Namen. Die Helo Antwort ist jedoch richtig gesetzt. lg Stefan

Hi, zur vollständigkeit: Mag Exchange das Zeichen @ im Mailnickname auch nicht mehr? lg

hi Server nur in Netzwerk B, eventuell mit DMG (oder dem ReverseProxy deines Vertrauens) dort hin gehen. natürlich wie oben genannt ein NAT/PAT (wobei ich persönlich nicht das originalport nehmen würde, sondern via PAT translaten) lg Stefan

hi, kann er die MS Seiten richtig auflösen mit nslookup? kommst du via onlineproxy hin? (zB Backfox) ? lg