RobertWi

Ja, dass die Rolle schon da ist, wird erkannt. Dass Du das CNO schon angelegt hast, kann zu einem Fehler führen, dann löschst Du es einfach wieder. Muss aber nicht. Nun wird die DAG angelegt, Netzwerke zugewiesen mit einer IP für das DAG (braucht man theoretisch nicht mehr, praktisch aber schon) und danach die Knoten aufgenommen. Dann sollest Du im AD einen Computer-Objekt mit dem Clusternamen sehen, im DNS einen Eintrag und die beiden Knoten samt Quorum (der sich Fileshare Wittness nennt) im Cluster Manager.

Ja. Sie sind Bestandteil der SQL Server Data Tools und werden auch von anderen Komponenten von SQL benutzt, da SQL Visual Studio als Entwicklungswerkzeug verwendet. Natürlich gibt es Gründe: Der Hauptgrund ist, dass die Entwickler von Exchange einfach nicht erwarten und darauf eingehen, dass da noch andere Komponenten drauf sind. Exchange braucht sehr viel von Windows und im Netzwerk und erwartete, dass das einen genau definierten Zustand hat. Hat es den nicht, knallt es i.d.R. Beispiel: IIS. Exchange nutzt den für OWA, EAS und auch für die Verwaltung. Und es erwartet bestimmte Einstellungen mit dem Wert X. Nun installiert irgendjemand eine andere IIS-Anwendung, die den Wert auf Y ändert. Das Ergebnis ist nicht, dass Exchange meckert. Das Ergebnis ist: Exchange funktioniert nicht mehr. Oder nimmt die PowerShell und WinRM: Wird von Exchange intensiv genutzt und erwartet daher bestimmte Einstellungen. Liegen die nicht vor, knallt es. Exchange erwartet bestimmte Versionen von WinrRM, PowerShell, .NET und sogar mit dem Internet Explorer gab es schon Probleme, als der aktualisiert wurde und plötzlich die EMC von Exchange nicht mehr funktioniert. Und die Logik ist nun ganz einfach: Je mehr fremde Dinge Du auf einem Exchange, desto höher ist die Wahrscheinlichkeit, dass Du Dir mit irgendeiner Komponente den Exchange zerschiesst. Ich habe in meiner Zeit eine Menge defekte Exchange-Installation erlebt und da war eine Regel gut zu erkennen: Ein Exchange, der nur Exchange ist und nah am Best Practise betrieben wird, macht keine Probleme. Probleme gab es bis auf wenig Ausnahmen nur dann, wenn irgendwas fremdes auf dem Exchange war. und dann gibt es natürlich praktische Dinge: CPU-Nutzung, RAM-Auslastung, Festplatten-Verwendung - kannst Du alles nicht steuern, wenn zu viele Programme auf einem Server sind. Exchange ist ein Datenbank-System, dass massiv vom RAM lebt. Und wenn zu wenig RAM, dann muss die Festplatte ran. SQL ist ein Datenbank-System, dass massiv vom RAM lebt. Und wenn zu wenig RAM, dann muss die Festplatte ran. Merkst Du was? Was meinst Du, wie lange wird ein echte SQL auf einem Exchange wirklich gut gehen?# Na ja, eigentlich hast Du die Frage schon hier in diesem Thread beantwortet. Ohne den SQL hättest Du keine Backup-Probleme des Exchange gehabt. QED.

Moin, das ist sicher keine Thema, das man in einem Forum besprechen kann. Grundsätzlich wird aber bei Exchange eher eine Zentralisierung angestrebt, weil eine Client-Anbindung an "fremde" Standort einfacher ist, als verschiedene Exchange-Datacenter. Eine Standortübergreifende DAG ist dann die absolut hohe Schule, dafür solltest Du Dir absolute Fachleute ins Haus holen.

Warum hast Du ein Visual Studio auf dem Exchange installiert? Merke: Auf einen produktiven Exchange gehört nichts anders drauf, außer Exchange und die Produkte, die man direkt für Exchange braucht: Backup, Virenscanner, Archiv, Transport - fertig.

Moin, Du nimmst keine Einstellungen am FC vor, das macht alles Exchange. Der installiert die Rolle wenn erforderlich und konfiguriert sie komplett durch. In alten Versionen brauchtest Du noch ein CNO, das geht aber mittlerweile auch allein (solange Exchange nicht auf einem DC läuft). Also lass den Clustermanager in Ruhe, Konfig hier führt nur zu späteren Fehlern.

Moin, genau diese Fälle meine ich. Ich hatte die sogar ohne Neuinstallation, einfach irgendwann -> Sekretärin legt einen Ordner im Postfach des Chefs an. Er sieht ihn, sie nicht. Sehr gerne auch bei größeren Postfächern (Chef > 2 GB). Lösung bei uns: Automapping deaktivieren, warten und das Chef-Postfach manuell als natives Exchange Postfach einbinden (inkl Cache).

Moin, nichts mit Bordmitteln. Per Script das Postfach anlegen und dann aus diesem Script auch die Mail verschicken, wäre eine Möglichkeit. Ab Ex 2010 könnte man einen sog. Extension Agent erstellen. Das muss man zwar auch selbst bauen, der automatisiert dann aber den Versand.

Moin, das kannst Du problemlos im Betrieb machen, egal ob Du die Scripte nimmst oder es manuell machst (Suchdienst anhalten, CatalogData-Ordner entfernen, Suchdienst wieder starten). Bis der Index wieder aufgebaut ist, bekommen die Anwender halt nicht alle Treffer angezeigt. Aber sonst merkt man davon nichts.

Also ich habe ich dutzende Shared-Postfächer und definitiv keine Probleme mit dem Cache. Im Gegenteil: Ich habe nur Probleme, wenn kein Cache benutzt wird, weil das Ding per Automapping eingebunden ist. Automapping aus, nativ einbinden = ordentlicher Cache -> Problem weg.

Das ist nicht nur supported, sondern absoluter Standard. Ich habe hier dutzende von Mailboxen, die teilweise bis zu 30 Leute geteilt verwenden. Es gibt technisch keine "normale" und "shared" Mailbox, nur Mailbox und keine-Mailbox. Lizenzrechtlich ist das egal, da Du (ausgehend von User-CALs) eine CAL pro Anwender (= Mensch) brauchst. Ob die 10 Leute zehn Mailboxen oder eine nutzen, spielt dabei keine Rolle. Für den Rest gilt dann leider meine Signatur.

Oder: Automapping deaktivieren und das zusätzliche Postfach von Hand als weiteres natives Exchange Postfach einbinden. Dann macht Outlook das von alleine.

Du solltest es tunlichst unterlassen, irgendwas im Datenstrom des OWA (oder der anderen Protokolle) zu ändern. Das geht schief und führt zu elendiger Sucherei, warum OWA in dieser oder jener Bedingung plötzlich nicht mehr funktioniert. Und natürlich nicht nachvollziehbar, weil niemand die genauen Eingriffsfaktoren kennt. Port 443 geht komplett und ohne weitere Filterung an Exchange durch, nur als Portweiterleitung. Das ist ein gut gemeinter Rat aus der Praxis und das Forum ist voll von Einträgen, wo ein Filter zu viel oder falsch gefiltert hat. Wie gesagt: Du wirst nicht glücklich damit, egal, was Dir der Hersteller verspricht. Microsoft legt die "OWA-Beschreibung" nicht offen (im Gegensatz zur Active Sync Beschreibung oder der EWS Beschrebung), folglich kann kein Hersteller einer Firewall darin filtern. Jedes Exchange Update musst Du dann sehr intensiv testen und wenn was nicht funktioniert, bist Du darauf angewiesen, dass der Hersteller der Firewall möglichst schnell nachzieht. Dann kommst Du in die paradoxe Situation, dass Du ein wichtiges Sicherheitsupdate für OWA nicht installieren kann, weil sonst eine andere Sicherheitsfunktion nicht mehr fehlerfrei arbeitet. ECP -> Server -> Server -> Bleistift -> Oultook Anywhere.

Und warum drei verschieden? Die landen doch eh alle beim gleichen Ziel, dann reicht auch ein. "autodiscover.abc.com" fehlt aber eventuell, wenn Autodiscover auch extern benutzt werden soll.

Und sie wird sogar mit Microsoft-Suchmachine als erster Treffer gefunden - was sonst nicht unbedingt vorkommt.

Moin, ich würde spontan sagen, dass diese Meldung noch von Exchange kommt. Da müsste sie anders aussehen. Wir die Mail bei Euch direkt per SMTP an den Exchange geliefert, oder ist da noch was zwischen: Provider, Firewall, Proxy, Gateway, Spamfilter, usw.

Moin, ich kann mir gar nicht vorstellen, dass man diesen Artikel nicht auf anhieb findet: Klick.

Moin, wie verteilen die denn? Manuell? Drag&Drop? Outlook-Regel? Aber im Prinzip suchst Du nicht "Weiterleiten", sondern "Umleiten". Manuell in Outlook kann man auch "Als Anlage weiterleiten" nutzen.

Moin, sowohl ARR als auch WAP arbeiten als Proxy (was übrigens auch der Titel Deiner Frage ist ;)). Du lässt als ALLES, was 443 ist, auf dem Proxy ankommen und der kümmert sich um die Weiterleitung auf den korrekten internen Host.

Wenn ich schreibe, dass Du etwas in den Eigenschaften der Postfach-Datenbank ändern sollst und ich Dir sogar noch sage, wie die heißt, warum gehst Du dann im ECP in den Abschnitt "Öffentliche Ordner"? Und ob Du den Eintrag in der Postfachdatenbank löschen oder auf einen korrekten Wert ändern musst, kann ich Dir nicht sagen, weil dafür nicht genügend Informationen zu Deiner Umgebung vorliegen.

Moin, und dabei steht doch alles in der Fehlermeldung, was man wissen muss. In der Postfachdatenbank "Mailbox Database 0392768068" ist eine Öffentliche Ordner-Datenbank eingetragen, die Du gelöscht hast. Und sollst Du korrigieren. BTW: CU 5 ist aktuell.

Bei SSL sind Domänenname und Pfad normalerweise verschlüsselt, darum der Aufwand mit dem Proxy oder den unterschiedlichen IP-Adressen.

Würde ich mir gut merken. Ist wie gesagt, weder supported und vorgesehen und ich kenne sowohl iOS als auch Windows Phone Versionen, die quittieren die Eingabe von "server:port" mit "ungültiger Servername". Selbst, wenn es jetzt funktioniert, kann sich das also jederzeit und ohne Ankündigung wieder ändern. Mit Windows fallen mir drei Möglichkeiten ein (mehr geht mit Zusatzprodukten wie TMG/UAG oder Dritt-Proxys): - SNI (gibt es ab Windows 2012): Setzt aber voraus, dass die Applikation das auch kann und bei Exchange geht das IMHO noch nicht - IIS ARR -> Vorteil: man kann ziemlich differenziert steuern; Nachteil: IMHO ziemlich aufwendige IIS Konfiguration und damit fehlerträchtig - WAP -> Vorteil: sehr einfache Konfig (Zertifikat einspielen, Hostnamen festlegen, fertig); Nachteil: ADFS muss konfiguriert sein (aber man muss es nicht verwenden) Ich selbst benutze bei mir einen WAP. Der leitet die Subdomain "login.XXX" auf den ADFS weiter (für Office 365), die Subdomain "rd.XXXX" auf ein Remotedesktop Gateway und die Domain "mail.XXXX" auf Exchange. Dafür braucht es drei unterschiedliche Zertifikate die mit private Key sowohl auf dem WAP aus auch auf den Zielservern installiert sind. Geht aber alles über eine IP, die noch dazu dynamisch ist.

Moin, IMHO ist ein anderer Port als 443 für OWA nicht supported und die Änderung dafür zwar wohl angeblich möglich, aber nicht trivial und fehlerträchtig. Wie hast Du es denn geschaft, dass Active Sync auf einem anderen Port funktioniert? Beim Client ist ein anderer Port offiziell gar nicht vorgesehen und man kann ihn bei den meisten Clients auch gar nicht eintragen. Also selbst, wenn das jetzt bei Dir geht, kann das nächste Update das wieder kaputt machen. Außerdem darfst Du nicht vergessen, dass Deine Anwender in fremden Netzen eventuell gar keinen anderen Port benutzen dürfen, weil die ausgehend geblockt werden. Und schlussendlich bleibt die Frage nach dem Sinn. Der Sicherheitsgewinn ist sehr gering (bis gar keiner), die Komplexität steigt aber rapide und die Fehlersuche wird auch sehr schwer.

Wenn Du beim Provider eine SMTP-Weiterleitung hast, muss der Provider die gleiche Größe oder weniger erlauben. Auf keinen Fall darf er eine Mail annehmen, die ihr danach ablehnt. Sonst erzeugt ihr schönsten Backscatter und riskiert, auf eine Blacklist zu kommen. Und dann erzeugt den NDR wieder der Absender.

Würde ich dann aber lieber mit verschiedenen Sende Connectoren machen. Ist zwar mehr Konfigurationsaufwand, aber übersichtlicher, flexibler und der Ort, an den erfahrene Admin zu erst suchen würden. @bill: Definiere "intern"? Innerhalb von Exchange ist alles verschlüsselt. Und auch hier würde ich dann lieber mit einem eigenen Connector arbeiten, die man bei Share Maildomains eventuell eh hat.