Jump to content

oh2204

Members
  • Gesamte Inhalte

    102
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Junior Member

Fortschritt von oh2204

Community Regular

Community Regular (8/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Moin, natürlich ist das fehlerfrei beschrieben ;-) Wir kommen leider um die Nutzung von ÖO nicht Drumherum... Bitte nicht verwechseln, ich meine keine Outlook-Regeln! Die Weiterleitung von PublicFolderA ist über die PublicFolder Konsole direkt auf dem Ordner definiert. Ich habe es nun komplett über Transportregeln gelöst, und die Weiterleitung vom ÖO PublicFolderA entfernt.
  2. Guten Morgen, folgendes Szenario: Es gibt PublicFolderA und PublicFolderB. Auf PublicFolderA ist einer Weiterleitung zu einem internen Postfach gesetzt (+Nachricht an Weiterleitungsadresse und Postfach übermitteln). Zusätzlich gibt es eine Transportregel, in dieser ist definiert: Alle Nachrichten die an PublicFolderA gesendet werden, werden umgeleitet an PublicFolderB, AUßER wenn im Betreff XYZ steht. Fall 1: Geht nun eine Nachricht an PublicFolderA mit XYZ im Betreff, wird diese an das interne Postfach weitergeleitet und verbleibt zusätzlich im PublicFolderA. Fall 2: Geht eine Nachricht an PublicFolderA mit XYW im Betreff, greift die Transportregel und die Nachricht wird nach PublicFolderB umgeleitet. Soweit so gut und so die Theorie. Nun zur Praxis: Tritt Fall 2 ein, es geht also eine Nachricht mit XYW im Betreff an PublicFolderA, greift die Transportregel wie definiert, die Nachricht wird aber dennoch an das interne Postfach weitergeleitet (Weiterleitung auf PublicFolderA definiert). Die Transportregel müsste die Nachricht doch schon vorher umleiten und PublicFolderA sollte davon Garnichts mitbekommen, oder sehe ich das falsch? VG
  3. Es liegt am Reverse-Proxy der davor geschaltet ist, hier muss noch einiges konfiguriert werden. Über NAT funktioniert es.
  4. Hi, in meiner OWA URL wird mir die interne IP des Exchange Servers angezeigt. Gehe ich auf mail.domainname.de/owa, wechselt die URL zu folgender: https://mail.domainname.de/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2fxxx.xxx.xxx.xxx%2fowa%2f (xxx.xxx.xxx.xxx entspricht der internen IP). Hat jemand Ahnung warum dies passiert? PS:Grundsätzlich funktioniert OWA
  5. Die Archivierung läuft nun täglich, sodass die DBs nicht mehr weiter anwachsen. Der Ausfall wäre ja kalkulierbar, indem es am Wochenende läuft. Damit würde ich klarkommen. Es gibt mehrere Gründe für die Verkleinerung: Platzprobleme, Backupzeiten und Reduzierung des Backups. Danke für eure Hilfe.
  6. Mit diesem Befehl habe ich ja herausgefunden, dass der AvailableNewMailboxSpace knapp 200GB beträgt. Also ich denke eine Offline Defragmentierung macht bei dem Whitespace schon Sinn. Was meinst du?
  7. Ja, standardmäßig sind es 14 Tage. Und nach Ablauf der 14 Tage, verkleinert sich auch die DB entsprechend? Um die Sache zu beschleunigen könnte ich die Aufbewahrungszeit auch auf 7 Tage setzen richtig?
  8. Hi Robert, wie lange muss man da abwarten? :-) Die Archivsoftware läuft ja nun schon knapp eine Woche. Mir geht es ja nur darum, die DB zu verkleinern um das Backup zu verkürzen und zu verkleinern. Die Mailbox DB habe ich da noch nicht eingerechnet, aber ich rechne mit ca. 400GB Einsparung (MBDB und PFDB).
  9. Hi Günther, ok die Empfehlung von Microsoft ist, eine neue DB zu erstellen und die Mailboxen da hin zu verschieben. Mit einer MBDB ist das ja auch kein Problem, aber ich habe hier eine Public Folder DB, wie macht man es in diesem Fall? Danke für die Hilfe!
  10. Hallo, wie im Titel angegeben nutze ich einen Exchange 2010 SP2 mit UR2. Nachdem ich eine Software zur E-Mail Archivierung eingesetzt habe (welche auch funktioniert), habe ich knapp 200GB Whitespace in meiner Public Folder Datenbank und würde den Whitespace gern freigeben und die Datenbank dadurch verkleinern. Ist das gegenwärtig immer noch nur durch eseutil /d xxx.edb lösbar? VG!
  11. Hi, danke euch Jungs für die Hilfe. Ich werde das am Wochenende so machen! :)
  12. Hi, richtig, die Maschinen laufen zur Zeit alle auf dem noch lebenden Knoten. VG
  13. Hi, danke für deine Antwort. Das bedeutet an der Konfuguration der Virtuellen Maschinen sollte nichts durch das Entfernen des Knoten verändert werden? VG
  14. Hi, ich habe habe folgendes Problem: Ich betreibe einen Zwei-Knoten Hyper-V Cluster und habe am Wochenende beide Clusterknoten (Server 2008 R2) auf Service Pack 1 aktualisiert. Auf einem Knoten (NodeA) ging die Installation schief und wurde rückgängig gemacht. Nachdem die Änderungen rückgängig gemacht wurden, konnte der Knoten nicht mehr gestartet werden und dummerweise habe ich dann "Die letzte als funktionierende Konfiguration" über F8 auf dem Knoten gestartet. Vermutlich war das ein Fehler, denn nun kann ich den DIenst "Hyper-V-Verwaltung für virtuelle Computer" nicht mehr starten. Der Host hat ja jetzt die Registrierung wieder zurückgesichert, nur ist das die Registrierung als noch alle VMs auf diesem Host liefen, was sie ja nun nicht mehr tun. Der Host denkt jetzt er hostet noch die VMs, tut er aber nicht. Nun ist die Frage, wie bring ich dem Knoten bei, das er längst die VMs nicht mehr hostet (sondern der andere Knoten)? Kann ich den Knoten einfach aus dem Cluster entfernen, Hyper-V Rolle deinstallieren -> Hyper-V Rolle installieren und Knoten dem Cluster hinzufügen? Ist eine Rücksicherung beider Knoten besser? Ich weiß hier nicht mehr weiter und hoffe auf eure Hilfe. VG
  15. Hi, ich bin gerade am Aufbau einer RDS-Farm und renne in einen merkwürdigen Fehler. Folgender Aufbau: - 2x RDS Host im NLB-Cluster (laufen im Hyper-V Cluster) - 1x RDS-Broker - Farmname farmxy.domaene.local (NLB-CLuster heißt genauso; DNS Eintrag gesetzt auf NLB-Cluster-IP) Die Sessionverteilung über die beiden RDS funktioniert über den farmnamen soweit gut. Nur will ich mich jetzt über RDP auf einen bestimmten RDS verbinden, erhalte ich die Fehlermeldung (RDPClient 6.1): "Die Verbindung kann nicht hergestellt werden, da es sich bei dem erreichten Remotecomputer nicht um den angegebenen Computer handelt. Dies kann durch einen veralteten Eintrag im DNS-Cache verursacht werden. Verwenden SIe statt des Namens die IP-Adresse des Computers." DNS-Cache geleert, nichts. Im DNS nachgesehen, keine Probleme. Ping auf die DRS-Computernamen bringt auch die richtige IP. Die Meldung mit einem RDP-Client 6.0 sieht anders aus und machte mich etwas stutzig: "Es kann keine Verbindung mit dem Terminalserver hergestellt werden. Die Terminalserverfarm RDSmember1 (!?), mit der Sie eine Verbindung herstellen möchte, leitet Sie zum Server RDSmember2 um. Es kann nicht überprüft werden, ob dieser Server zur gleichen Serverfarm gehört. Dieses Problem kann auftreten, wenn im Netzwerk ein Server mit dem gleichen Namen wie die Serverfarm vorhanden ist." Kann ich ausschließen... Hat jemand eine Idee?? VG
×
×
  • Neu erstellen...