Die Installation von Lexware reisekosten pro 2019 wurde durch einen Fehler beendet

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

Fehlerdetail: Beim Herunterladen der Dateien aus dem Internet ist ein Fehler aufgetreten. Bitte überprüfen Sie Ihre Internetverbindung und führen Sie den Vorgang erneut aus.

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!

 

 

Falsche CPU Auslastung bei Windows 10 durch 1809 Update

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

 

Veeam VSS Error nach Hyper-V zu VMWare Migration

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.

PermError (protection.outlook.com: domain of **** used an invalid SPF mechanism)

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;

Fritzbox 6490 im Bridge Modus (Fritz!OS 06.63)

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.

 

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