RobertWi

Moin, Du wirst sicher ganz viele kleine Stolperstellen erleben, aber grundätzlich ist das schon ein Weg. Sorge halt ganz sicher dafür, dass die Maschinen keine Verbindung ins Internet und das restliche Netzwerk haben. Was beim neuen Server, wenn der Updates haben will, schon ein wenig Aufwand ist. Und warum sollten wir das nicht empfehlen: Das ist doch nur zum Testen und Spielen - und Testen und Spielen sind nie verkehrt.

Auch nach mehrmaligem Lesen, finde ich oben keinen "Posteingang" in Deinem PowerShell-Befehl. IMHO ist es auch nicht möglich, die Suche auf einen Ordner zu beschränken, nur auf eine Nachrichtenklasse (Mail oder Kontakte). Für Deine Aufgabe würde man normalerweise Aufbewahrungsrichtlinien einsetzen. Die deutsche Bezeichnung wäre "Gelöschte Elemente" oder "Gelöschte Objekte" - je nach Exchange und Outlook Version und ob migriert oder nicht. Eventuell kann man in der Searchquery mit "deleted" oder "isdeleted" arbeiten, dazu habe ich aber kein Beispiel gefuinden, nur das hier: http://msdn.microsoft.com/en-us/library/aa965711%28v=vs.85%29.aspx

Wie, Du schaust in die Hilfe und findest es trotzdem nicht? Get-PublicFolder \ -GetChildren

Ich schrieb ja oben, dass es viel mit den Daten zu tun hat. SMB 3.0 wurde von Microsoft konsequent auf die gute Nutzung der Netzwerkkarten designt. Hyper-V Live Migration wäre ein anderes gutes Beispiel. RDP dagegen ist ein typisches Beispiel, wo es aus Performancesicht meist wenig bringt, weil bei RDP das Netzwerk i.d.R. gar nicht der Flaschenhals ist. Trotzdem darf man unabhängig von den Daten nicht vergessen, dass es das Netzwerk komplexer macht und einfache Austausche erschwert. Ich habe z.B. einige Kunden, da ist kein Admin vor Ort und schon gar keiner, der Ahnung vom Netzwerk hat. Wenn ich bei dem ein Problem analysiere, dass auf einen defekten Switch zurückzuführen ist, dann sage ich ihm, fahre in einen Elektronikmarkt, kauf einen neuen und wechsel die Kabel 1:1. Mit Teaming geht das nicht mehr. Zum Finden der IP des Geräts: Eventuell reicht auch ein Ping in einer Schleife: for /l %i in (1,1,254) do @ping 192.168.1.%i -n 1 -w 100 | find "Antwort"

Du gibst Dir die Antwort doch selbst, oder? ;) Dein Netzwerk ist langsam, trotz Teaming und Du weißt nicht warum. Und wenn mal der eine Switch ausfällt, kommst Du im besten Fall gar nicht mehr an den Server, weil Du erst einen neuen Switch brauchst, der für Teaming geht und den wieder konfigurieren musst. Ohne Team steckst Du einfach nur einen neuen ran und fertig. Die höhere Leistung kommt leider in der Praxis nur selten zu Tage, weil Netzwerk eben nicht nur von der Netzwerkkarte abhängt, sondern viel mit den Daten zu tun hat, die übertragen werden.

Bei HP heißt das in der Konfig IMHO LACP oder Link Aggregation. Wobei man dazu sagen muss, dass das mit einem Switch eigentlich nur sehr wenig bringt (Redundanz gar nichts, Performance marginal), aber die Komplexität erhöht. Setze ich daher nur noch ein, wenn es auch zwei Switche sind.

Moin, ein solcher Fehler sollte eigentlich sofort auftreten und die Mail sofort zurückgehen, nicht erst 24 Stunden später. Wie wird die Mail in Richtung Internet gesendet - Smarthost oder DNS? Siehst Du die Mail in der Warteschlange? Welchen Fehler hat sie dort?

Grundsätzlich häng Dich bitte nicht an andere Thread, vorallem, wenn Du selbst schon die Fehlerursache des Original-Threads (falscher Cipher) ausgeschlossen hast Das würde ich abschalten und nur wieder einschalten, wenn man genau weiß, was das ist und das man es braucht. ;)

Moin, gäbe es für die Frage jedesmal einen Euro, bräuchte ich nicht mehr arbeiten. Entweder nutzt Du ein SAN-Zertifikat, in dem beide Namen enthalten sind. Vorteil: Funktioniert mit allen Gerät; Nachteil: Kostet Geld Oder Du legst im DNS einen SRV-Eintrag für Autodiscover an, der dann auf remote..... zeigt. Vorteil: Kostenlos, Nachteil: Funktioniert nicht mit allen Geräten Nachtrag: An den beiden fast zeitgleichen und nahezu identischen Antworten kannst Du vielleicht sehen, wie oft diese Frage schon aufgetaucht ist, dass man über die Antwort nicht mal mehr nachdenken muss.

Das höre ich nun allerdings zum ersten Mail. Wichtig war bisher nur, welchen Weg die Wiederherstellung nahm. Unsupported ist Schreiben in die EDB-Datei, supported der Weg über MAPI. Und das ist auch das, was die Programm benutzen, die ich kenne. Laut meinem Backup-Admin kann die neueste Version Ex 2013. Ich weiß allerdings nicht, welche Nummer die gerade trägt. Das wäre allerdings nicht neu. Vor Hyper-V war auch alles mögliche in der Virtualisierung unsupported.

Moin, dass man keine Empfehlungen findet, kann ich kaum glaube: Klick. Das füllt ausgedruckt ein kleines Buch. Für die Performance aus Exchange Sicht ist das ziemlich egal. Die Summe des ESE-Caches steigt mit der Anzahl der Datenbanken, das wirkt sich in der Praxis aber wenig aus, als ausreichend RAM und schnelle Platten. Daher macht man das Design der Datenbank in der Regel an der Hardware oder den Restore-Anforderungen fest. Eine gute Restore-Software ist übrigens problemlos in der Lage, einzelne Mails oder Postfächer wiederherzustellen. ;)

Falls noch Antworten kommen, vor hier mal lesen: http://www.msxforum.de/modules/newbb/viewtopic.php?post_id=84480

Moin, willst Du wirklich, dass die Benutzer ihre Optionen in OWA nicht mehr ändern können? Wenn ja -> http://www.hrzdata.com/node/46

Und außerdem ist SP 1 nicht mehr supported -> auf aktuellen Stand patchen! Nicht, dass wir hier über einen Bug reden, der schon seit Jahren behoben ist.

Oder, ist halt 2013: Verhalten geändert oder Bug. Beim SP1 ist es definitiv so, dass keine Mail rausgeht, zeige ich im Kurs.

Das passiert vollautomatisch durch Exchange. Natürlich musst Du dazu Deine Backup-Software korrekt konfigurieren und die richtige Sicherungsart verwenden. Bitte richtig lesen! Da steht drin: Die einfachste Methode der Protokollabschneidung ist die Verwendung der Backup-Option VSS-Voll-Backup aktivieren (Optionen –> Standardoptionen für Backup und Recovery –> Standardoptionen für Backup –> Volume Shadow Copy Service –>VSS-Voll-Backup aktivieren). Sie wird in den meisten Fällen empfohlen. Da muss keine Umlaufprotokollierung eingeschaltet werden, die im Desaster Fall eventuell zu Datenverlust führt. Die sollte überhaupt nur aktiviert werden, wenn man weiß, was man tut und warum. Der OP muss nur Acronis richtig konfigurieren. Auch die beste Backup-Software bringt nichts, wenn sich der Admin wie in diesem Fall weder mit der Backup-Software noch mit dem gesicherten Produkt auskennt. ;)

Wieso so weit? Steht doch sogar im fünften Kommentar unterhalb des Artikels.

Oder einfach die Bereitstellung aufheben und die Log-Dateien löschen. Unsauber gibt es eine Reihe von Möglichkeiten, aber vernünftig ist erstmal nur ein Backup.

Moin, wenn Du keine Fehlermeldung am Client haben willst, darfst Du das nicht abschalten. Sonst gibt es, egal, welchen Weg Du nimmst, immer irgendeine Meldung. Ist auch logisch, oder? Was geht: Per Script auf Postfachebene steuern; per Script am IIS steuern; an Friewall/Proxy/Gateway steuern. Aber was eingebautest gibt es da nicht. OWA und EAS sind, korrekt umgesetzt, von einander unabhängig.

Moin, der KB bezieht sich auf Exchange Server, die nur die CAS-Rolle installiert haben. Ist das bei Dir auch so?

Moin, wenn etwas von einen Tag auf den anderen nicht mehr geht, muss man sich mal fragen, was sich geändert hat. Und die Antwort kann nicht sein "nichts", denn sonst würde ja noch alles laufen. Und eine Problemsuche beginnt dann auch damit, dass man nach Fehlermeldungen such und die den Leuten zeigt, die man fragt. Die Mails stehen ja mit Fehler in der Warteschlange, bzw. sind mit Fehler zurückgegangen. Ja, Exchange braucht einen Sende Connector und da sollte nach einer frischen Installation keiner vorangelegt sein. Allerdings gibt der Connector nicht pro Server, sondern für die Organisation hast Du eventuell noch andere Exchange Server in der Organisation?

Nein, so ist das nicht. Im Standard ist das so: - Authentifizierte Benutzer dürfen mit IHRER Adresse an jeden Empfänger intern/extern senden - Anonym darf gar nicht einliefern Schalte ich Anonym in der EMC frei, darf jeder Mails ohne Anmeldung einliefern, aber NUR an interne Adressen (bzw. an jede Adresse der eigenen Domäne). Sowohl die Möglichkeit, den Absender frei vorzugeben (Accept-Any-Sender), als auch den Empfänger (Accept-Any-Recipient) hat im Standard niemand und muss über die Shell/AD eingestellt werden. (Ausnahmen hiervon könnten Exchange-interne Gruppen sein, aber das interessiert uns jetzt hier mal nicht). Wie gesagt: Das ist der Standard. Da Du oben schon eine Einstellung hattest, die nicht dem Standard entspricht, kann es durchaus sein, dass auch die Berechtigungen schief sind.

Korrekt, im Standard ist da nur "Exchange Benutzer" ausgewählt. Das ist auch OK. Man kann dafür auch einen eigenen Connector anlegen, solange die Remote IP korrekt ist. Wo siehst Du das? Ich sehe da Frank redet da von einem zusätzlichen Recht. Das hat aber im Normalfall nur "Authentifiziere Benutzer" und nicht Anonym. Aber er schreibt nichts davon, dass Anonym im Standard frei relayen kann. Wäre auch nicht so. Das, oder man spielt mit den Berechtigungen. Mache ich persönlich lieber.

Das ist korrekt. Ich finde aber, das es trotzdem ein Unterschied ist, ob man die Cloud als große Chance oder als einzige Pflicht sieht. Die MPVs führen intern immer Diskussionen über kommende CU oder über Features der nächsten Exchange Version und die Productgroup ist auch offen in Fragen wie "seht ihr bei Euren Kunden Bedarf eher für X oder Y". Und dabei kommt ziemlich gut heraus, dass zwar einige neue Features zuerst in der Cloud sein werden und erst mit Verzögerung On-Prem, aber es gibt dafür seit einiger Zeit wieder gute, nachvollziehbare technische Begründungen. Vor dem Erscheinen von Ex 2013 wurde Fragen die lautet "warum so Cloud und nicht so On-Prem" mit "machen wir halt so" beantworten. Jetzt kommt da sogar ohne Nachfrage proaktiv von dem PM die Aussage, "machen wir vorerst so, weil [technische Anforderung], aber wenn sich das bewährt, ist unser Ziel, das auch on-prem zu bringen." Man kann das schlecht beschreiben, wenn man es nicht selbst liest, aber die Kommunikation hat sich in den vier Jahren, in denen ich MVP bin, zwei mal drastisch verändert. Erst nach unten (da war on-prem gefühlt tot) und seit einem Jahr wieder deutlich nach oben. Und das stimmt mich hoffnungsvoll und die Hoffnung stirbt bekanntlich zuletzt. :) Was ich aber denke ist, dass sich das Release-Modell verändern wird. Weg von einem Major Release alle X Jahr, hin zu kleineren Releases in kürzeren Abständen. Wir sehen es ja jetzt schon bei Windows. Oder beim SQL, der als Versionsnummern 2012 und 2014 trug. Die Cloud wird so entwickelt und das wird sich auch lokal wiederspiegeln.

Ein freigegebenes Postfach geht technisch auch und lässt sich ohne Fremdtools auf mobile Geräte einbinden (mind. bei Apple und MSFT), erfüllt allerdings nicht die gewünschten Berechtigungen, weil Vollzugriff notwendig ist.