Bei verschiedenen Kunden hatte ich neulich folgendes Problem: Der manuelle Scans als auch die geplanten Scans mit SMSMSE schlugen jeweils mit folgender Fehlermeldung fehlt:

The scan Manual could not be completed as Microsoft Exchange’s Client Access Server is not reachable.
Error code:0x80004005

Eine Google Suche findet zwei Einträge zu diesem Thema:

https://knowledge.broadcom.com/external/article?legacyId=tech250662
https://knowledge.broadcom.com/external/article?legacyId=TECH212055

Den ersten Eintrag konnte ich ignorieren, da der Scan bei allen Kunden schon funktioniert hatte.

Als Ursache für das Problem hatte ich zuerst das aktuelle CU15 für den Exchange 2016 in Verdacht – jedoch gab es eine Installation, bei der der Scan funktionierte – obwohl CU15 installiert war.

Blieb also der zweite Eintrag. Aber egal was ich gemacht habe, die Scans funktionierten weiterhin nicht.

Bei der Google Suche fand ich dann aber folgenden Eintrag:

https://knowledge.broadcom.com/external/article?legacyId=tech224647

und dort wird interessanterweise als Beispiel für eine EWS Url genannt

For example: https://server2008r2.exchange2010.internal/EWS/Exchange.asmx

während bei TECH212055 die Rede vom FQDN ist.

Sollte das die Ursache sein?

Tatsächlich, nachdem ich den Registy-Eintrag

ExchangeWebserviceURL auf https://Servername.internedomain.local/ews/ Exchange.asmx gesetzt habe und die Symantec Dienste neu gestartet habe funktionierte es wieder.

Die Dokumentation von Symantec ist daher falsch! Die EWS Url kann man mit

Get-WebServicesVirtualDirectory |Select name, *url* | fl

auslesen. Und in allen Fällen waren die URLs korrekt auf den externen offziellen FQDN gesetzt. Trägt man den jedoch bei ExchangeWebserviceURL ein, so funktionieren die Scans nicht.

Man muss bei ExchangeWebserviceURL den internen Servernamen inkl. Domäne eintragen.

Und selbst wenn es dann funktioniert, darf man den SJMAutoDiscoverTimeoutSeconds Eintrag nicht vergessen, sonst löscht SMSMSE die korrekten Einträge immer wieder.

PS: Das das SSL Zertifikat für die interne URL nicht ausgestellt ist, spielt scheinbar keine Rolle.

Beim Update von Lexware reisekosten auf einem Windows 2016 Server bekam ich folgende Fehlermeldung:

Laut Hotline sollte man die Firewall und den Virenschutz deaktivieren.

Auch die Online-Hilfe brachte nicht weiter:

https://www.lexware.de/support/faq/produkt/kassenbuch/faq-beitrag/000003248-es-besteht-keine-internet-verbindung-bitte-stellen-sie-eine-verbindung-her-oder-pruefen-sie-ihre-proxy-und-firewalleinstellungen/

Alle Massnahmen führten aber nicht zum Erfolg. Auf den richtigen Weg brachte mich dann aber dieser Eintrag im Logfile (im Temp Ordner)

Error 0x80072f76: Failed to acquire payload from: ''https://downloadsetup.haufedev.systems/24B302CD-9AAF-49c9-94CC-42C6F99A06F6/2019/19.00.00.0067/Installationshinweise.rtf' to working path: 'C:\Users\USERNAME\AppData\Local\Temp\{2A2D3FC7-BA58-4F90-9487-A99F467FFC49}\payF69DDF3920847B17435F37A72822DC75'

Genau diese besagte Datei https://downloadsetup.haufedev.systems/24B302CD-9AAF-49c9-94CC-42C6F99A06F6/2019/19.00.00.0067/Installationshinweise.rtf konnte ich auf dem Server jedoch nicht herunterladen, da auf dem Server für den IE natürlich die verstärkten Sicherheitskonfiguration aktiviert war und diese den Download von RTF Dateien im IE nicht erlaubt.

Mit anderen Worten: Das Setup-Programm von Lexware nutzt den IE zum Download der Dateien und dieser richtet sich natürlich nach den Voreinstellungen im OS.

Also im Servermanager die verstärkte Sicherheitskonfiguration für den IE deaktivieren und das Update läuft durch.

Danke Lexware!

Auf einem Windows 10 Computer hatte ich neulich ein interessantes Phänomen – im Taskmanager wurden teilweise sehr hohe Auslastungen in der Übersicht angezeigt, obwohl die einzelnen Prozesse eine sehr geringe Auslastung hatten.

Die Summe der CPU Last stimmte hinten und vorne nicht:

Zuerst kam natürlich der Verdacht, dass der Rechner von Malware befallen war eine gründliche Überprüfung hat jedoch nichts gefunden.

Dann viel mir einem anderen Windows 10 Rechner das gleiche Problem auf – auch hier stimmten die Werte im Taskmanager nicht und da kam mir ein Verdacht: Beide Computer hatten das erste (fehlerhafte) Windows 10 Update 1809 durchgeführt – und siehe da, das ist ein Bug im Windows 10 1809:

Quellen:

https://www.pcgamer.com/task-manager-bug-in-windows-10-october-update-misreports-cpu-usage/

https://social.technet.microsoft.com/Forums/en-US/b7e65c74-1ab9-4082-9579-a8fbf932cd65/windows-10-1809-task-manager-processes-tab-cpu-bug?forum=win10itprogeneral

https://www.pcwelt.de/a/windows-10-oktober-2018-update-task-manager-hat-einen-bug,3452445

Task Manager is not showing correct CPU usage! Windows 10 Version 1809 from Windows10

Nachdem ich mehrere virtuelle Server von Hyper-V nach VMWare migriert hatte, scheiterte die Datensicherung mit Veeam bei allen diesen Server mit folgender Fehlermeldung:

Failed to prepare guest for hot backup. Error: VSSControl: -2147212529 Backup job failed.

Discovery phase failed.

Cannot add volumes to the snapshotset.Volume name: [\\?\Volume{5a0b136c-5066-4965-9ed4-c1a794a96f8f}\].
 
Cannot add volume to the set of volumes that should be shadowed.

VSS error: VSS_E_UNEXPECTED_PROVIDER_ERROR. Code:0x8004230f

Ursache für den Fehler war der VSS Provider von Hyper-V der auf der VM noch immer aktiv war.

Die Eingabe von “vssadmin list providers” ergab:

C:\Windows\system32>vssadmin list providers
vssadmin 1.1 - Verwaltungsbefehlszeilenprogramm des Volumeschattenkopie-Dienstes

(C) Copyright 2001-2013 Microsoft Corp.

Anbietername: "Hyper-V IC Software Shadow Copy Provider"
Anbietertyp: Software
Anbieterkennung: {74600e39-7dc5-4567-a03b-f091d6c7b092}
Version: 1.0.0.0

Anbietername: "Microsoft File Share Shadow Copy provider"
Anbietertyp: Dateifreigabe
Anbieterkennung: {89300202-3cec-4981-9171-19f59559e0f2}
Version: 1.0.0.1

Anbietername: "Microsoft Software Shadow Copy provider 1.0"
Anbietertyp: System
Anbieterkennung: {b5946137-7b9f-4925-af80-51abd60b20d5}
Version: 1.0.0.7

Den ersten Provider benötigt man nicht mehr. Man deaktiviert diesen, indem man den entsprechenden Eintrag in der Registry unter

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Providers\

einfach löscht.

Nach einem Reboot funktionieren die Veeam Backups wieder wie gewohnt.

Bei einem Office 365 Migrationsprojekt stolperte ich über folgenden SPF Fehler:

Authentication-Results: spf=permerror (sender IP is 40.107.1.124)
smtp.mailfrom=KundenDomainXYZ.com; hotmail.com; dkim=pass (signature was verified)
header.d=KundenDomain.onmicrosoft.com;hotmail.com; dmarc=none action=none
header.from=KundenDomainXYZ.com;
Received-SPF: PermError (protection.outlook.com: domain of KundenDomain.com used
an invalid SPF mechanism)

Das interessante war, dass alle anderen Mail-Systeme (Barracuda) etc. die ausgehenden Emails des Kunden als korrekt durchliess – nur die Server von Microsoft (Office 365, Outlook.com etc.) meckerten immer.

Die gängingen SPF Validatoren fanden interessanterweise auch keinen Fehler im SPF Eintrag für die KundenDomäne:

v=spf1 mx ip4:XYZ.XYZ.XYZ.XYZ/32 include:spf.protection.outlook.com include:mail.kundenserverXZY.de ?all

Der Eintrag sollte die Emails vom Mail-Server mit der IP XYZ.XYZ.XYZ.XYZ als valide darstellen, genau wie die von Office 365 und dem on-premise Exchange-Server.

Ursache

Der Fehler bei Microsoft wurde durch die falschen Nutzung des “include:” Attributes in dem SPF Eintrag verursacht. Denn “include:” bedeutet, dass der Server nachschaut, ob es für “mail.kundenserverXZY.de eigene SPF Einträge existieren. Wenn dieser aber nicht existieren, dann wäre das Attribut “a:” korrekt.

Somit wurde der SPF Eintrag korrigiert:

v=spf1 mx ip4:XYZ.XYZ.XYZ.XYZ/32 include:spf.protection.outlook.com a:mail.kundenserverXZY.de ?all

und schon gingen die Emails durch:

Received-SPF: Pass (protection.outlook.com: domain of kundendomainxyz.com
designates 40.107.1.131 as permitted sender) receiver=protection.outlook.com;
client-ip=40.107.1.131; helo=EUR02-HE1-obe.outbound.protection.outlook.com;

Nachdem an unserem Unitymedia Anschluss das Cisco Kabelmodem kaputt war, brauchten wir ein neues Kabel-Modem damit wir die Watchguard als Firewall daran hängen konnten. Der Unitymedia Support empfahl mit eine Fritzbox zu kaufen, da diese den Bridge Modus beherrschen.

Leider stimmt diese Aussage nicht mehr, da die aktuelle Fritzbox 6490 mit Fritz!OS 06.63 den Bridge Modus nicht mehr zur Verfügung stellt….

Nun eigentlich…. man kann diese doch noch aktivieren.

1. Man sichert die Config der Fritzbox unter System->Sicherung lokal auf einen Rechner.
2. Den Eintrag “lanbridges_gui_hidden = yes;” ändern man entsprechend mit einem Texteditor ab zu “lanbridges_gui_hidden = no;”
3. Für den gesamten Text muss man dann eine neue Checksumme berechnen lassen – das geht z.B. hier: http://www.mengelke.de/Projekte/FritzBoxJSTool
4. Den neuen Wert trägt man dann in der letzten Zeile ein (**** END OF EXPORT XZY123 ****) und speichert die Datei wieder.
5. Diese modifizierte Config lädt man dann in die Fritzbox hoch und führt einen Neustart durch

Und siehe da:

Entsprechenden LAN Port auswählen und dann die Firewall daran anschließen. Per DHCP erhält man dann eine externe IP.

Aber Vorsicht: Die Fritzbox zieht sich natürlich auch eine IP -d.h. hat man einen Tarif mit nur einer externen IP Adresse, dann wird auch nur diese geroutet.

In einem solchen Fall ist die Konfiguration als Exposed Host ratsam.

Für einen Kunden habe ich eine Exchange 2016 Organisation mit drei Exchange Servern aufgebaut.

Auf den Windows 10 Computern bekamen aber alle Benutzer folgende Fehlermeldung, sobald Sie OWA mit IE oder Edge öffnen wollten:

Auf dem betroffenen Exchange 2016 Server (CU6 und CU7) kam jeweils folgende Fehlermeldung im Systemprotokoll:

MSExchange Front End HTTP Proxy - EventID 1003

[Owa] An internal server error occurred. The unhandled exception was: System.Globalization.CultureNotFoundException: Culture is not supported.
 Parameter name: culture
 4096 (0x1000) is an invalid culture identifier.
    at System.Globalization.CultureInfo.InitializeFromCultureId(Int32 culture, Boolean useUserOverride)
    at Microsoft.Exchange.Net.ClientCultures.GetCultureInfoInstance(Int32 lcid)
    at Microsoft.Exchange.Net.ClientCultures.GetBrowserDefaultCulture(HttpRequestBase httpRequest)
    at Microsoft.Exchange.Clients.Owa.Core.OwaPage.InitializeCulture()
    at ASP.auth_errorfe_aspx.__BuildControlTree(auth_errorfe_aspx __ctrl)
    at ASP.auth_errorfe_aspx.FrameworkInitialize()
    at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
    at System.Web.UI.Page.ProcessRequest()
    at System.Web.UI.Page.ProcessRequest(HttpContext context)
    at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
    at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Interessanterweise kam die Meldung aber nur beim Zugriff auf die Exchange 2016 Server die auf Windows 2016 Server installiert waren. Der Zugriff auf den Exchange 2016, welcher auf Windows 2012 R2 installiert, war funktionierte einwandfrei.

Auch der Zugriff von externen Windows 10 Computern oder mit Firefox oder Chrome funktionierte einwandfrei.

Versucht wurde:

• Installation aller aktueller Windows Updates
• Umstellen der Mailbox-Default Sprache der betroffen User
• Update der Exchange Server auf CU7
• Update Windows von 1706 auf 1709

Ohne Verbesserung.

Bei der weiteren Fehlersuche fiel mir auf, dass im Windows 10 eine sehr merkwürdige Sprachauswahl English (en-DE) stand:

Lösung:

Nach der Korrektur der Sprachauswahl trat der Fehler nicht mehr auf. Interessanterweise kann man nachträglich diese Spracheauswahl auch nicht mehr auswählen:

Ursachenforschung:

Bei der Installation der Windows 10 Rechner wurde immer eine englische Evaluations ISO von Windows 10 genommen, als Tastatur aber Deutsch und als Region Deutschland ausgewählt. Somit kam “English (de-EN)” zustande.

Laut Microsoft (Quelle https://msdn.microsoft.com/en-us/library/ee825488(v=cs.20).aspx) gibt es diese “Culture” aber gar nicht.

Wieso kommt bei Windows Server 2016 eine Fehlermeldung aber bei Windows Server 2012 R2 nicht?

Die Powershell Abfrage system.Globalization.CultureInfo]::GetCultures(‘AllCultures’)  ergibt beim Windows 2016 Server:

D.h. diese Culture-Auswahl ist bekannt, ergibt aber 4096

Bei einem Windows 2012 R2 Server fehlt diese:

Fazit

Meiner Meinung nach handelt es sich also um einen Bug im Windows 1706 und 1709, da eine scheinbar ungültige Sprachkombination English (en-DE) im System eingetragen wird. Diese wird dann von IE und vom Edge an den OWA übertragen,  der damit dann aber nicht anzufangen weiss. Ergo Fehlermeldung.

Auf einem Windows 2012 R2 Server kommt es zu der Fehlermeldung nicht, da der Server diese Kombination nicht kennt und somit ignoriert.

Ausgangssituation

Nach einem Exchange 2013 Crash dank ESXI 6.0 musste ich eine Recovery-Installation durchführen.

Während der Neu-Installation des Exchange 2013 brach diese jedoch immer wieder mit Folgender Fehlermeldung ab:

Prozess Microsoft.Exchange.Directory.TopologyService.exe (PID=4772) Gesamtstruktur xxxxx.local. Fehler bei der Topologieerkennung, Fehlerdetails

No Minimal Required Number of Suitable Directory Servers Found in Forest xxxxx.local Site Standardname-des-ersten-Standorts and connected Sites..

Die Domäne hatte schon immer nur einen Domain-Controller, von daher war die Meldung erstmal unverständlich.

Verschiedende Seiten und Blogs empfehlen in diesem Fall den Wert

MinSuitableServer = “1”  in in der Microsoft.Exchange.Directory.TopologyService.exe.config zu ändern.  Aber auch das brachte keine Veränderung.

Letztendlich habe ich einen zweiten DC installiert – aber auch dies brachte keine Veränderung. Die Fehlermeldung blieb.

Die Lösung

Zielführend war folgende Seite:

https://bloke.org/windows/exchange-2003-2007-2010-topology-discovery-failed-error-0x80040a02-dsc_e_no_suitable_cdc/#comment-3982

Der Zusammhang war zwar ein anderer, aber das beschriebene Problem war das gleiche: In der Default Domain Controllers Policy hat unter

Computer Configuration ->Windows Settings -> Security Settings ->Local Policies -> User Rights Assignment  beim “Mange auditing and security log” der Eintrag “Exchange Servers” gefehlt (Warum auch immer in diesem Fall….)

Das heisst, der Exchange-Server hatte nicht das Recht auf die Auditing und Security Logs des Domain-Controllers zuzugreifen und das Installationsprogramm interpretierte dies mit der Meldung, dass nicht genügend Domain-Controller verfügbar waren – was natürlich kompletter Quatsch war.

Nachdem das korrigiert war, lief die Installation ohne Probleme durch.