addy0604

Hallo zusammen, ich bekomme bald graue Haare und hoffe sehr, das mir jemand weiterhelfen kann. Vor ca. 2 Monaten hab ich die Migration von Exchange 2010 auf Exchange 2016 gemacht und alles lief "eigentlich" relativ geschmeidig. Danach hab ich den alten Mail-Server von Netzwerk genommen und alles lief normal weiter. Auch die Anbindung von Office 2010 und 2016 HB an den neuen Exchange. Um die Migration nun abzuschließen hab ich letzten Freitag den alten Mail-Server wieder ins Netzwerk genommen um Exchange 2010 zu deinstallieren. Seit dem bekommen nun alle Clients beim Start von Outlook eine Zertifikatsmeldung bzgl. Autodiscover (Screenshot 1). Danach laufen zwar die bestehenden Clients weiter, aber neue Office 2016 Clients kann ich nicht anbinden. Ein neuer Benutzer, den ich angelegt hab, kann problemlos ohne Zertifikatsmeldung angebunden werden, nur bei alten Benutzern nicht. Komischerweise will er eine "Microsoft-Anmeldung". Zum Schluss heißt es jedes mal "Leider konnte wir ...". Wenn ich das Outlook-Profil über die Systemsteuerung hinzufügen will fragt er mich nach Login-Daten vom 1und1-Server. Da liegt zwar unsere Domäne und die Mails wurden auch eine Zeit lang dort gehostet, aber seit ca. 5 Jahren empfangen wir die Mails selber. Gibt es bei den alten Benutzern vielleicht noch alte Einträge in irgendwelchen Attributen? Kann das was mit den Zertifikaten zu tun haben? Auf dem alten Mail-Server war nur ein Zertifikat für Webmail drauf. Auf dem neuen Mail-Server hab ich nun extra ein Zertifikat von Comodo für Webmail UND Autodiscover gekauft und installiert. Die oben angesprochene Zertifikatsmeldung bzgl. Autodiscover bei den alten Benutzern hat auch als Aussteller nicht Comodo, sondern das vom alten Mail-Server. Also scheinen ja die alten Benutzer das alte Autodiscover-Zertifikat zu nutzen und nicht das neue. Da bei dem neu angelegten Testbenutzer alles "normal" läuft gehe ich mal davon aus, das der das neue Zertifikat nutzt. Wie kann ich den alten Benutzern verklickern, das sie das neue Zertifikat nutzen? Ich hab es übrigens schon mit unterschiedlichen PCs, unterschiedlichen Benutzern etc. getestet. Outlook-Profile gelöscht und ganze Benutzerprofile gelöscht und getestet. Ich weiß echt nicht mehr weiter... Vielen Dank schon mal für das Kopf zerbrechen. Grüße Matthias

Nee oder? Wie peinlich... Ich habe nur sowas hier gefunden und mich damit abgemüht: Dim Blatt As Worksheet For Each Blatt In ActiveWorkbook.Worksheets Blatt.Protect ("schutz") Next Blatt Aber das ein einfaches Password:="Test" hinter der Zeile ActiveWorkbook.SaveAs ausreicht hätte ich nicht gedacht. Vielen herzlichen Dank :) Grüße Matthias

Hallo Zusammen, ich weiß nicht, ob ich hier beim Scripting mit meinem Problem richtig bin. Es geht eher um Makros in einer Excel-Datei. Ich beschreib mal mein Problem, vielleicht kann ja jemand helfen: Bei mir wird aus einem Hostsystem eine Excel-Datei mit einer Auswertung exportiert. Die Daten sind etwas durcheinander, sollen aber von einer anderen Abteilung weiter verarbeitet werden. Um die Datei also besser lesen zu können habe ich ein Makro erstellt, das den Inhalt etwas aufbereitet (richtige Spaltenbreite, farbige Zeilen etc.) und unter einem Namen mit angehängten Datum abspeichert. Soweit so gut, keine große Sache. Übrigens Excel 2016 auf Windows 7. Nun soll diese Datei aber per Mail an einen Kollegen verschickt werden. Der automatische Mail-Versand ist auch nicht so tragisch, dafür haben wir ein Tool. Allerdings sind in der Datei personengezogene Daten, was unseren Datenschutzbeauftragten auf den Plan bringt. Meine Idee war nun, in dieses Makro die Verschlüsselung mit einzubauen. Mail-Verschlüsselung geht mit dem oben genannten Tool nicht. Ich hab zwar einiges im Internet gefunden und hab auch einiges getestet, aber auf einen grünen Zweig bin ich noch nicht gekommen :( Vielleicht hat ja jemand eine Idee? Grüße Matthias

Hallo, vielen Dank für die Antworten. Ich bin fündig geworden. Mit TCPView (danke an massaraksch) konnte ich sehen, das der Antipam-Prozess vom Kaspersky for Exchange alle paar Sekunden eine neue Verbindung hergestellt, aber die alten nicht freigibt. Sie behalten den Status "Schießen_warten". Ich machen dann mal einen Call bei Kaspersky auf. Dieser Beitrag kann geschlossen werden. Vielen Dank an alle Beteiligten... Grüße Matthias

Hallo djmaker, ich gehe die Sachen morgen mal durch und halte dich auf dem Laufenden...

Guten Morgen zusammen und noch eine gesundes neues Jahr :) Für unseren Exchange hat das Jahr schlecht aufgehört und noch schlechter angefangen. Ich habe nämlich für mein Problem noch keine Lösung gefunden und hoffe, ihr hättet einen Idee. Zu meiner Umgebung: Eine Windows-Domäne mit überwiegend 2008 R2 Servern. Ein Exchange 2010 SP3 (seit einer Woche RU16). Alles virtuell unter VMware. Ende November ist der Exchange nachts stehen geblieben. Im Eventlog stand jede Menge mit "Could not find any available Domain Controller". Backup ist abgebrochen, weil kein Zugriff auf den Server. Keine ein- und ausgehende Mails, keine Zugriff über Outlook oder OWA. Server am nächsten Morgen neu gestartet, alles geht wieder. Das macht er allerdings alle 8 Tage. Mit den Fehlern im Eventlog konnte ich irgendwie keine Ursache finden. Dann bin ich plötzlich über eine "Warnung" gestolpert, die unmittelbar vor dem Abschmieren des Servers ins Eventlog geschrieben wurde: Warnung Ereignis 4227 Tcpip - TCP/IP konnte keine ausgehende Verbindung herstellen.... Nach etwas Recherche bin ich auf den Registry-Eintrag TCPTimedWaitDelay gestoßen und hab ihn, wie in einigen Foren empfohlen, auf 30 gesetzt. Momentan läuft der Server seit 7 Tagen. netstat -a zeigt mir allerdings wieder kiloweise Verbindungen zur Firewall an, die auf SCHLIESSEN_WARTEN stehen, aktuell 65534. Ist das normal? Ich will nicht unbedingt warten bis der Server kommende Nacht wieder stehen bleibt, mein Vorstand steigt mir aufs Dach. Ich habe auch gelesen, das man mit deaktivieren und aktivieren der NIC diese Verbindungen wieder freigeben kann. Ich kann natürlich einen Batch-Datei jede Nacht laufen lassen, die die NIC kurzzeitig deaktiviert. Damit hätte ich zwar das Problem umgangen, aber nicht gelöst. Ich sollte vielleicht noch erwähnen, das etwa zum gleichen Zeitpunkt die Server von der alten VMware 5.1 Umgebung auf neue Hardware und eine VMwaren 6 Umgebung umgehoben wurde. VMware-Tools sind aktualisiert und alle anderen Server laufen völlig normal. Deshalb habe ich das als Ursache "eigentlich" erst mal ausgeschlossen. Ich hab mal ein paar Screenshots mit angehangen, "mhbfw01" ist unsere Firewall (Sophos UTM9) Bin momentan etwas ratlos. Der Server lief bis jetzt völlig problemlos seit mehr als 4 Jahren. Grüße Matthias

Moin Moin, bin mittlerweile bei Veeam fündig geworden https://www.veeam.com/kb1277 Da wird genau mein Problem beschrieben mit einem Lösungsweg. Nur leider funktioniert der nicht so ganz, weil ich die nächste Fehlermeldung bekomme: Naming Information cannot be located because: The specified Domain either does not exist or could not be contacted. Zum Haare raufen... Das Image vom DC1 läuft jedenfalls. Dann werde ich mal alle Rollen auf den DC1 schaufeln und schauen was passiert. Gibt es was besonderes zu beachten bei einer Offline-Verschiebung der Rollen? Gruß Matthias

Hallo zusammen, ich hab hier ein Problem, bei dem ich absolut nicht weiter weiß. Ich hoffe, es kann mir jemand helfen. Folgende Situation: Wir haben 2 DCs (Win 2008 R2) bei uns, DC1 ist physikalisch und DC2 ist virtuell. Beide sind DNS-Server, AD integriert. FSMO-Rollen alle auf dem DC2. Der DC2 wird mit Veeam gesichert, der DC1 mit Acronis plus anschließender Umwandlung in eine VM. In einem anderen RZ testen wir jährlich einmal, ob wir alle Systeme mit den Backup-Medien wiederherstellen können. Bis jetzt gab es nie größere Probleme. Bis gestern... Ich hab per Veeam den DC2 wiederhergestellt. Das hat bis jetzt immer prima geklappt. Diesmal kommt gleich nach dem Booten der VM eine kurze Meldung mit "Directory Service", ist aber gleich wieder weg. Beim Start von AD User und Computer kommt dann die Fehlermeldung: Naming Information cannot be located for the following reason: The Server is not operational. Ich hab ein wenig im Internet geforscht, hab aber bis auf den Beitrag: https://support.microsoft.com/en-us/kb/323542 nix weiter gefunden. Bei dem Artikel geht es um fehlerhafte Einstellung bei der TCP/IP-Filterung. Allerding scheint er für Windows 2000 zu gelten. Außerdem habe ich bis jetzt die Einstellungen bzgl. TCP/IP-Filterung noch nicht gefunden. Hat jemand einen Tipp für mich? Vielen Dank schon mal... Gruß Matthias

Hallo zusammen, mein Chef hat ein neues Hobby: Er will alles, was das BSI vorschlägt, hier umsetzen :suspect: Unter anderem hat er dort gelesen, das sämtlicher Fernzugriff auf das OWA kontrolliert und protokolliert werden soll. Hat jemand eine Idee? Tauchen die Login/Logout am OWA vielleicht im Eventlog auf dem Exchange auf? Das wäre ja schon mal was. Habe bis jetzt leider nix gefunden. Muss man diese Events erst freischalten/aktivieren? Über die FW habe ich jedenfalls keine Möglichkeit :nene: Wir haben übrigens ein MS Exchange 2010 SP3 (ab kommenden WE auch mit RU11). Der Zugriff auf OWA erfolgt ganz normal über ein SSL-Zertifikat. Vielen Dank schon mal Gruß Matthias

Gut zu wissen. Man lernt halt nicht aus... Vielen Dank für die Erläuterungen. Grüße Matthias

Auch wieder wahr... ;) So, die Ordnerumleitung ist raus, im Nachhinein keine große Sache. (Unser Revisor wäre mir trotzdem an den Hals gesprungen...) Wie du vorgeschlagen hast habe ich eine Kopie von der DDP gemacht, die Kopie mit der OU verlinkt und die originale direkt unter die Domäne gehangen. Und siehe da, schon klappt es auch mit dem "maximalen Kennwortalter", zumindest per net accounts /domain auf dem DC2. Ich gehe aber davon aus, das sich die Kennwort-Policy morgen früh bei den beiden Benuztern meldet, deren Kennwort älter als 30 Tage ist. Vielen vielen Dank für die Hilfe. Beste Grüße Matthias

Ich glaub, ich habe mir hier gerade eine größere Baustelle aufgemacht. Der wahrscheinlichste Grund, warum man von der DDP kein Backup machen oder kopieren kann (PowerShell bringt gleiche Fehlermeldung), ist wohl der, das die DDP mal eine Ordnerumleitung beinhaltete, die jetzt nicht mehr gültig ist. Vor etwa 4 Jahren, als ich noch nicht hier war, waren File-Server und DCs auf Win2003. Ich vermute, das dort die Ordnerumleitung irgendwann mal eingerichtet wurde mit Ziel auf den alten File-Server. Mittlerweile gibt es einen neuen File-Server (File1) und neue DCs unter Win2008R2. Die Einstellungen könne logischerweise nicht mehr verifiziert werden, weil die Pfade nicht mehr stimmen, aber ändern kann ich die Einstellungen in der DDP auch nicht, was vermutlich mit dem Wechsel auf Win2008R2-DC zusammenhängt. Hier http://serverfault.com/questions/154588/how-can-i-erase-the-traces-of-folder-redirection-from-the-default-domain-policy habe ich was gefunden, wie man die Ordnerumleitung manuell entfernen kann. Hat zwar etwas von einer Operation am offenen Herzen, könnte aber durchaus funktionieren. Ich könnte auch die Benutzerkonfiguration deaktivieren. Damit würde ich das Problem zwar nicht beheben, aber zumindest umgehen. Ich geb Bescheid wie es ausgegangen ist. Gruß Matthias

Womöglich wollte der frühere Admin damit sicherstellen, das die Kennwortrichtlinien nur auf "richtigen" Benutzer-Konten angewendet werden und nicht auf teilweise administrative Benutzerkonten in der OU Users. Aber soweit ich weiß gelten Kennwort-Richtlinien eh domänenweit, solange in den Benutzer-Accounts nicht der Haken bei "Kennwort läuft nicht ab" gesetzt ist. Oder liege ich da falsch? Ich gehe mal Norberts Vorgehensweise durch versuche die DDP zu kopieren, und schau mal wie ich da weiterkomme... Gebe dann Bescheid... Vielen Dank schon mal Gruß Matthias Hmm, scheint wohl doch nicht so einfach zu sein. Wenn ich die DDP kopieren will kommt die Meldung: Fehler - Die Bibliothek, das Laufwerk oder das Medium ist leer. (siehe Screenshot) Der gleiche Fehler kommt, wenn ich einfach nur ein Backup davon machen will. Es gibt auch einen Eintrag im Anwendungs-Eventlog: Copy of GPO failed. Error [The library, drive, or media pool is empty. Auf meinem Win7 ist die Event-ID 2004, auf dem DC (Win2008R2) ist die Event-ID 2008 Bei allen anderen GPOs geht es problemlos, nur bei der DDP nicht... Mir gefällt das immer weniger... :(

Guten Morgen, tschuldigung, das ich mich erst jetzt melde. Hatten letzte Woche einiges um die Ohren... Also: Das mit dem Zeilenumbruch kam mir auch komisch vor. Im Editor sah es noch "normal" aus. In der Vorschau waren die Zeilenumbrüche schon weg und in der Live-Umgebung auch. Ich arbeite i.d.R. mit dem IE. Eine Zeit lang hatte ich den IE 11 drauf. Nach Problemen mit der Anzeige bei einigen Web-Anwendungen hab ich wieder den IE 10 drauf. Ich arbeite auf einem Win7 x64, kein Copy-Paste. Zu meinem Problem. Die Default Domain Policy hat ja irgendwann mal funktioniert, weil die entsprechenden Einstellungen bei "net accounts /Domain" angezeigt werden. Spanisch kommt mir auch vor, das die Policy nicht nur umbenannt, sondern auch verschoben wurde. Ich kann mich an früher bei Windows 2000 Domänen erinnern, das die beiden Haupt-Policy's immer direkt in der Root der Domäne stehen sollten/mussten. Ist das nach wie vor so? In der momentanen Umgebung ist es jedenfalls so, das die Default Domain Controllers Policy mit der OU "Domain Controllers" verknüpft ist, in der nur die beiden DCs liegen. Die Default Domain Policy war umbenannt (siehe oben) und ist mit einer OU verknüpft, in der (aufgeteilt in weitere OUs) alle User-Konten und alle PC-Konten liegen (siehe Screenshots). Ich habe nun die Default Domain Policy wieder in den richtigen Namen umbenannt, aber Änderungen darin werden beim Aufruf von "net accounts /Domain" nicht angezeigt, auch nach Neustart des PCs nicht. RSoP habe ich auf dem DC2 ausgeführt, der auch alle Betriebsmaster hat, auch PDC-Master. Dort wird aber angezeigt, das die Kennwort-Policys gar nicht definiert sind! Kann das damit zusammenhängen, das die Policys nicht direkt mit der Domäne, sondern mit einer OU verknüpft ist? Ich habe mal ein paar Screenshots gemacht und mit angehangen, um es etwas zu verdeutlichen. Die beiden DCs habe ich bis jetzt noch nicht neu gestartet... Gruß Matthias

Die ID passt, es ist also dir richtige Policy. Bei gpresult /r ist zu erkennen, das sie sowohl bei Computer- als auch bei Benutzereinstellungen angewendet wird. Ich werde sie heute Abend nach Feierabend mal umbenennen und schauen was passiert. Gebe morgen Bescheid... Vielen Dank schon mal Gruß Matthias

Hallo Nils, Danke für die Erläuterungen. Sie machen wirklich Sinn und ich werde mit Sicherheit auch einige Werte entsprechend anpassen. Was die "Default Domain Policy" angeht, so ist es zumindest die einzige in der Domäne, die so heißt. Auch wenn Sie "Default Domain Policy 2004" heißt. Allerdings sagt "net accounts /domain" etwas anderes. Da heißt es plötzlich: "Maximales Kennwortalter 60 Tage". Kann es am Namen der Policy liegen, das die Änderungen nicht übernommen werden? Kann es sein, das mein Vorgänger die Kennwortrichtlinien eingerichtet hat und danach (aus welchem Grund auch immer) die "Default Domain Policy" umbenannt hat? Ich kann sie ja einfach mal "zurück umbenennen". Siehst du da irgendwelche Risiken? Gruß Matthias

Ich hatte es ehrlich gesagt nicht explizit getestet. Werde mal einen Testuser anlegen. Alle anderen pflegen ihr Kennwort anscheinend gewissenhaft, es kamen jedenfalls keine Beschwerden. Ich habe einen Screenshot von der GPO angehangen. Wäre es denn so ok wie es dort eingestellt ist? Ich lasse den Benutzer mit dem 49-Tage-Kennwort mal noch 11 Tage. Wenn das Kennwort dann abgelaufen ist, wurde die neue Einstellung anscheinend noch nicht richtig übernommen.

Hallo Zusammen, ich habe hier ein Problem mit Kennwörtern, die eigentlich abgelaufen sein sollten, aber trotzdem noch funktionieren. Wir haben hier eine normale Windows-Domäne mit Win2008R2-DCs und einer Kennwortrichtlinie (hat mein Vorgänger eingerichtet) in der Default Domain Policy, die besagt, das die Kennwörter alle 60 Tage geändert werden müssen. Da es damit nie Probleme gab, wurde auch nichts geändert. Seit neusten sollten die Kennworte aber alle 30 Tage geändert werden (neue betriebliche Vereinbarung). Ich hab also den Eintrag "maximales Kennwortalter" in der Policy von 60 auf 30 Tage geändert. Heute erfuhr ich, das manche Kennworte wohl älter sind. Das Ganze mit pwexpire geprüft und siehe da, ein Kennwort ist 34 Tage und ein anderes 49 Tage alt. Beide PCs werden täglich neu gestartet, beide Benutzer können sich nach wie vor normal an der AD anmelden, kommen auf alle Netzlaufwerke, Outlook inkl. ein- und ausgehender Mails gehen auch. Habe ich was vergessen? Muss an anderer Stelle noch was eingestellt werden? Oder muss noch etwas resetet oder neu gestartet werden? Ich will nur, das sich ein Benutzer nicht mehr an der Domäne anmelden kann, wenn sein Kennwort älter als 30 Tage ist. (Der Haken "Kennwort läuft nie ab" ist draußen.) Vielen Dank schon mal Grüsse Matthias

Entschuldigung, das ich mich jetzt erst melde. Ich war kurzfristig in eine andere Geschichte eingebunden...Danke erst mal für die konstruktiven Vorschläge.Ich bevorzuge in der Regel auch lieber eine alternative Lösung, als lange an einem Problem zu basteln. Aber es hätte ja auch nur eine Kleinigkeit sein können, die ich einfach übersehen hab.Nun gut, jedenfalls hab ich das Skript mal in den NETLOGON-Ordner vom DC gepackt und plötzlich wird das Skript auch über den UNC-Pfad ausgeführt. Ich hab den Pfad in der GPO geändert und lass das erst mal so. Falls es wider Erwarten erneut zu Problemen führen sollte, werde ich das mit der lokalen Skript-Ausführung einrichten.Besten Dank für die Hilfe.GrüßeMatthias Hallo, ich noch mal,hab es eben erst geschnallt, das Skript von der Blogspot-Seite ist von dir Martin.Vielen Dank das du es veröffentlicht hast. Hat mit Sicherheit vielen geholfen, die sich mit abgelaufenen Benutzerkennwörtern herumschlagen müssen.Ich hatte es übrigens in der GPO unter "Diese Programme bei der Benutzeranmeldung ausführen" eingetragen. Allerdings mit UNC-Pfad auf ein freigegebenes Verzeichnis auf dem File-Server.Wie gesagt, vom NETLOGON aus funktioniert es prima.GrüßeMatthias

Hallo Sunny61, danke für die schnelle Antwort. Ich weiß momentan nicht, was du mit Zone meinst. Ich gebe in der Explorer-Leiste ganz normal den UNC-Pfad an, \\servername\freigabename\dateiname Ich kann die Fehlermeldung halt nicht nachvollziehen. Wie es aussieht kann wohl nur der Windows Skript Host Prozess nicht auf die Datei zugreifen. Ich will die Geschichte halt nicht unnötig verkomplizieren und erst eine Datei rumschicken und dann dort lokal ausführen.

Hallo zusammen, ich bin oft hier im Forum und habe auch schon manche Lösung gefunden. Dafür schon mal vielen Dank. Aber nun habe ich ein Problem, da habe ich bis jetzt noch nichts gefunden. Ich weiß auch nicht, ob ich hier überhaupt richtig bin. Es geht zwar um ein Skript, aber nicht um den Inhalt, sondern um die Ausführung. Ich habe hier folgende Umgebung: Windows 2008 Domäne, alle Server und DCs Win2008R2, mehrere Subnetze, wird alles über Cisco-Switche geroutet. Alle WS sind Win7 x64. Alles Standard-Komponenten, nix dramatisches. Nun hab ich im Internet ein VB-Script gefunden, das ein wenig komfortabler dem Benutzer bei der Anmeldung eine Meldung bringt, wenn sein Kennwort kurz vor dem Ablaufen ist. Ich hab eine GPO gebastelt, damit das Script bei der Anmeldung ausgeführt wird. Angegeben habe ich das Script mit UNC-Pfad. Ich hab vor ca. 2 Wochen in einer Testgruppe eingerichtet und lief bis gestern tadellos. Seit gestern bekomme ich bei der Anmeldung die Fehlermeldung: Die Skriptdatei "\\fileserver\Skript.vbs" wurde nicht gefunden. Ich habe mal ein wenig rumgetestet und das komische ist, das die Meldung nur kommt, wenn ich über den UNC-Pfad auf die Datei zugreife. Wenn ich das Skript lokal per Doppelklick ausführe geht es. Wenn ich die Datei von einem verbunden Netzlaufwerk aus starte, geht es auch. Nur wenn ich über den UNC-Pfad darauf zugreife, kommt die Fehlermeldung. Server und Workstation sind schon mehrfach neu gestartet. Stehe momentan völlig auf der Leitung, wo das Problem sein könnte. Zumal es 2 Wochen lang ging und nun nicht mehr. Hat vielleicht jemand eine Idee? Grüße und Danke schon mal Matthias Screenshot der Fehlermeldung

Ich hab den Dienst angehalten und deaktiviert, sollte "eigentlich" nichts damit zu tun haben... Ich hab mal ein wenig weiter gebastelt und das lokale Outlook Profil gelöscht und ein neues erstellt, aber im online-Modus. Da tut Outlook jetzt das was es machen soll. Ich lösche mal die ost-Datei und lege das Profil im Cache-Modus neu an. Mal schauen, was da passiert. Außerdem ist lokal überall ein AddIn von Siemens für die Telefonanlage (OLI/myPortal) drauf. Laut Google hat es sich in der Vergangenheit wohl auch schon recht zickig verhalten. Gruß Matthias Hmpf, da war die ost-Datei wohl im Ar.... Profil jedenfalls im Cache-Modus neu angelegt, nun geht's wieder normal. Aber gleichzeitig auf 5 PCs von 23? Seeeehr merkwürdig.... Ich prüf das mal auf den anderen PCs. Aber wenns bei mir geklappt hat "sollte" es bei den anderen auch klappen Gruß Matthias

Hallo alle miteinander, ich habe seit heute früh ein Phänomen, da komme ich echt nicht weiter. Ich hab ein Exchange 2010 SP3 und auf allen Clients Office 2010, Windows 2008 Domäne. Es ist eine virtuelle Maschine mit 8 GB RAM. Heute früh kam ein Kollege und meinte, eine Mails steht im Postausgang und geht nicht raus. Nach einigen Überprüfung der Dienste (alle normal), Server trotzdem neu gestartet und einigen Testmails kristallisierte sich folgendes Szenario heraus: Ausgehende Mails werden nur verschickt (egal ob extern oder intern), wenn eine Mail im Postausgang steckt, d.h. wenn der Postausgang leer ist, bleibt die erste Mail, die verschickt wird (egal ob extern oder intern) dort stecken. Alle weitern Mails werden normal verschickt, egal ob extern oder intern. Aber sobald ich diese stecken gebliebene Mail aus dem Postausgang lösche, bleibt die nächste sofort wieder stecken. Aber halt wieder nur die erste, alle anderen danach werden wieder normal übertragen Hat jemand eine Idee, was das sein könnte??? Den Kaspersky 8.0 für Exchange hatte ich im Verdacht, weil der nach der Installation vom SP3 Probleme gemacht hatte. Aber das Update wurde eingespielt und hat bis heute früh auch keinerlei Probleme mehr gemacht. Eingehende Mails normal. Ich bin echt ratlos. Danke fürs Gedanken machen Gruß Matthias

So, letzter Status, um den Fall abzuschließen... alles läuft wieder normal. KAV 8 für Exchange installiert, Patch installiert (manueller Tausch einer Handvoll dll's) Büchse noch mal neu gestartet, alles geht wieder. Vielen Dank an alle Gruß Matthias

Das ist in der Tat noch ein altes Relikt von meinem Vorgänger. Ich bin noch nicht dazu gekommen mich damit zu beschäftigen. So was hab ich bis jetzt noch nicht gemacht. Muss ich mich erst noch reinlesen, wo welche MX-Records gesetzt werden. Aber alles nacheinander ;) Gruß Matthias Wohl dem, der so ein Lappy hat. Mein Chef ist sogar zu knausrig für ein Headset fürs Telefon. Das ist nicht lustig, wenn du stundenlang mit diversen Hotlines telefonierst und hast den Hörer zwischen Kopf und Schulter eingeklemmt :mad: Aber du hast Recht. Ich denke ich werde es heute nach Feierabend machen, da nervt keiner mehr :D Ich geb Bescheid, wie es gelaufen ist... Gruß Matthias