Exchange 2016 – 4096 (0x1000) is an invalid culture identifier

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.

 

No Minimal Required Number of Suitable Directory Servers Found in Forest

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.

Raid Erweiterung auf einem HP Proliant Server unter ESXi 6.0

Ausgangssituation

Auf einem HP Proliant Server mit ESXi 6.0 wird der freie Platz im Datastore knapp. Man fügt also zusätzliche Festplatten hinzu und möchte diese Platten jetzt dem Raid-Array und dann dem logischen Laufwerk hinzufügen ohne Downtime.

Durchführung: Man schaltet sich per SSH auf den ESXi Host und nutzt das Kommando

/opt/hp/hpssacli/bin/hpssa

Doof ist nur wenn dieses Programm nicht da ist – der Server wurde aber mit einem originalen HP ISO für VMWare installiert…

Lösung

Das notwendige Programm liegt bei ESXI 6.0.0 524934 unter

/opt/smartstorageadmin/ssacli/bin/

und unterstützt den interaktiven Modus nicht mehr.

Somit muss man jetzt eingeben:

ssacli ctrl all show config

und bekommt in meinem Fall (4x 900 GB mit Raid 10 und 2 zwei neuen Platten)

[root@esx01:/opt/smartstorageadmin/ssacli/bin] ./ssacli ctrl all show config

Smart Array P440ar in Slot 0 (Embedded)   (sn: XXXXXXXXX)


   Port Name: 1I

   Port Name: 2I


   Internal Drive Cage at Port 1I, Box 6, OK



   Internal Drive Cage at Port 2I, Box 6, OK


   Array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 1+0, OK)

      physicaldrive 2I:6:1 (port 2I:box 6:bay 1, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:2 (port 2I:box 6:bay 2, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:3 (port 2I:box 6:bay 3, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:4 (port 2I:box 6:bay 4, SAS HDD, 900 GB, OK)

   Unassigned

      physicaldrive 1I:6:5 (port 1I:box 6:bay 5, SAS HDD, 900 GB, OK)
      physicaldrive 1I:6:6 (port 1I:box 6:bay 6, SAS HDD, 900 GB, OK)

und dort sind auch die beiden neuen Festplatten. Diese fügt man jetzt hinzu mit:

ssacli ctrl slot=0 array A add drives=allunassigned

Dieser Vorang dauer jetzt sehr lange…..bei mir ca 8 Stunden.

Mit ssacli ctrl all show config kann man den Vorang beobachen:

....

   Array A (SAS, Unused Space: 1716905  MB)

      logicaldrive 1 (1.6 TB, RAID 1+0, Transforming, 2.66% complete)

und wenn es fertig ist:

Smart Array P440ar in Slot 0 (Embedded)   (sn: XXXXXXXXXXX)


   Port Name: 1I

   Port Name: 2I


   Internal Drive Cage at Port 1I, Box 6, OK



   Internal Drive Cage at Port 2I, Box 6, OK


   Array A (SAS, Unused Space: 1716905  MB)

      logicaldrive 1 (1.6 TB, RAID 1+0, OK)

      physicaldrive 1I:6:5 (port 1I:box 6:bay 5, SAS HDD, 900 GB, OK)
      physicaldrive 1I:6:6 (port 1I:box 6:bay 6, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:1 (port 2I:box 6:bay 1, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:2 (port 2I:box 6:bay 2, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:3 (port 2I:box 6:bay 3, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:4 (port 2I:box 6:bay 4, SAS HDD, 900 GB, OK)

Jetzt muss man das logische Laufwerk erweitern mit:

ssacli ctrl slot=0 logicaldrive 1 modify size=max forced

Die Erweiterung kann man dann mit kontrollieren mit ssacli ctrl all show config

Smart Array P440ar in Slot 0 (Embedded)   (sn: XXXXXXXXXXXXX)


   Port Name: 1I

   Port Name: 2I


   Internal Drive Cage at Port 1I, Box 6, OK



   Internal Drive Cage at Port 2I, Box 6, OK


   Array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (2.5 TB, RAID 1+0, OK)

      physicaldrive 1I:6:5 (port 1I:box 6:bay 5, SAS HDD, 900 GB, OK)
      physicaldrive 1I:6:6 (port 1I:box 6:bay 6, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:1 (port 2I:box 6:bay 1, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:2 (port 2I:box 6:bay 2, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:3 (port 2I:box 6:bay 3, SAS HDD, 900 GB, OK)
      physicaldrive 2I:6:4 (port 2I:box 6:bay 4, SAS HDD, 900 GB, OK)

Jetzt geht es zurück in den vCenter Client wo man den Datastore erweitert kann:

Fertig!

WSUS Datenbank auf Windows 2012 R2 neu erzeugen

Ich hatte neulich den Fall, dass die WSUS Datenbank auf einem Windows 2012 R2 Server korrupt war und daher der WSUS Dienst nicht mehr funktionierte.

Die naheliegende Idee, WSUS Server deinstallieren und wieder neu zu installieren brachte kein Erfolg, da die notwendige Datenbank

C:\Windows\WID\Data\SUSDB.mdf

durch die Deinstallation NICHT entfernt wird. D.h. nach der Neuinstallation des WSUS ist man an der gleichen Stelle.

Wenn man jetzt die o.g. Datebank einfach löscht, so bekommt man bei der Neuinstallation Fehlermeldungen.

In dem dazugehörigen Logfile steht dann auch die Ursache:

2016-06-02 11:37:26  Configuring WID database...
2016-06-02 11:37:26  Configuring the database...
2016-06-02 11:37:26  Establishing DB connection...
2016-06-02 11:37:26  Checking to see if database exists...
2016-06-02 11:37:26  Database exists
2016-06-02 11:37:26  Switching database to single user mode...
2016-06-02 11:37:27  System.Data.SqlClient.SqlException (0x80131904): Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'.
Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'.
Die SUSDB-Datenbank konnte nicht neu gestartet werden. Der vorherige Status wird wiederhergestellt.
Fehler bei der ALTER DATABASE-Anweisung.
Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch.
Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch.
   bei Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e)
   bei Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteCommandNoResult()
   bei Microsoft.UpdateServices.Administration.ConfigureDB.ConnectToDB()
   bei Microsoft.UpdateServices.Administration.ConfigureDB.Configure()
   bei Microsoft.UpdateServices.Administration.ConfigureDB.Run(String instanceName, Action`1 logWriter, Boolean contentLocal)
   bei Microsoft.UpdateServices.Administration.PostInstall.Run()
   bei Microsoft.UpdateServices.Administration.PostInstall.Execute(String[] arguments)
ClientConnectionId:5c9b6d98-4cbe-47eb-8465-f7fde71f8c4f
Fehlernummer (Error Number):5120,Status (State):101,Klasse (Class):16
Schwerwiegender Fehler: Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'.
Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'.
Die SUSDB-Datenbank konnte nicht neu gestartet werden. Der vorherige Status wird wiederhergestellt.
Fehler bei der ALTER DATABASE-Anweisung.
Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch.
Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch.

D.h. die eigentliche Konfiguration für den WSUS wurde wieder übernommen und jetzt fehlen natürlich die (gelöschten) Datenbanken.

Wie bekommet man also des WSUS dazu die Datenbank komplett neu zu erstellen?

  1. Man benötigt das MS SQL 2012 Management Studio Express, was man unter https://www.microsoft.com/de-de/download/details.aspx?id=29062 herunterladen kann.
  2. Das Programm installiet man und startet es explizit als Administrator!
  3. Man verbindet sich zu \\.\pipe\Microsoft##WID\tsql\query
  4. Dort löscht man dann die WSUS Datebank:

06-06-_2016_15-58-06

Wenn der Eintrag für die Datenbank gelöscht ist, startet man die WSUS Installation auf dem Server erneut – und siehe da – er startet die Komplette Konfiguration des WSUS erneut und legt die Datenbank komplett neu und sauber an!

 

Quellen:
https://en.wikipedia.org/wiki/Windows_Internal_Database

Move or Delete a WSUS 4 Windows Internal Database (WID) on Windows Server 2012

 

Office öffnet keine Dateien von Netzwerklaufwerken oder Onedrive

Auf einem Lenovo Thinkpad T450s mit Windows 10 hatte ich neulich folgendes Problem:

Sämtliche Office 2016 Programm konnten keine Dateien mehr öffnen wenn diese auf einem Netzwerk-Laufwerk oder auch OneDrive gespeichert waren. Nach dem Starten des Programms stürzte dieses sofort wieder ab und das Dokument wurde geschlossen.

Kopierte man die Datei jedoch auf die lokale Festplatte des Computers, konnte man diese auch normal öffnen.

Im Ereignisprotokoll stand jeweils:

Ereignis 1000, Application Error

Name der fehlerhaften Anwendung: WINWORD.EXE, Version: 16.0.6366.2056, Zeitstempel: 0x568f31f0
Name des fehlerhaften Moduls: ntdll.dll, Version: 10.0.10586.20, Zeitstempel: 0x5654262a
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0003ef53
ID des fehlerhaften Prozesses: 0x23b0
Startzeit der fehlerhaften Anwendung: 0x01d15b37ff9e51f1
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Microsoft Office\Root\Office16\WINWORD.EXE
Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll
Berichtskennung: 3de9f46e-c72b-11e5-9ccc-68f728db1328
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

Folgende Maßnahmen waren ohne Erfolg

  • Office Reparatur
  • Office De- und Neu-Installation
  • Installation aller aktueller Windows-Updates
  • Installation aller aktueller Office Updates

Ziel weisend für die Fehlerbehebung war schließlich folgender Microsoft KB Eintrag für Office 2013:

https://support.microsoft.com/de-de/kb/2813143

Und in der Tat war der Schuldige tatsächlich eine ältere Version der Displaylink-Software.

Nach der Deinstallation funktionierte Office 2016 wieder normal.

 

 

 

Fehlermeldung: Application Manager kann nicht ausgeführt werden.

Seit dem Update auf die Version 5.0.142.5 des Autodesk Application Manager erhalten die Benutzer nach dem Login folgende Fehlermeldung:

22-10-_2015_14-51-04
Fehlermeldung: Application Manager kann nicht ausgeführt werden.

Autodesk hat hierzu einen Eintrag in ihrer Knowledgebase mit einer vermeintlichen Lösung: http://knowledge.autodesk.com/de/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/DEU/Error-Unable-to-run-Application-Manager.html

Den Hinweis, man möge doch die Benutzerkontensteuerung doch einfach ausschalten kann aber nicht wirklich deren Ernst sein – oder ? Auch der Hinweis, man möge das Programm doch einfach als Administrator starten hilft einem nicht weiter, wenn die User eben dieses Recht nicht haben.

Das Problem ist nun aber, dass Autodesk dieses Programm beim Login jedes Users starten lässt und somit erhalten die User jedes mal eine schöne Fehlermeldung.

Im Programm selber kann man unter Einstellungen angeben, dass es bei Anmeldung am Computer nicht automatisch gestartet werden soll – aber auch das funktioniert nicht.

Meine Lösung: Ich schmeiße das Programm aus den Autostart.

Hierzu muss der Eintrag ADSKAppManager in der Registry der Rechner im Pfad

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run]

entfernen. Das kann man entweder lokal machen oder per Gruppenrichtlinie.

Danach haben die Benutzer Ruhe und die Admins können das Programm wenn nötig manuell starten.

Konfiguration von VPN Verbindungen unter Windows 10

Richtet man unter Windows 10 eine neue native VPN Verbindung ein – also mit Windows-Bordmitteln sozusagen – dann stellt man schnell fest, dass man nicht mehr an die TCP/IP Einstellungen der Verbindung herankommt.

Dieser „Bug“ wird u.a. auf Youtube hier gezeigt: https://www.youtube.com/watch?v=I3fjNpkB-EE

Das ist insofern ärgerlich, weil neue VPN Verbindung immer das Standard-Gateway aktiviert haben. D.h. wählt sich der  Benutzer ein, so gehen sofort alle Verbindungen nur noch über diese VPN Verbindung  – in der Praxis wird das selten gewünscht.

Möchte man nun eine solche „Split-Tunnel“ Konfiguration aber haben, so sind mir zur Zeit nur zwei Möglichkeiten bekannt.

a) Das Editieren der „rasphone.pbk“

oder besser

b) mit Powershell:

Set-VpnConnection -Name "NameVPNVerbindung" -SplitTunneling $True

Dies entfernt die Nutzung des Standard-Gateway der VPN-Verbindung.

 

 

 

Die VMRC-Konsole hat die Verbindung getrennt…

Neulich hatte ich bei einem VMWare ESXi 5.0 Server das Problem, dass ich auf keine VM-Konsole mehr zugreifen konnte. Bei jeder VM bekam ich den Fehler „Die VMRC-Konsole hat die Verbindung getrennt….“

27-07-_2015_13-58-38

Ich wusste aber, dass es mit dieser vSphere Client Installation schon funktioniert hat – und die Installation war auch schon älter.

Die gängigen Hilfmassnahmen die man im Netz findet (Neustart  VMWare Dienste, Neuinstallation des Clients) haben nicht geholfen.

Durch Zufall bin ich auf die Lösung gestossen – es lag an der VERSION des vSphere Client.  Der ESXi Server selber lotste mich immer zum Download http://vsphereclient.vmware.com/vsphereclient/6/2/3/3/7/3/VMware-viclient-all-5.0.0-623373.exe – aber diese Version „VMware vSphere Client 5.0 Update 1“ ist längst veraltet.

Glücklicherweise bietet VMWare eine Übersichtsseite für den Download der jeweils aktuellen Version der Client an:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2089791

Und dort fand ich auch die notwendige Version 5.0.0-1300600. Installiert – und schon gings wieder.

 

 

qvPDF unter Windows 8/8.1 – Fehlermeldung pdftk.exe funktioniert nicht mehr

Auf mehreren Windows 8.1 Systemen hatte ich neulich folgendes Problem:

Beim Erzeugen eines PDFs mit Hilfe von qvPDF bekamen die Anwender folgende Fehlermeldung:

09-04-_2015_12-53-49
pdftk.exe funktioniert nicht mehr

Wenn man die Fehlermeldung wegegklickt, kam qvPDF ganz normal hoch und man konnte das PDF abspeichern.  Die Fehlermeldung war jedoch nervig.

Im Ereignisprotokoll fand ich dann folgenden Eintrag:

Name der fehlerhaften Anwendung: pdftk.exe, Version: 0.0.0.0, Zeitstempel: 0x4cc9eed0
Name des fehlerhaften Moduls: libiconv2.dll, Version: 6.3.9600.17668, Zeitstempel: 0x54c846bb
Ausnahmecode: 0xc0000135
Fehleroffset: 0x0009e052
ID des fehlerhaften Prozesses: 0x2f94
Startzeit der fehlerhaften Anwendung: 0x01d072b373403526
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\qvPDF\pdftk.exe
Pfad des fehlerhaften Moduls: libiconv2.dll
Berichtskennung: b0f64aae-dea6-11e4-8375-0024d79e0a9c
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

Das interessante daran ist, dass sich auf dem PC das angeblich fehlerhafte Modul  libiconv2.dll gar nicht befand!

Diese Datei ist Bestandteil der Library libiconv (http://www.gnu.org/software/libiconv/).

Also habe ich die Library für Windows von http://gnuwin32.sourceforge.net/packages/libiconv.htm heruntergeladen und die Datei libiconv2.dll in das Verzeichnis C:\Program Files (x86)\qvPDF der betroffenen Computer kopiert.

Siehe da – die Fehlermeldung kommt nicht mehr.