Exchange Server unterschiedliche Patchstände sendet gesendete Mails erneut

Seit letzter Woche gibt es eine neue Exchange Angriffsvariante egal welcher Patchstand und welche Version von 2013 bis 2019. Nach langer Recherche haben wir den Angriffspunkt gefunden, hierbei wird der httpProxy als Eintrittspunkt benutzt.

Folgende Einstellung muss geändert werden damit der Mailserver wieder funktioniert und das senden gestoppt wird:

 

  1. Exchange Management Shell öffnen (wird nicht funktionieren Fehler mit WIN-RM Client)
  2. IIS öffnen -> Server -> Sites -> Default Web Site -> Powershell öffnen
  3. Rechts oben auf „Grundeinstellungen öffnen“
  4. Physische Pfad zeigt momentan auf Frontend und HttpProxy gehöhrt aber standardmäßig auf:
    1. „C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Powershell“
    2. Einstellung anpassen und IISreset durchführen
  5. Exchange Management Shell erneut als Admin Starten

Für die Kontrolle gibt es noch den Exchange Health Checker diesen am besten von GitHub herunterladen https://github.com/dpaulson45/HealthChecker/releases/tag/v3.3.9

 

Postfächer verlustfrei aus defekter EDB wiederherstellen Exchange 2016/2019

Nachdem uns zwei Server unsere Exchange Server abgeraucht sind und wir keine Möglichkeit mehr hatten die Postfächer intern zu moven mussten wir die Postfächer aus der EDB wiederherstellen.

Hierzu haben wir einen neuen Exchange Server installiert auf aktuellen Patchstand gebracht und alle Einstellungen neu vorgenommen.

Danach die Festplatte des defekten EX eingebunden und die Mailbox Database gesichert in den neuen Exchange Standardpfad (C:\Program Files\Microsoft\Exchange Server\V15\Mailbox)

 

Um an die Postfächer zu kommen müssen folgende Schritte erledigt werden:

 

  1. Empfehlung eine neue leere Datenbank in Exchange anlegen, entweder über ECP oder über die Management Shell und die Verweise direkt auf die kopiere EDB legen
  2. Befehl für die Management Shell: New-MailboxDatabase -Name „Name der neuen Datenbank“ -Server „Name des Exchange“ -edbFilePath „Pfad zur EDB Datei“ -LogFolderPath „Pfad zu den Logfiles“
  3. Zu beachten, dass der „Name der neuen Datenbank“ in die AD geschrieben wird und somit später noch von Bedeutung ist!
  4. Nach erfolgreichem Anlegen der Datenbank diese auf den Clean Shutdown kontrollieren (Powershell als Admin ausführen und in den Ordner der EDB wechseln cd „Pfad zum EDB-Ordner“) via eseutil /mh „Name der Datenbank“ kontrollieren ob diese im Clean Shutdown sitzt.
  5. Mittels dem Befehl  Set-MailboxDatabase „Name der neuen Dankbank“ -AllowFileRestore:$true das kopieren erlauben
  6. Nach erfolgreicher Befehlsausführung die Datenbank mounten und das Ergebnis kontrollieren via: Mount-Database „Name der neuen Datenbank“   Get-MailboxDatabaseCopyStatus
  7. Da unsere Benutzer das HomeMBD in den Attributen verloren hatten, über den Domaincontroller das ADSI öffnen, die Konfiguration öffnen und den Pfad manuell dem Benutzer wieder einfügen

.

8. Der Pfad in dem Benutzer sollte dann wie folgt aussehen:

CN=Name der neuen Datenbank,CN=Databases,CN=ExchangeAdministrativeGroup,CN=…………

(Immer von der Datenbank nach oben arbeiten Ordner für Ordner

 

Nachdem das geschehen ist, ist das Postfach wieder erreichbar und die Daten waren bei uns wieder vorhanden. Somit konnten wir die Postfächer auf eine neue Datenbank moven und das „Backupkonstrukt“ wieder löschen.

 

 

Outlook Startfehler Exchange Wartungsmodus

Hier handelt es sich um den Fehler, dass das Konto des Benutzers in Quarantäne ist. Um die Postfächer wieder funktionsfähig zu machen folgende Schritte in der Exchange Management Shell ausführen.

 

  1. Get-Mailbox | Get-MailboxStatistics | Where {$_.IsQuarantined -eq $True} (hier werden alle Postfächer angezeigt, die in Quarantäne sind)
  2. Disable-MailboxQuarantine „Postfachname“ (mit diesem Befehl können einzelne Postfächer freigegeben werden)
  3. Disable-MailboxQuarantine -IncludeAllMailboxes (hiermit werden alle Postfächer aus der Quarantäne geholt.)

Danach können sich die Benutzer wieder normal mit Outlook verbinden.

Exchange Server CU Update schlägt bei Transportdienst fehl Fehler5506

Nachdem wir häufiger mit diesem Problem konfrontiert werden hier nun die Lösungen die wir herausgefunden haben.

 

  1. Start des IIS-Managers und anklicken von „Sites“ und anschließend die „Default Web Site“
  2. Rechts im Fenster „Bindings“ bzw. „Bindungen“ anklicken

3. alle manuell angeleten Bindings entfernen und nur die 127.0.0.1 und * mit http und https stehen lassen

4. öffnen der https Bindings (127.0.0.1 und *) durch Doppelklick

5. Zertifikat auf „Exchange Server“ legen

6. Neustart des Updates

 

Durch das Umlegen des Zertifikates funktioniert das Update. Es wird ebenfalls erkannt, dass eine unvollständige Installation vorangegangen ist, deshalb auf jeden fall bei der Abfrage ob es fortgesetzt werden soll auf „JA“ klicken!

Lets Encrypt Zertifikat über das Programm WACS.exe

Hier gibt es eine kurze Einweisung in das Programm WACS, mit dem man sich Lets Encrypt Zertifikate erstellen kann (für Testinstallationen ect.).

VORAB: Diese Zertifikate sind NICHT für den Livebetrieb gedacht!

 

Unter folgendem Link kann das Programm heruntergeladen werden.

https://www.win-acme.com/

 

Die Dateien entpacken, vorzugsweise direkt unter C:\ und wacs.exe starten.

.Net Framework 4.8 muss installiert sein, damit es funktioniert, ebenso wie ein Portforwarding auf Port 80 und 443 von außen. Ohne diese Zugriffe ist es NICHT möglich die Zertifikate zu erstellen.

 

Danach den Punkten folgen und Zertifikate erstellen lassen.

 

Lets Encrypt (WACS) Zertifikatskennwort auslesen

Nachdem man bei o.g. Programm das Problem hat, dass das Hauptzertifikat Kennwortverschlüsselt ist haben wir uns mal hingesetzt und gesucht, wo das generierte Kennwort zu finden ist. (Wird z.b. zum Import bei Remotedesktopgateways oder IIS Servern benötigt)

Wie folgt vorgehen, um das Kennwort auszulesen:

  1. Wacs.exe als Administrator starten.
  2. „L“ drücken um die Renewals Scheduled angezeigt zu bekommen
  3. betreffenden Scheduled auswählen
  4. unter Details steht das pfx Password

 

Dieses Kennwort wird für das Zertifikat unter „C:\ProgramData\win-acme\acme-v02.api.letsencrypt.org\Certificates\zertifikatsname-all.pfx “ benötigt. Mit diesem Kennwort kann das Kennwort in betreffende Features importieren.

 

Im diesem Beitrag wird das Programm „WACS“ beschrieben.

Office Click-to-run und Windows Setup parallel installieren

Wenn Sie Office per Windows Installer installieren, bekommen Sie bei der Click-To-Run Installation eine Fehlermeldung, dass es nicht installiert werden kann.

Die Folgenden Schritte helfen, das zusätzliche Office oder Projekt/Visio zu installieren.

 

  • über „Systemsteuerung“ und „Programme und Funktionen“ schauen welche Version (x86 oder x64) installiert ist.
  • öffnen Sie die Registry (über „Start“ (links unten auf dem Desktop) und direkte Eingabe des Wortes (Regedit)
  • navigieren Sie zu dem folgenden Key:
  •  bei 32-bit HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall
  • bei 64-bit HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
  • per Rechtsklick einen neuen DWORD erstellen mit dem Namen „SystemComponent“ und dem Wert 1
  • Danach wieder in „Programme und Funktionen“ und über F5 aktualisieren, hier sollte das Office dann verschwinden.
  • ausstehende Installation ausführen und danach einmal starten.
  • zum Schluss den Registryeintrag einfach wieder löschen und über „Programme und Funktionen“ und F5 kontrollieren, ob beide Office angezeigt werden

 

 

Moviestar Patientenakte bleibt ohne Inhalt

Nach Update bleibt die Patientenakte in Moviestar leer.

 

Lösung:

IPv6 in der Netzwerkkarte deaktivieren.

Unter Moviestar Installationspfad in den Ordner „Admin“ und dort die Datei „DB Compact“ ausführen.

 

Danach sollte die Akte wieder einsehbar sein. Problem liegt an der Access Datenbank, da diese zu groß wird und nicht mehr gelesen werden kann.

Outlook 2016/2019 verlangt immer wieder Passwort

Problem war nur an einem PC existent. Die anderen PCs der Firma liefen fehlerfrei. Nach den Standardlösungen (neues Profil inkl. PC-Bereinigung, Neuinstallation Outlook, Exchange Cache Mode deaktivieren, Kontrolle Exchange2016 MAPI Authentifizierung und IIS-Logs), haben wir in ITler Manier in einer Tag und Abendaktion angefangen das Problem zu identifizieren. Das Problem ist so einfach wie simpel, aber man muss es finden.

Kontrolle und Lösung:

In der Anmeldeinformation in der Windows Systemsteuerung fiel unter den „generieschen Anmeldeinformationen“ auf, dass es einen Punkt von „Office365“ gab, was erklärt weshalb Mitschnitte des Verkehrs bei der Authentifizierung immer nach „aussen“ kommuniziert haben.

Durch setzen des folgenden Registrykeys wird eine nicht benötigte Office365 Authentifizierung unterbunden (ACHTUNG WENN IHR UNTERNEHMEN Office365 BENUTZT DIESEN SCHRITT NICHT MACHEN)

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

 

Bei uns gab es den Schlüssel „Autodiscover“ nicht, diesen haben wir angelegt und anschließend darin den dWord angelegt.

 

 

Danach Registry schließen, in Outlook ein neues Profil anlegen und verbinden.

Es funktioniert sowohl im Cache, als auch ohne Cache Modus.

Seitdem dieser Key gesetzt wurde tritt das Problem nicht mehr auf.