RobertWi

Moin, was sollen wir Dir denn helfen? Beim Journal funktioniert das so und lässt sich auch nicht ändern. Wenn Du das anders haben willst, kannst Du das nicht über ein Journal lösen, sondern z. B. über eine Transportregel. Außerdem brauchst der Kunde dann dafür auch keine Enterprise-CAL.

Moin, die Exchange-Befehle werden nicht als Module oder Snappin eingebunden. Beim starten der EMS ein Script ausgeführt, dass die Befehl in Functions "wrapped". Dadurch wird das Remoting erleichtert und außerdem RBAC abgedeckt. Wenn Befehl nicht auftauchen, ist es meist ein Berechtigungsproblem. Ist das das gleiche Konto? Hat der beiden Maschinen die gleichen lokalen Berechtigungen? Verbindet sich die EMS mit dem "richtigen", sprich lokalen, Server? Haut die Benutzerkontensteuerung eventuell irgendwie dazwischen?

Moin, bitte häng Dich nur an fremde Fragen, wenn Du genau identisch die gleiche Konfiguration und identisch den gleichen Fehler hast. Mit anderen Worte: Wenn Du der OP bist. Ansonsten hast Du andere Fehler und damit eine neue Frage in einem neuen Thread. Warum der OP gar keine Antworten bekommen hat, könnte daran liegen, dass er im falschen Forum gepostet hat, kein Mod das gesehen hat und die Leute aus dem Exchange-Forum seine Frage daher gar nicht gesehen haben.

Moin, in diesem Fall wäre es mal sinnvoller gewesen, den Thread nicht zu teilen, weil im letzten Post des anderen Threads auch die Antwort zu diesem "Problem" hier besteht. Es ist nämlich nur ein Anzeigeproblem: Erklärung: Das Ablaufdatum wird nicht gespeichert, es wird beim Login berechnet. Überleg Dir mal, wie umständlich das bei Änderungen an der DDP wäre, dann müssten alle Konten angefasst und berechnet werden und bei Replikationsverzögerungen würde es eventuell lange dauern, bis die Änderung bei den Konten ankommt. Viel sinnvoller ist es, einfach nur beim Login zu überprüfen und dann zu reagieren. (lastLogonTimestap - pwdLastSet) > MaxPasswordAge = Password expired Dabei wird dann noch userAccountControl beachtet, ob das Kennwort überhaupt abläuft, usw. Die von Dir oben genannten Tools berechnen daher vermutlich einfach nur die Anzeige falsch.

Der Exchange-Teil ist einfach. Du musst ein sog. "Hard Recovery" durchführen (auch diesen Begriff hat Dein Link falsch verwendet), setzt aber ein korrektes Online-Recovery der Backup-Software voraus: http://technet.microsoft.com/de-de/library/aa996168(v=exchg.65).aspx http://msexchangeguru.com/2009/07/12/exchange-database-recovery-using-eseutil-commands/ (Bei den Korrekturen falschen Knopf erwischt)

(Und noch einer: http://social.technet.microsoft.com/Forums/de-DE/0e86120c-17b4-4f75-8b49-a43dd65417f8/ex07-komplettes-vm-recovery-transaction-logs-nachpfelgen nein, viel hilft NICHT viel. Viel führt in diesem Fall nur dazu, dass niemand mehr Lust hat, zu antworten, wenn Du so mit der Freizeit anderer Leute umgehst!) Zum Thema: Niemand kann alles wissen, daher sollte es überhaupt kein Problem sein, einem Kunden zu erklären, dass man kein Experte für ein Recovery vom Exchange im Allgemeinen und mit Veeam im Speziellen ist. Sonst wäre Dir zum Beispiel die merkwürdige Reihenfolge in Deinem Link aufgefallen (nimm lieber den hier - klick oder den offiziellen). Wie gesagt, gibt es vom Hersteller eine Software i.d.R. Restore-Strategien. Einfach nur Log-Dateien zurückkopieren, nützt Dir nichts. Der Exchange muss auch gesagt bekommen, dass er ein Recovery durchführen soll. Es kann sein, dass Veeam das gleich mitmacht und Exchange danach auf die Logs wartet. Daher sammle zuerst mal die benötigten Infos. "Hörensagen" ist immer schlecht und hilft weder Dir noch uns.

Das muss nicht zwingend was mit der DB zu tun haben. Laufen alle Dienste (test-servicehealth)? /R, /P und bei Bedarf noch /D wäre die richtige Reihenfolge. Wobei /R nichts bringen sollte, wenn die DB sauber dismounted wurde. Theoretisch schon. Eventuell ist das Computer-Kennwort abgelaufen, dann könnte es noch lustig werden. ABER: Was sagt den Veeam, wie das Recovery eine Exchange VM durchgeführt werden soll? Gibt es kein Wiederherstellungs-Konzept? Theoretisch und mit dem richtigen Backup gesichert, geht das. Aber das übersteigt bei weitem die Möglichkeiten eines Forums. Da wäre es sinnvoller, ihr holt Euch einen Fachmann ins Haus.

Moin, welchen Zugriff auf die Konfiguration des Hyper-V und die VMs hast Du denn?

Die Etage oberhalb von Dir bezahlt Dich doch aber hoffentlich für Deine Expertise und könnte auf Dich hören, wenn Du Ihnen Gründe lieferst, warum das von Ihnen geplante in der Praxis nicht sinnvoll ist, oder? Speziell für Exchange wirst Du neben hohem Aufwand (jeden PC anfassen), auf sehr viele andere Probleme stoßen. Im Endeffekt ist es egal, mit welchem Tool Du die Daten aus der alten Datenbank saugst und in die neue schiebst (die meisten der oben erwähnten machen das nur via PST-Dateien): Es sind nur scheinbar die alten Daten. In Wirklichkeit wirst Du aber viele lustige Effekte feststellen: Wenn Du auf interne Mails nicht mehr direkt antworten kannst (fehlerhafte LegacyExchangeDN). Oder wenn sich Termine aus Einladungen nicht mehr ändern lassen (falscher Besitzer, Änderung nicht möglich).

Dir ist aber bewusst, dass ein Reverse Proxy sehr viel Komplexität, aber quasi kaum Sicherheitsgewinn bringt?

Manche Sachen davon auf allen Servern, manche nur auf RDP, manche nur auf Clients.

Bei uns: - WSUS - Bildschirmschoner - Templates für Office (per Script) - Fonts (per Copy und Reggkey) - Stammstellen-Zertifikate - VPN-Voreinstellung - WLAN-Voreinstellung - Makro-Sicherheit - PST-Datei-Abschaltung

Aber am Ende kann die Frage nur der Hersteller der Drittanbietersoftware beantworten.

BTW: Stille Post ist b***d. Daher gib an Deinen Admin auch weiter, dass der bei O365 für den Support bezahlt, also soll er den auch dort in Anspruch nehmen! Entweder stellt er die Frage in den offiziellen O365 Foren oder er schreibt den Support über den Admin-Bereich von O365 an. Die können dann auch direkt nachsehen, was er konfiguriert hat.

Moin, wo steht denn der Smarthost? Wenn Du den nutzt, gehen ja die Mails über diesen und nicht direkt an web.de oder gmx.de.

Moin, die Abwesenheitsmeldung kann man auch über die EMS ändern: "Get-MailboxAutoreplyConfiguration". Ist aber ein wenig sperrig, da Exchange hier HTML benutzt. Wenn er eine Regel im Abwesenheitsassistenten eingerichtet hat, kenne ich von außen keine einfache Lösung. Dann ist Vollzugriff die einfachste. Wenn er eine normale Posteingangsregel hat, kann man die auch via EMS anfassen: Get-Inboxrule.

Moin, ist die Weiterleitung auf eine dynamische Adresse? Wenn ja, dann habe ich bei GMX schon festgestellt, dass das sehr, sehr lange dauert, bis die Mails zustellen. Es gibt in der Zeit nicht mal Verbindungsversuche, was darauf hindeutet, dass GMX einfach sehr lange mit der DNS-Auflösung braucht. Schick doch zum Test mal direkt an die Weiterleitungsadresse. Bei mir war das so nervig, dass ich meinen GMX-Account - wird bei einigen Online-Shops benutzt - über eine andere Methode in Exchange bekomme (ich sage jetzt nicht welche, sonst werde ich gesteinigt).

Ach? Frage von mir: Antwort von Dir: Meisten stelle ich solche Fragen nicht ohne Grund und erhoffe eine korrekte Antwort . :(

Moin, ich würde am Empfangs-Connector mal TLS abschalten, weil ich öfter erlebt habe, dass so ein MuFu nur simpelstes SMTP kann.

Und auch Outlook nutzt ihn nicht intern. Ein Domain-Client benutzt den SCP. Ein mobiles Gerät kann sich auch mit fehlerhaften Autodiscover verbinden, weil es dann einfach alle Daten fragt. Outlook dagegen ist ziemlich "hilflos" und will dann nicht.

Moin, der Beitrag ist kaum zu lesen, das macht Hilfe nicht unbedingt einfach. - Ist Autodiscover korrekt konfiguriert? - Warum hast Du einen SRV-Eintrag gesetzt? - Ist das Zertifikat fehlerfrei?

Nicht zwingend. Würde ich die Lizenzen eines Kunden verkaufen, würde die 24 Euro + Ust kosten. Da ist bis zu 150 Euro eine Menge Gewinnspanne. ;) Jeder VL-Vertrag kann anders aussehen. In der Firma würde ich auch mindestens das doppelte bezahlen. Das wiederum wissen wir nicht.

Moin, offensichtlich ist für diesen Standort der SCP für Autodiscover oder die Autodiscover-Site falsch konfiguriert. Fehler 403 bedeutet "Forbidden".

Im ersten Kommentar steht, dass Microsoft den Key angeblich als echt definiert hätte. Die Frage ist: Kontrollieren die dabei nur den Key oder die gesamte Lizenz. Das der Key echt ist, bezweifelt niemand, aber die Lizenz selbst.

Das ist ja eingeblich ein Prof Plus und müsste damit aus einem VL stammen. Das kann zwar aus der Ferne niemand würden, macht die Sache aber noch komischer.