-hannes-

Hallo, wir haben einen Server 2003 R2 x86 Standard mit allen SPs und Updates. Auf dem Server läuft Blackberry Express Version 5.x. Vergangene Woche habe ich manuell Windows Updates installiert. Problem ist, dass der Server anschließend nicht richtig runter gefahren ist. Ich musste mich erst noch einmal Remote anmelden. Hier war dann nur der blaue Bildschirm ohne jegliche Meldung zu sehen und nach drücken einer beliebigen Taste, startete der Server dann korrekt neu. Dumm ist, das ich den Fehler erst später bemerkte und zwischendurch niemand mehr Mails über BB zugestellt bekommen hat. Für die Zukunft würde ich diesen Fehler gerne abstellen. In der Ereignisanzeige steht aber leider nur: EventID: 7023 Quelle: Service Control Manager Beschreibung: "Der Dienst Config Installer, Microsoft Driver und Center Manager wurden mit folgendem Fehler beendet --> Das angegebene Modul wurde nicht gefunden" Die Meldung wird mit der gleichen ID und Quelle für die 3 Dienste jeweils 1x mit der gleichen Beschreibung ausgegeben. Deshalb habe ich die Meldung zusammengesfasst. Wie es aussieht, bestehen also Probleme damit, Dienste rechtzeitig zu beenden bzw. die Beendigung dauert zu lang und wird nicht korrekt abgeschlossen. Wenn ich sc query auf z. B. Center Manager mache, erhalte ich "Fehler 1060 der Dienst ist nicht installiert". Schaue in in die Diensteverwaltung, ist der Dienst zwar aufgeführt mit Starttyp automatisch, aber beim Versuch diesen zu starten erhalte ich "Fehler 126 das angegebene Modul wurde nicht gefunden". Bei den beiden anderen Diensten verhält es sich genauso. Komisch ist also, dass der Neustart sich aufgrund der Beendigung eines Dienstes zu lange verzögern soll, der gar nicht installiert ist? Einzige Brauchbare Hilfe im Internet war bisher dies hier: Event ID 7023 Ich würde zwar gerne versuchen den Timeout für die Dienste zu verlängern, aber wenn diese gar nicht laufen ... Vielleicht bin ich ja auf einem falschen Lösungsweg? Freue mich auf eure Hilfe. Danke, hannes

Hallo, habe den alten 2003er DC jetzt herabgestuft. Ging mit DC promo sauber ohne Fehlermeldung. Der DNS Server ist erstmal noch drauf geblieben. Mit Outlook 2007 lief innerhalb der Domäne, wie auch zuvor, alles reibungslos wie immer und ich konnte in Exchange auch problemlos neue Benutzer anlegen. Jetzt zuhause wollte ich OWA testen, da erschien nach der Anmeldeseite folgende Fehlermeldung: Exception message: Could not find any available Domain Controller. Hab`kurz gegoogelt und die Ergebnisse ließen auf Probleme mit prepare Domain in Child-Domains schließen. Nur leider haben wir gar keine Child-Domains?! Also vielleicht hat der Admin, der schon vor längerem den Exchange 2007 installiert hat ja einfach das Prepare der Domäne aus irgend einem Grund nicht sauber hinbekommen, wie auch hundele schrieb? Könnte man das nachträglich nochmal ausführen? Kann mir als in diese Richtung belesener Exchange-Admin aber nicht vorstellen, dass eine Installation ohne ein korrektes Prepare Domain überhaupt möglich gewesen wäre? Nach einer 20 Minuten später durchgeführten Aktualisierung von OWA auf der Fehlerdialog-Seite, war ich dann aber auf einmal ganz normal in meinem Posteingang?! Ziemlich unverständlich. Ich kann mir nur denken, dass hier vielleicht bei meiner letzten Anmeldung der alte 2003er DC, der herabgestuft wurde als Anmeldeserver verwendet wurde und dies irgendwo zwischengespeichert wurde. Allerdings ist in der Exchange Management Konsole ein 2008er DC als Konfigurations-DC hinterlegt und auch die DNS-Server sind manuell in der Konsole eingestellt. Könnte es sein, dass hier nun die Einstellungen der Netzwerkkarte nicht mehr beim DNS auf den 2003er DC als sekundären DNS zeigen dürfen? Merkwürdig. Ich hoffe nur, dass ich jetzt keine 100 Tickets erhalte, mein OWA geht nicht mehr - drücken Sie bitte F5. Deswegen würde es mich schon interessieren, was es hiermit aufsich hat. Und um nochmal zu dem Outlook-Anywhere Problem mit Autodiscover zurückzukommen: wir haben leider, leider derzeit kein gültiges Vertrauenswürdiges Zertifikat für den Exchange 2007, da in nächster Zeit ein Providerwechsel geplant und auch schon beauftragt ist. Da sich hier noch Verschiebungen ergeben können, warten wir damit noch ab. Kann es nun sein, wie hundele geschrieben hat, dass das Fehlen des Zertifikats meine Fehlermeldung bei den Berechtigungen auf das OAB-Verzeichnis im ExBPA direkt oder indirekt beinflusst? Ich denke eigentlich, solange die CALs richtig gesetzt sind, stimmen die Berechtigungen? Beim Inhalt der OABs ist jedenfalls bei den Outlook-Anywhere Benutzern immer alles O.K. und die Übernahme von Änderungen dauert auch normal lange. Sogar Android und iPhone zeigen korrekte Adressbücher. Will ich aber das OAB manuell über Senden/Empfangen neu herunterladen erhalte ich die Fehlermeldung 0x8004010F. Ich könnte mir höchstens vorstellen, dass der Abruf von der https:// Seite der IIS hier dazwischenfunkt, da man evtl. das nicht vertrauenswürde Zeritifikat in Ermangelung eines nochmaligen Dialogs hierzu nicht ignorieren kann, was aber beim Anmelden an Outlook-Anywhere selbt mit einer gesonderten Bestätigung à la "... möchten Sie trotzdem / ja" funktioniert. Vielleicht wären hier ja geänderte Security Settings bezüglich der Anmeldung schon hilfreich? Schon mal Danke sagt, hannes

... Jede dieser Meldung wird im Exchange Best Practices Analyzer 2x hintereinander ausgegeben. Wie gesagt wurden die Berechtigungen hier von mir nachträglich manuell gesetzt inkl. Freigabe und zwar sowohl unter dem o. g. Pfad, als auch unter 'C:\Program Files\Microsoft\Exchange Server\OAB'. Bei mir zu Hause in der Testumgebung ist das Problem identisch vorzufinden. Ich frage mich deshalb, ob das momentan ein genereller Bug unter Exchange 2007 SP3 ist, oder wo ich hier ansetzen muss, um die Berechtigungen korrekt zu setzen. Fraglich ist auch, ob diese Berechtigungen das Problem der Outlook-Anywhere Benutzer (Outlook 2007) mit dem OAB beeinflusst, da es innerhalb des Domänen-Netzes keinerlei Probleme mit dem Download des OAB bei Outlook 2007 Clients über HTTP(s) gibt. Um zu testen, ob vielleicht das OAB defekt ist, habe ich probehalber mal in der Management-Konsole ein neues OAB erstellt, aber nicht auf die Mailbox-Datenbanken verlinkt, oder als Standard gesetzt. Hierbei trat wiederum folgender Fehler auf: Warnung: Der Task und der Öffentliche Ordner-Informationsspeicher >Exchange Server Name< stellen Verbindungen mit verschiedenen Domänencontrollern her, die Verteilung des Offlineadressbuchs in Öffentlichen Ordner funktioniert erst, nachdem der Öffentliche Ordner-Informationsspeicher >Exchange Server Name< seinen geplanten Wartungstask ausgeführt hat. Das neue OAB wurde dann nach dieser Warnung korrekt erstellt. Mir wäre jedoch nicht bekannt, wo ich für Öffentliche Ordner einen gesonderten DC einstellen könnte? Oder besagt die Warnung eigentlich nur, dass die Verteilung erst nach der nächsten Öffentlichen Ordner-Replikation für Outlook 2003 Clients über Öffentliche Ordner funktioniert, was ich mal annehme? Mein OAB-Problem tritt wie gesagt nur bei Outlook 2007 Clients mit Outlook-Anywhere auf. Outlook 2003 Clients gibt es keine mehr. Beim stöbern zu meinem Problem habe ich gelsen, dass es sein kann, das man mit NTBackup ein Vollbackup des alten Exchange 2003 machen soll, damit die Öffentlichen Ordner Replikate einem nicht mehr ins Handwerk pfuschen, aber vielleicht war ich da schon zu durch. Bevor ich gegangen bin, habe ich dann noch, wie mehrfach empfohlen, einen Host(A) Eintrag für die IP des Exchange 2007 mit dem Wert "autodiscover.domain.de" gesetzt. Jetzt frage ich mich, ob das ausreicht - ein Test am Nachmittag hatte mit diesem Eintrag nach 10 Minuten nichts bewirkt, aber vielleicht war ja die Zeit einfach zu kurz, obwohl es schon auf die anderen DNS Server repliziert war. Oder vielleicht ist einfach noch auf dem Server 2003 DC, der vorher den Exchange 2003 beheimatete noch irgendetwas zu richten bzw. existiert am AD-Schema vielleicht noch ein Verweis, der stört? Am liebsten wäre mir natürlich den 2003 DC einfach herabzustufen und abzuschalten, aber das löst das Problem wohl eher nicht :p Vielen Dank für eure Hilfe, hannes

Edit: musste den Beitrag auf 2 Teile trennen, da sonst zu lang. Hallo, in unserer Domäne wurde vor ein paar Wochen von mir der letzte Exchange 2003 Server mit viel Hängen und Würgen deinstalliert, nachdem der vorherige Admin diesen par tout nicht losgeworden ist. Leider war dieser auch noch auf einem Server 2003 DC installiert, der wiederum vom neuen Exchange 2007 als Konfigurations DC verwendet wurde :cry: Um die Domäne in nächster Zeit von 2003 auf 2008 upgraden zu können, habe ich zuerst versucht in den Einstellungen der Netzwerkkarte des Exchange 2007 nicht mehr auf diesen DC als DNS-Server zu verweisen und einen anderen Konfigurations DC zu verwenden. Das lief dann 14 Tage, bis die Mails nicht mehr raus gingen und sich in der Warteschlange stauten - warum auch immer? Einzigster aufgetretener Fehler war bis dato ein mittlerweile ungültiger Eintrag des Exchange 2003 bezüglich eines Adress-Typs, der nicht mehr existierte, in der Standard-Adress-Richtlinie, den ich über die Management Konsole beheben konnte und der nach Prüfung im ADSI Editor auch nicht (mehr) vorhanden war. Somit habe ich dann die DNS Server in der Exchange Management Konsole manuell vorgegeben und seitdem schiens zu laufen. Jetzt wollte ich mich schon fast daran machen den alten Server 2003 DC herabzustufen, da tritt unversehens ein Problem bei den Outlook-Anywhere Benutzern mit dem OAB auf. Der Fehler lautet: 0x8004010F Google liefert hierzu wirklich viele Ergebnisse und ich bin schon 3 Stunden lang die ersten 40 hiervon durchgegangen, wie z. B. Outlook clients receive error 0x8004010f when downloading the Offline Address Book - Exchange Team Blog - Site Home - TechNet Blogs Understanding why error code 0X8004010F is thrown when trying to download an OAB - Dgoldman's WebLog - Site Home - MSDN Blogs Leider hat hiervon das Problem auch nach intensivem testen nichts behoben. Eine Analyse mit dem BPA-Tool ergibt, dass die Berechtigungen auf das OAB-Verzeichnis angeblich nicht passen sollen, obwohl ich diese manuell bereits gesetzt und mehrfach, auch in der IIS7 Konsole, geprüft habe. Die Ergebnisse lauten: - 'Administratoren' verfügen nicht über die Berechtigung 'Vollzugriff' für Ordner 'C:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB\06227637-b030-4caa-a27c-f10dc6cfa9f0' - 'Authentifizierte Benutzer' verfügen nicht über die Berechtigung 'Lesen' für Ordner 'C:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB\06227637-b030-4caa-a27c-f10dc6cfa9f0' - 'Domänen-Admins' verfügen nicht über die Berechtigung 'Lesen' für Ordner 'C:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB\06227637-b030-4caa-a27c-f10dc6cfa9f0' - 'Organisationsadministratoren' verfügen nicht über die Berechtigung 'Lesen' für Ordner 'C:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB\06227637-b030-4caa-a27c-f10dc6cfa9f0' ...

Add-ons waren keine geladen. Den Virenscanner und Office 2007 hatte ich ja komplett neu installiert. Dann hilft wohl nur abwarten, ob der Fehler jetzt noch mal auftritt. Falls ja, worauf sollte ich bei der Deinstallation von Outlook/Office noch achten, außer den .ost Dateien? Danke, hannes

... noch vergessen: in OWA taucht die Mail auch nicht unter Gesendete Objekte auf. hannes

Hallo, sorry für die verspätete Antwort - Das Laptop war im Außendienst. Aber die Option ist gesetzt. Hab`s auch mal ohne den Haken probiert, dann wird auch nichts gespeichert. Mit haken landen dann die Mails auch i. d. R. im Ordner gesendete Objekte, nur eben manchmal nicht, obwohl es wie gesagt keine Regeln gibt. Woran kann das nur liegen? Gruß, hannes

Hi, ich hab` hier gerade fast das gleiche Problem. Ein User sendet eine Mail, die dort auch ankommt, aber beim Absender taucht die Mail einfach nicht unter "Gesendete Objekte" in Outlook 2007 auf. Habe deshalb heute mal Office 2007 komplett deinstalliert, alle Datei-/Ordnerreste gelöscht und wieder neu aufgespielt, da ich mehrere google Ergebnisse hatte, dass es ein Client-Problem sein müsste bei dem z. B. doppelte Ordner vorhanden sind und dann die Mail wo anders landet, als sie eigentlich angezeigt werden sollte. Oder es läge evtl. eine Regel zum verschieben vor ... Hat aber nicht geholfen. Dann habe ich die .ost Datei nochmal gelöscht und das Postfach in eine andere Mailboxdatenbank verschoben. Null Fehler hierbei. Half trotzdem ebenso nicht. Die Nachrichtenverfolgung zeigt mir für die Message-ID die korrekten Sende- und Empfangszeiten mit den Ereignissen "DELIVER" und "RECEIVE" für die Quelle "STOREDRIVER". Kann ich irgendwie sehen, ob die Nachricht noch tatsächlich in der Datenbank vorhanden ist und nicht versehentlich gelöscht wurde? Wobei der User aber berichtet, dass dieses Verhalten schon öfters vorgekommen ist. Wenn ja, wie? Vielen Dank. Grüße, hannes

aah, wunderbar. Genau so geht`s. Vielen Dank !! hannes

Hallo, habe neulich mal ausversehen in einer Exchange (2007) Best Practice Analyzer Systemdiagnose bei den Fehlern einen einzelnen Fehler ausgeblendet über "Dieses Element für alle Instanzen nicht mehr anzeigen". Leider finde ich nun nirgends eine Option um das eigentlich wichtige Fehlerelement wieder anzeigen zu lassen. Kann mir jemand bitte kurz erklären, wo sich der Schalter hierzu findet? Vielen Dank für die Hilfe. hannes

:D da kann man schon mal lachen. Geht mir auch so. Und vielen Dank für das kleine How-to. :D hannes

Hallo, kann ich hier einfach eine Profile (PRF) Datei von einem anderen Client kopieren? In dem Installationsverzeichnis der angepassten Installation habe keine PRF bzw. OPF Datei gefunden, die funktioniert hätte. Oder geht auch noch eine nachträgliche Erzeugung mit dem ORK? Vielen Dank, hannes

Das ist ja mal wirklich eine äußerst spannende Lektüre !! Wie`s aussieht sollte ich wohl auch mal auf NIC Ebene forschen. Vielleicht funkt z. B. einfach die Nagios Dienstüberwachung dazwischen, indem sie bestimmte TCP/IP Eigenschaften der NICs umkonfiguriert hat? Das NSTray Tool von Nagios produziert jedenfalls oft Windows-Fehler. Ebenfalls sehr spannend ist die Tatsache, daß eine Konfiguration von Auto am NIC und Force-Mode am Switch nicht wirklich zu empfehlen ist und Duplex Fehler produzieren kann. ...da wartet im nächsten Jahr aber noch ziemlich viel Arbeit, bis das Netz wirklich 100% stabil läuft. Vielen Dank hegl, für den wirklich informativen Link :) hannes

Hallo, ich habe auf einem Client, auf dem sich bis zu 7 Leute anmelden, Outlook 2003 neu installiert. Leider habe ich versehentlich nicht die richtige angepasste Installation gewählt, so dass jetzt der Exchange Server 2007 und der Anmeldename nicht richtig beim ersten Start von Outlook 2003 vorgegeben werden. Das hieße also bis zu 7 mal zu dem PC zu laufen, immer wenn sich ein Benutzer das erste mal auf dem Client an Outlook anmeldet. Jeglicher Versuch, mit dem Office Removal Tool aus dem ORK für 2003 zu deinstallieren und dann nochmal die richtige angepasste Installation auszuführen, brachte keinen Erfolg. Gibt es daher eine Möglichkeit den Parameter Exchange Server und Benutzername (Kontoname) irgendwie nachträglich nochmal anzugeben? Wäre für Hilfe sehr dankbar. Viele Grüße, hannes

... hier noch die weiteren Screenshots von der Netzwerkkonfiguration und der vSwitche: ESX01 Netzwerkadapter: ESX01 vSwitch: Teil 1: Teil2: ESX02 Netzwerkadapter: ESX02 vSwitch: Wäre nett, wenn noch mal jemand drüber schauen könnte. Vielleicht steckt der Wurm ja auch hier irgendwo drin? Vielen Dank, hannes

@Cybquest: Deine Empfehlung deckt sich hier völlig mit meiner geplanten Wunschkonfiguration. Vielen Dank für die Bestätigung. Jetzt fehlt nur noch die bestellte Hardware ... @zahni: nachfolgend erstmal, was ich momentan an Screenshots von gestern noch im Posteingang habe. Morgen mach' ich noch ein paar von den Konfigs. Hier sieht man aber jetzt schon mal die beschriebenen Fehler. Interne Firmennamen musste ich aufgrund von Vorgaben unkenntlich machen. @hegl: Danke für den Tipp. Das war auch mein erster Blick. Aber Fehler werden auf den GBIC Ports absolut keine gemeldet. 0,00 Fehler. Nichts. Der Port an dem der derzeit noch IPcop Router angeschlossen ist meldete allerdings 'ne Zeit lang ziemlich viele Fehler. Nachdem der Port am Switch dediziert auf Router umgestellt wurde, passts derzeit eigentlich auch da. Nach neuen Fehlern kann ich dann morgen noch mal schauen. Worauf deuten FCS-Error und CRC-Error jeweils? Lässt sich hieraus was direkt ableiten? So, hier die Screenshots: Vielen Dank, hannes

... ich stelle fest, dass ich für Visio 2010 eindeutig zu wenig Shapes habe. Aber ich denke den Grundaufbau kann man gut erkennen: Link zum Bild: http://h-3.abload.de/img/verteiler-uebersichtjg53.jpg An den Verteilern gibt es, wie bereits eingangs erwähnt, noch zahlreiche andere Switche, da sonst die Ports nicht ausreichen. Spielt es für die Performance und RSTP eine Rolle, ob die zusätzlichen Switche untereinander, anstatt jeweils 1x direkt mit dem D-Link der den GBIC hat, verbunden sind? Die ESX-Server sind per Kupfer je 6x mit dem "Haupt-Switch" im Serverraum verbunden. Wie sollte eine saubere Konfiguration am besten aufgebaut werden? Vielen Dank, hannes

So, ich stell fest, dass ich für Visio 2010 entschieden zu wenig Shapes habe ;) Link: Bild: verteiler-uebersichtjg53.jpg - abload.de Der Aufbau ist natürlich stark vereinfacht. Pro Verteiler gibt es wie o. g. noch zahlreiche verschiedene Switche, da hier die Ports sonst nicht ausreichen. Spielt es für die Performance und RSTP eine Rolle, ob diese untereinander verbunden sind, oder sollte jeder separat 1x an dem Switch mit dem GBIC-Modul von D-Link angeschlossen sein? Jeder ESX ist 6x per Kupfer an den "Haupt-Switch" im Server-Raum angebunden. Wie sollte der Aufbau optimal gelöst werden? Danke, hannes

oh, sorry. wollte natürlich keine Verwirrung stiften. Bei den LWL-Verbindungen kommt auch Multi-Mode, statt Single-Mode zum Einsazt. War gestern Abend schon leicht hinüber. GBICs sind auch in den D-Links vorhanden. Aber ob sich die auf Kupfer spiegeln lassen, wage ich mal zu bezweifeln, weild das Kombo-Ports sind, d. h. wenn einer von den 4 äußersten LWL-Ports mit einem GBIC belegt ist, kann man den korrespondierenden Kupfer-Port nicht belegen. Das auszuprobieren gestaltet sich auch heikel, da mir sonst im Fehlerfall das Produktivnetz wegbricht ... Aber die Idee ist natürlich Gold wert :) Werde ich auf jeden Fall zusätzlich im Auge behalten. Bild mach` ich gleich. Dauert sicher etwas ... Gruß, hannes

Hallo, die Geschichte mit dem Loop habe ich natürlich bedacht und deshalb ist RSTP auch eingeschalten, was aber das Problem beim pingen nicht gelöst hat. Sich bei LWL in die Uplink-Ports einzuschleifen dürfte wohl aufgrund fehlender Netzwerkkarten eher schwieriger bis unmöglich werden. Gibt`s denn stattdessen gar keine Möglichkeiten? Irgendwelche "Hausmittel", die man mal abarbeiten sollte, wie z. B. den TCP/IP Stack zu resetten, oder etwas in der Art? Wegen dem HA-Problem, hier eine genauere Beschreibung: 1.) Konfigurationsprobleme: "Der Host ESX02 verfügt momentan über keine Verwaltungsnetzwerkredundanz" (Fehler auf Registerkarte "Übersicht" bei markiertem Knoten HA in der Baumstruktur links des vCenter Server) 2.) Konfigurationsprobleme: "Der HA-Agent auf ESX01 in Cluster ha_01 im Datencenter Fimenname hat einen Fehler: Zeitüberschreitung bei der Kommunikation mit dem HA-Agenten. (Fehler auf Registerkarte "Übersicht" bei markiertem Server ESX01 direkt unterhalb des Knotens HA ind der Baumstruktur links des vCenter Server) Wird es jetzt etwas deutlicher? Beide ESX Server haben je 3 NICs mit 2 Ports, wovon je 1 NIC für das Verwaltungsnetzwerk bestimmt ist. Die so insgeamt 12 Ports hängen alle per Kupfer an dem selben Switch. Bin sehr daran interessiert, das Problem im Laufenden Betrieb zu lösen, da dies sicher viel weniger fehleranfällig ist als mein erster Vorschlag. Vielen Dank. hannes

Hallo, ich habe in unserem Netzwerk ein Problem mit dem ping auf bestimmte Server. Die Umgebung ist relativ simpel, außer was die LWL-Leitungen zwischen den Verteileren betrifft. Es gibt 4 Verteiler, von denen 3 per LWL im Single-Modus über D-Link DGS-1210-24 Switche verbunden sind. Ein Verteiler ist zum Hauptserverraum über je 1x Cisco Catalyst per LWL ebenfalls im Single-Modus angebunden. Außer den D-Link DGS-1210-24, die eigentlich viel zu klein sind, gibt es sowohl an den einzelnen Verteilern, als auch im Haupt-Server-Raum noch zahlreiche ältere D-Link Switche verschiedenster Modellreihen und auch Switche anderer Hersteller, die dann alle mit Kupfer untereinander verbunden sind. Die Server laufen auf VMware vSphere mit ESX-Server 4.0 im HA-Modus, d. h. es sind 2x ESX inkl. Infrastructure-Server vorhanden. Wenn ich nun z. B. den DC pinge ist alles in Bester Ordnung. Pinge ich aber einen bestimmten anderen Server, habe ich nach ca. 20 pings immer eine "Zeitüberschreitung der Anforderung", was aufgrund der zeitkritischen Anwendung, die dort läuft, eigentlich nicht zu vertreten ist. Firewall ist aus. Netzwerkeinstellungen der Karte und DNS sollten passen. Einzigstes Problem seit einem Stromausfall durch den Netzbetreiber ist, dass der ESX1 einen Fehler beim HA meldet, wo er angibt "Das Management Netzwerk wäre nicht redundant aufgebaut", falls das hier mit rein spielen kann. In den Weihnachtsferien ist hier mal ein Reboot im Wartungsmodus geplant um das zu beheben. Meine Frage deshalb: nach was kann ich suchen oder z. B. mit Wireshark capturen, um den Grund für die Zeitüberschreitung beim pingen herauszufinden? Problem ist nämlich, dass sich das ganze derzeit öfters mal "aufschaukelt" und dann eben mehr als eine Zeitüberschreitung hintereinander auftritt, so dass die Clientanwendungen den Dienst quittieren, die auf den Server zugreifen. Mein persönlicher Ansatz ist, dass die Infrastruktur aus den unzähligen Switchen einfach zu verworren ist und es auf dem Weg durch die zahllosen Switche zu Kollisionen kommt, so dass Pakete verworfen werden. Dies leitet mich direkt zu meiner zweiten Frage über: Hat jemand damit Erfahrung die D-Link DGS-1210 in einer Art "quasi" Stack-Modus zu betreiben z. B. über V-LANs? Wie müsste das aussehen? Ich würde dann nämlich die Kraut-und-Rüben-Landschaft mal bereinigen und einfach pro Verteiler und beim Haupt-Server 2-3 Stk. von den 48-Port-Modellen Anschaffen und diese per LWL untereinander verbinden. Dabei müsste aber gewährleistet sein, dass die Switche praktisch nach außen hin wie z. B. ein großer 96-Port arbeiten, aber gleichzeitig es bei den Verbindungen zu den anderen Verteileren über ebenfalls LWL zu keinen "Schleifen" kommt, wofür unsere Infrastruktur momentan ohnehin extrem anfällig ist. Wie wäre hier ein V-LAN umzusetzen? Kann bitte jemand helfen? Ich hab`s nämlich langsam echt satt ständig an irgendwelchen einzelnen Ports herum zur flickschustern :cry: Vielen Dank, hannes

neee, is schon klar ;) Remove-EmailAddressPolicy -Identity <EmailAddressPolicyIdParameter> [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-UseRusServer <String>] [-WhatIf [<SwitchParameter>]] Remove-EmailAddressPolicy: Exchange 2007 Help Hatte mich nur gefragt, ob`s bei den alten Policys vom 2003er eben genauso geht ... Hast aber recht, eigentlich war ich ja erst am Sa und So auf genau dieser Seite :) O.K. Dann erstmal vielen Dank. Hoffe es klappt alles. hannes

Oh, das wäre glaube ich was ich bräuchte, falls ich da noch was finde. Weißt Du für Löschen oder Ersetzen den Shell-Befehl? Ich denke vielleicht geht es so: Delete-EmailAddressPolicy -Identity XYZrichtlinie [/Code] Oder spielt hier der Unterschied zwischen den 2003er und 2007er Richtlinien noch eine Rolle? Vielen Dank, hannes

O.K. werde mal den Befehl: get-emailaddresspolicy -IncludeMailboxSettingOnlyPolicy ausprobieren, den ich hier gefunden habe: MSXFAQ.DE - Benutzermanagement Irgendwo habe ich nämlich noch ein paar Adressen gesehen, die mit RUS: begonnen haben. Anschließend sollte evtl. dieser Befehl helfen: Get-EmailAddressPolicy | Update-EmailAddressPolicy Bzw. wäre es dann nicht besser, die gefundenen alten Policys des 2003er Exchange auf dem 2007er zu löschen? Vielen Dank, hannes

Danke, Nils. Gibt`s sonst nichts, was hier schief gehen kann? Was passiert z. B. wenn eine E-Mail-Adressenrichtlinie gelöscht wird mit den dazugehörigen E-Mail-Adressen? Was ist mit den RUS-Adressen aus vorherigen Migrationen? Vielen Dank, hannes